模块二

一、朋友圈复杂度分析：

1.从业务功能点上看，涉及到业务流程比较简单，业务复杂度不高

2.从质量复杂度上看，要保证朋友发布的动态能及时更新，发布的图片，视频要能快速的展现出来，

存储和加载是个比较高的要求，质量复杂度偏高

整体复杂度落在这个区间：

二. 业务高性能分析

根据微信 20201 年 1 月提供的数据来看，每天有 10.9 亿人打开微信，7.8 亿人进入朋友圈，1.2 亿用户发表

朋友圈，其中照片 6.7 亿张，短视频 1 亿条。

假设/推断：用户使用朋友圈的时间点集中在 8 点-10 点，12 点-14 点，19 点-21 点，按 6 个小时算，7.8 亿用户极端情况下会集中在 2 到 3 个小时，考虑实际情况，浏览的 QPS: 7.8 亿*0.8(推断的系数)/6/3600=2.89 万.

发布的主要是写入数据，计算 TPS: 1.2 亿*0.8/6/3600=0.44 万.

点赞和评论算一起 TPS: 假设每个动态的评论和点赞数为 5（根据日常经验来看），TPS=0.44*5=2.2 万

每个功能按照高性能复杂度分析如下

发布：主要是写入数据，存储图片和端视屏，单机主要考虑的是存储，集群的存储考虑分片存储

单机的计算高性能不考虑，集群的计算高性能 使用负载均衡

数据量比较大，考虑使用 Hbase 集群存储，考虑到浏览时 QPS 较大，需要在 redis 集群里也存一份数 据供浏览时使用

点赞和评论：

针对朋友圈动态的写入，也是主要考虑存储高性能，对好友朋友圈的评论和点赞，针对好友的 ID 和动态 id 进行 Hash 分片存储，点赞和评论的 TPS 比较大，考虑使用 redis 集群作为缓冲（也可以使用 MQ）,最后数据落入 hbase.

单机的计算高性能不再考虑，集群的计算高性能使用 redis 的 list,每个动态的评论和点赞用链表存储，根据动态 id 可以直接全部拿出来

浏览：

浏览主要是加载好友的动态，是个查询的过程，涉及到视频和图片的加载，需要针对图片和视频优化加载，使其速度更快，单机的计算和存储高性能不涉及，集群的存储高性能不涉及，主要是计算高性能，使用任务分配，发布的时候已经把动态存储到 hbase，点赞和评论数存储到 redis,查询的时候 QPS2.8 万，比价高，所以存储的时候考虑 redis 里也存一份朋友圈动态

最终架构如下：

发布，浏览，点赞和评论考虑使用微服务拆分，如果一个服务出问题，不会影响其他服务