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

【作业要求】

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

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

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

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

【提示】

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

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

1. 总体分析

1.1 核心功能点

• 动态

• 动态发布

• 动态查看（时间线）

• 评论（点赞类似）

• 发表评论

• 评论查看

1.2 高性能指标

截止到 2015 年 7 月，微信每月活跃用户约 5.49 亿，朋友圈每天的发表量（包括赞和评论）超过 10 亿，浏览量超过 100 亿。得益于 4G 网络的发展，以上数据仍有很快的增长，而且相对于 PC 互联网时代，移动互联网时代的峰值要来得更加凶猛。比如，2015 年元月的流量到了平时的 2 倍，而峰值则达到了平时峰值的 2 倍，相当于平时正常流量的 5 倍。

日均发布 10 亿，以一条动态平均 5 条评论加点赞估算

正常流量：

• 动态发布 2000TPS

• 动态查看 2W QPS

• 评论 1W TPS

• 评论查看 10W QPS

设计时以峰值考量（正常流量 5 倍）：

• 动态发布：1W TPS

• 动态查看 10W QPS

• 评论 5W TPS

• 评论查看 50W QPS

2.高性能复杂度分析

2.1 动态

2.1.1 发布动态

1. 复杂度应对思路

• 存储使用关系数据库，核心数据如下

• 动态详细信息

• 用户维度所有发布内容索引（一个用户发布的所有动态）

• 时间线：一个用户所有朋友的发布内容索引

• 需要支撑 1W TPS，所以使用数据分片

2. 架构图

2.1.2 动态查看

1. 复杂度应对思路

• 需要支持 10W QPS，关系数据库支撑困难，引入 redis cluster 存储

• 使用 zset 维护每个用户的好友动态时间线，维护时间顺序下的动态 id

• 使用 hash 或 string 存储动态详细信息

2. 架构图

2.2 评论

• 发评论基本与发布动态类似

• 评论查看基本与动态查看类似

2.3 整体架构