原文： http://blog.csdn.net/zhangzhaokun/article/details/7834797
完全用nosql轻松打造千万级数据量的微博系统
微博feed系统的push和pull模式和时间分区拉模式架构探讨
关于如何构建一个微博型广播
关于如何构建一个微博型广播2
用 mongodb 储存多态消息/提醒类数据
构建高性能的微博系统-再谈新浪微博架构
新浪微博Cache设计@TimYang.pdf
最后这篇文章写得很不错的，也基本讲清楚了Feed系统的方方面面的考虑了，基本涉及到了一个Feed系统从小发展到大的全过程了！还没有完全领会到它为用Cassandra替换Redis的理由，或者他还是考虑把Casandra的作为半缓存的结构来替换的，加大Cassandr的内存，可以缓存大量的热数据，当然它的好处是冷热数据都可以完美的持久化，但是数据的一致性处理起来有些麻烦，毫无疑问他会是采用R+W>N的模式，但是无论写多份还是读多份都是有些难于取舍的，Feed系统的写入量本来就很大，如果写入多份的话会大大降低写入的性能，另外，存在Feed的系统，无一例外的是Feed都会是全系统的核心，提高读的性能会大大提高用户的体验，如果读取的时候读多份数据会相对降低性能，到底取舍哪一个呢？我这里光是凭空想象，无法取舍，具体还可以看性能测试来说法，如果有同学做过这方面的压测，还望留言告知下！
腾讯微博主要使用拉模型，只有未读的微博数是使用推得模式实现的！拉模型的问题在于一个人跟随了几百或者上千的人的时候，去看关注的人所发的消息要进行多个层次的Map/Reduce才能得到结果，需要非常高效的获取最新Feed的方式以及快速的聚合算法，只用Memcache\Redis之类的从性能上是比较难于实现的，需要从数据层面或者是缓存的层面都进行聚合，再在应用层面进行聚合，技术难度比较大！这个模式属于知易行难，绝大多数公司不具备构建基础设施的能力！
新浪微博使用推拉结合的方式，大号不推送，小号则推送，看Feeds的时候，需要将推过来的Feeds索引数据与关注的大号的Feed进行聚合，小小的牺牲下拉的性能一下子就将大号的推送问题解决掉了！
对于稍微小些的网站，比如Pinterest和花瓣都使用推的方式来实现，PInterest的直接在Redis中保存500个最新的索引信息，使用Python脚本定时来扫描，保证缓存的索引信息始终只保存最新的500个，老的信息则直接丢弃掉，花瓣则将老索引存储到LevelDBA中去了！
Pinterest网站的内容信息缓存在memcache中，关系信息则缓存到Redis中，持久化方式保存！对于那种大号的粉丝，亦或是关注的人数太多则需要将关系数据拆分之后再缓存起来，对于动态变化的部分则需要独立存放，在使用的时候需要将两部分数据聚合，在可变部分达到一定长度的时候，需要与不变的部分进行合并！
当然推送的时候，所有的网站都使用异步的方式来实现！
