第一代网络通讯，源于1996年4个以色列人发明的IM(Instant Message)鼻祖–ICQ“坏小子”，其初衷是方便他们4个朋友之间的沟通。但是出乎所有人的意料，ICQ其后的发展可谓是顺风顺水，用户增长一发不可收拾，其后QQ、MSN Messenger、AOL Instant Messenger、Yahoo! Messenger、NET Messenger Service、Jabber等等一大批IM软件占据了互联网发展史的重要地位。相信多数读者朋友上网的第一件事情，不是阅读电子邮件，而是打开QQ或者MSN，这些IM已经成为我们生活中不可缺少的部分。

　　在IM软件风靡全球之后，大约2、3年前，BLOG又开始流行。BLOG这种公开的日记在悄然改变我们的生活——我们开始将喜怒哀乐都尽情倾诉到互联网上，也会因为有人回复了自己的BLOG而感觉兴奋和亲切，并且乐此不疲。不过，博客也并不是网络通讯的终结。2007年，从美国开始刮起了新一代网络通讯旋风——Twitter。Twitter是架构在IM、BLOG和手机之上的崭新网络服务模式，这是可以让你播报短消息给你的朋友或“followers(跟随者)”的一个在线服务，它也同样允许你指定你想跟随的Twitter用户，这样你在一个页面上就能读取他们发布的信息。所有的Twitter消息都被限制在140个字符之内，可用手机发送。Twitter.com于2007年登上了美国《商业周刊》和《PC Magazine》，而中国的《财经时报》、《环球企业家》等等媒体也都对其进行了报道，时下，Twitter.com已经成为最热门的网站。

　　Twitter到底有多热门呢?仅仅成立一年，Alexa的全球排名已经从10万开外，上升到了目前的500名左右，而且势头有增无减。排名的上升势也意味着流量的增加，如compete所示，twitter.com的访问人数在一年间上升了数百倍。

　　Twitter的火爆情况超出了其创始人的意料。最开始Twitter.com的平台采用的是Ruby on Rails(RoR)，该平台在用户较少的时候运行良好。但是当用户激增的时候，公司内对是否应该继续采用RoR平台展开了讨论。如果是采用其他的语言和框架，站点速度可能会有所提升，但是提升幅度可能仅仅是10%~20%，对比数百倍流量的增加，语言和框架改变无疑杯水车薪，显然这并非问题的关键。最终，公司决定保留RoR，而在服务器架构配置上做足文章，最后完美的达成了扩展。我们下面就来详细研究一下。 为扩展所做的努力：

　　监控：

　　当Twitter流量激增的时候，一系列的问题都出现了。各个程序经常失效，网站非常不稳定。更糟糕的是，开始的Twitter没有监听，没有图表，甚至连统计也没有。所以问题出在哪一部分，到底是软件还是硬件，网站管理员经常也不清不楚，解决一个问题往往需要花上很长时间。所以，网站决定部署Munin和Nagios。Munin 是一个基于 Web 界面的系统监视工具，使用它你可以即时了解系统的性能和状况。Munin 主要对系统、进程、网络、磁盘等方面进行监视，从中你可以随时观测文件系统的占用情况、网络流量、进程、CPU 及内存负载情况等等。Nagios也是监视程序，向较之下，Munin可能偏重服务器整体状况，而Nagios则可能对于网络状况的监视更偏重一些。其实，整个Twitter网站架构基础是Solaris操作系统，而对于Munin和 Nagios，运行在Unix Solaris下可能有些问题，这两款监控毕竟不是为Unix环境定做的。该网站也同时采用免费的Google Analytics监控，Twitter的网站工程师认为这些监控解决方法都不是特别理想，不过虽然不够完善，但有了监控还是使问题解决更加便捷。

　　缓存：

　　Twitter是一个互动性很强的网站，用户随时都会去检索其他用户的情况——对方过去都说了什么话?什么时间留的言? 

　　当用户数量增加的时候，这种检索需求的增长要比用户数增长大得多——因为每个用户都开始有越来越多的好友，旧的检索系统不堪重负。这个时候，Twitter采用缓存的办法来处理。据一个例子，如果获得一个count可能很慢，但是这个count缓存到memcache只需要1毫秒，却能够减少数据库调用，加快速度。实际上，获得一个好友的动态资料的过程是比较复杂的，有安全和其他方面的很多问题。所以好友动态资料被更新之后放入缓存，而不接触数据库。这样的流程提供了一个可以预测响应时间的结构(上限是20毫秒)。至于ActiveRecord目标没有被缓存，是因为这些目标太大了。

　　由于Twitter通常是与各种IM、Blog、手机捆绑在一起，其实90%的请求都是来自于API 。这样一来缓存的目标就很明确了，前端不用做任何碎片和页面的缓存，只去缓存API 请求就可以提速了。