【科技】Pinterest架构之路

本篇文章6908字，读完约17分钟

前言

pinterest可以支持每2.5个月流量增加一倍的指数增长，在两年内每月pv从0亿增加到10亿。 从两名创始人和一名或多名工程师到40名或多名工程师，从一台mysql服务器到180台web服务器、240 api引擎、88个mysql db和一个从属库、110个redis实例、200个MEMI

惊人的成长！ 他们是怎么做到的？ 一年半yashwanth nelapati和marty weiner演讲了这个戏剧性的结构进化故事，当初早，选择多，他们也做了很多错误的选择(接下来是教训和经验总结)。

这是伟大的演讲，非常详细，但接地气体，体系结构战略适合各自的普通你和我，强烈推荐！

我从演讲中学到了两个基本的东西。

1 .体系结构是在业务发展时可以轻松添加同样的东西。 如果你认为扩展体系结构只会投入越来越多的钱，增加越来越多的服务器( boxs )，但如果你的体系结构能做到，那就是钱。

2 .达到极限后，所有的技术都会以自己特有的方法失败。 这将引出我们选定时的大致情况。 成熟，简单实用，广为人知，喜欢的，社区支持友好，性能总是很好，尽量不出故障，免费。 这些基本上，他们选择了mysql、solr、memcache和redis。 cassandra和mongodb被抛弃了。

这两个几乎是相互关联的。 基本上可以基于两个工具增加和扩展越来越多的空间。 负载增加时成熟的工具会减少问题。 即使有问题，社区也会一起处理。 如果选定的工具太少，可能会与南墙发生冲突。

我认为这也是整个演讲中最好的，关于切片( sharding )比集群更好的讨论，如果在业务成长时追加越来越多的资源，就显示出失效少、成熟、简单、能良好支持等特征。 观察所有的工具，他们会选择瓷砖而不是群集。 关于这一部分的讨论可能你以前也没有想到过。

是的，你等不及了吗，let's go:)

术语表

喜欢的图像( pins ) :带新闻的图像，包括说明、重要性、跟踪链接等。

pinterest :包含关注的人和板块功能的图像sns

数据库database :关注顾客库-顾客板块与包括板块在内的引脚转录( repin )的关系、认证新闻等。

年3月项目开始-自我搜索

这时你甚至不知道要建设什么产品，有很多想法，但总是很快改变，最后留下一点奇怪的mysql查询。

一个初始数据:

两个创始人

我是工程师

在rackspace中主机

小web服务引擎

小mysql数据库

年1月

还在秘密开发，根据客户的反馈反复进行。 一点数据:

亚马逊ec2 + S3 + cloudfront

1 nginx，4 web engines (由于冗馀，在线不采用)

1 mysql db + 1只读库(防止主库down掉落)

1任务队列+ 2任务解决方案

1 mongodb (计数器用)

两个工程师

年9月-到考试阶段

疯狂的成长，每两个半月增加一倍。

当你达到这个增长速度时，所有的东东每晚都会掉链子

这时，在网上调查了很多模式方案，只能说要追加服务器吧。 追加吧。 又添加了很多其他技术，都无效了。

我可以看到你组更多复杂的数据。

亚马逊ec2 + S3 + cloudfront

2 nginx，16 web引擎+ 2 api引擎

5功能片mysql db + 9只读库

4 cassandra节点

15 membase节点( 3独立群集)

8 memcache节点

10 redis节点

3任务路由+ 4任务解决方案

4 elastic search节点

3 mongo群集

3工程师

五个主要的数据库分别存储自己的数据

增长太快，mysql也快受不了了，所有的技术都到了极限

所有的技术使用极限都用自己的方法失效了

我放弃了技术，开始问我们想要什么。 然后是重建。 我是。 我是。 重建。 我是。 我是。

年1月-成熟期

所有重建的系统如下所示。

amazon ec2 + s3 + akamai，elb

90 web引擎+ 50 api引擎

66 mysql dbs (m1.xlarge) +各1个从属库

59 redis实例

51 memcache实例

1 redis任务管理器+ 25任务解决方案

瓷砖的solr

6工程师

现在在切片的mysql、redis、memcache、solr上运行，所以利益是技术简单成熟的。

站点流量以同样的速度增加，同样iphone的流量也开始增加。

年10月12日-历史循环

大约是一月的四倍。 数据是这样的。

亚马逊EC2 + S3 + edge cast，akamai，level 3

180 web引擎+ 240 api引擎

88 mysql dbs (cc2.8xlarge) +各配1从站库

110 redis实例

200 memcache实例

4 redis任务管理器+ 80任务解决方案

瓷砖的solr

40工程师(还在成长)

不，架构很容易使用，扩展时只需要追加同样的东西，想破坏越来越多的钱来扩展吗？ 还是想增加空间容量？

硬盘使用了ssd

为什么选择amazon ec2/s3？

稳定性好。 数据也有问题，增加了风险，但总体来说还是好的。

好的报告和支持。 他们很清楚结构知识的问题在哪里。

是很好的周边支持。 快速增长后，可以更快地整理缓存、负载平衡、map reduce、数据库等需要的东西，不需要写任何东西，用他们的服务启动，有工程师的时候可以和自己玩。

新实例只需几秒钟即可启动。 这是云服务的力量。特别是只有两个工程师的情况下，不注意流量增加计划需要两周的时间。 十台缓存服务几分钟就能完成

弊病:选择有限。 到最近为止，只有ssd可用，还没有大内存可以配置。

特征:选择有限。 不需要在不同服务器的不同配置中终止

*在国内，AlibabaCloud (阿里巴巴云)似乎是个很好的选择。

为什么选择mysql

真的很成熟

结实。 我没有做过机器也没有丢失数据。

大部分人都可以招募。

响应时间和请求数量呈线性增加。 有些技术路线没有这样增长。

是很好的软件支持。 xtrabackup、innotop、maatkit

是很好的社区支持。 得到问题的回答很简单。

得到percona等企业的支持也很容易

是免费的。一开始没有投资就非常重要。

为什么选择memcache？

非常成熟。

非常简单。 就像带插座的散列表。

一贯性能很好

广为人知，又喜欢

不会崩溃

免费的

为什么选择redis？

虽然还不成熟，但是很容易使用。

提供了多种多样的数据结构。

有持久层和复制，可以选择如何实现。 如果你想留下来就像mysql一样，但如果你不想留下来就好了。 如果你想只留下三个小时就行了。 证明:1.redis的根种子( home seed )每三小时保存一次，每三小时没有复制功能。 每三小时备份一次2 .如果服务器( box )上没有数据，则只备份几个小时。 这并不足够可信，但还很简单。 不需要使持久化和副本多而杂乱无章。 这只是一种更简单、更便宜的体系结构方法。

广为人知，喜欢。

一贯性能很好。

很少到期。 你只需要知道少数微妙的失效。 这也是成熟的理由之一，学好就能解决。

为什么是solr？

崛起中的伟大产品。 安装几分钟，有很大的搜索引擎。

服务器之间不能扩展(至少到目前为止)。

我们尝试了elastic search的各大搜索引擎，但扩展有问题，特别是解决小文档，查询太多了。

现在的是websolr，pinterest支持搜索小组。

是的商业将来

也

等等

节点堆必须调整，在生产环境中没有太大错误。

我不太支持社区。 在产品分割中各阵营只有少量的支持。

困难和可怕的升级机制。

集群管理的算法在spof中，某个节点锁定时会影响所有节点，锁定过4次。

集群管理较多、噪音较多的代码可能会通过所有节点，1 .数据的重新平衡可能会中断。 如果新节点在同步开始时卡住了怎么办？ 因为没有人告诉我，所以做成卡片，最后回到了mysql。 2 .破坏的数据感染所有节点。 3 .不正确的平衡也很难修正。 4 .数据批准失败。

瓷砖-所有手工

选定结果:滑动方案获胜！ 证明瓷砖像flickr的体系结构一样普遍使用。

特征:我删除了你讨厌的集群的所有特征。 数据的分布是手动设定的，数据不迁移。 有些人这么做，但争论很大。 在分割数据分散负荷的各节点之间不需要信息表现，主节点控制一切。

特征:

可以分割数据库来增加容量。

地理分布和可调整的数据

负载均衡

数据的算法很简单。 第一个理由是，虽然也使用了spof，但是比多而杂的集群方案只复杂了一半以上，所以才知道是否可以使用。

id生成很简单。

劣势:

大多数join操作都无法执行

我不支持事务。 写a库是成功的，还是写b库是失败的。

许多约束是移动到应用程序中实现的。

( schema表)结构的制作必须更加谨慎

查询报告必须在所有片上运行，并手动聚合

聚合是在应用层进行的

你的应用必须解决上述问题: d

什么时候可以制作瓷砖？

如果你的项目只有几tb的数据，马上开始切片。

当第一个业务表的行数达到数亿行时，索引会超过内存，或者使用交换机分区。

需要将最大的表分别检索到独立的数据库中

单一的库让你的空间充满了光。

那么，开始享受切片的美好时光:)

开始瓷砖表演。

开始瓷砖时，不要添加新功能。

明确怎么切成片。 基本上，可以使用几个数据库以最小的查询和最小的遍历生成页面。

删除所有连接操作。 join无法运营，因为表可能会从不同的分区返回。

我增加了非常多的缓存。 基本上每个查询都有缓存。

步骤如下。

1 db + foreign keys + joins

1 db +逆范式denormalized +高速缓存

1 db +只读库+缓存

一些图片库+只读库+缓存

id片的数据库+备份来自库+缓存

尽早从只读库中检索数据不是延迟引起的问题。 对从程序库的读取请求可能是主程序库没有完成复制。 这看起来像是数据丢失了。 要避免这个问题，请使用缓存。

客户表没有切片。 只有一个巨大的数据库，name是唯一的，重复客户名称失败了。 许多写入请求被写入瓷砖的数据库。

怎么分影子？

让我们看看cassandra的环形模式( ring model )、membase和twitter的gizzard。

策略:最小的数据延迟等于最大的稳定性。

cassadra有数据均衡和批准的问题。 我不知道谁有哪个数据。 这绝对不是问题，因为pinterest的方法是在应用层确定数据的目的地。

我计划了今后5次切片。

从一开始就创建了很多虚拟片。 8台服务器，每台有512个数据库，每个数据库都有所有的表。

为了高可用性，他们建立了多主库复制模式。 每个主库被分配到不同的地区，一个失效可以切换到新的交换库。

如果数据库的压力增加了:

检查提交的新代码是否出现新功能、缓存问题或其他问题。

如果负载增加，他们会分割数据，告诉应用层将数据检索到新的数据中心。

在分割数据之前，启动这些主库的从库，切换应用层代码，访问新库。 在几分钟内，数据被写入旧库(然后复制到新的从库)，最后旧库被删除(应用层代码此时访问新的从库。 此时成为主库)。

id的结构

61比特

瓷砖id:16位

类型: 10位-管脚( pin )、版本、客户和其他对象

本地id :其他位用于本地表的自增加id。

推特使用映射表将id映射到物理主机。 这是因为pinterest在aws上运行，mysql查询一次需要3毫秒，不接受其额外的间接开销，所有位置(库、表所在的服务器地址新闻)也在id中定义

新注册的客户在随机分配瓷砖的服务器上。

所有数据(包括pin、版本等)都分配给同一片。 这不需要跨越很多不同的片，例如生成一个客户的新闻页面，从而带来更快的利益。

id的设计65536个片就足够了。 但是，最初只能使用到4096。 然后，也可以水平扩展。 客户库已满后，开放越来越多的片，将新客户分配给新片。

查询。

如果有50个查询，则假设pinterest被id分割，所有并发查询、延迟都是最长的等待时间。

每个应用程序都有一个将片区间映射到物理主机的配置文件

shard db 001 a:( 1，512 )

shard db 001 b:( 513，1024 ) -热主机备份

如果要检查的客户id位于sharddb003a上:

分解id

瓷砖映射中的查询

连接到区块所在的服务器，根据类型选择数据库，用本地id重新确认正确的客户，返回序列化的数据

物件和对映

所有数据都是对象( pin、版本、客户、注释)或映射(客户版本、喜欢的图像pin )

对于对象，本地id映射到MySQL blob。 blob块样式是json，但返回昌序列化的thrift (请参见fackbook thrift )。 。

映射的情况下，是可以询问顾客版本的映射表，id中包含时间戳，可以据此按事件顺序进行排序。

pinterest还维护了反射映射表、多对多的表来回答这种类型的查询问题。 请关注客户。

表名是名词动词名词，如userlikepings、pinslikeuser等。

查询是用主键或键查询的(没有join )。

数据不像集群一样飞。 如果一个客户被分配到第20片，他所有的数据都在这张片上，永远不会飞到别的地方。 64位id包含片id，一切保持不变。 物理数据可以移动到其他数据库，但连接到同一片。

所有的表在所有切片中都是一样的(数据不同)。 没有特殊的切片。 不发生顾客表这样的大表检测顾客名冲突的问题。

不需要更改表的结构或新索引(最棒的地方！ 看看他们是怎么做到的)

表结构大多是key= >； value格式，value只是一个blob，可以自由添加字段而不更改表结构。 还有表示blob版本的version字段。 这允许应用层检测是否需要更改blob的结构。 不需要立即更新所有数据，在客户咨询时会自动升级。

写大表的结构有时会消耗几个小时到一整天，因此这种表结构很有特点。 如果您想添加新索引，请创建新表，迁移数据，不要随时杀死它(此更新是否安全事务)。 。

实战-生成客户个人新闻页面

从ulr获得顾客名，从巨大的个别顾客表中查找顾客id

分析(分割)客户id

选择瓷砖，连接瓷砖

selectbodyfromuserswhereid = userid & gt；

selectboardidfromuserhasboardswhereuserid = id & gt；

selectbodyfromboardswhereidin ( ids & gt； )中被调用，将出现故障

selectpinidfromboardhaspinswhereboardid = id & gt；

selectbodyfrompinswhereidin ( Pinids )

许多请求从缓存中返回，实践上流量很少删除数据库。

剪切过程和脚本

迁移到瓷砖模式时，有两个新的和旧的模式。 脚本是用于迁移到新方案的代码

pinterest转移了5亿条pins和1亿6千万的兴趣等

低估了迁移的价格，他们以为需要两个月，实际上花了四到五个月。 请观察。 是冻结新功能上线的时候了。

应用层必须将数据写入新的、旧的两个方案

确认所有数据都迁移到新架构后，将请求逐步断开到新架构，逐步增加后台并进行测试

制作很多脚本，投入很多人完成剪辑。

pyres，访问用python编写的github RES que队列的工具，在redis上建立的队列服务，支持优先和重试，比celery和rabbitmq好得多。

接收过程中犯了很多错误。 为了确保客户没有版本，只做了几次就没错。

开发

我试图为开始部署系统的所有基本环境提供独立的mysql，但业务发展迅速，没有效果。

学习facebook是在生产环境中开发的，但必须小心。

未来的方向

soa

随着数据库负载的增加，应用程序服务和服务器堆增加，所有服务都连接到mysql和memcache，3万个连接到memcache时内存达到g，memcache是交换分区

导航到soa方案是一种方法。 例如，通过关注服务，只进行关注的查询，可以隔离为30个进行连接，可以承受压力。

soa也有助于隔离功能。 根据服务配置项目组、支持组和安全组。

学到的知识点

任何事情都可能失败。 需要简单地注意。

让事件感兴趣。

用极限什么都断东东。

骨架只需要追加复制之类的东就能扩展容量。 好的框架也是钱。

群集管理算法是spof，如果一个错误与每个节点发生冲突，则将其乘以四次。

分散数据，分散负载

分散数据越少，模式越稳定。 因此，pinterest选择的是瓷砖而不是群集。

soa规范:功能隔离。 有助于减少链接、组织团队、支持组织和提高安全性。

问问自己想要什么，不要管理技术。 即使需要所有重建，也请遵循你的愿景(或商业模式)。

不要害怕扔掉数据。 pinterest将客户数据保留在内存中，定期写入数据库，意味着几个小时的数据消失了，但系统变得简洁高效。 这更重要。