一、2021 微信最新数据

2021微信最新数据

通过 2021 年 1 月最新数据得知，每天有 7.8 亿人浏览，1.2 亿人发朋友圈，是个读多写少的场景。假设每天 80%的用户集中在 4 小时内发布和浏览朋友圈，服务压力峰值估算如下：

• 峰值 QPS：7.8 亿*0.8/4*60*60 = 43333.33 ~= 4.5 万

• 峰值 TPS：1.2 亿*0.8/4*60*60 = 6666.66 ~= 7 千

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

二、高性能复杂度分析

架构复杂度模型

微信朋友圈主要包括朋友圈发布、浏览、评论和点赞 4 个业务场景，业务复杂度低，但对服务的性能和可用性要求较高，属于质量复杂度高的场景。

2.1 复杂度分析模型

2.2 发朋友圈

2.2.1 复杂度分析

2.2.2 架构设计

2.2.3 设计理由

发朋友圈是写的场景，复杂度主要体现在数据存储的性能。朋友圈每天 1.2 亿的增长，单库单表或单库多表都不满足存储需求，需要多库多表存储，可按用户 ID 路由。性能上，7 千左右的 QPS，假设单台 master 节点 QPS 为 3000，部署 3 台 Master 节点即可满足性能需求。写的请求可直接打到 DB 上。

2.3 评论

2.3.1 复杂度分析

2.3.2 架构设计

2.3.3 设计理由

评论是写的场景，复杂度主要体现在存储的性能。评论的 TPS 为 7 万，性能要求较高，为了不影响发朋友圈的服务，评论数据单独存储。且评论的实时性要求不高，先将数据写入 Redis，再异步同步到数据库，降低 DB 的写入压力。

2.4 点赞

2.4.1 复杂度分析

2.4.2 架构设计

2.4.3 设计理由

点赞和评论一样是写的场景，复杂度主要体现在存储的性能。TPS 为 7 万，性能要求较高，为了不影响发朋友圈和点赞的服务，点赞数据也单独存储。且点赞的实时性要求不高，先将数据写入 Redis，再异步同步到数据库，降低 DB 的写入压力。

2.5 浏览

2.5.1 复杂度分析

2.5.2 架构设计

2.5.3 设计理由

朋友圈浏览是查询的场景，复杂度主要体现在数据读取 &缓存的策略和性能。浏览朋友圈的 QPS 为 4.5 万，为了提高查询性能，首先客户端缓存已浏览过的朋友圈记录，其次服务端添加本地+Redis 双缓存，同时，服务端对缓存未命中的朋友圈记录，通过即将读取的朋友圈 ID 列表，拆解为多个任务并行获取，最后在 DB 侧通过 HAProxy 等服务做负载，进一步提高服务的查询性能。