微信朋友圈的高性能复杂度分析

据 2021 年微信公开数据显示，每天有 10.9 亿人打开微信，3.3 亿人进行视频通话，7.8 亿人进入朋友圈，1.2 亿人发朋友圈，朋友圈每天有 1 亿条视频内容，3.6 亿公众号，4 亿用户使用小程序。每天有 3.6 亿人进入公众号，4 亿用户使用小程序。

1. 朋友圈高性能复杂度分析

根据以上数据，微信的活跃用户数非常多，朋友圈的并发访问量极大，且在节假日尤其是春节期间峰值流量会达到平时的 2 倍以上。

朋友圈 QPS：7.8 亿/86400 = 9027 ，TPS：1.2 亿/86400=1388

峰值估算：假设 80%的人都集中在 4 个小时内读和发朋友圈，则

• 峰值 QPS 约为 9027 x 80% x 6 ≈ 43330

• 峰值 TPS 约为 1388 x 80% x 6 = 6662 ≈ 7000

• 评论和点赞（假设平均每条朋友圈有 10 个评论和点赞）峰值约为 7000*10 = 7 万

朋友圈的业务逻辑：

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

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

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

• 一个是评论。评论就是针对某个具体发布的朋友评论和点赞操作。

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

2. 朋友圈整体架构

3. 架构方案设计考虑

a）朋友圈的并发写入量非常大，使用消息队列可以应对峰值请求量过大时发生阻塞，朋友圈整体业务的实时性和一致性要求并不高，借助消息队列可以将朋友圈的写入操作变为异步操作，提高响应性。

b）朋友圈是基于朋友关系而建立的，其本身的存储应当基于关系数据库模型，但是针对每个用户的朋友圈消息流，可以预先对其进行异步计算，然后存储到 Redis 缓存中，甚至直接推送到客户端，加速用户浏览朋友圈时的性能。

c）点赞和评论的写入量高于朋友圈发布量，且要求及时看到发布效果，因此选择使用 Redis 存储点赞和评论数据。