Feed系统的本质就是一个相对更加简单的IM系统。
推模式
- 写入延迟问题：并行写入，对存储到写入压力大，更牛B的写入存储引擎：LevelDB、TokuDb等
- 存储量特别大：压缩率更高的存储引擎 + 定期清理数据
- 微博分组，更是扩大了写入量
- 取消关注、删除微博等操作对该模式影响也很大（可以通过读时过滤来解决）
问题重重，feed推模式，更适合粉丝有限的场景，例如朋友圈
拉模式
用户发件箱，来缓存UP最近5天发布的微博
缓存节点的带宽成本比较高，可以通过多缓存副本来解决。
推拉结合
- 按照用户是否活跃在线与不在线
- 按照UP的粉丝数来划分
- 区分关注的普通人与大V
