导读：本文与大家分享Pinterest在产品发展时的架构变迁与升级之路。

本文是总结我在查找相关资源时发现的最重要内容。

Pinterest 的发展路线图

Pinterest 的系统扩张历程可以分为四个不同的阶段：

• 发现自我的时代：这一阶段的特点是快速原型设计和不断发展的产品需求，这由一个小型工程团队管理。

• 试验时代：用户数量呈指数级增长，需要快速扩展，因此需要采用多种技术。然而，这导致了系统复杂，变得脆弱。

  
  

• 成熟期：此阶段涉及有意识地简化架构，专注于成熟、可扩展的技术，如 MySQL、Memcache 和 Redis。Pinterest 并没有增加额外技术堆栈，而是将资金投入到发展那些运行良好的技术上。

• 回归时代：有了正确的架构，Pinterest 只需水平扩展就能继续其增长轨迹，验证自己的选择。

让我们来看看，为什么这些技术在残酷的重新架构清除之后仍然“屹立不倒”。

核心技术：可扩展性的构建模块

Pinterest 优先考虑那些可靠、易于理解且能够随着用户群的增长而轻松扩展的技术。

让我们来深入研究这些技术：

• MySQL：一个强大而成熟的关系数据库管理系统，以其稳定性和广泛的用户社区而闻名。这确保了易于维护、故障排除和聘请熟悉该技术的工程师。最重要的是，它是我最喜欢的词：免费。

• Memcache：这是一个简单、高性能的系统，用于在内存中缓存经常访问的数据。Memcache 的简单性和可靠性使其成为卸载数据库读取的理想选择。它也是免费的。

• Redis：一种多功能数据存储，能够处理各种数据结构，并提供持久性和复制灵活性。这使得 Pinterest 能够根据数据敏感性自定义持久性策略。正如你能猜到的那样，这也是免费的。

• Solr：之所以选择它，是因为它可以快速使用。团队还“尝试过 Elastic Search，但以他们的规模，它无法处理大量小文档和大规模查询。”

集群与分片：如何扩展数据库

随着数据量激增，Pinterest 面临一个关键的选择：如何分配数据库来处理负载？

这出现了两种主要方法，每种方法都有各自的优点和缺点。

理解集群

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

集群的实际作用如下：

• 有新的数据到达时做分派

• 聚类算法确定该数据的最佳节点

• 数据在多个节点上复制以实现冗余

• 如果一个节点发生故障，其他节点将接管，从而确保数据可用性。

优势：

• 自动扩展：添加新节点会自动扩大容量。

• 易于设置：集群技术管理数据放置和分发，简化初始设置。

• 地理数据分布：集群可以分布在不同的地理位置，从而提高数据局部性和对数据中心中断的恢复能力。

• 高可用性：数据复制和自动故障转移确保，即使单个节点发生故障也能持续运行。

• 负载平衡：工作负载分布在各个节点，防止任何单个节点不堪重负。

缺点：

• 复杂性：集群引入了节点之间的复杂交互，使故障排除和维护更加困难。

• 成熟度：Pinterest 做出此决定时，成熟的集群技术有限，导致经验丰富的工程师和社区支持较少。

• 升级挑战：由于需要跨多个节点进行协调更改，因此升级集群可能很复杂。

• 单点故障：负责协调活动的集群管理算法可能成为单点故障。此算法出现问题可能会影响整个集群。

理解分片

想象一下将数据分成更小的块，并将每个块放在单独的独立服务器上。这就是数据分片/分区。应用程序不再依赖自动协调，而是确定数据所在的位置并相应地路由查询。

分片实际操作：

• 数据根据特定标准（例如用户 ID）进行分区。

• 每个分区（分片）都位于专用服务器上。

• 应用程序确定给定查询的正确分片。

• 分片内的数据可以被复制以实现高可用性。

优势：

• 更简单的架构：分片消除了节点间通信和自动数据分发的复杂性，从而使系统更易于理解和管理。

• 独立扩展：各个分片可以独立扩展，从而提供对资源分配更精细的控制。

• 明确的数据所有权：每个分片对特定的数据子集都有明确的责任，消除了集群中可能出现的所有权模糊性。

• 简化算法：数据放置逻辑比复杂的集群管理算法简单得多，从而降低了发生灾难性故障的可能性。

缺点：

• 没有数据库级连接：由于数据分布在多个分片中，因此跨不同分片执行连接变得具有挑战性。这通常需要对数据进行非规范化或在应用程序层内执行连接。

• 没有数据库级事务：无法进行跨越多个分片的事务，需要应用程序级逻辑来维护数据的一致性和完整性。

• 增加了应用程序的复杂性：应用程序必须处理分片路由并管理跨分片的数据一致性，这增加了开发过程的复杂性。

• 模式更改更为复杂：修改数据库模式需要将更改应用于所有单独的分片。

• 报告复杂性：生成跨多个分片的报告需要从每个分片检索数据并手动汇总结果。

Pinterest 为什么选择分片

Pinterest 选择分片而不是集群，是因为分片相对简单，而且他们在“实验时代”使用集群时有过负面经历。

人们正面临着：

• 集群管理问题：集群管理算法中的错误导致多次中断，并且很难排除故障。

• 数据重新平衡问题：自动重新平衡可能会导致性能瓶颈和数据不一致问题。

• 数据所有权混淆：有时，辅助节点会错误地承担主节点的角色，从而导致数据的丢失。“有一次，他们引入了一个新的辅助节点。当节点达到 80% 左右时，辅助节点会说它是主节点，而主节点会变成辅助节点，这样你就丢失了 20% 的数据。丢失 20% 的数据比丢失所有数据更糟糕，因为你不知道自己丢失了什么。”

分片提供了一种更可预测且更易于管理的方法。他们愿意牺牲一些数据库级别的功能（如连接和事务）来换取应用程序级别的控制力与简易性。

迁移到分片架构

向分片的转变并不是瞬间发生的。

Pinterest 采取了分阶段的方法，在功能冻结期间精心执行，以最大限度地减少对用户的影响：

• 消除连接：所有 MySQL 连接均被删除，因此需要对数据进行非规范化，并增加对缓存的依赖以保持性能。积极增加的缓存有助于弥补丢失连接和查询多个分片的需求对性能的影响。

• 基于 ID 的分片：最后阶段涉及基于 64 位 ID 的分片。此 ID 嵌入了分片位置，从而无需单独的查找表并简化了数据路由。“用户的所有数据（图钉、图板等）都位于同一个分片上。巨大的优势例如，呈现用户个人资料不需要多个跨分片查询。它的速度也很快。 ”

这种分阶段的方法，允许在每个阶段逐步实施，并进行彻底验证。

分片的代价：缺点和解决方案

虽然分片提供了一种更易于管理的方法，但它也给 Pinterest 带来了一些挑战：

• 迁移脚本：将大量数据传输到分片基础设施比预期的要耗费更多时间，这凸显了对强大的脚本工具和流程的需求。

• 应用程序逻辑：缺乏数据库级连接和事务，要求开发人员实现在应用程序层内维护数据一致性和完整性的逻辑。

• 模式修改：更改数据库模式需要仔细规划并在所有分片中应用更改。

• 报告障碍：跨多个分片生成报告需要额外的步骤来汇总每个分片的结果。

收获智慧：Pinterest 发展历程中的关键经验

Pinterest 的扩张历程将为任何构建增长系统的人士，提供了宝贵的经验教训：

• 简单是关键：选择简单易懂的技术可以简化故障排除，并且降低不可预见问题的风险。

• 优先考虑可扩展性：愿意为了可扩展性而牺牲一些数据库功能，特别是在快速增长的环境中。

• 水平增长设计：选择一种允许你随着用户群扩大，而添加更多资源的架构。

结语

通过拥抱简单性、强调可扩展性以及从实践经验中学习，Pinterest 成功应对了爆炸式增长带来的挑战。

他们的故事是我们在构建和扩展高性能分布式系统时的宝贵案例与研究典范。

作者：洛逸

参考：

https://www.youtube.com/watch?v=QRlP6BI1PFA