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

发布时间：2016-09-27 11:40:38 所属栏目：系统来源：csdn.net

导读：副标题#e# 导读：和许多新兴的网站一样，著名的轻博客服务Tumblr在急速发展中面临了系统架构的瓶颈。每天5亿次浏览量，峰值每秒4万次请求，每天3TB新的数据存储，超过1000台服务器，这样的情况下如何保证老系统平稳运行，平稳过渡到新的系统，Tumblr正面临

每个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中读取数据。一个分层的数据复制计划。这可以帮助迁移到多个数据中心。

在纽约启动运作

纽约具有独特的环境，资金和广告充足。招聘极具挑战性，因为缺乏创业经验。