翻译：Pinterest如何仅用6名程序员就支撑1100万月活用户？

欢迎大家来到IT世界,在知识的湖畔探索吧!

背景

本文原文地址：https://read.engineerscodex.com/p/how-pinterest-scaled-to-11-million

原文是基于 Pinterest 团队于 2012 年发表的演讲 Scaling Pinterest。

2012 年 1 月，Pinterest 仅用 6 名程序员就达到了 1170 万月活用户。

该公司于 2010 年 3 月推出，是当时月用户突破 1000 万最快的公司。

缤趣Pinterest创立于2008年，总部位于美国加州旧金山，主打图片社交分享，是世界上超过2.5亿人为他们的生活获取灵感的地方。

欢迎大家来到IT世界,在知识的湖畔探索吧!

股票走势：

扩展Pinterest服务的经验教训

• 使用已知的、经过验证的技术。Pinterest 当时对新技术的投入导致了数据损坏等问题。
• 把事情简单化。
• 不要太有创意，研发团队确定了一种可以添加更多相同节点来扩展的架构。
• 限制你的选择。
• 数据库分片 优先于 集群，因为它减少了节点之间的数据传输。

2010 年 3 月：内测启动，1 名程序员

Pinterest 于 2010 年 3 月推出，拥有 1 个小型 MySQL 数据库、1 个小型 Web 服务器和 1 名程序员（以及 2 名联合创始人）。

2011 年 1 月：10,000 名用户，2 名程序员

九个月后，即 2011 年 1 月，Pinterest 的架构已经发展到可以处理更多用户。他们仍然仅限受邀者参加，这时有了 2 名程序员。

They had: 他们有：

• 基本的 Web 服务器（Amazon EC2、S3 和 CloudFront）
• Django (Python) 作为他们的后端
• 4 个 Web 服务器用于容灾
• NGINX 作为他们的反向代理和负载均衡器。
• 此时有 1 个 MySQL 写数据库 + 1 个只读数据库
• 用于计数器的 MongoDB
• 1 个任务队列和 2 个用于异步任务的任务处理器

2011 年 10 月：320 万用户，3 名程序员

从2011年1月到2011年10月，Pinterest增长极其迅速，每个半月用户数量就翻一番。

他们于 2011 年 3 月推出的 iPhone APP是推动这一增长的因素之一。

当事物快速发展时，技术出现故障的频率会超出您的预期。

Pinterest 犯了一个错误：他们的架构过于复杂化了。

他们只有 3 名程序员，但他们的数据却有 5 种不同的数据库技术。

他们都手动对 MySQL 数据库进行分片，并使用 Cassandra 和 Membase（现在的 Couchbase）对数据进行集群。

“过于复杂的技术栈”：

• •Web 服务器堆栈（EC2 + S3 + CloudFront）
• Pinterest 开始转向 Flask (Python) 作为后端
• 16 个Web服务器
• 2个API引擎
• 2 个 NGINX 代理
• 5 个手动分片的 MySQL 数据库 + 9 个只读辅助数据库
• 4 个 Cassandra 节点
• 15 个 Membase 节点（3 个独立集群）
• 8 个Memcache内存缓存节点
• 10 个 Redis 节点
• 3 个任务路由器 + 4 个任务处理器
• 4个Elastic Search节点
• 3个Mongo集群

集群崩了

数据库集群是将多个数据库服务器连接起来作为单个系统一起工作的过程。

理论上，集群可以自动扩展数据存储，提供高可用性、免费负载平衡，并且不存在单点故障。

不幸的是，在实践中，集群过于复杂，升级机制困难，并且存在很大的单点故障。

每个数据库都有一个从数据库路由到数据库的集群管理算法。

当数据库出现问题时，会添加一个新的数据库来替换它。

理论上，集群管理算法应该可以很好地处理这个问题。

事实上，Pinterest 的集群管理算法存在一个错误，该错误破坏了所有节点上的数据，破坏了数据重新平衡，并造成了一些无法修复的问题。

Pinterest 的解决方案？从系统中删除所有集群技术（Cassandra、Membase）。全力使用 MySQL + Memcached（经过验证）。

MySQL 和 Memcached 是经过充分验证的技术。Facebook 利用两者创建了世界上最大的 Memcached 系统，该系统每秒可以轻松处理数十亿个请求。

2012年1月：1100万用户，6名程序员

2012 年 1 月，Pinterest 每月处理约 1100 万活跃用户，其中每日用户数量在 1200 万到 2100 万之间。

此时，Pinterest 已花时间简化其架构。

他们删除了当时不太成熟的想法，例如集群和 Cassandra，并用经过验证的想法取而代之，例如 MySQL、Memcache 和分片sharding。

他们的简化后的技术栈：

• Amazon EC2 + S3 + Akamai（取代 CloudFront）
• AWS ELB（弹性负载均衡）
• 90 个 Web 引擎 + 50 个 API 引擎（使用 Flask）
• 66 个 MySQL 写数据库 + 66 个只读数据库
• 59 个 Redis 实例
• 51 个内存缓存实例
• 1 个 Redis 任务管理器 + 25 个任务处理器
• Apache Solr（取代 Elasticsearch）
• 删除了 Cassanda、Membase、Elasticsearch、MongoDB、NGINX

如何手动分片数据库

数据库分片Database sharding是一种将单个数据集拆分为多个数据库的方法。

优点：高可用性、负载均衡、放置数据的算法简单、易于拆分数据库以添加更多容量、易于定位数据

当 Pinterest 第一次对数据库进行分片时，他们的功能被冻结了。在几个月的时间里，他们手动增量地对数据库进行了分片：

研发团队从数据库层删除了表Join和复杂查询。他们添加了大量缓存。

由于维护跨数据库的独特约束需要付出额外的努力，因此他们将用户名和电子邮件等数据保存在一个巨大的、未分片的数据库中。

他们所有的table都存在于他们的所有分片上。

手动分片的一个小例子

由于他们有数十亿个“pin”，他们的数据库索引耗尽了内存。

他们将获取数据库中最大的表并将其移动到自己的数据库中。

然后，当该数据库空间不足时，它们就会分片。

2012 年 10 月：2200 万用户，40 名程序员

2012 年 10 月，Pinterest 每月约有 2200 万用户，其工程团队的程序员数量增加了四倍，达到 40 名。

架构是一样的。他们只是添加了更多相同的系统。

• • Amazon EC2 + S3 + CDN（EdgeCast、Akamai、Level 3)
• • 180 个 Web 服务器 + 240 个 API 引擎（使用 Flask）
• • 88 个 MySQL DB + 88 个只读数据库
• • 110 个 Redis 实例
• • 200 个 Memcache 实例
• • 4 个 Redis 任务管理器 + 80 个任务处理器
• • Sharded Apache Solr

他们开始从HDD转向SSD。

一个重要的教训是：有限的、经过验证的选择是一件好事。

坚持使用 EC2 和 S3 意味着他们的配置选择有限，从而减少麻烦并变得更加简单。

但是，新实例可能会在几秒钟内准备就绪。这意味着他们可以在几分钟内添加 10 个 Memcache 实例。

Pinterest 的数据库结构ID

与 Instagram 一样，Pinterest 也有独特的 ID 结构，因为它们有分片数据库。

他们的 64 位 ID 如下所示：

Shard ID：哪个分片 (16 bits)

Type：对象类型，例如pin（10位）

Local ID：表中的位置 (38位)

这些 ID 的查找结构是一个简单的 Python 字典。

Tables

他们有对象表和映射表。对象表用于pins, boards, comments, users等。他们有一个映射到 MySQL blob（例如 JSON） 的本地 ID。

映射表用于对象之间的关系数据，例如将boards映射到用户或将点赞映射到pin。

他们有一个完整 ID 映射到一个完整 ID 和一个时间戳。

为了提高效率，所有查询都是 PK（主键）或索引查找。他们删除了所有的 JOIN。