什么是读、写扩散？

什么是读、写扩散？

读写扩散的概念

inbox: 收件箱，你收到的消息，即你所关注的人发布的消息。
outbox: 发件箱，你发布的消息。

写扩散(Push)

该方式为每个用户维护一个订阅列表，记录该用户订阅的消息索引（一般为消息ID、类型、发表时间等一些元数据）。每当用户发布消息时，都会去更新其follower的订阅列表。
优点：读很轻。初始化时仅需要读取自己的inbox即可。
缺点：写很重。每发布一个消息，会导致大量的写操作。
注：一般来说，用户发布消息，并不会更新所有followers的订阅列表，仅更新在线followers即可。

读扩散(Pull)

该方式为每个用户维护一个发送列表，记录该用户所有发表过的消息索引。
优点：写很轻，节省空间。用户每发布一条消息，仅需更新自己的outbox。
缺点：读操作很重，计算量大。假设你收听了1k用户，则初始化时，需要从1k个用户的outbox拉取消息，然后计算获得最新的n条消息。

混合模式(Push+Pull)

该方式既为读写扩散的结合，根据用户followers的数量来决定是读扩散还是写扩散。例如followers大于1k的，则使用读扩散，否则使用写扩散。

实际场景

从目前现在网上的一些资料来看，Twitter是写扩散，腾讯微薄是读扩散，新浪微薄则是二者结合。

好，下面我们就结合群聊和朋友圈的场景来看一下读写扩散是怎么使用的。

这里要知道微信每个人的好友有上限，群聊的人数也有上限，所以这就限制了微信的设计复杂度没有新浪微博那样复杂，因为群聊是个耗时的操作，所以可以采用异步队列写扩散的方式来实现消息的发送。

当A用户在群里发送了一条消息（在outbox）以后，会在群中其他所有人的inbox中添加一条这条消息的索引，即使你并没有在线，当离线用户上线的时候，只需要检查自己的inbox列表就能收到“离线消息”。

换句话说就是：消息扩散写到每个人的消息存储（消息收件箱）后，接收者到后台同步数据时，只需要检查自己收件箱即可，同步逻辑跟单聊消息是一致的，这样可以统一数据同步流程，实现起来也会很轻量。

至于为什么不采用读扩散，一是因为一个群聊的人数相对较少，利用写扩散更加合适，二是如果采用读扩散，微信群聊每秒钟都可能有消息产生，那么用户会执行大量的读操作，这个过程并不是完全可靠的，很可能发生数据丢失。

朋友圈例子

下面再看一个微信朋友圈的例子

比如有两个用户小王和Mary。小王和Mary各自有各自的相册，可能在同一台服务器上，也可能在不同的服务器上。现在小王上传了一张图片到自己的朋友圈。上传图片不经过微信后台服务器，而是直接上传到最近的腾讯CDN节点，所以非常快。图片上传到该CDN后，小王的微信客户端会通知微信的朋友圈CDN：这里有一个新的发布（比如叫K2），这个发布的图片URL是什么，谁能看到这些图片，等等此类的元数据，来把这个发布写到发布的表里。

在发布的表写完之后，会把这个K2的发布索引到小王的相册表里。所以相册表其实是很小的，里面只有索引指针。相册表写好了之后，会触发一个批处理的动作。这个动作就是去跟小王的每个好友说，小王有一个新的发布，请把这个发布插入到每个好友的时间线里面去。

然后比如说现在Mary上朋友圈了，而Mary是小王的一个好友。Mary拉自己的时间线的时候，时间线会告诉到有一个新的发布K2，然后Mary的微信客户端就会去根据K2的元数据去获取图片在CDN上的URL，把图片拉到本地。

在这个过程中，发布是很重的，因为一方面要写一个自己的数据副本，然后还要把这个副本的指针插到所有好友的时间线里面去。如果一个用户有几百个好友的话，这个过程会比较慢一些。这是一个单数据副本写扩散的过程。但是相对应的，读取就很简单了，每一个用户只需要读取自己的时间线表，就这一个动作就行，而不需要去遍历所有好友的相册表。

为什么选择这样一个写扩散的模型？因为读是有很多失败的。一个用户如果要去读两百个好友的相册表，极端情况下可能要去两百个服务器上去问，这个失败的可能性是很大的。但是写失败了就没关系，因为写是可以等待的，写失败了就重新去拷贝，直到插入成功为止。所以这样一个模型可以很大的减少服务的开销。