微博类产品的架构难点

提问：目前国内很多互联网门户都在做微博产品，你觉得微博技术架构的主要难点在哪些方面？

回答：从复杂度上面来说，微博产品的业务是相对比较简单的，我认为它在技术架构上有两大要素：消息传递与缓存。

微博产品从产品性质上来说几乎完全就是一个消息分发平台，因此一个良好的消息传递机制是至关重要的。当一个用户发出消息之后，它可以被许多人观察到。对于一个名人来说，被数十万用户所追随是一件非常普通的事情。那么此时，如果期望所有的追随者都即时地看到消息这几乎是件不可能的事情，因此在实现时我们往往需要构建一个消息队列，将消息快速地派送至队列中等待处理，最终将这条消息“陆续地”显示在每个追随者的时间轴上。这里势必会产生延迟，但对于业务质量来说并非不可接受。但显然这个延迟也不可以太长，在Twitter上这个平均延迟是500毫秒，从绝对数值上看并不算太短，但也已够用。 Twitter在这方面的处理方式是利用Scala的Actor模型及Apache Mina编写了一个分布式的消息传输框架Kestrel，它具有快速、轻量（包括注释才不到2000行代码）、持久、稳定等特性，但不具备事务性，也不保证消息的顺序处理。因此可以这么说，Kestrel是一个Twitter根据自身需求“定制”出的消息传输机制。

另外一个要点便是每个大型系统都不可或缺的缓存机制。有人说缓存就好比万能膏药，哪儿不舒服就再哪儿擦点便能见效。这话有一定道理。如 Twitter便设计了相对复杂的多级缓存机制，几乎对于每个IO密集的地方都进行了缓存。例如记录ID序列的向量缓存（Vector Cache），纪录每条消息等具体内容的行缓存（Row Cache）。此外，由于它的API访问量很大，仅仅是从消息内容转化成API的输出形式（可能只是一些字符串连接操作）也会消耗较多代价，因此 Twitter还为消息的API输出形式设计了片断缓存（Fragment Cache）。最后自然还有对某些热门页面的页面缓存（Page Cache）。除了页面缓存之外，其他缓存的命中率都在95%以上，可见缓存机制对于Twitter系统的重要程度。值得注意的是，向量缓存及行缓存都是 Write Through的，这意味着基本上所有的新数据都在缓存中存在一份拷贝。正如Twitter的Evan Weaver在QCon London 2009会议上讲的那样：Everything runs from memory in Web 2.0。

最后，对于微博类应用来说，可能会因为某个突发事件造成访问量暴增的现象，如何抵抗住消息轰炸也是一个重要的课题。例如Twitter使用了云计算的方式来应对此类问题，在需要的时候它便会租用更多的计算资源。不过增加服务器只是纯硬件的投入，而架构设计能否顺利且充分地利用起新增的设备也是一个值得关注的地方。从这个角度看，一个高效的分布式消息传递机制在这里会扮演重要的角色。如果有了合适的消息机制，首先能够将消息负载较为容易地平衡至多台服务器上，其次即使是在压力增大的情况下，响应时间虽然会按线性增长，但是系统的吞吐量还是可以保持在正常的水平。