在权限管理上，微信使用“标签”对用户进行分组。这个标签的分组和微信通讯录是一致的。在数据上，就是给每一个关系加上一个“标签”标记。这里需要注意的是，虽然微信关系对于产品使用中的用户来说是双向的（即相互关注），但是在存储的时候，关系数据是为这两个相互关联的用户建立的，即每个人独立拥有他们自己的“通讯录”。这可以通过删除自己的朋友，而不是从其他人的通讯录中删除来看到。这是标签分组的基础数据，也是后面朋友圈权限管理的基础。对于个人朋友圈时间线可以看到的消息，按照一般的逻辑，先获取所有好友的消息，然后删除没有授权给你看的消息，删除用户消息您已阻止的信息，然后获取您当前看到的信息。时间线。如果是这样的逻辑，那就意味着每次刷新朋友圈，都要去所有的消息池中查找上面通讯录中好友的消息，判断用户是否有阅读每条消息的权限成立。这显然是一种低效的方式，更何况微信有这么大的流量和数据。因此，这种数据结构设计是不可行的。在一般的逻辑下，朋友圈的每个阅读过程都是利用分散的时间进行关系计算来解决这个性能问题。大意是把需要大量计算的过程分散到平时分散的时间。这里的思路是：平时根据权限设置准备每个用户需要的时间线数据，使用时直接读取准备好的内容（刷新朋友圈）。那么答案就出来了：除了存储上面提到的文字、图片等基本信息外，还需要为每个用户存储一条时间线数据。请注意，它是每个用户一件。当然，这里的“each”不需要存储完整的信息，只需要存储消息的ID和时间（可能需要）。大家在刷新朋友圈的时候，只需要读取自己的数据即可。不需要在消息池中过滤，也不需要判断用户权限。那么如何实现权限控制呢？新消息产生新权限。用户发布消息时，会根据上述标签设置相关权限，服务器会将消息写入到每个有权限接收消息的用户的时间线上。也就是说，在用户发布的那一刻，就进行了权限安排，而不是等到阅读的时候。这样自然减少了读取时的计算量，提高了效率。发布时进行权限控制（示意图，其实比这个复杂多了）。至于分库分表，就不展开了，知道有这么个东西就知道了。有时这种技术设计也限制了产品设计。那么你如何证明上述说法呢？有兴趣的同学可以去测试一下：先发一条有阅读权限的消息，比如允许某个标签的人阅读。然后给这个标签添加一个新人。结果是这个新人看不到这个消息，因为发布的时候权限划分好了，新人添加标签的时间是发布之后，所以没办法得到这个的权限分配机会消息，虽然他后来在标签组里，但还是没办法看到这条消息。作为微信设计的旁观者，以上回答是从系统分析的角度考虑了用户，并不代表微信确实是这样的设计思路，只是回答中的方案已经尽可能验证过了。答案中没有涉及具体的技术，只是一个系统分析思路。
