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

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

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

发布：1.2亿用户发朋友圈，假设平均每天发3条

平均TPS，1.2亿 *3 * 0.8 / (6 * 60 * 60) = 13333 ~= 1.4w TPS，峰值按20%的余量评估越 1.7w 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；

浏览：7.8亿用户进入朋友圈，假设没个评价浏览10次

平均QPS，7.8亿 * 10 * 0.8 / (6 * 60 * 60) = 288888 ~= 30万 QPS，峰值36万QPS。

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

1.发布

架构设计

设计理由

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

2. 浏览

架构设计

设计理由

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

3. 点赞/评论

架构设计

设计理由

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

整体架构设计

单机房架构

设计理由

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

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