架构师训练营 模块 2 作业

作业

设计微信朋友圈高性能架构

业务指标

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

朋友圈高性能复杂度分析

• 发朋友圈 1.2 亿/天 = 1388*2*5 = 13880 TPS （假设平均峰值为日常的 2 倍，节假日峰值为平均值的 5 倍设计）

• 点赞/评论 = 13880*10 = 138800 TPS（假设每个朋友圈有 10 人点赞评论）

• 查看朋友圈 7.8 亿*3 = 27000 QPS， 图片 27000*5=135000（假设每人每天看 3 次，每个朋友圈的图片最少 1 张，最大 9 张，均值 5 张）

朋友圈高性能复杂度应对思路

朋友圈高性能方案-发朋友圈

发朋友圈架构图

设计理由

发朋友圈时，短时间内只有自己能看，因此只需要通过关系数据库保存，同时客户端可以做一些兼容，默认自己看得到最新的记录就行。

朋友圈高性能方案-点赞评论

点赞评论架构图

设计理由

点赞、评论一般和朋友圈文章紧密关联，存储了点赞的用户和评论数据，非常适合非结构化的 Redis 存储。

Redis 中使用 文章 ID 为 key 存储为 List 结构，方便快速查询。

朋友圈高性能方案-看朋友圈

看朋友圈架构图

设计理由

由于朋友圈会被用户经常刷新查看是否有新的记录、评论和点赞，因此设计通过 Redis 缓存数据，文章与 点赞评论分别加载，不互相影响。

朋友圈高性能方案-整体架构

朋友圈整体架构图-单机房示意图

由于朋友圈业务极度重要，一旦出现故障影响面非常大，因此以 三机房 建设为最低保障要求，在成本允许的情况下，实现异地多活最佳。