设计要点：
1）DB只作为持久化容器，一切操作在逻辑层完成
2）异步，前端的请求只要在中间server上完成就好，后续的持久化由LazyWriter完成（定时）
3）可以分布式实现，中间逻辑的read和write可是分号段，以适应批量操作，map/reduce
4）尽量做到全量cache，尤其是index
流程说明：
1）在A产生Feed的时候，更新index中A节点的最后更新时间，并标记Feed_id（对于微博来说没有必要做摘要）；然后将content等详细记录写入元数据存储空间
2）B（A的粉丝）登录拉取最新Feed时，由于数量限制（首页有显示空间限制，一般都要做成page_index+page_count）只能拉取所有关注对象中最新的N条Feed，这时先通过批量查询对B的所有关注对象最新Feed做一个排序，因为完全在内存中实现，而且可以map/reduce，所以时间消耗很少，在生成了最新的Feed列表后，直接批量向元数据存储空间拉取完成信息
pull模式的实时性比push模式要好，但是也会遇到关注对象太多时拉取慢的情况，无论pull还是push，最后都可以通过cache index实现快速索引的生成，通过map/reduce实现批量请求的分割与快速处理。
作为互联网应用来说，保证最终一致性才是最重要的，另外一点，对逻辑数据分层次处理，做优先级划分
6月1日更新：
本文是pull模式，关于微博的push模式请参见 http://blog.csdn.net/cleanfield/archive/2011/04/21/6339428.aspx
