What is Feed?

通俗点说feed系统就是当你登陆进对应网站后：微信朋友圈的动态、人人网上看到的一件件新鲜事、新浪微博上推到你面前的一条条新围脖等等。

实现方式

feed的获取方式主要有两种：push（推）以及pull（拉）

PUSH

写的过程中提前计算好feed，取轻、发重。类似宅急送服务，打开家门就可以看到货物已经在门口了，不用关心物流过程。

缺点：对于大V，推送粉丝多，占用空间大。而且如果粉丝活跃度不高，造成空间浪费。

PULL

读取的过程中收集feed。取重、发轻。类似020电影票服务，网上购买了电影票，还要去电影院换票才能看到

缺点：读取是信息搜集耗时

Feed难点

信息聚合

根据feed信息的访问频率可能会存在不同的服务器存储区域中。借用淘宝网核心系统专家余峰对各存储区与读书的比喻加以修改就是：
“CPU访问L0就像是你读手边的一本书，访问L1就像从书桌拿一本书，L2是从书架拿一本书，L3是从客厅桌子上拿一本书，访问主存就像骑车去社区图书馆拿一本书。”

特别是结合了push 和 pull 策略的feed系统，需要不同的聚合策略。

信息去重

排序

新浪微博

新浪微博使用推拉结合的方式，大号不推送，小号则推送，看Feeds的时候，需要将推过来的Feeds索引数据与关注的大号的Feed进行聚合，小小的牺牲下拉的性能，不过一下子就将大号的推送问题解决掉了！

Pinterest和花瓣

对于稍微小些的网站，比如Pinterest和花瓣都使用推的方式来实现，PInterest的直接在Redis中保存500个最新的索引信息，使用Python脚本定时来扫描，保证缓存的索引信息始终只保存最新的500个，老的信息则直接丢弃掉，花瓣则将老索引存储到LevelDB中去了！

Pinterest网站的内容信息缓存在memcache中，关系信息则缓存到Redis中，持久化方式保存！对于那种大号的粉丝，亦或是关注的人数太多则需要将关系数据拆分之后再缓存起来，对于动态变化的部分则需要独立存放，在使用的时候需要将两部分数据聚合，在可变部分达到一定长度的时候，需要与不变的部分进行合并！

腾讯微博

腾讯微博主要使用拉模型，只有未读的微博数是使用推得模式实现的！拉模型的问题在于一个人跟随了几百或者上千的人的时候，去看关注的人所发的消息要进行多个层次的Map/Reduce才能得到结果，需要非常高效的获取最新Feed的方式以及快速的聚合算法，只用Memcache\Redis之类的从性能上是比较难于实现的，需要从数据层面或者是缓存的层面都进行聚合，再在应用层面进行聚合，技术难度比较大！这个模式属于知易行难，绝大多数公司不具备构建这种基础设施的能力！

选择性分发

基于生产者的选择性分发

Yahoo的Adam Silberstein等人所著的论文中，提出了一种选择性推送用户feed的方法，Twitter目前也在使用类似的方法。明星用户的消息分发会给系统带来突然和巨大的负载压力，这意味着必须要预留出额外的空间来保持实时性。这篇论文中建议通过选择性地分发消息，来减少这些明星用户带来的负载。Twitter采用了这个方法后，在用户读取时才加载这些明星用户的tweet，性能得到了大幅度提升。

基于消费者的选择性分发

另外一种选择性分发方式是指对那些活跃用户（比如过去一周登录过的用户）分发消息。我们对这个方法进行了修改，为活跃用户存储最近的3600条动态，为非活跃用户存储180条，读取180条之后的数据需要重新访问数据库，这种方式对于非活跃用户的体验不太好，但是能有效降低内存消耗

参考：
http://www.csdn.net/article/2013-11-07/2817430-design-decisions-for-scaling-your-high-traffic-feeds
http://blog.csdn.net/zhangzhaokun/article/details/7834797