架构实战模块 2 作业：微信朋友圈高性能复杂度分析

1、总体分析

• 微信是高业务、高质量复杂度，那是因为微信涵盖了许多业务，而朋友圈本身业务并不复杂，只包含了朋友圈的发布、查看和评论，所以朋友圈的复杂度应属于 低业务复杂度、高质量复杂度。

2、高性能复杂度分析

参考红包高性能复杂度依次分析：

数据参考

• 微信 2021 年 1 月份发布的数据：每天有 1.2 亿人在发朋友圈、7.8 亿人在看朋友圈；3.6 亿人在看公众号文章；4 亿人在用小程序

1、发布

每天有 1.2 亿人发朋友圈，那么可计算出平均每秒大约发 1500 条，设计的目标应该以峰值来计算，按平均值的 4 倍来计算，那么发朋友圈的 TPS 是 6000。

2、查看

每天有 7.8 亿人再看朋友圈，可以算出平均每秒大约有 9000 人在看朋友圈，以峰值来计算，按平均值的 4 倍来计算，那么查看朋友圈的 QPS 为 36000。

3、评论（包括点赞）

可假设查看朋友圈的人数中两人有一人点赞，那么评论的 TPS 为 18000。

3、方案设计

1、发布

说明：

1. 发朋友圈业务比较单一，所以使用负载均衡，无需拆分为多个任务。

2. 存储的朋友圈量很大，所以存储模型采用分库分表。

2、查看

说明：

1. 由于查看朋友圈时，会对应到不同朋友的相应朋友圈，所以负载均衡采用 Hash 算法。

2. 由于浏览查询的量极大，对实时性要求较高，所以采用缓冲模型 Redis Cluster。

3. 由于 Jedis 多线程使用同一个连接时，是线程不安全的，而 Lettuce 是线程安全，同时是基于 Netty 框架的 Reactor 和事件驱动的通信，可异步调用，适用于分布式缓冲。

3、评论（包括点赞）

说明：

1. 同样评论也是针对到不同朋友的相应朋友圈，所以负载均衡采用 Hash 算法。

2. 考虑到评论可能对实时性要求不是很高，如果没有成功，可以再发一遍，所以采用数据库集群模型，不适用缓冲模型。

3. 评论的量相较发的朋友圈的量更大，所以也采用分库分表。