两年内从零到每个月十亿 PV 的发展来谈 Pinterest 的架构设计（转）

原文：Scaling Pinterest - From 0 To 10s Of Billions Of Page Views A Month In Two Years

译文：两年内从零到每个月十亿 PV 的发展来谈 Pinterest 的架构设计

 

Pinterest正经历了指数级曲线般的增加，每隔一个半月翻翻。在这两年里，Pinterest，从 每个月PV量0增加到10亿，从两名成立者和一个工程师成长为四十个工程师，从一台MySQL 服务器增加到180台Web 服务器(Web Engine)，240台接口服务器(API Engine), 88台MySQL 数据库 (cc2.8xlarge) ，而且每台DB有一个备份服务器，110台Redis 实例服务（Redis Instance），200台 Memcache 实例服务（Memcache  Instance）。

使人叹为观止的增加。想一探Pinterest的传奇吗？咱们请来了Pinterest的两位创立者Yashwanth Nelapati 和 Marty Weiner，他们将以 Scaling Pinterest为题讲述关于Pinterest架构的充满戏剧化的传奇故事。他们说若是能在一年半前飞速发展时能看到有人作相似题材的演讲的话，他们就会有更多的选择，以免本身在这一年半里作出的不少错误的决定。

这是一个很不错的演讲，充满了使人惊讶的细节。同时这个演讲也是很务实的，归根结底，它带来了可以让你们选择的策略。极度推荐！

这篇演讲中有两个我最为看重的经验：

1.强大的架构在处理增加时经过简单增长相同的东西(服务器)来应对，同时还能保证系统的正确性。当遇到某种（性能）问题时，你想经过砸钱来扩容指的是你能够简单增长服务器(boxes)。若是你的架构可以作到这一点，那它就如金子通常强大而珍贵！

2. 当某些（性能问题）快到极限时大多数技术都会以他们本身的方式失败。这致使他们在审核工具时要考虑如下一些特性：成熟，好且简单，有名气且用的人多，良好的支持，持续的优异性能，不多失败，开源。按照这样的标准，他们选择了：MySQL, Solr, Memcache, and Redis，放弃了Cassandra ，Mongo。

这两点经验是相互联系的。遵循（2）中提到的标准的工具能够在扩容时简单增长服务器(boxes).当负载增长了，成熟的产品更少会有问题。当你遇到问题时，你至少但愿它的社区团队可以帮助解决。当你使用的工具过于技巧化和过于讲究时，你会发现你遇到一堵没法逾越的墙。

在这段演讲里，碎片化（sharding）优于集群(clusterting)的观点是我认为最好的一部分。为了应对增加，经过增长资源，更少失败的模式，成熟，简单，良好的支持，最终圆满完成。请注意他们选择的工具以sharding的方式增加，而不是clustering。关于他们为何选择sharding和他们如何作sharding是颇有趣的事，这极可能触及到你之前未考虑过的场景。

如今，让咱们看看Pinterest如何扩容：

（本段有些术语黑话不是很明白，望纠错）

基本概念

• Pins是一幅关于其余信息的集合的图片，描述了为何它对于用户来讲很重要，能够链回到他们发现它的地方。
• Pinterest是一个社交网络。你能够追踪人或者板报(boards).
• Database:它包含了拥有pins的板报（boards）和拥有板报（boards）的人 ，能够追踪或从新创建（repin）联系，还包含认证信息。

启动于2010年三月--自我发现时期

此时此刻，你甚至不知道你在作的这个产品将要作什么。你有想法，迭代开发更新产品的频率很高。最终因遇到一些在现实生活中永远不会遇到的奇怪的简短的MySQL查询而结束。

早期的一些数字：

• 两个创始人
• 一个工程师
• Rackspace托管服务器
• 一个小型web引擎
• 一个小型MySQL数据库

2011年1月

扔在潜伏前进中，产品获得了一些用户反馈。如下是数据：

• Amazon EC2 + S3 + CloudFront云服务
• 一台NGinX，4台Web 引擎（做冗余用，不是真正为了负载）
• 一台MySQL数据库+一台读备份服务器（防止主服务器宕机）
• 一个任务队列+两个任务处理
• 一台MongoDB（为了计数）
• 两个工程师

至2011年9月--试运行阶段

 

每个半月翻翻的疯狂增加阶段。

• 当高速发展时每一个晚上每一个星期都会有技术失败的状况发生
• 这时，你阅读大量白皮书，它会告诉你把这个增长进来就好了。当他们添加了大量技术时，毫无例外都失败了。
• 最终你获得一个极为复杂的架构图：
  • Amazon EC2 + S3 + CloudFront
  • 2NGinX, 16 Web Engines + 2 API Engines
  • 5 Functionally Sharged MySQL DB + 9 读备份
  • 4 Cassandra 节点
  • 15 Membase 节点(分红三个单独的集群)
  • 8 Memcache 节点
  • 10 Redis 节点
  • 3 任务路由（Task Routers）+ 4 Task Processors
  • 4 ElasticSearch 节点
  • 3 Mongo集群
  • 3名工程师
• 5种主要的数据库技术只为了应付他们本身的数据
• 增加极快以致MySQL负载很高，而其余一些技术都快到达极限
• 当你把某些技术的应用推至极限时，他们又以本身的方式宣告失败。
• 放弃一些技术并问它们到底能作什么。对每一件事情从新构架，海量工做量。

架构成熟 2012 1月

从新设计的系统架构以下：

• Amazon EC2 + S3 + Akamai, ELB
• 90 Web Engines + 50 API Engines
• 66 MySQL DBs (m1.xlarge) + 1 slave each
• 59 Redis Instances
• 51 Memcache Instances
• 1 Redis Task Manager + 25 Task Processors
• Sharded Solr
• 6 Engineers .使用Mysql，Redis，Memcache Solr，他们的优点是简单高效而且是成熟的技术。 随着Web流量增长，Iphone的流量也随之开始愈来愈大。 
  稳按期 2012 10月 12 仅仅在一月份之后，大概就有4倍的流量增加。 系统架构数据以下： The numbers now looks like:
  • Amazon EC2 + S3 + Edge Cast,Akamai, Level 3
  • 180 Web Engines + 240 API Engines
  • 88 MySQL DBs (cc2.8xlarge) + 1 slave each
  • 110 Redis Instances
  • 200 Memcache Instances
  • 4 Redis Task Manager + 80 Task Processors
  • Sharded Solr
  • 40 Engineers (and growing)
  注意到，此时的架构应该是合理的，只是经过增长更多的服务器。你认为此时经过更多的投入来应对这么大的规模的流量，投入更多的硬件来解决这个问题， 下一步 迁移到SSDs

为何是Amazon EC2/S3

• 至关的可靠。数据中心也会宕机， Multitenancy 加入了很多风险，但不是坏处。
• 良好的汇报和支持。他们确实有很不错的架构师并且他们知道问题在哪里。
• 良好的额外服务支持（peripherals），特别是当你的应用处于增加时期。你可能在App Engine中转晕，你不用亲自去实现，只须要简单和他们的服务打交道，例如maged cache，负载均衡，映射和化简，数据库和其余全部方面。Amazon的服务特别适合起步阶段，以后你能够招聘工程师来优化程序。
• 分秒钟得到新的服务实例。这是云服务的威力。特别是当你只有两名工程师，你不用担忧容量规划或者为了10台memcache服务器等上两周。10台memcache服务器几分钟内就能加完。
• 反对的理由：有限的选择。直到最近你才能用SSD并且还没高内存配置的方案。
• 同意的理由：仍是有限的选择。你不须要面对一大堆配置迥异的服务器。

为何是 MySQL？

• 很是成熟
• 很是耐用。从不宕机且不会丢失数据。
• 招聘方便，一大堆工程师懂MySQL.
• 反应时间和请求数量（requies rate，我认为是request rate参考下面）是线性增加的。有些数据库技术的反应时间在请求飙升时不是很好。
• 很好的软件支持-- XtraBackup, Innotop, Maatkit
• 很好的社区，问的问题总能轻易获取到答案
• 很好的厂商支持，譬如Percona
• 开源--这一点很重要，特别是你刚开始没有不少资金支持时。

为何选择Memcache?

• 很是成熟
• 很是简单。它就是一个socket的哈希表。
• 性能一直很好
• 不少人知道并喜欢
• 从不崩溃
• 免费

为何选择Redis?

• 还不成熟，但它是很是好而且至关简单。
• 提供了各类的数据结构。
• 能够持久化和复制，而且能够选择如何实现它们。你能够用MySQL风格持久化，或者你能够不要持久化，或者你只要3小时的持久化。
• Redis上的数据只保存3个小时，没有3小时以上的复本。他们只保留3个小时的备份。
• 若是存储数据的设备发生故障，而它们只是备份了几个小时。这不是彻底可靠的，但它很简单。你并不须要复杂的持久化和复制。这是一个更简单，更便宜的架构。
• 不少人知道并喜欢
• 性能一直很好
• 不多的一些故障。你须要了解一些小故障，学习并解决它们，使它愈来愈成熟。
• 免费

Solr

• 只须要几分钟的安装时间，就能够投入使用
• 不能扩展到多于一台的机器上（最新版本并不是如此）
• 尝试弹性搜索，可是以Pinterest的规模来讲，可能会由于零碎文件和查询太多而产生问题。
• 选择使用Websolr，可是Pinterest拥有搜索团队，未来可能会开发本身的版本。 

集群vs.分片

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

集群 —— 全部事情都是自动化的

• 示例: Cassandra, MemBase, HBase
• 结论: 太可怕了，不是在如今，可能在未来，但如今太复杂了，有很是多的故障点
• 属性:
  • 自动化数据分布
  • 可移动数据
  • 可从新进行分布均衡
  • 节点间可通信，大量的握手、对话
• 有点:
  • 自动伸缩数据存储，至少白皮书上是这么说的
  • 安装简单
  • 在空间中分布存储你的数据，可在不一样区域有数据中心
  • 高可用性
  • 负载均衡
  • 没有单点故障
• 缺点 (来自用户一手的体验):
• 仍是至关年轻不成熟
• 仍是太复杂，一大堆节点必须对称的协议,这是一个在生产环境中难以解决的问题。
• 不多的社区支持，有一个沿着不一样产品线的分裂社区会减小每一个阵营的支持。
• 不多工程师有相关的知识，多是不少工程师都没用过 Cassandra.
• 复杂和和可怕的升级机制
• 集群管理算法是一个 SPOF 单点故障，若是有个 bug 影响每一个节点，这可能会宕机 4 次。
• 集群管理器编码复杂，有以下一些失败的模式：
• 数据从新均衡中断：当一个新机器加入而后数据开始复制,它被卡住了。你作什么工做?没有工具来找出到底发生了什么。没有社会的帮助,因此他们被困。他们又回到了MySQL。
• 全部节点的数据损坏. What if there’s a bug that sprays badness into the write log across all of them and compaction or some other mechanism stops? Your read latencies increase. All your data is screwed and the data is gone.
• 均衡不当并且很难修复. 很是常见，若是你有10个节点，你会注意到全部节点都在一个节点上，有一个手工处理方式，但会将全部负载分布到一个单节点上
• 权威数据失效. 集群方案是很智能的。In one case they bring in a new secondary. At about 80% the secondary says it’s primary and the primary goes to secondary and you’ve lost 20% of the data. Losing 20% of the data is worse than losing all of it because you don’t know what you’ve lost.

分片(sharding) - 全凭人手

• 裁决: 分片是赢家。我以为他们分片的方案与Flicker很是类似。
• 特色:
• 若是去掉集群方式下全部很差的特色，就获得了分片。
• 人工对数据进行分布。
• 不移动数据。
• 经过切分数据来分担负荷。
• 节点不知道其它节点的存在。某些主节点控制一切。
• 优势:
• 能够经过切分数据库来扩大容量。
• 在空间上分布数据。
• 高可用。
• 负载均衡。
• 放置数据的算法十分简单。这是最主要的缘由。虽然存在单点(SPOF)，但只是很小的一段代码，而不是复杂到爆的集群管理器。过了第一天就知道有没有问题。
• ID的生成很简单。
• 缺点:
• 没法执行大多数链接。
• 没有事务功能。可能会出现写入某个数据库失败、而写入其它库成功的状况。
• 许多约束只能转移到应用层实现。
• schema的修改须要更多的规划。
• 若是要出报表，必须在全部分片上分别执行查询，而后本身把结果合起来。
• 链接只能转移到应用层实现。
• 应用必须应付以上全部的问题。

什么时候选择分片？

• 当有几TB的数据时，应该尽快分片。
• 当Pin表行数达到几十亿，索引超出内存容量，被交换到磁盘时。
• 他们选出一个最大的表，放入单独的数据库。
• 单个数据库耗尽了空间。
• 而后，只能分片。

分片的过渡

• 过渡从一个特性的冻结开始。

• 确认分片该达到什么样的效果——但愿尽少的执行查询以及最少数量的数据库去呈现一个页面。

• 剔除全部的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有不一样的版本，因此应用程序将检测它的版本号而且将新记录转换成相应的格式，而后写入。全部的数据不须要马上的作格式改变，能够在读的时候进行更新。
• 巨大的胜利，由于改变表格须要在上面加几个小时甚至是几天的锁。若是你须要一个新的索引，你只须要创建一张新的表格，并填入内容；在不须要的时候，丢弃就好。

呈现一个用户文件界面

• 从URL中取得用户名，而后到单独的巨型数据库中查询用户的ID。

• 获取用户ID，并进行拆分

• 选择分片，并进入

• SELECT body from users WHERE id = <local_user_id>

• SELECT board_id FROM user_has_boards WHERE user_id=<user_id>

• SELECT body FROM boards WHERE id IN (<boards_ids>)

• SELECT pin_id FROM board_has_pins WHERE board_id=<board_id>

• SELECT body FROM pins WHERE id IN (pin_ids)

• 全部调用都在缓存中进行（Memcache或者Redis），因此在实践中并无太多链接数据库的后端操做。

脚本相关

• 当你过渡到一个分片架构，你拥有两个不一样的基础设施——没有进行分片的旧系统和进行分片的新系统。脚本成为了新旧系统之间数据传输的桥梁。

• 移动5亿的pin、16亿的follower行等。

• 不要轻视项目中的这一部分，Pinterest原认为只须要2个月就能够完成数据的安置，然而他们足足花了4至5个月时间，别忘了期间他们还冻结了一项特性。

• 应用程序必须同时对两个系统插入数据。

• 一旦确认全部的数据都在新系统中就位，就能够适当的增长负载来测试新后端。

• 创建一个脚本农场，雇佣更多的工程师去加速任务的完成。让他们作这些表格的转移工做。

• 设计一个Pyres副本，一个到GitHub Resque队列的Python的接口，这个队列创建在Redis之上。支持优先级和重试，使用Pyres取代Celery和RabbitMQ更是让他们受益良多。

• 处理中会产生大量的错误，用户可能会发现相似丢失board的错误；必须重复的运行任务，以保证在数据的处理过程当中不会出现暂时性的错误。

动态

• 最初试图给开发者一个分片系统。每一个开发者都能拥有本身的MySQL服务器，但事情发生了快速的变化，致使不能工做。变

• 去了Facebook的模式：每一个人能够得到一切。因此，你不得不很是谨慎

将来发展方向

• 基于服务的架构。

  • 当他们开始看到了不少的数据库负载，便像产卵同样，致使了不少的应用服务器和其余服务器堆在一块儿。全部这些服务器链接到MySQL和Memcache。这意味着有30K上的memcache链接了一对夫妇演出的RAM引发的memcache守护进程交换。

  • 做为一个修补程序，这些都是移动的服务架构。有一个跟随服务，例如，将只回答跟随查询。此隔离的机器数目至30访问数据库和高速缓存，从而减小了链接。

  • 帮助隔离功能。帮助组织，解决和支持这些服务的团队。帮助开发人员，为了安全开发人员不能访问其余服务。

学到的知识

• 为了应对将来的问题，让其保持简单。

• 让其变的有趣。只要应用程序还在使用，就会有不少的工程师加入，过于复杂的系统将会让工做失去乐趣。让架构保持简单就是大的胜利，新的工程师从入职的第一周起就能够对项目有所贡献。

• 当你把事物用至极限时，这些技术都会以各自不一样的方式发生故障。

• 若是你的架构应对增加所带来的问题时，只须要简单的投入更多的主机，那么你的架构含金量十足。

• 集群管理算法自己就用于处理SPOF，若是存在漏洞的话可能就会影响到每一个节点。

• 为了快速的增加，你须要为每次负载增长的数据进行均匀分配。

• 在节点间传输的数据越少，你的架构越稳定。这也是他们弃集群而选择分片的缘由

• 一个面向服务的架构规则。拆分功能，能够帮助减小链接、组织团队、组织支持以及提高安全性。

• 搞明白本身究竟须要什么。为了匹配愿景，不要怕丢弃某些技术，甚至是整个系统的重构。

• 不要惧怕丢失一点数据。将用户数据放入内存，按期的进行持久化。失去的只是几个小时的数据，可是换来的倒是更简单、更强健的系统