Twitter的增容处理

文/Patrick Joyce译/杨昊

       由于之前爆发的一些问题，大家产生了对Twitter的成见。并不是说对Rails进行增容很难，实际上针对基于Rails的网站进行增容并不是问题所在，对所有的网站来讲，增容从来都不是一个容易的问题。

      Twitter的故事  

Twitter源自于ODEO公司的一个小的分支项目，它是Jack Dorsey提出的，并且成为了世界上最大的Rails应用。Jack Dorsey 对AIM的状态消息十分着迷。问题在于，如果想把消息发到世界的各个角度，你必须得坐在电脑前面。

Twitter自去年三月发布之后访问量少得可怜，直到去年的西南偏南音乐节，大家都能从大屏幕上看到Twitter的使用过程，自此之后一下火了起来，访问量骤增。然后又平静了一阵。接着媒体技术粉墨登场，又掀起了一股热潮。

       所以，你该怎样面对这些呢？

l  更多的主机—仍旧是一个包含主/从副本的数据库

l  Joyent网站提供的具有32个CPU核的SUN主机

l  横跨19个CPU核的120个mongrel实例

l  横跨16个CPU核的消息处理

l  横跨2核的Jabber服务实例

l  一个构建于8核主机之上的MySQL实例

l  16GB以上的memcache应用

为何需要这些呢？

l  平均每秒200-300的连接数量

l  高峰期每秒800个连接

l  它们处理了11000个连接

l  MySQL每秒处理2400个

l  Alexe（有所保留地）说他们有着巨大的流量，那还没计算占用了很大流量的API访问。在他们最新的一次测试中通过API的流量访问是web流量的20倍

       而配备了cache_fu与acts_as_cached这两个Rails插件的Memcache成了他们的救星。此外，他们还使用扩展了的cache_stats插件获取状态。

       他们写了一个自定义的API缓存插件，在执行过滤之前和之后完成自定义操作。他们打算共享抽取出来的缓存。如何使缓存失效是这样做的一个难点。他们既做基于时间的过期限制，也做事件驱动的过期限制。

       在数据库设计方面，诸如一些ID列表之类，他们采取了反正规化（denormalize）的方式。通过对id列表进行缓存，这样避免了数据库中的连接操作，这为他们减轻了许多数据库方面的压力。      

       他们与Gmail的创建人Paul Buchheit在处理系统缓存时，如何构建一个健壮的分布式队列。因为此前他们的架构工作做的有些过多了。一秒钟会有多少条消息呢？9条。6个月的时间里又能有多少？这个系数是10。只要将他们扔到磁盘里面进行处理就好了。

他们希望能够开放队列系统的源代码。它是基于memecache系统的。通过memcache，任何消息都可以加入到队列中，并使用memcache客户端进行访问。

       他们所做的最有帮助的事情之一，就是与社区之间的讨论和互动。你不能总猫在你的办公室。社区能够提供很多帮助。和他们进行讨论，你可以得到众多的顾问。社区中有太多优秀的人了，你没有理由不去借助他们的帮助。

问答环节

问：对于缓存中的事件驱动失效机制，其相关的逻辑是放在什么地方的？在Mongrel里面？还是在Rails和XMPP的集成里面？

答：是放在Jabber服务器中，它可以将这些以Ruby写就的处理客户端完全隔离开来。

问：他们打算什么时候加入分区机制？如何处理用户间的随机关系？

答：用户不是关键。他们仍未进行分区的原因是，他们想要基于时间进行划分，因为大多数请求从时间上看是本地的。他们计划在未来3到4个月里做这件事情。Oracle完成了这工作，但Alex说他宁肯把自己的帽子吃掉，也决不会去买oracle的许可证。所以当他们解决了之后就会推出来。

试着尽量发现如何高效地开展开源工作，并努力去多做一些。

问：你的商业模式是什么？计划如何赚钱？

答：每个人都在问这个问题。简单点回答就是下一个问题（大笑）。他们有一些想法，这些聪明人们正在做一些事情。它一定能够让大家耳目一新。

问：他们有多少eJabberd节点？

答：很多，多得令人吃惊。

问：在eJabberd和rail用户之间进行同步会有问题吗？

答：不会。

问：有了所有这些mongrel，你们是如何完成部署并保证全部正常运行的？

答：他们希望从观众中得到建议。他们付出了很多努力，做了复查和改进。如果你在他们进行部署的时候是连接着的，你会与500个用户相联。这是很惊人的。他们仍没有一个很好的办法来解决这个。对于Mongrel中的队列，他们由Ezra的一个讲演中受到了启发。

问：这么说当你重启的时候你便杀掉了所有的mongrel进程，或是作了一次“回滚”？有些公司就是采取了回滚的方式来解决问题。

答：他们关掉了所有进程，因为队列在mongrel之中，若他们那样做就会填满了所有队列。他们这样尝试过，但得到的结果却是乱七八糟的。

问：怎样看待“Twitter是愚蠢的，因为他们没有采用ETag”这种说法？

答：他们确实在用ETag，但并不起作用，因为它们在末尾有一个显示消息请求时间的时间戳。Web流量的分块小得足以将其忽略不计了。Yahoo高性能小组（High Performance group）在演示中提到了它是无关紧要的。

问：ETag不会对API缓存有帮助吗？

答：只有在客户端执行它们时才可以，大多数情况下是没有帮助的。

问：下一步目标？

答：回调API有很大潜力。第三方的开发人员在打算做这件事。让我们期待着把。

       我们热爱XMPP，并在和Jabber社区的人们一起努力通过一些很cool的新方法来使用Jabber以推进其发展。