1. 微信用户数据

每天有 10.9 亿人打开微信，3.3 亿人进行视频通话，7.8 亿人进入朋友圈，1.2 亿人发朋友圈，朋友圈每天有 1 亿条视频内容，3.6 亿公众号，4 亿用户使用小程序。每天有 3.6 亿人进入公众号，4 亿用户使用小程序。(https://www.ithome.com/0/530/979.htm)

朋友圈 QPS：7.8 亿/86400 = 0.9 万，TPS：1.2 亿/86400=0.14 万

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

• 峰值 QPS 约为 0.9*0.8*6 = 4.32 万 ~= 4.5 万

• 峰值 TPS 约为 0.14*0.8*6 = 0.672 ~= 7000

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

2. 总体复杂度分析

朋友圈的主要业务有：发朋友圈、读朋友圈、评论和点赞。业务复杂度低。

通过数据分析可以看出朋友圈的质量复杂度高。

所以朋友圈是低业务复杂度、高质量复杂度。

3. 总体架构图

3.1 发朋友圈

3.2 读朋友圈

3.3 评论和点赞

4. 设计理由

朋友圈属于典型的读多写少的场景，修改的场景也少。

1. 发朋友圈采用分库分表方案，可以采用 userid 进行分表

2. 读朋友圈采用多级缓存方案，采用 端上的 local 缓存+服务器的 local 缓存+Redis 缓存，减小数据库压力

3. 评论和点赞采用读写 redis 缓存，然后定时同步到数据库的方案