两年内从零到每月十亿 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架构的充满戏剧化的传奇故事。他们说如果能在一年半前飞速发展时能看到有人做类似题材的演讲的话,他们就会有更多的选择,以避免自己在这一年半里做出的很多错误的决定。 这是一个很不错的演讲,充满了令人惊讶的细节。同时这个演讲也是很务实的,归根结底,它带来了可让大家选择的策略。极度推荐! |
ajavaloser
|
其它翻译版本(1) |
这篇演讲中有两个我最为看重的经验: 1.强大的架构在处理增长时通过简单增加相同的东西(服务器)来应对,同时还能保证系统的正确性。当遇到某种(性能)问题时,你想通过砸钱来扩容指的是你可以简单增加服务器(boxes)。如果你的架构能够做到这一点,那它就如金子一般强大而珍贵! 2. 当某些(性能问题)快到极限时大多数技术都会以他们自己的方式失败。这导致他们在审核工具时要考虑以下一些特性:成熟,好且简单,有名气且用的人多,良好 的支持,持续的优异性能,很少失败,开源。按照这样的标准,他们选择了:MySQL, Solr, Memcache, and Redis,放弃了Cassandra ,Mongo。 这两点经验是相互联系的。遵循(2)中提到的标准的工具可以在扩容时简单增加服务器(boxes).当负载增加了,成熟的产品更少会有问题。当你遇到问题 时,你至少希望它的社区团队能够帮助解决。当你使用的工具过于技巧化和过于讲究时,你会发现你遇到一堵无法逾越的墙。 在这段演讲里,碎片化(sharding)优于集群(clusterting)的观点是我认为最好的一部分。为了应对增长,通过增加资源,更少失败的模 式,成熟,简单,良好的支持,最终圆满完成。请注意他们选择的工具以sharding的方式增长,而不是clustering。关于他们为什么选择 sharding和他们如何做sharding是很有趣的事,这很可能触及到你以前未考虑过的场景。 现在,让我们看看Pinterest如何扩容: (本段有些术语黑话不是很明白,望纠错) |
ajavaloser
|
其它翻译版本(1) |
基本概念
启动于2010年三月--自我发现时期 此时此刻,你甚至不知道你在做的这个产品将要做什么。你有想法,迭代开发更新产品的频率很高。最终因遇到一些在现实生活中永远不会遇到的奇怪的简短的MySQL查询而结束。 早期的一些数字:
|
ajavaloser
|
2011年1月 扔在潜伏前进中,产品得到了一些用户反馈。以下是数据:
每一个半月翻翻的疯狂增长阶段。
|
ajavaloser
|
其它翻译版本(1) |
架构成熟 2012 1月重新设计的系统架构如下:
|
葱油拌面
|
为什么是Amazon EC2/S3
为什么是 MySQL?
|
ajavaloser
|
为什么选择Memcache?
为什么选择Redis?
|
hbdhj
|
Solr
集群vs.分片
|
lidashuang
|
集群 —— 所有事情都是自动化的
|
红薯
|
分片(sharding) - 全凭人手
何时选择分片?
|
AlfredCheung
|
分片的过渡
|
如何进行分片?
|
ID结构
查找
|
lidashuang
|
对象和映射
|
lidashuang
|
呈现一个用户文件界面
脚本相关
|
lidashuang
|
动态
未来发展方向
|
尹春红
|
学到的知识
- 为了应对未来的问题,让其保持简单。
- 让其变的有趣。只要应用程序还在使用,就会有很多的工程师加入,过于复杂的系统将会让工作失去乐趣。让架构保持简单就是大的胜利,新的工程师从入职的第一周起就可以对项目有所贡献。
- 当你把事物用至极限时,这些技术都会以各自不同的方式发生故障。
- 如果你的架构应对增长所带来的问题时,只需要简单的投入更多的主机,那么你的架构含金量十足。
- 集群管理算法本身就用于处理SPOF,如果存在漏洞的话可能就会影响到每个节点。
- 为了快速的增长,你需要为每次负载增加的数据进行均匀分配。
- 在节点间传输的数据越少,你的架构越稳定。这也是他们弃集群而选择分片的原因
- 一个面向服务的架构规则。拆分功能,可以帮助减少连接、组织团队、组织支持以及提升安全性。
- 搞明白自己究竟需要什么。为了匹配愿景,不要怕丢弃某些技术,甚至是整个系统的重构。
- 不要害怕丢失一点数据。将用户数据放入内存,定期的进行持久化。失去的只是几个小时的数据,但是换来的却是更简单、更强健的系统!