|
流量提升逾百倍 服务器配置有妙法(2)
缓存：
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个。
|
搜索相关内容
精彩文章
