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以推进其发展。