架构训练营模块二作业

微信朋友圈高性能复杂度

业务指标

【业务复杂度】

朋友圈的业务复杂度较低，只有内容发布、查看、评论及点赞等。

【质量复杂度】

朋友圈的用户非常多，根据张小龙在“2021 微信公开课 PRO”中的演讲：

每天有 10.9 亿用户打开微信，3.3 亿用户进行视频通话，7.8 亿用户进入朋友圈，1.2 亿用户发表朋友圈(其中照片 6.7 亿张，短视频 1 亿条)，3.6 亿用户读公众号文章，4 亿用户使用小程序。

可知，微信朋友圈的 UV 约为 7.8 亿，考虑到大部分人都集中在 06:00-24:00 时间段进行访问，则得到平均 qps 为 1.2w，再考虑到在某些时间段如吃饭、上下班路上使用朋友圈的情况会相对集中，假设峰值是平均值的 5 倍，那么高峰期的 qps 大约为 6w。

假设浏览朋友圈的人有一半会点赞，则点赞功能的 tps 约为 3w。

假设点赞朋友圈的人有 1/3 会发表评论，则评论的 tps 约为 1w。

假设发朋友圈的人与评论的人相当，则发布的 tps 约为 1w。

因此，对于朋友圈的架构设计，关键在于：

1. qps/tps 持续很高

2. 用户量很大

所以，需确保其高可用、高性能。

这里我们只讨论其高性能架构设计。

高性能分为计算高性能和存储高性能。

计算高性能分为集群高性能和单机高性能。集群高性能一般通过业务拆分+各拆分业务集群负载均衡实现，(类似中间件集群中的分片+副本机制)；单机高性能一般通过各种优化手段实现，如缓存、异步、队列等。

存储高性能也分为集群高性能和单机高性能。集群高性能一般通过关系型数据分库分表(如 ShardingJdbc)、NoSQL(如 HBase/ES)或分布式存储(FastDFS/云存储(如 OSS))实现。单机高性能则一般通过优化 SQL 来实现。

其整体架构可如下所示：

发朋友圈、浏览朋友圈、点赞朋友圈和评论朋友圈可分别作为一个单独的服务，每个服务部署多个副本实现请求的负载均衡和高可用。

图片、视频比较适合缓存在 CDN。

存储层可使用关系型数据库或 NoSQL：关系型数据库如 MySQL，可做双主多备、读写分离、分库分表和冷热数据分离；NoSQL 如 HBase 集群。

每个用户有哪些朋友可维护在 Redis 中。写数据(发朋友圈、点赞朋友圈、评论朋友圈)时可先写 Redis Cluster 和 MQ 消息队列，然后异步从队列取数据刷 MySQL，这样浏览朋友圈时就可直接读 Redis。

图片、视频存 FastDFS 或云存储(如 OSS)，近期的图片/视频可推到 CDN。