微信朋友圈 架构

概述

团队与技术栈简介

服务器的配置基本都是普通的服务器，最好的服务器也就是64G内存，这部分占比不多，大部分是32G内存，也有很少一部分8G内存的。硬盘是SSD和SATA都有。CPU以16核居多，有一部分新机器是32核。至于带宽则是比较多的，对外带宽很大。

然后到逻辑层。逻辑层包括注册、消息、群聊、朋友圈等等，还有iOS系统的通知。iOS系统跟安卓不一样在于，一个iOS App进入后台之后只有大概15秒的存活期，所以iOS上的推送通知要用API的Push完成，不在接入层做。

涉及朋友圈数据的有四个核心的表：

一个是发布。发布数据记录了来自所有用户所有的feed，比如一个用户发布了几张图片，每张图片的URL是什么，在CDN里的URL是什么，它有哪些元属性，谁可以看，谁不可以看等等。

一个是相册。相册是每个用户独立的，记录了该用户所发布的所有内容。

一个是时间线。所谓“刷朋友圈”，就是刷时间线，就是一个用户所有朋友的发布内容。

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

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

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

解法其实也简单，只要单项同步最初的发布写操作。比如小王这个用户是在上海数据中心的，他在自己相册上新增了一条发布K2，那么就只要单项同步把K2写到香港去就好了。反过来，比如Mary是在香港，那么她有新的发布，只要在香港写进去之后，单项同步到上海就可以了。这样就不存在时间线多数据副本同步的问题了，只要在各个数据中心内分别做批处理。

1 发朋友圈 2 刷朋友圈 3 删除，拉黑，标签，不让他看，三天可见 怎么办