架构训练营第 1 期 模块二作业

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

【作业要求】

1. 对照模块 2 讲述的复杂度分析方法，分析微信朋友圈的复杂度。

2. 针对各个复杂度，画出你的架构设计方案(无需做备选方案，只需要最终的方案即可)。

3. 给出你的架构方案中关键的设计理由。

4. 3~5 页 PPT 即可，涵盖复杂度分析、架构设计、设计理由。

【提示】

1. 分析过程可以参考模块 2 第 5 课的实战案例，但是不需要将分析过程一一列举出来。2. 如果某个地方被卡主了，请及时联系助教或者老师讨论。

朋友圈高性能业务指标分析

• 2021 年：在微信公开课 Pro 直播演讲中，微信创始人张小龙披露微信最新数据：每天有 10.9 亿人打开微信，3.3 亿人进行视频通话，7.8 亿人进入朋友圈，1.2 亿人发朋友圈，朋友圈每天有 1 亿条视频内容，3.6 亿公众号，4 亿用户使用小程序。每天有 3.6 亿人进入公众号，4 亿用户使用小程序。

• 假设进入朋友圈的人平均一天刷 20 次朋友圈，每次刷 15 次 7.8 亿 * 20 ～= 150 亿

• 假设峰值是平均值的 20 倍，则峰值为

  刷朋友圈：约 350 万 QPS

  发朋友圈：约 28 万 TPS

  点赞评论：约 280 万 TPS（假设每条朋友圈有 10 次互动）

朋友圈高性能复杂度分析

• 单机（使用现有微信基础架构，无需考虑）

• 集群

  计算高性能

  任务分配（多机房）

  任务分解（从高性能角度考虑无需分离，从高可用角度考虑可以将发表动态分离来实现应急的服务降级）

  储存高性能

  任务分配（多机房）

  任务分解（用户相册及互动数据与 Feed 数据分离）

朋友圈高性能整体架构图

朋友圈高性能整体架构（单机房示意）

设计关键点：

• 复用微信现有的任务分配器做负载均衡。复用微信现有的 CDN 服务做图片与视频的储存与分发。

• 由于朋友圈的即时性较弱，只需客户端做 polling 即可，无需设计 push 机制

• 相册与互动数据根据动态发表用户 ID 以及时间来做 sharding 来应付数据增长

• 朋友圈 Feed 以动态查看用户 ID 做 sharding，Redis 的容量大约为 10PB 左右，分析如下：

• 只储存最近 3 日内的动态内容

• 每日 1.2 亿人发朋友圈，假设平均每人发 1.5 条，即每日产生约 2 亿条动态

• 假设平均每条动态会进入 50 人的 Feed，则 Redis 集群中需要存放的单日动态数量为 2 亿 x 50 x 3 = 300 亿

• 假设平均每条动态需要约 300 字节（文字+元数据+图片视频 cdn 链接+评论点赞信息），则 Redis 集群中需存放数据为 9PB

• 只储存活跃用户最近 50 条动态内容

• 每日 7.8 亿人进入朋友圈

• 假设平均每条动态需要约 300 字节（文字+元数据+图片视频 cdn 链接+评论点赞信息），则 Redis 集群中需存放数据为 7.8 亿 x 50 x 300Bytes = 11PB