读扩散、写扩散，主要应用在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沈剑-读扩散，写扩散，终于讲清楚了！