随着信息爆炸的加剧，微博客网站Twitter横空出世了。用横空出世这个词来形容Twitter的成长，并不夸张。从2006年5月 Twitter上线，到2007年12月，一年半的时间里，Twitter用户数从0增长到6.6万。又过了一年，2008年12月，Twitter的用 户数达到5百万。[1]
Twitter网站的成功，先决条件是能够同时给千万用户提供服务，而且提供服务的速度要快。[2,3,4]
有观点认为，Twitter的业务逻辑简单，所以竞争门槛低。前半句正确，但是后半句有商榷余地。Twitter的竞争力，离不开严谨的系统架构设 计。
【1】万事开头易
Twitter的核心业务逻辑，在于Following和Be followed。[5]
进入Twitter个人主页，你会看到你following的那些作者，最近发表的微博客。所谓微博客，就是一则短信，Twitter规定，短信的 长度不得超过140个字。短信不仅可以包含普通文字信息，也可以包含URL，指向某个网页，或者照片及视频等等。这就是following的过程。
当你写了一则短信并发表以后，你的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服务器， 检查正在看的这个个人主页是否有更新。如果有更新，立刻下载新的主页内容。这样follower就能读到最新发表的短信了。
从作者发表到读者获取，中间的延迟，取决于JavaScript更新的间隔，以及Twitter服务器更新每个follower的主页的时间。
从系统架构上来说，似乎传统的三段论(Three-tier architecture [6])，足够满足这个业务逻辑的需要。事实上，最初的Twitter系统架构，的确就是三段论。
Reference：
[1] Fixing Twitter. （?cid=100777）
[2] Twitter blows up at SXSW conference. （）
[3] First Hand Accounts of Terrorist Attacks in India on Twitter and Flickr. （）
[4] Social Media Takes Center Stage in Iran. （）
[5] Twitter的这些那些. () ()
[6] Three tier architecture.
【2】三段论
网站的架构设计，传统的做法是三段论。所谓“传统的”，并不等同于“过时的”。大型网站的架构设计，强调实用。新潮的设计，固然吸引人，但是技术可 能不成熟，风险高。所以，很多大型网站，走的是稳妥的传统的路子。
2006年5月Twitter刚上线的时候，为了简化网站的开发，他们使用了Ruby-On-Rails工具，而Ruby-On-Rails的设计 思想，就是三段论。
1. 前段，即表述层(Presentation Tier) 用的工具是Apache Web Server，主要任务是解析HTTP协议，把来自不同用户的，不同类型的请求，分发给逻辑层。
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，姓名，登录名和密码，状态（在线与否）。
2. 短信表：短信ID，作者ID，正文（定长，140字），时间戳。
3. 用户关系表，记录追与被追的关系：用户ID，他追的用户IDs (Following)，追他的用户IDs (Be followed)。
再说中段，逻辑层。
当用户发表一条短信的时候，执行以下五个步骤，
1. 把该短信记录到“短信表” 中去。
2. 从“用户关系表”中取出追他的用户的IDs。
3. 有些追他的用户目前在线，另一些可能离线。在线与否的状态，可以在“用户表”中查到。过滤掉那些离线的用户的IDs。
4. 把那些追他的并且目前在线的用户的IDs，逐个推进一个队列(Queue)中去。
5. 从这个队列中，逐个取出那些追他的并且目前在线的用户的IDs，并且更新这些人的主页，也就是添加最新发表的这条短信。