Twitter遇到的麻烦

从用户增长和媒体反映的角度来看， Twitter 是一个很令人惊叹的成功故事。我很有幸能和开发团队谈过他们富有挑战性的开发经历。那个时候，他们需要在只有很少缓存的16块芯片情况下，巧妙的处理超过11000次每秒的访问请求。毫无疑问，他们的网站那个时候会感觉有些慢。

 

听起来他们那个时候有一个很好的解决方案。放进来几台新的服务器，想办法引入实质性的缓存，而且实现多个数据库服务器。这也是大多数正常的快速成长的网站采用的解决方法。

 

不过看起来最起码有一个开发人员觉得这种标准的扩容方法需要太多的工作，决定把他的想法在 一个采访 里面拿出来共享。

 

速度过慢的解决方案是把所有的琐碎细节都缓存起来，同时设立数个只读的从属数据库，这些没有一个是很短时间内就能实现的。所以说这个不是费用，而是时间的问题，因为在用户无法访问你的网站的时候，时间是更加宝贵。没有任何一个扩容的方法是比在Rails上开发更加简单有有意思。

 

在某种程度上，我能够理解这种感触。Rails让开发的过程变成一个开心的过程，但是当你需要经历所有其他开发环境同样的扩容过程时，这个对比会显得很突兀。或许这是一个自然的反应来为这个反差找一个替罪羊，而无论这个替罪羊（Rails）是多么的自然。

 

但是我还是要对采访里面提到的两点发表一下意见。第一，Alex提到增加更多的服务器来对系统进行扩容最终会导致给数据库带来很大的压力。这绝对是正确的，但是也是意料之中的结果，而不是事先完全没有考虑到负面效应。这不应该有任何值得大惊小怪的地方。

 

扩容就是一个削除瓶颈的方法。当你消除一个瓶颈的时候（比如说应用代码的执行），你多半可能发现另外一个瓶颈（比如数据库的查询）。这很正常，代表你已经取得了进展。但是你再消除这个新的瓶颈的时候，必须保持你的思路正确。如果你的瓶颈已经转移到数据库方面，那即使你大大的改进程序结构，也不会看到很显著的成效。换句话说，如果数据库一次查询需要0.5秒，那你把一个循环从耗时0.05秒改进到0.01秒就完全没有花时间来做了。

 

其次，当你在使用开源软件，发现有些要求是这个软件无法达到的时候，这就是你给开源软件作回报的大好机会。与其坐在原地等待某些厂家来解决你的问题，使用开源软件会给你独特的机会，来做自己命运的主人。与其作这个社区的旁观者，不如作一个参与者。对于用高级编程语言（比如说Ruby）实现的程序框架Rails,以上的话尤其贴切，因为作贡献的门槛非常的低。

 

在这个例子里面，看起来Twitters需要更多的复杂的手段，来同时和多个数据库进行交谈。Alex还专门强调“…Rails没有功能来和多个数据库同时进行交谈”，这不完全正确，但是Rails肯定可以可以做的更好。上次我和Twitter聊得时候，我们还讨论过这个，他们也对能够在Rails的这个领域更上一步很感兴趣。我很失望看到他们放弃了这个机会，而选择了保守旁观。

 

不论如何，我很自豪Twitter正在努力的挑战Rails扩容的上线。处理每秒一万一千次以上的请求，对任何动态网站应用而言都不是小成就了。一旦现在需要处理这个危机的压力消失以后，我相信Twitter的开发团队会跳出指责软件工具的圈子，而会作为参与者，完全的融入到Rails开发这个开源社区里来，贡献出他们在这次扩容的过程学到的经验和教训。我们都会因此受益。