模块二作业

一、复杂度分析

先说结论：朋友圈业务是属于业务复杂度低、质量复杂度高的类型

业务复杂度分析

主要功能有：

1.发朋友圈

2.查看我的朋友圈

3.查看单人的朋友圈

4.点赞

5.评论

6.新消息提示：通知其他用户，你的动态有N条新点赞，N条新评论

高性能业务指标

2021年1月19日，张小龙披露微信最新数据：目前每天有10.9亿用户打开微信，3.3亿用户进行了视频通话；有7.8亿用户进入朋友圈，1.2亿用户发表朋友圈，其中照片6.7亿张，短视频1亿条；有3.6亿用户读公众号文章，4亿用户使用小程序。

高性能复杂度分析

1.发朋友圈： 1.2亿发朋友圈的用户，按照照片和短视频数量估算，日平均发送5条记录，一共产生 6亿条朋友圈记录，平均TPS接近7000，考虑到多数人都是白天发，会有一定的时间波动性，特别是节日期间/重大活动期间更是发送的高峰。可以将这个数据放大10倍估算。TPS暂时设定为7万。

2.查看我的朋友圈：7.8亿人进入朋友圈，很多人会多次进入，还会经常性的下拉刷新。可以估算为每人每天触发10次查看接口。则QPS为1万，考虑到节日/重大活动期间，有突增的可能。也可以放大10倍估算QPS为10万。

3.查看单人的朋友圈：这个属于较低概率事件，通常较少看单个人的朋友圈。假设10次朋友圈请求，会看一个人的单人动态，再考虑高峰因素，QPS设定为1万。

4.点赞：操作较多，假设每个动态有10人点赞。可以将发朋友圈的TPS*10 = 70万

5.评论：操作较多，假设每个动态有5人次评论，可以将发朋友圈的TPS*5 = 35万

6.未读消息提示：通常有用户轮询、长链接主动推送，推拉两种选择。推的模式通常更可控。所以进入微信后，使用拉的模式，拉取一次未读消息。朋友圈打开时，则通过长链接推送未读提示。假设10.9亿人，平均新打开微信100次，平均QPS接近100万，考虑到节日/重大活动期间，有突增的可能。也可以放大10倍估算QPS为1000万。为了降低复杂度，长链接消息不做估算。

7.其他功能：安全、运营等等，先不做高性能分析。

高可用复杂度分析

朋友圈不是生活必须的，但是长时间的停机是会影响公司声誉的。可以容忍的不可用时间为分钟级。特殊情况下（不得以的维护、功能大升级、大规模网络故障，是可以容忍更长时间的）

所有的业务通常都是可以分钟级不可用，遇到故障，几个小时不可用也不是完全不行（尤其是可以把维护时间调整到夜间，形成错峰的情况下）

1.发朋友圈：需要实时发送，发完对我可见

2.查看我的/他人发的朋友圈：需要近实时体验，可以容忍秒级延迟

3.点赞/评论：对我要求实时，对他人可以近实时，可以容忍秒级延迟

4.未读消息提示：近实时，可以容忍秒级延迟

二、高性能方案

1.发朋友圈

高性能方案

单机 计算高性能 进程模型 团队擅长的就好，Java、Go都可以

 网络模型 传统方案，Nginx等

 缓存模型 不涉及

 存储高性能 存储模型 关系数据库存储

集群 计算高性能 任务分配 负责均衡即可，不需要再拆分业务

 存储高性能 任务分解 数据分片存储

高性能架构图

高可用方案

计算高可用 任务分配 负载均衡即可

 任务分解 不再拆分

存储高可用 数据复制 复制格式 操作都是单条记录，用命令格式

 复制方式 要求不高，异步、半同步、多数复制均可

 状态决策 独裁式 Mysql Router

高可用架构图

2.查看我的朋友圈

高性能方案

单机 计算高性能 进程模型 团队擅长的就好，Java、Go都可以

 网络模型 传统方案，Nginx等

 缓存模型 需要用redis存储，避免遍历所有好友查询

 存储高性能 存储模型 不涉及

集群 计算高性能 任务分配 负责均衡即可，不需要再拆分业务

 存储高性能 任务分解 不涉及

高性能架构图

为了节省时间，借用红包架构图

高可用方案

计算高可用 任务分配 负载均衡即可

 任务分解 不再拆分

存储高可用 数据复制 复制格式 操作都是单条记录，用命令格式

 复制方式 要求不高，异步、半同步、多数复制均可

 状态决策 独裁式 Redis Cluster

高可用架构图