读扩散、写扩散，主要应用在feed流场景中，什么是feed流？

• 微博
• 微信朋友圈
  等都是典型的信息流业务，存在好友关系，如关注和粉丝，自己的主页由别人发布的内容组成。

feed流业务最大的特点是自己的主页由别人的feed组成，获得主页本质上就是在组装别人的内容。
从技术上主要有两种方式：

• 拉取（读扩散）
• 推送（写扩散）

拉模式（读扩散）

假设存在A关注BC，那么存储A关注B、A关注C；C的粉丝有A、B的粉丝有A，这么一组关系。
发布流程：当B/C发布内容时，只需将自己的内容存储在自己的队列（feed记录）中。
查询个人主页流程：当A查看自己的主页时：

1. 拉取A的关注列表：存在B、C
2. 获取所关注列表中B、C的feed记录，判断是否有可见性设置
3. 对消息进行 order by time desc，分页取数据

缺点

1. 拉取信息流时，业务非常复杂
2. 多次访问时，每次都需要进行大量计算

优点

1. 存储结构简单，数据存储量较小，只存储一份不会冗余。
2. 关注、取关、发布feed的流程都很简单
3. 适合早期业务量不大的时候，可以快速实现

推模式（写扩散）

这是蓝色的文字

继续上面的假设，关注关系依旧不变，但与读扩散不同的是，每个用户还需要存储自己收到的feed流
发布流程：当B/C发布内容时，需要查询自己的粉丝列表，然后分别在粉丝A的feed中，写入B、C发布的feed信息。
查询个人主页的流程：当A查看自己的主页时：直接拉取自己的feed记录即可。

缺点

1. 实现关注取关时，关注时，需要将信息从写入到粉丝的feed记录中，移除时，同样需要将内容从feed记录中删除。
2. 极大的存储资源消耗，需要存储多份feed信息。

优点

1. 拉取信息时非常简单，只需直接查询feed记录。

总结

1. 拉模式，读扩散，feed存一份，存储小，用户集中访问数据，性能差;
2. 推模式，写扩散，feed存多份，用冗余存储换锁冲突，性能高;

参考

全文参考自：58沈剑-读扩散，写扩散，终于讲清楚了！