重学架构之微信朋友圈高性能架构分析

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

https://cloud.tencent.com/developer/article/1030046

按官统计刷朋友圈主要集中在 7:00～7:45， 10:00～12:00，17:00～18:00，20:00～22:00 这 4 个时间段：6 个小时的时间，假设这 6 个小时集中了 80%的流量。

朋友圈的业务主要是发布、浏览、点赞与评论，由统计数据可知，是一个读多写少的业务，点赞与评论比较相似，将它们放在一起讨论。

发布：平均 TPS，1.2 亿 * 0.8 / (6 * 60 * 60) = 5555 ~= 6000 TPS，峰值按 20%的余量评估越 7000 TPS；

图片：平均 TPS 按 1:6 约为:3.6 万 TPS，峰值 4.2 万 TPS；

视频：平均 TPS 按 1:1 约为:6000 TPS， 峰值 7000 TPS；

评论/点赞：假设平均每条朋友圈有 10 个点赞和评论，平均 TPS 按 1:10 约为:36 万 TPS， 峰值 7 万 TPS；

浏览：平均 QPS，7.8 亿 * 0.8 / (6 * 60 * 60) = 36111 ~= 3.6 万 QPS，峰值 4.3 万 QPS。

分析完朋友圈业务特点后，再逐个分析发布、浏览与点赞评论的高性能架构方案

1.发布

架构设计

设计理由

图片和短视频内容较大且数量多，不太适合放到关系型数据库中，将其用分布式文件系统存储，在朋友圈动态中只存图片或短视频的地址即可，每条动态都有唯一的 UID，根据动态的 UID 进行分库分表。

2. 浏览

架构设计

设计理由

任务分配器使用 Hash，因为使用了本地缓存，按用户 ID Hash 能保证用户的请求能在同一台机器上，再加上 APP 端的缓存，能最大限度的使用缓存。动态为读多写少，将动态缓存能降低数据库的压力。

3. 点赞/评论

架构设计

设计理由

点赞/评论如用 HBase，系统中的组件过多，会增加系统复杂度已经维护的成本，所以仍然选用关系型数据库存储。

整体架构设计

单机房架构

设计理由

1. 微信的业务量大用户多，整体上采用多机房架构比较合适，机房与机房之间通过专线同步数据。

2. 不同地区的用户通过 DNS 或者 GSLB 将用户接入到不同的机房。