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

　　第一代网络通讯，源于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。

　　Twitter.com网站目前的大体状况：

　　●网站有至少35万使用者，有的媒体估计高达500万，不过具体的数值还不得而知。

　　●Twitter.com平均每秒有600次请求，每秒有200-300个连接，最高时候是800个。

　　●MySQL每秒钟处理2400个请求。一共有一台主的MySQL服务器，采用8核心的Sparc芯片，还有一台附属服务器。附属服务器只处理简单的统计和报告。

　　●除了MySQL服务器之外，还有8台SUN服务器X4100。

　　●在Rails中处理一个要求的时间，在200毫秒内。其中花在数据库的平均时间为50-100毫秒。

　　●高性能分布式的内存对象缓存系统memcached占有了16GB空间。

　　学习总结：

　　Twitter.com经过一系列的部署，现在已经可以稳定的面对巨大的流量了。我们从中能够学到的东西有很多。

　　首先，Twitter非常开放，它将自己遇到的问题全部在网络社区上讨论，很多IT相关的人员都给出了自己的解决方法，不少普通用户也给出了建议。这些都是免费的，也很大程度上促进了Twitter.com的进步。当然，诚如上文所说，有一些方法，是采取了他人建议而部署的，也不是特别理想，所以建议是要采纳的，但是还一定要有自己的思想和主线。

　　Twitter以前宕机多是因为疯狂的用户举动，这一点很有趣。不仅是在互联网，在公司内部的IT中，也总有极个别用户会想尽办法来搞点鬼，要有方案预先对他们的行为做以限制。还有，最好要确保你的应用是容易分区的，这样你就有将来扩展系统的制高点。

　　数据库一定要经常优化。尽可能的将内容都编进目录，Rails可不会自动为你做这些。另外，Twitter也非常强调测试的重要性，现在Twitter已经有了一整套完善的测试方法，来辨别哪些应用是值得部署的，哪些最好淘汰。我们也发现 Twitter对各种各样的方法都做过尝试，很多方法也不是很理想，但是勇于尝新的精神的确值得我们学习。

　　Twitter.com在西方非常火爆，目前中国也有了数十家网站竞相模仿，但是相信只有架构完善、服务周全、切入点准确的模仿者才能够最终生存发展。而对于我们广大服务器使用者而言，Twitter的充分沟通，勇于尝试，开放，和许多部署细节，也都给我们上了生动的一课。