读扩散、写扩散，主要应用在feed流场景中，什么是feed流？
- 微博
- 微信朋友圈
等都是典型的信息流业务，存在好友关系，如关注和粉丝，自己的主页由别人发布的内容组成。
feed流业务最大的特点是自己的主页由别人的feed组成，获得主页本质上就是在组装别人的内容。
从技术上主要有两种方式：
- 拉取（读扩散）
- 推送（写扩散）
拉模式（读扩散）
假设存在A关注BC，那么存储A关注B、A关注C；C的粉丝有A、B的粉丝有A，这么一组关系。
发布流程：当B/C发布内容时，只需将自己的内容存储在自己的队列（feed记录）中。
查询个人主页流程：当A查看自己的主页时：
- 拉取A的关注列表：存在B、C
- 获取所关注列表中B、C的feed记录，判断是否有可见性设置
- 对消息进行
order by time desc，分页取数据
缺点
- 拉取信息流时，业务非常复杂
- 多次访问时，每次都需要进行大量计算
优点
- 存储结构简单，数据存储量较小，只存储一份不会冗余。
- 关注、取关、发布feed的流程都很简单
- 适合早期业务量不大的时候，可以快速实现
推模式（写扩散）
这是蓝色的文字
继续上面的假设，关注关系依旧不变，但与读扩散不同的是，每个用户还需要存储自己收到的feed流
发布流程：当B/C发布内容时，需要查询自己的粉丝列表，然后分别在粉丝A的feed中，写入B、C发布的feed信息。
查询个人主页的流程：当A查看自己的主页时：直接拉取自己的feed记录即可。
缺点
- 实现关注取关时，关注时，需要将信息从写入到粉丝的feed记录中，移除时，同样需要将内容从feed记录中删除。
- 极大的存储资源消耗，需要存储多份feed信息。
优点
- 拉取信息时非常简单，只需直接查询feed记录。
总结
- 拉模式，读扩散，feed存一份，存储小，用户集中访问数据，性能差;
- 推模式，写扩散，feed存多份，用冗余存储换锁冲突，性能高;
参考
全文参考自：58沈剑-读扩散，写扩散，终于讲清楚了！