一、  业务量估算

1.1 发动态业务量

根据 2021 年张小龙 在公开课中公布的数据，平均每天发动态业务量为：

● 7.8 亿用户进入朋友圈，1.2 亿用户发表朋友圈，其中照片 6.7 亿张，短视频 1 亿条。

折算每秒数据如下：

● 每秒 1400 条动态，其中照片 7800 张，视频 1200 条。

没有查到峰值数据，暂时按照 10 倍来估算发朋友圈和杜朋友圈的事件量，即每秒峰值数据：

● 发状态：每秒 1.4w 条，其中照片 7.8w 张，视频 1.2w 条。

1.2 看朋友圈业务量

按照公布数据，进入朋友圈的用户数量是发动态用户数量的 6.5 倍，再做如下假设：

● 每个人查看 10 条动态；

● 点赞数为查看数的 20%；

● 评论数为查看数的 5%

则估算查看看动态的峰值数据为：

● 看动态：每秒 90w 条，其中照片 78000 张，视频 12000 条。

● 点赞：每秒 18w 个

● 评论：每秒 4.5w 条

1.3 朋友圈状态管理业务量

一般来说，状态一经发布，就很少有人再更改状态，相对于发状态和看状态，业务量相差 n 个数量级，所以这里不做考虑。

1.4 业务量图示

二、  高性能复杂度分析

三、  架构方案

3.1 架构图

3.2 架构设计关键步骤说明

1.  存储选型

朋友圈包含文字、图片、视频，且读写频繁，不适合 MySQL 等关系型数据库；且文字、图片、视频又有不同，这里选择 hdfs 存储图片视频，mongoDB 存储文字。

点赞数比较简单，在 kv 数据库和 MySQL 中做选择时，考虑到数据类型和表结构都很简单，放在 MySQL 中性能也可以符合需求，再考虑持久化存储的需要，最终选择了 MySQL。

2.  任务分配 &任务分解

是否应该将朋友圈服务器集群分解为发状态、读状态、点赞、评论等集群，因为访问量虽然很大，但其实场景比较简单，所以没有再次拆分。