流量提升 服务器配置有妙法

第一代网络通讯，源于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 请求就可以提速了。

　　消息：

　　Twitter的角色归根结底，是一个信息桥梁。Twitter可以为Web、手机短信、和IM软件的信息提供一个互通的平台。其释放缓存的策略，是和Ruby的Send Message同步释放缓存，而不是单独的释放，这有助于提升Twitter在消息策略配置上的灵活性。网站也采用了DRb(Distributed Ruby，分布式Ruby)，library允许通过TCP/IP，跟远端Ruby目标发送和接收Message。不过，这样的结构可能也不是很完美。工程师们也尝试Rinda，一个tuplespace模型的分享队列，但也有缺点，队列是持续的，如果实效，消息可能将丢失。工程师还尝试过使用 Erlang语言。他们最后采用由Ruby写成的分布式消息队列Starling，分布式队列可以避免系统崩溃。很多大型网站都在使用这种简单的方法。手机短信则由第三方网关的API处理。

　　一些部署策略：

　　工程师们采用了新的mongrel服务器，不过这些mongrel的部署，是闪电式部署，因为缓慢的逐一部署可能会导致过多队列在现有的mongrel之中，进而堵塞mongrel。

　　流量增大后，twitter遇到过许多次宕机，经过研究后表明，大多数宕机并非不是twitter自身的问题。宕机源自个别的用户非常疯狂，可以在24 小时之内添加9000个好友，而这也是twitter始料未及的。所以后来twitter添加了用户监控，一旦发现哪个用户行为异常，该用户将被立即删除。

　　Twitter未来改进方向是分区。但暂时还没有具体的分区时间表，因为Twitter的改进已经足够应对当前流量了。那么 Twitter中哪部分最重要呢?显然是Twitter API。由于Twitter的特殊性，API的流量几乎是Twitter网站流量的10倍，结构和普通网站区别很大。所以，保持一个简单开放的基础架构，才可以使很多开发者加入其中，并且能有更好的主意来改进Twitter。