为什么Twitter很少把租赁来的计算资源，分配给Mongrel Rails Server，MemCached Servers，Varnish HTTP Accelerators等等其它环节？在回答这个问题以前，我们先复习一下前一章“数据流与控制流”的末尾，Twitter从写到读的6个步骤。
这6个步骤的前2步说到，每个访问Twitter网站的浏览器，都与网站保持长连接。目的是一旦有人发表新的短信，Twitter网站在500ms 以内，把新短信push给他的读者。问题是在没有更新的时候，每个长连接占用一个Apache的进程，而这个进程处于空循环。所以，绝大多数Apache 进程，在绝大多数时间里，处于空循环，因此占用了大量资源。
事实上，通过Apache Web Servers的流量，虽然只占Twitter总流量的10%-20%，但是Apache却占用了Twitter整个服务器集群的50%的资源[16]。 所以，从旁观者角度来看，Twitter将来势必罢黜Apache。但是目前，当Twitter分配计算资源时，迫不得已，只能优先保证Apache的需 求。
迫不得已只是一方面的原因，另一方面，也表明Twitter的工程师们，对其系统中的其它环节，太有信心了。
在第四章“抗洪需要隔离”中，我们曾经打过一个比方，“在晚餐高峰时段，餐馆常常客满。对于新来的顾客，餐馆服务员不是拒之门外，而是让这些顾客在 休息厅等待”。对于Twitter系统来说，Apache充当的角色就是休息厅。只要休息厅足够大，就能暂时稳住用户，换句行话讲，就是不让用户收到 HTTP-503的错误提示。
稳住用户以后，接下去的工作是高效率地提供服务。高效率的服务，体现在Twitter业务流程6个步骤中的后4步。为什么Twitter对这4步这 么有信心？
Reference,
[16] Updating Twitter without service disruptions.
()
[30] Giants and Patriots draws 97.5 million US audience to the Super Bowl. ()
[31] Twitter traffic during Super Bowl 2008.
()
[32] Joyent provides Twitter free extra capacity during the Super Bowl 2008.
()
[33] Twitter stopped using Joyent’s cloud at 10PM, Jan 30, 2008. ()
[34] The hasty divorce for Twitter and Joyent.
()
[35] The usage of Netcraft by Twitter.
(?url=http://twitter.com)
【7】作为一种进步的不彻底
不彻底的工作方式，对于架构设计是一种进步。
当一个来自浏览器的用户请求到达Twitter后台系统的时候，第一个迎接它的，是Apache Web Server。第二个出场的，是Mongrel Rails Server。Mongrel既负责处理上传的请求，也负责处理下载的请求。Mongrel处理上传和下载的业务逻辑非常简洁，但是简洁的表象之下，却蕴 含着反常规的设计。这种反常规的设计，当然不是疏忽的结果，事实上，这正是Twitter架构中，最值得注意的亮点。
Figure 9. Twitter internal flows
Courtesy
所谓上传，是指用户写了一个新短信，上传给Twitter以便发表。而下载，是指Twitter更新读者的主页，添加最新发表的短信。Twitter下载 的方式，不是读者主动发出请求的pull的方式，而是Twitter服务器主动把新内容push给读者的方式。先看上传，Mongrel处理上传的逻辑很 简洁，分两步。
1. 当Mongrel收到新短信后，分配一个新的短信ID。然后把新短信的ID，连同作者ID，缓存进Vector MemCached服务器。接着，把短信ID以及正文，缓存进Row MemCached服务器。这两个缓存的内容，由Vector MemCached与Row MemCached在适当的时候，自动存放进MySQL数据库中去。
2. Mongrel在Kestrel消息队列服务器中，寻找每一个读者及作者的消息队列，如果没有，就创建新的队列。接着，Mongrel把新短信的ID，逐 个放进“追”这位作者的所有在线读者的队列，以及作者本人的队列。
品味一下这两个步骤，感觉是Mongrel的工作不彻底。一，把短信及其相关IDs，缓存进Vector MemCached和Row Cached就万事大吉，而不直接负责把这些内容存入MySQL数据库。二，把短信ID扔进Kestrel消息队列，就宣告上传任务结束。Mongrel 没有用任何方式去通知作者，他的短信已经被上传。也不管读者是否能读到新发表的短信。
为什么Twitter采取了这种反常规的不彻底的工作方式？回答这个问题以前，不妨先看一看Mongrel处理下载的逻辑。把上传与下载两段逻辑联 系起来，对比一下，有助于理解。Mongrel下载的逻辑也很简单，也分两步。
1. 分别从作者和读者的Kestrel消息队列中，获得新短信的ID。