Tumblr：150亿月浏览量背后的架构挑战（下）

原文：http://cloud.csdn.net/a/20120215/311867.html

导读：和许多新兴的网站一样，著名的轻博客服务 Tumblr 在急速发展中面临了系统架构的瓶颈。每天 5 亿次浏览量，峰值每秒 4 万次请求，每天 3TB 新的数据存储，超过 1000 台服务器，这样的情况下如何保证老系统平稳运行，平稳过渡到新的系统，Tumblr 正面临巨大的挑战。近日，HighScalability 网站的 Todd Hoff 采访了该公司的分布式系统工程师 Blake Matheny，撰文系统介绍了网站的架构，内容很有价值。我们也非常希望国内的公司和团队多做类似分享，贡献于社区的同时，更能提升自身的江湖地位，对招聘、业务发展都好处多多。




内部的 firehose(通信管道)

内部的应用需要活跃的信息流通道。这些信息包括用户创建/删除的信息，liking/unliking 的提示，等等。挑战在于这些数据要实时的分布式处理。我们希望能够检测内部运行状况，应用的生态系统能够可靠的生长，同时还需要建设分布式系统的控制中心。
以前，这些信息是基于 Scribe (Facebook 开源的分布式日志系统)/Hadoop 的分布式系统。服务会先记录在 Scribe 中，并持续的长尾形式写入，然后将数据输送给应用。这种模式可以立即停止伸缩，尤其在峰值时每秒要创建数以千计的信息。不要指望人们会细水长流式的发布文件和 grep。
内部的 firehose 就像装载着信息的大巴，各种服务和应用通过 Thrift 与消防管线沟通。(一个可伸缩的跨语言的服务开发框架。)
LinkedIn 的 Kafka 用于存储信息。内部人员通过 HTTP 链接 firehose。经常面对巨大的数据冲击，采用 MySQL 显然不是一个好主意，分区实施越来越普遍。
firehose 的模型是非常灵活的，而不像 Twitter 的 firehose 那样数据被假定是丢失的。
firehose 的信息流可以及时的回放。他保留一周内的数据，可以调出这期间任何时间点的数据。
支持多个客户端连接，而且不会看到重复的数据。每个客户端有一个 ID。Kafka 支持客户群，每个群中的客户都用同一个 ID，他们不会读取重复的数据。可以创建多个客户端使用同一个 ID，而且不会看到重复的数据。这将保证数据的独立性和并行处理。Kafka 使用 ZooKeeper (Apache 推出的开源分布式应用程序协调服务。)定期检查用户阅读了多少。
为 Dashboard 收件箱设计的 Cell 架构

现在支持 Dashboard 的功能的分散-集中架构非常受限，这种状况不会持续很久。
解决方法是采用基于 Cell 架构的收件箱模型，与 Facebook Messages 非常相似。
收件箱与分散-集中架构是对立的。每一位用户的 dashboard 都是由其追随者的发言和行动组成的，并按照时间顺序存储。
就因为是收件箱就解决了分散-集中的问题。你可以会问到底在收件箱中放了些什么，让其如此廉价。这种方式将运行很长时间。
重写 Dashboard 非常困难。数据已经分布，但是用户局部升级产生的数据交换的质量还没有完全搞定。
数据量是非常惊人的。平均每条消息转发给上百个不同的用户，这比 Facebook 面对的困难还要大。大数据+高分布率+多个数据中心。
每秒钟上百万次写入，5万次读取。没有重复和压缩的数据增长为2.7TB，每秒百万次写入操作来自 24 字节行键。
已经流行的应用按此方法运行。
cell
每个 cell 是独立的，并保存着一定数量用户的全部数据。在用户的 Dashboard 中显示的所有数据也在这个 cell 中。
用户映射到 cell。一个数据中心有很多 cell。
每个 cell 都有一个 HBase 的集群，服务集群，Redis 的缓存集群。
用户归属到 cell，所有 cell 的共同为用户发言提供支持。
每个 cell 都基于 Finagle（Twitter 推出的异步的远程过程调用库），建设在 HBase 上，Thrift 用于开发与 firehose 和各种请求与数据库的链接。(请纠错)
一个用户进入 Dashboard，其追随者归属到特定的 cell，这个服务节点通过 HBase 读取他们的 dashboard 并返回数据。
后台将追随者的 dashboard 归入当前用户的 table，并处理请求。
Redis 的缓存层用于 cell 内部处理用户发言。
请求流：用户发布消息，消息将被写入 firehose，所有的 cell 处理这条消息并把发言文本写入数据库，cell 查找是否所有发布消息追随者都在本 cell 内，如果是的话，所有追随者的收件箱将更新用户的 ID。（请纠错）
cell 设计的优点：
大规模的请求被并行处理，组件相互隔离不会产生干扰。 cell 是一个并行的单位，因此可以任意调整规格以适应用户群的增长。
cell 的故障是独立的。一个 Cell 的故障不会影响其他 cell。
cell 的表现非常好，能够进行各种升级测试，实施滚动升级，并测试不同版本的软件。
关键的思想是容易遗漏的：所有的发言都是可以复制到所有的 cell。
每个 cell 中存储的所有发言的单一副本。 每个 cell 可以完全满足 Dashboard 呈现请求。应用不用请求所有发言者的 ID，只需要请求那些用户的 ID。(“那些用户”所指不清，请指正。)他可以在 dashboard 返回内容。每一个 cell 都可以满足 Dashboard 的所有需求，而不需要与其他 cell 进行通信。
用到两个 HBase table ：一个 table 用于存储每个发言的副本，这个 table 相对较小。在 cell 内，这些数据将与存储每一个发言者 ID。第二个 table 告诉我们用户的 dashboard 不需要显示所有的追随者。当用户通过不同的终端访问一个发言，并不代表阅读了两次。收件箱模型可以保证你阅读到。
发言并不会直接进入到收件箱，因为那实在太大了。所以，发言者的 ID 将被发送到收件箱，同时发言内容将进入 cell。这个模式有效的减少了存储需求，只需要返回用户在收件箱中浏览发言的时间。而缺点是每一个 cell 保存所有的发言副本。令人惊奇的是，所有发言比收件箱中的镜像要小。(请纠错)每天每个 cell 的发言增长 50GB，收件箱每天增长2.7TB。用户消耗的资源远远超过他们制造的。
用户的 dashboard 不包含发言的内容，只显示发言者的 ID，主要的增长来自 ID。(请 Tumblr 用户纠错)
当追随者改变时，这种设计方案也是安全的。因为所有的发言都保存在 cell 中了。如果只有追随者的发言保存在 cell 中，那么当追随者改变了，将需要一些回填工作。
另外一种设计方案是采用独立的发言存储集群。这种设计的缺点是，如果群集出现故障，它会影响整个网站。因此，使用 cell 的设计以及后复制到所有 cell 的方式，创建了一个非常强大的架构。
一个用户拥有上百万的追随者，这带来非常大的困难，有选择的处理用户的追随者以及他们的存取模式（见 Feeding Frenzy）
不同的用户采用不同并且恰当的存取模式和分布模型，两个不同的分布模式包括：一个适合受欢迎的用户，一个使用大众。
依据用户的类型采用不同的数据处理方式，活跃用户的发言并不会被真正发布，发言将被有选择的体现。(果真如此？请 Tumblr 用户纠错)
追随了上百万用户的用户，将像拥有上百万追随者的用户那样对待。
cell 的大小非常难于决定。cell 的大小直接影响网站的成败。每个 cell 归于的用户数量是影响力之一。需要权衡接受怎样的用户体验，以及为之付出多少投资。
从 firehose 中读取数据将是对网络最大的考验。在 cell 内部网络流量是可管理的。
当更多 cell 被增添到网络中来，他们可以进入到 cell 组中，并从 firehose 中读取数据。一个分层的数据复制计划。这可以帮助迁移到多个数据中心。
在纽约启动运作

纽约具有独特的环境，资金和广告充足。招聘极具挑战性，因为缺乏创业经验。
在过去的几年里，纽约一直致力于推动创业。纽约大学和哥伦比亚大学有一些项目，鼓励学生到初创企业实习，而不仅仅去华尔街。市长建立了一所学院，侧重于技术。
团队架构

团队：基础架构，平台，SRE，产品，web ops，服务；
基础架构：5层以下，IP 地址和 DNS，硬件配置；
平台：核心应用开发，SQL 分片，服务，Web 运营；
SRE：在平台和产品之间，侧重于解决可靠性和扩展性的燃眉之急；
服务团队：相对而言更具战略性，
Web ops：负责问题检测、响应和优化。
软件部署

开发了一套 rsync 脚本，可以随处部署 PHP 应用程序。一旦机器的数量超过 200 台，系统便开始出现问题，部署花费了很长时间才完成，机器处于部署进程中的各种状态。
接下来，使用 Capistrano（一个开源工具，可以在多台服务器上运行脚本）在服务堆栈中构建部署进程（开发、分期、生产）。在几十台机器上部署可以正常工作，但当通过 SSH 部署到数百台服务器时，再次失败。
现在，所有的机器上运行一个协调软件。基于 Redhat Func（一个安全的、脚本化的远程控制框架和接口）功能，一个轻量级的 API 用于向主机发送命令，以构建扩展性。
建立部署是在 Func 的基础上向主机发送命令，避免了使用 SSH。比如，想在组A上部署软件，控制主机就可以找出隶属于组A的节点，并运行部署命令。
部署命令通过 Capistrano 实施。Func API 可用于返回状态报告，报告哪些机器上有这些软件版本。
安全重启任何服务，因为它们会关闭连接，然后重启。
在激活前的黑暗模式下运行所有功能。
展望

从哲学上将，任何人都可以使用自己想要的任意工具。但随着团队的发展壮大，这些工具出现了问题。新员工想要更好地融入团队，快速地解决问题，必须以他们为中心，建立操作的标准化。
过程类似于 Scrum（一种敏捷管理框架），非常敏捷。
每个开发人员都有一台预配置的开发机器，并按照控制更新。
开发机会出现变化，测试，分期，乃至用于生产。
开发者使用 VIM 和 TextMate。
测试是对 PHP 程序进行代码审核。
在服务方面，他们已经实现了一个与提交相挂钩的测试基础架构，接下来将继承并内建通知机制。
招聘流程

面试通常避免数学、猜谜、脑筋急转弯等问题，而着重关注应聘者在工作中实际要做什么。
着重编程技能。
面试不是比较，只是要找对的人。
挑战在于找到具有可用性、扩展性经验的人才，以应对 Tumblr 面临的网络拥塞。
在 Tumblr 工程博客（Tumblr Engineering Blog），他们对已过世的 Dennis Ritchie 和 John McCarthy 予以纪念。
经验及教训

自动化无处不在
MySQL（增加分片）规模，应用程序暂时还不行
Redis 总能带给人惊喜
基于 Scala 语言的应用执行效率是出色的
废弃项目——当你不确定将如何工作时
不顾用在他们发展经历中没经历过技术挑战的人，聘用有技术实力的人是因为他们能适合你的团队以及工作。
选择正确的软件集合将会帮助你找到你需要的人
建立团队的技能
阅读文档和博客文章。
多与同行交流，可以接触一些领域中经验丰富的人，例如与在 Facebook、Twitter、LinkedIn 的工程师多交流，从他们身上可以学到很多
对技术要循序渐进，在正式投入使用之前他们煞费苦心的学习 HBase 和 Redis。同时在试点项目中使用或将其控制在有限损害范围之内。
翻译：包研，张志平