读扩散、写扩散

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