微信朋友圈高性能复杂度

业务指标

【业务复杂度】

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

【质量复杂度】

朋友圈的用户非常多，根据张小龙在“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。

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

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

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

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

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

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

其整体架构可如下所示：

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

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

存储层内容发布、点赞和评论可分别使用一个单独的库。可使用关系型数据库或NoSQL：关系型数据库如MySQL，可做双主多备、读写分离、分库分表和冷热数据分离；NoSQL如HBase集群。

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

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

可能还需辅以熔断、限流、降级等服务治理手段，如Sentinel。