Tumblr：150亿月浏览量背后的架构挑战（下）
原文地址
http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html
转自： http://cloud.csdn.net/a/20120215/311867.html
导读：和许多新兴的网站一样，著名的轻博客服务Tumblr在急速发展中面临了系统架构的瓶颈。每天5亿次浏览量，峰值每秒4万次请求，每天3TB新的数据存储，超过1000台服务器，这样的情况下如何保证老系统平稳运行，平稳过渡到新的系统，Tumblr正面临巨大的挑战。近日，HighScalability网站的Todd Hoff采访了该公司的分布式系统工程师Blake Matheny，撰文系统介绍了网站的架构，内容很有价值。我们也非常希望国内的公司和团队多做类似分享，贡献于社区的同时，更能提升自身的江湖地位，对招聘、业务发展都好处多多。欢迎通过@CSDN云计算的微博向我们投稿。
以下为译文的第二部分，第一部分在这里（括号内小号字为CSDN编辑所注）：
内部的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。同时在试点项目中使用 或将其控制在有限损害范围之内。
翻译：包研，张志平
转自： http://cloud.csdn.net/a/20120215/311867.html
导读：和许多新兴的网站一样，著名的轻博客服务Tumblr在急速发展中面临了系统架构的瓶颈。每天5亿次浏览量，峰值每秒4万次请求，每天3TB新的数据存储，超过1000台服务器，这样的情况下如何保证老系统平稳运行，平稳过渡到新的系统，Tumblr正面临巨大的挑战。近日，HighScalability网站的Todd Hoff采访了该公司的分布式系统工程师Blake Matheny，撰文系统介绍了网站的架构，内容很有价值。我们也非常希望国内的公司和团队多做类似分享，贡献于社区的同时，更能提升自身的江湖地位，对招聘、业务发展都好处多多。欢迎通过@CSDN云计算的微博向我们投稿。
以下为译文的第二部分，第一部分在这里（括号内小号字为CSDN编辑所注）：
内部的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。同时在试点项目中使用 或将其控制在有限损害范围之内。
翻译：包研，张志平