一、应用场景

读扩散和写扩散主要用于类似微博，朋友圈这种信息流的拉取的场景

二、什么是feed

这里以微博举例，微博首页每一条消息就是一条feed，feed流也就是信息流

三、这种信息流的场景主要技术细节

假设这里有A,B,C,D四个用户,A关注B和D,C关注B，那么这种场景最起码会有如下三种存储结构，其中关系如下

1、关注存储

这里A关注C和D,C关注B

A->B,D
B->null
C->B
D->null

2、粉丝存储

这里根据上面的关注关系可以推出粉丝关系，B的粉丝为C，C的粉丝有A和B，D的粉丝有A

A->null
B->A,C
C->null
D->A

3、feed发布存储

这里假设B和D都发布了消息(feed)

A->null
B->1,2
C->null
D->3
`

4、业务场景如下

关注，取消关注，获取消息列表，发布feed

四、读扩散(拉模式)

如果我们用读扩散的技术来实现，那么看看关注，取消关注，获取消息列表三种业务场景怎么实现

1、消息(feed)发布

这里只需要单纯的维护feed发布存储的相关记录即可。

2、关注

加上B关注C，那么其实很简单，只需要在关注存储B的记录上加上C就可以了
B->C，其它不用动

然后在粉丝存储C上加上B
C->B

3、取消关注

也很简单，只需要在关注存储和粉丝存储做些简单操作即可，移除对应用户的粉丝

4、获取消息列表

读扩散模式，获取消息列表是比较复杂的，比如A用户进入首页要获取消息列表，他需要先去关注存储中获取A的关注用户B和D，然后根据B和D再去feed发布存储获取B和D的feed。

所以，读扩散对关注和取消关注的业务场景是很简单的逻辑实现，但是对于获取消息列表这个业务场景比较复杂，要进行较多的内存计算耗费更多的网络开销。

五、写扩散(推模式)

对于写扩散，这里会多一个feed读取存储，这样对于”获取消息列表”的业务场景就很简单了，只需要查询这个feed接收存储即可。

A->1,2,3
B->null
C->1,2
D->null

这里相当于，在B发布feed的时候，不仅仅会在feed发布存储自己的记录中写入，还会在关注自己的A和C的feed接收存储中写入相关记录。

1、消息发布

这里因为多了一个存储，所以发布的时候要先去粉存储找到自己的所有粉丝，然后在每个粉丝的feed接收存储中存入feed

2、获取消息列表

对于处理获取消息列表的业务场景就变得很简单了，只需要去feed接收存储查询记录即可。

3、关注

关注的话这里就稍微复杂点，关注后，还需要把关注的用户发的feed拉到自己的feed接收存储中

4、取消关注

取消关注也需要把取消关注的用户的feed从自己的feed接收存储中移除

所以对于写扩散，关注，取消关注，消息发布会稍微麻烦点，但是对于获取消息列表变的很简单，但是消息存储了多份，存储空间耗费较大
要从

六、总结

简单理解，写扩撒就是写的时候要把消息写道多个粉丝对于的feed记录中，所以叫做写扩散，读扩撒就是读的时候要从多个关注用户的feed记录中拉取消息，所以叫做读扩散。

1、读扩散优缺点

优点：feed只需要存储一份，耗费存储空间小，关注，取消关注，发布消息业务实现逻辑简单
缺点：读取逻辑较复杂，要进行大量内存计算，并且要进行多次网络传输，性能较低

2、写扩散优缺点

优点：读取逻辑简单，性能较高
缺点：feed存储多份，耗费较大的存储，用户空间换时间，关注，取消关注，发布消息业务实现逻辑较复杂

3、使用场景

读扩散存储结构，业务流程都比较容易理解，适合项目早期用户量、数据量、并发量不大时的快速实现，如果查询比修改操作多得多，可以考虑写扩散，正常这种信息流模式，查询和修改的比例差距巨大，有些甚至高达100:1，也即是做100次查询可能才有1次修改