Pinterest谈实战经验：如何在两年内实现零到数百亿的月访问

绝地灬酷狼 2022-08-04 04:30 117阅读 0赞

Pinterest一直保持着指数增长，每一个半月都会翻一翻。在两年内，他们实现了从0到数百亿的月PV；从开始的两个创始人加一个工程师增长到现在超过40个工程师，从一个小型的MySQL服务器增长到180个Web Enigne、240个API Enigne、88个MySQL DB（cc2.8xlarge，每个DB都会配置一个从属节点）、110个Redis Instance以及200个Mmecache Instance。

在一个名为 [**《Scaling Pinterest》** ][Scaling Pinterest]的主题演讲上，Pinterest的[Yashwanth Nelapati][]和 [Marty Weiner][]为我们讲述了这个戏剧性的过程。当然扩展到当下规模，Pinterest在众多选择中不可避免的走了许多的弯路，而Todd Hoff认为其中最宝贵的经验该归结于以下两点：

1.  如果你的架构应对增长所带来的问题时，只需要简单的投入更多的主机，那么你的架构含金量十足。
2.  当你把事物用至极限时，这些技术都会以各自不同的方式发生故障，这导致他们对工具的选择有着特殊的偏好：成熟、简单、优秀、知名、被更多的用户喜爱、更好的支持、稳定且杰出的表现、通常情况下无故障以及免费。使用这些标准，他们选择了MySQL、Solr、Memcache、Redis、Cassandra，同时还抛弃了MongoDB。

同样这两个点是有关联的，符合第二个原则的工具就可以通过投入更多的主机进行扩展。即使负载的增加，项目也不会出现很多故障。即使真的出现难以解决的问题，至少有一个社区去寻找问题解决的方案。一旦你选择过于复杂和挑剔的工具，在扩展的道路上将充满荆棘。

需要注意的是所有他们选择的工具都依靠增加分片来进行扩展，而非通过集群。讲话中还阐述了为什么分片优于集群以及如何进行分片，这些想法可能是之前你闻所未闻的。

**下面就看一下Pinterest扩展的阶段性时间轴：**

**项目背景**

*  Pins是由其它零零碎碎信息集合成的图片，显示了对客户重要的信息，并且链接到它所在的位置。
 *  Pinterest是一个社交网络，你可以follow（关注）其他人以及board。
 *  数据库：Pinterest的用户拥有board，而每个board都包含pin；follow及repin人际关系、验证信息。

**1. 2010年3月发布——寻找真我的时代**

在那时候，你甚至不知道需要建立一个什么样的产品。你有想法，所以你快速的迭代以及演变。而最终你将得到一些很小的MySQL查询，而这些查询在现实生活中你从未进行过。

Pinterest初期阶段的一些数字：

*  2个创始人
 *  1个工程师
 *  Rackspace
 *  1个小的网络引擎
 *  1个小的MySQL数据库
 *  2011年11月

仍然是小规模，产品通过用户反馈进行演变后的数字是：

*  Amazon EC2 + S3 + CloudFront
 *  1 NGinX, 4 Web Engines (用于冗余，不全是负载)
 *  1 MySQL DB + 1 Read Slave (用于主节点故障情况)
 *  1 Task Queue + 2 Task Processors
 *  1 MongoDB (用于计数)
 *  2 Engineers

**2. 贯穿2011年——实验的时代**

迈上疯狂增长的脚步，基本上每1个半月翻一翻。

*  当你增长的如此之快，每一天每一星期你可能都需要打破或者抛弃一些东西。
 *  在这个时候，他们阅读大量的论文，这些论文都阐述着只需要添加一台主机问题就会得以解决。他们着手添加许多技术，随后又不得不放弃。
 *  于是出现了一些很奇怪的结果 ：

*  Amazon EC2 + S3 + CloudFront
 *  2NGinX, 16 Web Engines + 2 API Engines
 *  5 Functionally Sharged MySQL DB + 9 read slaves
 *  4 Cassandra Nodes
 *  15 Membase Nodes (3 separate clusters)
 *  8 Memcache Nodes
 *  10 Redis Nodes
 *  3 Task Routers + 4 Task Processors
 *  4 Elastic Search Nodes
 *  3 Mongo Clusters
 *  3个工程师

*  5个主数据库技术，只为了独立其中的数据。
 *  增长太快以至于MySQL疲于奔命，所有其它的技术也达到了极限。
 *  当你把事物用至极限时，这些技术都会以各自不同的方式出错。
 *  开始抛弃一些技术，并且自我反省究竟需要些什么，基本上重做了所有的架构。

**3. 2012年2月——成熟的时代**

*  在重做了所有的架构后，系统呈现了如下状态

*  Amazon EC2 + S3 + Akamai, ELB
 *  90 Web Engines + 50 API Engines
 *  66 MySQL DBs (m1.xlarge) +，每个数据库都配备了从属节点
 *  59 Redis Instances
 *  51 Memcache Instances
 *  1 Redis Task Manager + 25 Task Processors
 *  Sharded Solr
 *  6个工程师

*  现在采用的技术是被分片的MySQL、Redis、Memcache和Solr，有点在于这些技术都很简单很成熟。
 *  网络传输增长仍然保持着以往的速度，而iPhone传输开始走高。

**4. 2012年10月12日 —— 收获的季节**

大约是1月份的4倍

*  现在的数据是：

*  Amazon EC2 + S3 + Edge Cast,Akamai, Level 3
 *  180 Web Engines + 240 API Engines
 *  88 MySQL DBs (cc2.8xlarge) ，同样每个数据库都有一个从属节点
 *  110 Redis Instances
 *  200 Memcache Instances
 *  4 Redis Task Manager + 80 Task Processors
 *  Sharded Solr
 *  40个工程师（仍在增长）

*  需要注意的是，如今的架构已趋近完美，应对增长只需要投入更多的主机。
 *  当下已开始转移至SSD

--------------------

**下面一览该演讲中的干货，决策的制定：**

**为什么会选择EC2和S3**

1.  相当好的可靠性，即使数据中心发生故障。多租户会增加风险，但是也不是太坏。
2.  良好的报告和支持。它们（EC2和S3）有着良好的架构，并且知道问题所在。
3.  完善的周边设施，特别是在你需要快速增长时。你可以从APP Engine处获得maged cache、负载均衡、MapReduce、数据库管理以及其它你不想自己动手编写的组件，这可以加速你应用程序的部署，而在你工程师空闲时，你可以着手编写你需要的一切。
4.  新的实例可以在几秒内就绪，这就是云的力量；特别是在只有两个工程师的初期，不需要去担心容量规划，更不需要花两个星期去建立自己的Memcache，你可以在数分钟内添加10个Memcached。
5.  缺点：有限的选择。直到最近，才可以选择使用SSD，同时无法获得太大的内存配置。
6.  优点：你不需要给大量的主机进行不同的配置。

**为什么会选择MySQL**

1.  非常成熟。
2.  非常稳定。不会宕机，并且不会丢失数据。
3.  在招聘上具有优势，市场上有大把的人才。
4.  在请求呈直线上升时，仍能将相应时间控制在一定的范围内，有些数据库技术在面对请求的飙升时表现并不是很好。
5.  非常好的周边软件支持——XtraBackup、Innotop、Maatkit。
6.  可以从类似Percona这样的公司得到优秀的技术支持。
7.  开源（免费）——这一点非常重要，特别是在资金缺乏的初期

**为什么使用Memcache**

*  非常成熟。
 *  非常简单。可以当成是一个socket哈希表
 *  杰出稳定的表现
 *  知名并为大量用户喜爱
 *  永不崩溃
 *  开源

**为什么选择Redis**

*  虽然还不够成熟，但是非常简单及优秀
 *  提供了大量的数据结构类型
 *  提供多种的选择进行持久化和备份：你可以备份而非持久化，选择备份的话你还可以选择多久备份一次；同样你还可以选择使用什么方式进行持久化，比如MySQL等。

*  Home feed被储存在Redis上，每3个小时保存一次；然而并不是3个小时持久化一次，只是简单的每3个小时备份一次。
 *  如果你存储数据的主机发生故障，丢失的也只是备份周期内的数据。虽然不是完全可靠，但是非常简单。避免了复杂的持久化及复制，这样的架构简单且便宜。

*  知名并为大量用户喜爱
 *  稳定且杰出的表现
 *  很少出故障。有一些专有的故障模型，你需要学会解决。这也是成熟的优势，只需要学习就可以解决。
 *  开源

**Solr**

1.  只需要几分钟的安装时间，就可以投入使用
2.  不能扩展到多于一台的机器上（最新版本并非如此）
3.  尝试弹性搜索，但是以Pinterest的规模来说，可能会因为零碎文件和查询太多而产生问题。
4.  选择使用Websolr，但是Pinterest拥有搜索团队，将来可能会开发自己的版本。

**集群vs.分片**

*  在迅速扩展的过程中，Pinterest认识到每次负载的增加，都需要均匀的传播他们的数据。
 *  针对问题先确定解决方案的范围，他们选择的范围是集群和分片之间的一系列解决方案。

**集群——所有的操作都是通过自动化**

*  比如：Cassandra、MemBase、HBase
 *  结论：没有安全感，将来可能会比较成熟，但是当下这个解决方案中还存在太多的复杂性和故障点。
 *  特性：

*  数据自动分布
 *  节点间转移数据
 *  需要平衡分配
 *  节点间的相互通信，需要做很多措施用于防止干扰、无效传递及协商。

*  优点：

*  自动扩展你的数据存储，最起码论文中是这么说的。
 *  便于安装
 *  数据上的空间分布及机房共置。你可以在不同区域建立数据中心，数据库会帮你打理好一切。
 *  高有效性
 *  负载平衡
 *  不存在单点故障

*  缺点：

*  仍然不成熟。
 *  本质上说还很复杂。一大堆的节点必须对称协议，这一点非常难以解决。
 *  缺少社区支持。社区的讨论因为产品方向的不同而不能统一，而在每个正营中也缺乏强有力的支持。
 *  缺乏领域内资深工程师，可能大多数的工程师都还未使用过Cassandra。
 *  困难、没有安全感的机制更新。这可能是因为这些技术都使用API并且只在自己的领域内通行，这导致了复杂的升级路径。
 *  集群管理算法本身就用于处理SPOF（单点故障），如果存在漏洞的话可能就会影响到每个节点。
 *  集群管理器代码非常复杂，并且需要在所有节点上重复，这就可能存在以下的故障模式：

*  数据平衡失控。当给集群中添加新的主机时，可能因为数据的拷贝而导致集群性能下降。那么你该做什么？这里不存在去发现问题所在的工具。没有社区可以用来求助，同样你也被困住了，这也是Pinterest回到MySQL的原因。
 *  跨节点的数据损坏。如果这里存在一个漏洞，这个漏洞可能会影响节点间的日志系统和压缩等其它组件？你的读延时增加，所有的数据都会陷入麻烦以及丢失。
 *  错误负载平衡很难被修复，这个现象十分普遍。如果你有10个节点，并且你注意到所有的负载都被堆积到一个节点上。虽然可以手动处理，但是之后系统还会将负载都加之一个节点之上。
 *  数据所有权问题，主次节点转换时的数据丢失。集群方案是非常智能的，它们会在特定的情况下完成节点权利的转换，而主次节点切换的过程中可能会导致数据的部分丢失，而丢失部分数据可能比丢失全部还糟糕，因为你不可能知道你究竟丢失了哪一部分。

**分片——所有事情都是手动的**

*  结论：它是获胜者。Todd Hoff还认为他们的分片架构可能与[Flickr架构][Flickr]类似。
 *  特性：

*  分片可以让你摆脱集群方案中所有不想要的特性。
 *  数据需要手动的分配。
 *  数据不会移动。Pinterest永远都不会在节点间移动，尽管有些人这么做，这让他们在一定范围内站的更高。
 *  通过分割数据的方式分配负载。
 *  节点并没有互相通信，使用一些主节点控制程序的运行。

*  优点：

*  可以分割你的数据库以提高性能。
 *  空间分布及放置数据
 *  高有效性
 *  负载平衡
 *  放置数据的算法非常简单。主要原因是，用于处理单点故障的代码只有区区的半页，而不是一个复杂的集群管理器。并且经过短暂的测试就知道它是否能够正常工作。
 *  ID生成非常简单

*  缺点：

*  不可以执行大多数的join。
 *  失去所有事务的能力。在一个数据库上的插入可能会成功，而在另一个上会失败。
 *  许多约束必须放到应用程序层。
 *  模式的转变需要从长计议。
 *  报告需要在所有分片上执行查询，然后需要手动的进行聚合。
 *  Join在应用程序层执行。
 *  应用程序必须容忍以上所有问题。

**什么时候进行分片**

1.  如果你的项目拥有PB级的数据，那么你需要立刻对其进行分片。
2.  Pin表格拥有百万行索引，索引大小已经溢出内存并被存入了磁盘。
3.  Pinterest使用了最大的表格，并将它们（这些索引）放入自己的数据库。
4.  然后果断的超过了单数据库容量。
5.  接着Pinterest必须进行分片。

**分片的过渡**

*  过渡从一个特性的冻结开始。
 *  确认分片该达到什么样的效果——希望尽少的执行查询以及最少数量的数据库去呈现一个页面。
 *  剔除所有的MySQL join，将要做join的表格加载到一个单独的分片去做查询。
 *  添加大量的缓存，基本上每个查询都需要被缓存。
 *  这个步骤看起来像：

*  1 DB + Foreign Keys + Joins
 *  1 DB + Denormalized + Cache
 *  1 DB + Read Slaves + Cache
 *  Several functionally sharded DBs+Read Slaves+Cache
 *  ID sharded DBs + Backup slaves + cache

*  早期的只读从属节点一直都存在问题，因为存在slave lag。读任务分配给了从属节点，然而主节点并没有做任何的备份记录，这样就像一条记录丢失。之后Pinterest使用缓存解决了这个问题。
 *  Pinterest拥有后台脚本，数据库使用它来做备份。检查完整性约束、引用。
 *  用户表并不进行分片。Pinterest只是使用了一个大型的数据库，并在电子邮件和用户名上做了相关的一致性约束。如果插入重复用户，会返回失败。然后他们对分片的数据库做大量的写操作。

**如何进行分片**

*  可以参考Cassandra的ring模型、Membase以及Twitter的Gizzard。
 *  坚信：节点间数据传输的越少，你的架构越稳定。
 *  Cassandra存在数据平衡和所有权问题，因为节点们不知道哪个节点保存了另一部分数据。Pinterest认为应用程序需要决定数据该分配到哪个节点，那么将永远不会存在问题。
 *  预计5年内的增长，并且对其进行预分片思考。
 *  初期可以建立一些虚拟分片。8个物理服务器，每个512DB。所有的数据库都装满表格。
 *  为了高有效性，他们一直都运行着多主节点冗余模式。每个主节点都会分配给一个不同的可用性区域。在故障时，该主节点上的任务会分配给其它的主节点，并且重新部署一个主节点用以代替。
 *  当数据库上的负载加重时：

*  先着眼节点的任务交付速度，可以清楚是否有问题发生，比如：新特性，缓存等带来的问题。
 *  如果属于单纯的负载增加，Pinterest会分割数据库，并告诉应用程序该在何处寻找新的节点。
 *  在分割数据库之前，Pinterest会给这些主节点加入一些从属节点。然后置换应用程序代码以匹配新的数据库，在过渡的几分钟之内，数据会同时写入到新旧节点，过渡结束后将切断节点之间的通道。

**ID结构**

*  一共64位

*  分片ID：16位
 *  Type：10位—— Board、User或者其它对象类型
 *  本地ID——余下的位数用于表中ID，使用MySQL自动递增。

*  Twitter使用一个映射表来为物理主机映射ID，这将需要备份；鉴于Pinterest使用AWS和MySQL查询，这个过程大约需要3毫秒。Pinterest并没有让这个额外的中间层参与工作，而是将位置信息构建在ID里。
 *  用户被随机分配在分片中间。
 *  每个用户的所有数据（pin、board等）都存放在同一个分片中，这将带来巨大的好处，避免了跨分片的查询可以显著的增加查询速度。
 *  每个board都与用户并列，这样board可以通过一个数据库处理。
 *  分片ID足够65536个分片使用，但是开始Pinterest只使用了4096个，这允许他们轻易的进行横向扩展。一旦用户数据库被填满，他们只需要增加额外的分片，然后让新用户写入新的分片就可以了。

**查找**

*  如果存在50个查找，举个例子，他们将ID分割且并行的运行查询，那么延时将达到最高。
 *  每个应用程序都有一个配置文件，它将给物理主机映射一个分片范围。

*  “sharddb001a”: : (1, 512)
 *  “sharddb001b”: : (513, 1024)——主要备份主节点

*  如果你想查找一个ID坐落在sharddb003a上的用户：

*  将ID进行分解
 *  在分片映射中执行查找
 *  连接分片，在数据库中搜寻类型。并使用本地ID去寻找这个用户，然后返回序列化数据。

**对象和映射**

*  所有数据都是对象（pin、board、user、comment）或者映射（用户由baord，pin有like）。
 *  针对对象，每个本地ID都映射成MySQL Blob。开始时Blob使用的是JSON格式，之后会给转换成序列化的Thrift。
 *  对于映射来说，这里有一个映射表。你可以为用户读取board，ID包含了是时间戳，这样就可以体现事件的顺序。

*  同样还存在反向映射，多表对多表，用于查询有哪些用户喜欢某个pin这样的操作。
 *  模式的命名方案是：noun\_verb\_noun: user\_likes\_pins, pins\_like\_user。

*  只能使用主键或者是索引查找（没有join）。
 *  数据不会向集群中那样跨数据的移动，举个例子：如果某个用户坐落在20分片上，所有他数据都会并列存储，永远不会移动。64位ID包含了分片ID，所以它不可能被移动。你可以移动物理数据到另一个数据库，但是它仍然与相同分片关联。
 *  所有的表都存放在分片上，没有特殊的分片，当然用于检测用户名冲突的巨型表除外。
 *  不需要改变模式，一个新的索引需要一个新的表。

*  因为键对应的值是blob，所以你不需要破坏模式就可以添加字段。因为blob有不同的版本，所以应用程序将检测它的版本号并且将新记录转换成相应的格式，然后写入。所有的数据不需要立刻的做格式改变，可以在读的时候进行更新。
 *  巨大的胜利，因为改变表格需要在上面加几个小时甚至是几天的锁。如果你需要一个新的索引，你只需要建立一张新的表格，并填入内容；在不需要的时候，丢弃就好。

**呈现一个用户文件界面**

1.  从URL中取得用户名，然后到单独的巨型数据库中查询用户的ID。
2.  获取用户ID，并进行拆分
3.  选择分片，并进入
4.  SELECT body from users WHERE id = <local\_user\_id>
5.  SELECT board\_id FROM user\_has\_boards WHERE user\_id=<user\_id>
6.  SELECT body FROM boards WHERE id IN (<boards\_ids>)
7.  SELECT pin\_id FROM board\_has\_pins WHERE board\_id=<board\_id>
8.  SELECT body FROM pins WHERE id IN (pin\_ids)
9.  所有调用都在缓存中进行（Memcache或者Redis），所以在实践中并没有太多连接数据库的后端操作。

**脚本相关**

1.  当你过渡到一个分片架构，你拥有两个不同的基础设施——没有进行分片的旧系统和进行分片的新系统。脚本成为了新旧系统之间数据传输的桥梁。
2.  移动5亿的pin、16亿的follower行等。
3.  不要轻视项目中的这一部分，Pinterest原认为只需要2个月就可以完成数据的安置，然而他们足足花了4至5个月时间，别忘了期间他们还冻结了一项特性。
4.  应用程序必须同时对两个系统插入数据。
5.  一旦确认所有的数据都在新系统中就位，就可以适当的增加负载来测试新后端。
6.  建立一个脚本农场，雇佣更多的工程师去加速任务的完成。让他们做这些表格的转移工作。
7.  设计一个Pyres副本，一个到GitHub Resque队列的Python的接口，这个队列建立在Redis之上。支持优先级和重试，使用Pyres取代Celery和RabbitMQ更是让他们受益良多。
8.  处理中会产生大量的错误，用户可能会发现类似丢失board的错误；必须重复的运行任务，以保证在数据的处理过程中不会出现暂时性的错误。

**开发相关**

*  开始尝试只给开发者开放系统的一部分——他们每个人都拥有自己的MySQL服务器等，但是事情改变的太快，以至于这个模式根本无法实行。
 *  转变成Facebook模式，每个人都可以访问所有东西，所以不得不非常小心。

**未来的方向**

*  基于服务的架构

*  当他们发现大量的数据库负载，他们开始布置大量的应用程序服务器和一些其它的服务器，所有这些服务器都连接至MySQL和Memcache。这意味着在Memcache上将存在3万的连接，这些连接将占用几个G的内存，同时还会产生大量的Memcache守护进程。
 *  为了解决这个问题，将这些工作转移到了一个服务架构。比如：使用一个follower服务，这个服务将专注处理follower查询。这将接下30台左右的主机去连接数据库和缓存，从而减少了连接的数量。
 *  对功能进行隔离，各司其职。让一个服务的开发者不能访问其它的服务，从而杜绝安全隐患。

--------------------

**学到的知识**

1.  为了应对未来的问题，让其保持简单。
2.  让其变的有趣。只要应用程序还在使用，就会有很多的工程师加入，过于复杂的系统将会让工作失去乐趣。让架构保持简单就是大的胜利，新的工程师从入职的第一周起就可以对项目有所贡献。
3.  当你把事物用至极限时，这些技术都会以各自不同的方式发生故障。
4.  如果你的架构应对增长所带来的问题时，只需要简单的投入更多的主机，那么你的架构含金量十足。
5.  集群管理算法本身就用于处理SPOF，如果存在漏洞的话可能就会影响到每个节点。
6.  为了快速的增长，你需要为每次负载增加的数据进行均匀分配。
7.  在节点间传输的数据越少，你的架构越稳定。这也是他们弃集群而选择分片的原因。
8.  一个面向服务的架构规则。拆分功能，可以帮助减少连接、组织团队、组织支持以及提升安全性。
9.  搞明白自己究竟需要什么。为了匹配愿景，不要怕丢弃某些技术，甚至是整个系统的重构。
10. 不要害怕丢失一点数据。将用户数据放入内存，定期的进行持久化。失去的只是几个小时的数据，但是换来的却是更简单、更强健的系统！

原文链接： [Scaling Pinterest - From 0 To 10s Of Billions Of Page Views A Month In Two Years][] （编译/仲浩 审校/王旭东）

From: http://www.csdn.net/article/2013-04-16/2814902-how-pinterest-scaling-0-to-billions-pv

[Scaling Pinterest]: http://www.infoq.com/presentations/Pinterest
[Yashwanth Nelapati]: http://www.linkedin.com/in/yashh
[Marty Weiner]: http://pinterest.com/martaaay/
[Flickr]: http://highscalability.com/blog/2007/11/13/flickr-architecture.html
[Scaling Pinterest - From 0 To 10s Of Billions Of Page Views A Month In Two Years]: http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html