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

【作业要求】

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

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

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

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

【提示】

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

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

一、需求分析：

（一）性能指标分析：目前微信用户同时在线已经超过 10 亿在线，下面挑选发朋友圈、看朋友圈、评论三个场景进行性能指标分析。核心场景：发朋友圈、刷朋友圈、点赞和评价。各场景性能分析如下

（二）、领域模型（实体关系模型）

二、架构设计

（一）、微信朋友圈性能分析-整体架构

（二）发朋友圈-架构设计

Redis 集群 B 的 key-value 设计

角色定义（Role）：

1.F5 和 Nginx 构成多级负载均衡，用于分派流量。

2.Redis 集群 A，作为消息队列，缓存新发布的消息和消息更新指令（修改、删除）、点赞指令。

3.Redis 集群 B，存储了 10 亿用户的朋友圈信息，key 是用户 ID，value 是朋友群消息；

4.Redis 集群 C，缓存了数据库中记录的朋友关系。对于图片和视频并不存放到 Redis 集群中，而是存储在分布式文件系统中；

5.Redis 集群 D，缓存了消息的信息，为每条消息维护一个 key，value，其中 value 中包括了消息内容和点赞、评价信息。

6.Kafka 集群，用于把消息同步归档到 hadoop 集群。

7.应用集群，负责从 kafka 中读取新发布的消息或者消息指令（如修改、删除、点赞），结合 Redis 集群 C 中存储的朋友关系，把消息追加到 Redis 集群 B 用户的消息队列中。根据指令的不同，对 Redis 集群 B 做的操作也不同。

8.Hadoop/Hbase 集群，用于存储全量的消息。

9.分布式文件系统，用于存储图片、视频等非结构化文件。

规则（Rule）：

1.F5 和 Nginx 构成多级负载均衡，用于分派流量。

2.Nginx 直接对接 Redis 集群，把朋友圈消息发送到 Redis 队列中，作为热数据缓存起来。

3.应用程序从 redis 集群 A 中读取新发布的消息，根据朋友关系，把消息分别写入到 Redis 集群 B 的朋友队列中，刷朋友圈从 Redis 集群 B 中获取数据。

4.Redis 集群 A 不能无限制存储消息，需要把消息通过 kafka 同步分发到 hadoop/hbase 集群。Redis 集群 A 存储的是热数据，hadoop/hbase 存储的全量数据。

5.刷朋友圈时，从 Redis 集群 B 中获取，Redis 集群 B 的队列数据，通过应用程序更新。

6. 刷朋友圈时，从 Redis 集群 D 中获取消息的点赞和评价信息。

（三）刷朋友圈-架构设计

角色定义（Role）：

1. 1.F5 和 Nginx 构成多级负载均衡，用于分派流量。

2.Redis 集群 B，存储了 10 亿用户的朋友圈信息，key 是用户 ID，value 是朋友群消息；

3.Redis 集群 D，缓存了消息的信息，为每条消息维护一个 key，value，其中 value 中包括了消息内容和点赞、评价信息。

4.应用集群，负责更新 Redis 集群 B 朋友圈信息

5.Hadoop/Hbase 集群，用于存储全量的消息。

6.分布式文件系统，用于存储图片、视频等非结构化文件。

规则（rule）

1.Redis 集群 B 存储了 10 亿用户的朋友圈信息，key 是用户 ID，value 是朋友群消息；

2.应用集群通过轮询 Redis 集群 B，根据 Redis 集群 B 中各用户队列被读取情况（比如用户滑动朋友圈，查看朋友圈，为了确保继续滑动，消息能快速返回，需要让应用程序感知到，并调用 hadoop/hbase 集群，获取更多的历史消息内容补充到对应队列中。

3.刷朋友圈时，从 Redis 集群 B 中获取消息队列，Redis 集群 B 的队列数据，通过应用程序更新。

4.刷朋友圈时，从 Redis 集群 D 中获取消息的点赞和评价信息。

（四）点赞朋友圈-架构设计

角色定义（Role）：

1.F5 和 Nginx 构成多级负载均衡，用于分派流量。

2.Redis 集群 A，作为消息队列，缓存新发布的消息和消息更新指令（修改、删除）、点赞指令。

3.Redis 集群 B，存储了 10 亿用户的朋友圈信息，key 是用户 ID，value 是朋友群消息；

4.Redis 集群 C，缓存了数据库中记录的朋友关系。对于图片和视频并不存放到 Redis 集群中，而是存储在分布式文件系统中；

5.Redis 集群 D，存储消息的点赞信息，每条消息维护一个点赞列表。

5.Kafka 集群，用于把消息点赞信息同步归档到 hadoop 集群。

6.应用集群，负责从 kafka 中读取新发布的消息或者消息指令（如修改、删除、点赞），结合 Redis 集群 C 中存储的朋友关系，把消息追加到 Redis 集群 B 用户的消息队列中。根据指令的不同，对 Redis 集群 B 做的操作也不同。

7.Hadoop/Hbase 集群，用于存储全量的消息。

规则（Rule）：

1.F5 和 Nginx 构成多级负载均衡，用于分派流量。

2.Nginx 直接对接 Redis 集群，把点赞信息发送到 Redis 队列中，作为热数据缓存起来。

3.应用程序从 redis 集群 A 的点赞消息，根据朋友关系，把消息分别写入到 Redis 集群 B 的朋友队列中，刷朋友圈从 Redis 集群 B 中获取数据。

4.Redis 集群 A 不能无限制存储消息，需要把消息通过 kafka 同步分发到 hadoop/hbase 集群。Redis 集群 A 存储的是热数据，hadoop/hbase 存储的全量数据。

5.刷朋友圈时，从 Redis 集群 B 中获取，Redis 集群 B 的队列数据，通过应用程序更新。

（五）微信朋友圈-整体架构

角色定义（Role）：

1.F5 和 Nginx 构成多级负载均衡，用于分派流量。

2.Redis 集群 A，作为消息队列，缓存新发布的消息和消息更新指令（修改、删除）、点赞指令。

3.Redis 集群 B，存储了 10 亿用户的朋友圈信息，key 是用户 ID，value 是朋友群消息；

4.Redis 集群 C，缓存了数据库中记录的朋友关系。对于图片和视频并不存放到 Redis 集群中，而是存储在分布式文件系统中；

5.Redis 集群 D，缓存了消息的信息，为每条消息维护一个 key，value，其中 value 中包括了消息内容和点赞、评价信息。

6.Kafka 集群，用于把消息同步归档到 hadoop 集群。

7.应用集群，负责从 kafka 中读取新发布的消息或者消息指令（如修改、删除、点赞），结合 Redis 集群 C 中存储的朋友关系，把消息追加到 Redis 集群 B 用户的消息队列中。根据指令的不同，对 Redis 集群 B 做的操作也不同。

8.Hadoop/Hbase 集群，用于存储全量的消息。

9.分布式文件系统，用于存储图片、视频等非结构化文件。

规则（Rule）：

1.F5 和 Nginx 构成多级负载均衡，用于分派流量。

2.Nginx 直接对接 Redis 集群，把朋友圈消息及消息操作指令发送到 Redis 队列中，作为热数据缓存起来。

3.应用程序从 redis 集群 A 中读取新发布的消息，根据朋友关系，把消息分别写入到 Redis 集群 B 的朋友队列中，刷朋友圈从 Redis 集群 B 中获取数据。

4.Redis 集群 A 不能无限制存储消息，需要把消息通过 kafka 同步分发到 hadoop/hbase 集群。Redis 集群 A 存储的是热数据，hadoop/hbase 存储的全量数据。

5.刷朋友圈时，从 Redis 集群 B 中获取，Redis 集群 B 的队列数据，通过应用程序更新。

6. 刷朋友圈时，从 Redis 集群 D 中获取消息的点赞和评价信息。