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

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

1. 作业要求

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

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

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

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

提示

1. 分析过程可以参考模块 2 第 5 课的实战案例，但是不需要将分析过程一一列举出来。

2. 如果某个地方被卡住了，请及时联系助教或者老师讨论。

2. 背景

经过搜索，可以得到如下新闻报道：

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

3. 高性能复杂度分析

1. 已知每天 7.8 亿人进入朋友圈，1.2 亿人发朋友圈。

2. 预估发动态平均 TPS 的 100 倍为峰值 TPS，即 14W 的 TPS「1.2 X 100,000,000 / 86400 X 100」

3. 预估每人每天看朋友圈 10 次，预估看动态平均 QPS 的 100 倍为峰值 QPS，即 900W 的 QPS「7.8 X 100,000,000 / 86400 X 1000」。

4. 预估评论和点赞的 TPS 均为发动态的 10 倍，即 140W 的 TPS。

4. 发动态

1. 由于发动态是个写请求，单机无需缓存。

2. 发动态需要较强的一致性，可直接存入关系型数据库中「如 MySQL」。

3. 对请求在应用集群中做负载均衡即可。

4. 可通过 MySQL 分库分表，降低 MySQL 单实例、单表的写压力。

5. 按用户 ID 分片，简单方便。

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

单机房架构图 - 发动态

5. 看动态

1. 看动态是个纯粹的读请求，且不需要较高的一致性，所以直接读 Redis 缓存的动态即可。

2. 后台定时任务，定时将 MySQL 中的动态数据更新到缓存，可保证数据库压力可控。

3. 对请求在应用集群中做负载均衡即可。

4. 由于 QPS 极高，故读请求直接读 Redis 集群，不跟 MySQL 集群交互，保证数据库压力可用。

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

单机房架构图 - 看动态

6. 评论/点赞

1. 评论/点赞的 TPS 明显高于发动态，但是不需要较高的一致性，可以使用 Redis 做优化。

2. 评论/点赞直接写入 Redis Cluster，后台定时任务，定时将 Redis 中的数据更新到 MySQL，可保证数据库压力可控。

3. 对请求在应用集群中做负载均衡即可。

4. 极端情况下，丢失短时间内的评论/点赞数据，不会对业务造成明显影响。

5. 读请求可直接读 Redis，实时性较高，性能极佳。

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

单机房架构图 - 评论/点赞

整体方案

1. 动态使用单独的 MySQL 集群和 Redis 集群；评论/点赞使用单独的 MySQL 集群和 Redis 集群。

2. 动态写一致性要求较高，读一致性要求较低，故写请求写入 MySQL，读请求直接读缓存。

3. 动态 QPS 极高，故直接读缓存。

4. 评论/点赞写一致性要求较低，但是 TPS/QPS 均较高，故写请求写入缓存，后台定时任务定时同步 MySQL。

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

单机房架构图 - 整体架构