系统架构学习 Twitter系统架构设计分析

blog.haohtml.com http://blog.haohtml.com/archives/6453

2010/10/30

解剖解剖Twitter：：Twitter系统架构设计分析系统架构设计分析

随着信息爆炸的加剧，微博客网站Twitter横空出世了。用横空出世这个词来形容Twitter的成长，并不夸张。从2006年5

月Twitter上线，到2007年12月，一年半的时间里，Twitter用户数从0增长到6.6万。又过了一年，2008年12月，Twitter

的用户数达到5百万。[1]

Twitter网站的成功，先决条件是能够同时给千万用户提供服务，而且提供服务的速度要快。[2,3,4]

有观点认为，Twitter的业务逻辑简单，所以竞争门槛低。前半句正确，但是后半句有商榷余地。Twitter的竞争力，离

当你写了一则短信并发表以后，你的followers会立刻在他们的个人主页中看到你写的最新短信。这就是be followed的

过程。

实现这个业务流程似乎很容易。

1. 为每一个注册用户订制一个Be-followed的表，主要内容是每一个follower的ID。同时，也订制一个Following的表，

主要内容是每一个following作者的ID。

2. 当用户打开自己的个人空间时，Twitter先查阅Following表，找到所有following的作者的ID。然后去数据库读取每一

位作者最近写的短信。汇总后按时间顺序显示在用户的个人主页上。

3. 当用户写了一则短信时，Twitter先查阅Be-followed表，找到所有followers的IDs。然后逐个更新那些followers的主

页。

如果有follower正在阅读他的Twitter个人主页，主页里暗含的JavaScript会自动每隔几十秒，访问一下Twitter服务器，

Reference：

[1] Fixing Twitter. （http://www.bookfm.com/courseware/coursewaredetail.html?cid=100777）

[2] Twitter blows up at SXSW conference. （http://gawker.com/tech/next-big-thing/twitter-blows-up-at-sxsw-

conference-243634.php）

[3] First Hand Accounts of Terrorist Attacks in India on Twitter and Flickr.

（http://www.techcrunch.com/2008/11/26/first-hand-accounts-of-terrorist-attacks-in-india-on-twitter/）

[4] Social Media Takes Center Stage in Iran. （http://www.findingdulcinea.com/news/technology/2009/June/Twitter-

on-Iran-a-Go-to-Source-or-Almost-Useless.html）

[5] Twitter的这些那些. (http://www.ccthere.com/article/2363334) (http://www.ccthere.com/article/2369092)

[6] Three tier architecture. http://en.wikipedia.org/wiki/Multitier_architecture

的，不同类型的请求，分发给逻辑层。

2. 中段，即逻辑层 (Logic Tier）用的工具是Mongrel Rails Server，利用Rails现成的模块，降低开发的工作量。

3. 后段，即数据层 (Data Tier) 用的工具是MySQL 数据库。

先说后段，数据层。

Twitter 的服务，可以概括为两个核心，1. 用户，2. 短信。用户与用户之间的关系，是追与被追的关系，也就是

Following和Be followed。对于一个用户来说，他只读自己“追”的那些人写的短信。而他自己写的短信，只有那些“追”自

己的人才会读。抓住这两个核心，就不难理解 Twitter的其它功能是如何实现的[7]。

围绕这两个核心，就可以着手设计Data Schema，也就是存放在数据层(Data Tier)中的数据的组织方式。不妨设置三

个表[8]，

1. 用户表：用户ID，姓名，登录名和密码，状态（在线与否）。

3. 有些追他的用户目前在线，另一些可能离线。在线与否的状态，可以在“用户表”中查到。过滤掉那些离线的用户的

IDs。

4. 把那些追他的并且目前在线的用户的IDs，逐个推进一个队列(Queue)中去。

5. 从这个队列中，逐个取出那些追他的并且目前在线的用户的IDs，并且更新这些人的主页，也就是添加最新发表的这

条短信。

以上这五个步骤，都由逻辑层(Logic Tier)负责。前三步容易解决，都是简单的数据库操作。最后两步，需要用到一个

辅助工具，队列。队列的意义在于，分离了任务的产生与任务的执行。

队列的实现方式有多种，例如Apache Mina[9]就可以用来做队列。但是Twitter团队自己动手实现了一个队列，Kestrel

[10,11]。Mina与Kestrel，各自有什么优缺点，似乎还没人做过详细比较。

不管是Kestrel还是Mina，看起来都很复杂。或许有人问，为什么不用简单的数据结构来实现队列，例如动态链表，甚

发器无意义。但是如果逻辑层由多台机器组成，什么样的请求，发给逻辑层里面哪一台机器，就大有讲究了。逻辑层

里众多机器，可能各自专门负责特定的功能，而在同功能的机器之间，要分摊工作，使负载均衡。

访问Twitter网站的，不仅仅是浏览器，而且还有手机，还有像QQ那样的电脑桌面工具，另外还有各式各样的网站插

件，以便把其它网站联系到Twitter.com上来[12]。因此，Twitter的访问者与Twitter网站之间的通讯协议，不一定是

HTTP，也存在其它协议。

三段论的Twitter架构，主要是针对HTTP协议的终端。但是对于其它协议的终端，Twitter的架构没有明显地划分成三

段，而是把表述层和逻辑层合二为一，在Twitter的文献中，这二合一经常被称为“API”。

综上所述，一个能够完成Twitter基本功能的，简单的架构如Figure 1 所示。或许大家会觉得疑惑，这么出名的网站，

架构就这么简单？Yes and No，2006年5月Twitter刚上线的时候，Twitter架构与Figure 1差距不大，不一样的地方在于

加了一些简单的缓存(Cache)。即便到了现在，Twitter的架构依然可以清晰地看到Figure 1 的轮廓。

[10] Kestrel Readme (http://github.com/robey/kestrel)

[11] A Working Guide to Kestrel. (http://github.com/robey/kestrel/blob/master/docs/guide.md)

[12] Alphabetical List of Twitter Services and Applications

(http://en.wikipedia.org/wiki/List_of_Twitter_services_and_applications)

【【3】】Cache == Cash

Cache == Cash，缓存等于现金收入。虽然这话有点夸张，但是正确使用缓存，对于大型网站的建设，是至关重要的

大事。网站在回应用户请求时的反应速度，是影响用户体验的一大因素。而影响速度的原因有很多，其中一个重要的

原因在于硬盘的读写(Disk IO)。

Table 1 比较了内存(RAM)，硬盘(Disk)，以及新型的闪存(Flash)，在读写方面的速度比较。硬盘的读写，速度比内存

的慢了百万倍。所以，要提高网站的速度，一个重要措施是尽可能把数据缓存在内存里。当然，在硬盘里也必须保留

Figure 2. Twitter architecture with Cache

Courtesy http://farm3.static.flickr.com/2783/4065827637_bb2ccc8e3f_o.png

哪里需要缓存？越是Disk IO频繁的地方，越需要缓存。

前面说到，Twitter业务的核心有两个，用户和短信(Tweet)。围绕这两个核心，数据库中存放着若干表，其中最重要的

有三个，如下所示。这三个表的设置，是旁观者的猜测，不一定与Twitter的设置完全一致。但是万变不离其宗，相信

即便有所不同，也不会本质区别。

1. 用户表：用户ID，姓名，登录名和密码，状态（在线与否）。

2. 短信表：短信ID，作者ID，正文（定长，140字），时间戳。

3. 用户关系表，记录追与被追的关系：用户ID，他追的用户IDs (Following)，追他的用户IDs (Be followed)。

有没有必要把这几个核心的数据库表统统存放到缓存中去？Twitter的做法是把这些表拆解，把其中读写最频繁的列放