业务背景

2021 年初，微信创始人张小龙披露微信最新数据：每天有 10.9 亿人打开微信，3.3 亿人进行视频通话，7.8 亿人进入朋友圈，1.2 亿人发朋友圈，朋友圈每天有 1 亿条视频内容。

性能指标

假设

每人每天看朋友圈（包括消息）5 次，即总数为 39 亿人次，平均每秒约 4.5w 人次，

每人每天发朋友圈 2 次，即总数 2.4 亿人次，平均每秒约 3k 人次，

每人每天评论 3 次，即总数约 23 亿人次，平均每秒约 3w 人次，

每人每天点赞 10 次，即总数 78 亿人次，平均每秒约 9w 人次，

瞬时峰值都按平均值的 3 倍计算。

1. 发动态，瞬时最高 TPS 为 9k/s

2. 看动态，瞬时最高 QPS 为 13.5w/s

3. 评论，瞬时最高 TPS 为 9w/s

4. 点赞，瞬时最高 TPS 为 27w/s

5. 消息，瞬时最高 QPS 等于看动态的 QPS，即 13.5w/s

复杂度分析

业务复杂度

微信朋友圈功能可以大致分为

1. 动态

2. 评论

3. 点赞

4. 消息

比较明确，而且都不复杂。

质量复杂度

高性能

发动态

看动态

评论、点赞

消息

高可用

架构设计

设计理由

1. 从性能指标可以看出，最高 QPS 和 TPS 都在十万级别，而且数据总量很大，所以需要分库分表存储

2. 读比写需要更快的响应，而且朋友圈固有的属性，即用户绝大多数时间只会查看最近一段时间的朋友圈（预估 6 小时），所以引入了缓存 Redis cluster 存储一些统计数量和最近 6 小时的数据

3. 因为增删改查操作都会先过 Redis，所以操作 Redis 为同步操作，往 MySQL 写为异步操作

4. 任务分配器采用 hash，操作 Redis 和 Sharding-JDBC 也需要 hash，即按照用户 ID 和动态 ID hash，保证同一个用户和动态的数据都可以存在一起，方便读取

5. 朋友圈业务不是很复杂，不用拆分成太细粒度的微服务，都放到一个服务即可，也方便通过负载均衡进行任务分配