对应于每个短信，Mongrel已经从Vector MemCached那里知道，有哪些读者追这条短信的作者。Mongrel把这条短信的ID，逐个放进每位读者的队列，以及作者本人的队列。
5. 同一台Mongrel Server，或者另一台Mongrel Server，在处理某个Kestrel队列中的消息前，从这个队列的名称中解析出相应的用户ID，这个用户，既可能是读者，也可能是作者。
然后Mongrel从Kestrel队列中，逐个提取消息，解析消息中包含的短信ID。并从Row MemCached缓存器中，查找对应于这个短信ID的短信正文。
这时，Mongrel既得到了用户的ID，也得到了短信正文。接下去Mongrel就着手更新用户的主页，添加上这条短信的正文。
6. Mongrel把更新后的作者的主页，传递给正在空循环的Apache的进程。该进程把作者主页主动传送(push)给作者的浏览器。
如果读者的浏览器事先已经登录Twitter网站，建立连接，那么Apache给该读者也分配了一个进程，该进程也处于空循环状态。Mongrel 把更新后的读者的主页，传递给相应进程，该进程把读者主页主动传递给读者的浏览器。
咋一看，流程似乎不复杂。“水库”，“引流”和“渠道”，这抗洪三要素体现在哪里呢？盛名之下的Twitter，妙处何在？值得细究的看点很多。
Reference,
[26] Twitter user statistics by Purewire, June 2009.
()
[27] 截止2009年3月，中国移动用户数已达4.7亿户.
()
[28] 中国移动飞信网. ()
[29] 中国移动139说客网. ()
【6】流量洪峰与云计算
上一篇历数了一则短信从发表到被阅读，Twitter业务逻辑所经历的6个步骤。表面上看似乎很乏味，但是细细咀嚼，把每个步骤展开来说，都有一段 故事。
美国年度橄榄球决赛，绰号超级碗(Super Bowl)。Super Bowl在美国的收视率，相当于中国的央视春节晚会。2008年2月3日，星期天，该年度Super Bowl如期举行。纽约巨人队(Giants)，对阵波士顿爱国者队(Patriots)。这是两支实力相当的球队，决赛结果难以预料。比赛吸引了近一亿 美国人观看电视实况转播。
对于Twitter来说，可以预料的是，比赛进行过程中，Twitter流量必然大涨。比赛越激烈，流量越高涨。Twitter无法预料的是，流量 究竟会涨到多少，尤其是洪峰时段，流量会达到多少。
根据[31]的统计，在Super Bowl比赛进行中，每分钟的流量与当日平均流量相比，平均高出40%。在比赛最激烈时，更高达150%以上。与一周前，2008年1月27日，一个平静 的星期天的同一时段相比，流量的波动从平均10%，上涨到40%，最高波动从35%，上涨到150%以上。
Figure 8. Twitter traffic during Super Bowl, Sunday, Feb 3, 2008 [31]. The blue line represents the percentage of updates per minute during the Super Bowl normalized to the average number of updates per minute during the rest of the day, with spikes annotated to show what people were twittering about. The green line represents the traffic of a “regular” Sunday, Jan 27, 2008.
Courtesy
由此可见，Twitter流量的波动十分可观。对于Twitter公司来说，如果预先购置足够的设备，以承受流量的变化，尤其是重大事件导致的洪峰 流量，那么这些设备在大部分时间处于闲置状态，非常不经济。但是如果缺乏足够的设备，那么面对重大事件，Twitter系统有可能崩溃，造成的后果是用户 流失。
怎么办？办法是变买为租。Twitter公司自己购置的设备，其规模以应付无重大事件时的流量压力为限。同时租赁云计算平台公司的设备，以应付重大 事件来临时的洪峰流量。租赁云计算的好处是，计算资源实时分配，需求高的时候，自动分配更多计算资源。
Twitter公司在2008年以前，一直租赁Joyent公司的云计算平台。在2008年2月3日的Super Bowl即将来临之际，Joyent答应Twitter，在比赛期间免费提供额外的计算资源，以应付洪峰流量[32]。但是诡异的是，离大赛只剩下不到4 天，Twitter公司突然于1月30日晚10时，停止使用Joyent的云计算平台，转而投奔Netcraft [33,34]。
Twitter弃Joyent，投Netcraft，其背后的原因是商务纠葛，还是担心Joyent的服务不可靠，至今仍然是个谜。
变买为租，应对洪峰，这是一个不错的思路。但是租来的计算资源怎么用，又是一个大问题。查看一下[35]，不难发现Twitter把租赁来的计算资 源，大部分用于增加Apache Web Server，而Apache是Twitter整个系统的最前沿的环节。