如何抓住架构设计关键 - 作业

作业要求

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

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

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

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

复杂度分析

朋友圈业务指标

微信日活用户： 10.2 亿

• 发动态业务: 10.2 亿/10 = 1.02 亿/天 （30.6 亿/月） => 1157 TPS (假设每 10 个用户每天发一条动态)

• 评论点赞业务: 10.2 亿/1 = 10.2 亿/天 => 11570 TPS (假设每个用户每天评论或点赞一条动态)

• 查看朋友圈业务：10.2 亿 * 100 = 1000.2 亿/天 => 115764 QPS (假设每个用户每天浏览 100 条动态)

高性能复杂度分析

客户端

计算高性能： 缓存模型 使用客户端缓存 缓存今天已从服务器加载过的动态

单机

计算高性能： 缓存模型 使用独立缓存 redis cluster 来 cache 动态

存储高性能： 读多写少场景，使用 MySQL 持久化数据，数据索引 B+tree

集群

计算高性能： 使用独立缓存 redis cluster 来 cache 动态

任务分解成 发动态，评论点赞， 动态查看 等微服务

任务分配 nignx 作为任务分配器（轮询）， GSLB 作为主备机房流量路由

存储高性能： 30.6 亿/月 的朋友圈数据量需要对数据进行分库分表

分库：按照 userId hash 进行分库， 100 个库 3000w/月

分表：再按照动态发布时间，进行范围分表， 每天一张表， 单表数据 100w/月

冷热数据分开存储

最近一个月的数据放在 MySQL 中，更久之前的历史数据放在时序数据库中

多媒体数据存储

朋友圈的图片和视频存放在 OSS 中，通过朋友圈 ID 进行关联查询

架构设计

双机房-异地多活架构

高性能设计

1. 任务分解：分解发动态，评论点赞， 动态查看三个微服务

• 发动态：用户写数据库， 按照 userId 路由到库，按照时间路由到表， 多媒体文件指向 OSS link

• 评论点赞：发起评论点赞时，淘汰 cache，再写数据库，延时异步再次淘汰 cache；删除评论点时，hit cache 直接返回，没有命中，则从库读取评论，放入 cache。 发起评论之后，需要通知所有已经评论点赞的朋友。

• 动态查看：动态从数据读取，评论和点赞从 cache 读取

2. 任务分配：在每个机房使用 nginx 作为负载均衡和代理， 在双机房之间使用 GSLB 对 source IP 做 hash 负载均衡

高可用设计

1. 数据复制： 异地机房之间 mysql 数据采用异步复制数据，朋友圈数据不需要保证强时序，有同步延迟也是可以容忍的，朋友圈数据是增量更新的，需要再客户端，定时拉取最新朋友圈