初恋永远想不到的性能架构（朋友圈）

微信朋友圈的工作流程概述

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

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

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

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

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

至于赞和评论的实现，是相对简单的。上面说了微信后台有一个专门的表存储评论和赞的数据，比如 Kate 是 Mary 和小王的朋友的话，刷到了 K2 这一条发布，就会同时从评论表里面拉取对应 K2 的、Mary 留下的评论内容，插入到 K2 内容的下方。而如果另一个人不是 Mary 和小王的共同朋友，则不会看到这条评论。