Pinterest架构：两年内月PV从零到百亿
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）联系，还包含认证信息。
- 两个创始人
- 一个工程师
- Rackspace托管服务器
- 一个小型web引擎
- 一个小型MySQL数据库
2011年1月
扔在潜伏前进中，产品得到了一些用户反馈。以下是数据：
- Amazon EC2 + S3 + CloudFront云服务
- 一台NGinX，4台Web 引擎（作冗余用，不是真正为了负载）
- 一台MySQL数据库+一台读备份服务器（防止主服务器宕机）
- 一个任务队列+两个任务处理
- 一台MongoDB（为了计数）
- 两个工程师
- 当高速发展时每个晚上每个星期都会有技术失败的情况发生
- 这时，你阅读大量白皮书，它会告诉你把这个增加进来就行了。当他们添加了大量技术时，毫无例外都失败了。
- 最终你得到一个极为复杂的架构图：
- 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)
为什么是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个小时的备份。
- 如果存储数据的设备发生故障，而它们只是备份了几个小时。这不是完全可靠的，但它很简单。你并不需要复杂的持久化和复制。这是一个更简单，更便宜的架构。
- 很多人知道并喜欢
- 性能一直很好
- 很少的一些故障。你需要了解一些小故障，学习并解决它们，使它越来越成熟。
- 免费
