Pinterest架构：两年内月PV从零到百亿-白红宇

Pinterest架构：两年内月PV从零到百亿

阅读量：6293 次

发布时间：2019-06-22

本文共 3894 字，大约阅读时间需要 12 分钟。

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的两位创立者和，他们将以为题讲述关于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的服务特别适合起步阶段，之后你可以招聘工程师来优化程序。