Pinterest如何用仅6名工程师扩展至1100万用户

最近我看到一段非常出色的 YouTube 视频，“Pinterest 如何仅用 6 名工程师就扩展至 1100 万用户的故事” 和其引用的文章，[“Pinterest 的扩展之路 —— 在两年内，每月页面浏览量达到数十亿次” ]。这些都是非常不错的系统设计学习资源，强烈推荐大家去看看。本文将总结我在研究这些资料时发现的最重要的一点。

加入15万科技领袖的行列，通过我的免费通讯《AI简明》订阅号直接了解人工智能领域最重要的思想](https://artificialintelligencemadesimple.substack.com/)

Pinterest的发展历程可以划分为四个不同的阶段：

• 自我发现的时代： 这一阶段的特点是快速原型迭代和不断变化的产品需求，由一个小型工程团队来管理。
• 实验期： 用户数量的指数级增长要求快速扩展，导致采用了各种技术。然而，这导致了一个复杂而脆弱的系统。

• 成熟阶段：这一阶段涉及对其架构有意识地简化，专注于成熟和可扩展的技术，例如 MySQL、Memcache 和 Redis。Pinterest 没有增加技术栈的内容，而是将资金投入到这些运行良好的技术上。

• 回归时代: 拥有了适合的架构，Pinterest 通过横向扩展继续增长，证明了其选择是正确的。

我们来看看为什么这些技术在残酷的架构重组后仍然存在。

Pinterest优先使用了可靠、易于理解和能轻松扩展以适应不断增加的用户的技术。让我们来看看这些技术：

• MySQL: 一个健壮而成熟的关系型数据库管理系统，以其稳定性和广泛的用户社区而著称。这确保了易于维护、故障排除以及招聘熟悉该技术的工程师。最重要的是，它是我最喜欢的 F-词：免费。
• Memcache: 这是一个简单、高性能的内存缓存系统，用于缓存频繁访问的数据。Memcache 的简单性和可靠性使其非常适合减少数据库读取压力。同样也是免费的。
• Redis: 一个多功能的数据存储系统，能够处理多种数据结构，并提供在持久化和复制方面的灵活性。这使得 Pinterest 能够根据数据敏感性自定义持久化策略。显然，这也是免费的。
• Solr: 由于可以快速使用而被选中。团队也尝试了 Elastic Search，但在他们这个规模下，它在处理大量小文档和大量查询时遇到了麻烦。

随着数据量的急剧增长，Pinterest 面临了一个关键的抉择：它将如何分发其数据库以应对负载增长？出现了两种主要的方法，每种方法各有其利弊。

“数据库集群是指将多个数据库实例或服务器连接到您的系统的过程。在大多数常见的数据库集群中，多个数据库实例通常情况下由一个称为主服务器的数据库服务器管理。”

来源（原文）

聚类行动:

• 来了一个新的数据点。
• 聚类算法决定把这个数据点放在最佳位置。
• 数据会在多个节点上复制，以确保冗余。
• 如果某个节点挂了，其他节点会接手，保证数据依然可用。

福利:

• 自动扩展: 添加新节点时容量会自动扩展。
• 轻松部署: 集群技术管理数据放置和分布，简化了初始设置。
• 地理位置数据分布: 集群可以分布在不同的地理位置，提高数据本地化效率，并且增强了数据中心故障的恢复能力。
• 高可用性: 数据复制和自动故障转移确保即使单个节点发生故障也能持续运行。
• 负载均衡: 工作负载在节点之间分布，防止任何节点过载。

缺点：

• 复杂性: 建立集群会增加节点间的复杂互动，从而使故障排查和维护更加困难。
• 成熟度: 当Pinterest做出这个决定时，成熟的集群技术还不成熟，导致有经验的工程师和社区支持不足。
• 升级挑战: 由于需要对多个节点进行协调更改，升级集群变得复杂。
• 单点故障: 负责协调活动的集群管理算法可能成为单点故障。若该算法出问题，可能会影响整个集群。

想象把你的数据分成更小的部分，并将每一部分放在一个单独的服务器上。这就是所谓的分片。应用程序不再依赖自动协调，而是自行决定数据的位置，并相应地将查询路由到适当的位置。

分片的实际应用:

• 数据是根据特定标准（如用户ID）进行分割的。
• 每个分片都驻留在专用服务器上。
• 应用程序根据给定查询确定正确的分片。
• 分片内的数据可以复制以确保高可用性。

福利:

• 更简单的架构设计: 简化了节点间通信和数据自动分布的复杂过程，从而形成一个更易于理解和管理的系统。
• 每个分片都可以独立扩展: 提供更灵活的资源分配控制。
• 清晰的数据所有权: 每个分片都明确负责特定数据子集，消除了集群中数据所有权的不确定性。
• 简化的算法: 数据放置的逻辑比复杂的集群管理算法简单很多，降低了灾难性故障的风险。

需要注意的地方:

• 无法在数据库级别执行跨分片连接： 跨分片执行连接变得困难。这通常需要反规范化数据或在应用层执行连接操作。
• 无法在数据库级别实现跨越多个分片的事务： 需要应用层逻辑来确保数据一致性和完整性。
• 使应用更加复杂： 应用程序必须处理分片路由。
• 修改数据库模式更加复杂： 需要为每个分片单独修改数据库模式。
• 生成跨越多个分片的报告： 需要从每个分片获取数据并手动聚合结果。

Pinterest选择了分片而非集群作为其数据存储架构，因为分片相对简单，并且他们在“实验时代”使用集群时有过负面经验。

• 集群管理问题： 集群管理算法中的错误导致多次宕机，并且这些故障难以排查。
• 数据均衡问题： 自动均衡可能导致性能瓶颈和数据一致性问题。
• 数据所有权混淆： 在某些情况下，备节点错误地认为自己是主节点，导致数据丢失。“ 达到大约80%时，这个新的备节点声称自己是主节点，而真正的主节点变成了备节点，这时你已经丢失了20%的数据。丢失20%的数据比全部丢失更糟糕，因为你不知道丢失了哪些具体数据”。

分片提供了一种更易于预测和管理的方法。他们愿意为了在应用层面增加控制和简化而放弃一些数据库级别的特性，比如连接查询和事务。

转换到分片模式并不是瞬间完成的。Pinterest采取了分阶段的方法进行转换，在功能冻结期间仔细执行以减少对用户的影响。

1. 消除连接操作: 所有 MySQL 的连接操作都被移除，这需要对数据进行去规范化处理，并增加了对缓存的依赖程度以保持性能。激进的缓存策略帮助弥补了因失去连接操作而导致的性能影响以及需要查询多个分片的需求。
2. 基于 ID 的分片: 这一最终阶段涉及根据一个 64 位 ID 进行分片。该 ID 包含了分片位置信息，消除了单独查找表的需求，并简化了数据路由过程。“ 用户的数据（如图钉、板块等）都位于同一个分片上。这带来了巨大的优势。例如，渲染用户资料时无需进行多次跨分片查询。非常快。 ”

这种方法分阶段进行，使得每个阶段都能逐步推进并彻底检验。

尽管分片提供了一种更易管理的方法，但它也带来了Pinterest需要应对的几个挑战：

• 迁移脚本: 将大量数据迁移到分片架构上比预期的要耗时得多，凸显了对强大脚本工具和流程的迫切需求。
• 应用程序逻辑: 缺乏数据库级别的连接和事务，要求开发人员在应用层实现逻辑来确保数据的一致性和完整性。
• 模式修改: 修改数据库模式需要仔细规划并在所有分片上应用更改。
• 报告障碍: 跨多个分片生成报告需要额外步骤来汇总每个分片的数据。

Pinterest在增长过程中的经验对于任何正在构建增长系统的架构师来说提供了宝贵的经验和教训。

• 简洁至上: 选择简单且易于理解的技术，这可以简化故障排查，降低出现意外问题的风险。
• 优先考虑可扩展性: 在快速发展的环境中，有时需要牺牲一些数据库功能，优先考虑可扩展性。
• 为横向扩展而设计: 要为横向扩展设计架构，以便在用户基数扩大时可以轻松增加更多资源。

通过追求简约，重视可扩展性，并吸取经验，Pinterest 成功地应对了快速增长的挑战。他们的故事为构建和扩展高性能的分布式系统提供了宝贵的参考案例。

准备开始简单的技术旅程了吗？订阅《技术简明》获取清晰实用的建议，提升你的技术能力和职业发展。不用再花时间在无穷无尽的教程上——在这里你就能找到你需要的所有东西。

特别优惠！ 首年立减20%！

• 月套餐: 640 卢比 (8 美元) [原价为 800 卢比]
• 年套餐: 6400 卢比 (80 美元) [原价为 8000 卢比]

仍然犹豫不决？ 尝试我们的无忧保障，我们提供6个月的无条件退款保证期。不满意就全额退款，无需任何理由！只需给我发个消息就好。

点击下面的链接看看我的其他内容，了解更多关于辅导的信息，有关项目可以联系我，或者只是打个招呼就好。

关于科技、AI和机器学习的小贴士：

AI通讯- https://artificialintelligencemadesimple.substack.com/

我奶奶最爱的科技通讯简报- https://codinginterviewsmadesimple.substack.com/

你可以看看我在 Medium 上发表的其他文章哦：链接，点赞关注哦。

我的YouTube频道: [https://rb.gy/88iwdd]

跟我LinkedIn上联系，让我们连接：点击这里连接我：https://rb.gy/m5ok2y

我的Instagram账号：（https://rb.gy/gmvuy9）

我的推特：https://twitter.com/Machine01776819