一、微信朋友圈业务特点

微信月活用户 9 亿+，朋友圈每天发表量超过（包括赞和评论）超过 10 亿+，浏览量超过 100 亿+。朋友圈图片的特点是请求量大、消耗计算资源较多，视频则主要消耗带宽。朋友圈的数据是永远存储的，而且随着业务的快速发展，存储容量、带宽和设备的消耗大量增加，尤其重大节日带来的使用量增长，更加剧了消耗，也给运维人员的保障带来了巨大压力。春节要求的增长比例，是上传支持 9 倍增长，下载支持 1 倍增长。小视频的带宽平时会超过 1TB，节日效应增长明显，热点事件容易造成流量暴涨。

按照日均浏览量 100 亿推算，QPS 约 11 万 6 千，日均发表 10 亿推算，TPS 约 1 万 2 千。

春节上传 9 倍增长，峰值 TPS 达到 10 万 TPS。

二、微信朋友圈业务功能

三、朋友圈高性能方案

四、朋友圈发表动态架构图

五、朋友圈浏览架构图

六、方案设计理由

由于微信用户分布全国，建议使用异地多机房方案，确保数据容灾和数据读取效率。前端使用 Hash 负载均衡，业务服务器处理业务逻辑，朋友圈发表主要有图文和视频两种载体，为了减轻服务器的磁盘占用和便于业务展示，固需要对图片和视频进一步压缩和生成不同像素大小的副本，视频文件相对比较大，两者压缩方式也不同，视频压缩更耗时，图片数量更多，固做了业务上的任务拆分。

由于朋友圈的特性，发表的动态只有好友才能浏览，有扩散读和扩散写的方案，选择了扩散写的方案因为读是有很多失败的，一个用户如果要去读几百个好友的相册表，极端情况下可能要去多个服务器上去去数据，这个失败的可能性是很大的，读取的业务也相对复杂。微信朋友好友并不会好多，为了业务更简单拉取时间线只需一次性拉取，写扩散模型可以很大的减少服务的开销。批处理写入时间线数据耗时相对较长另外做了任务拆分。

图片和视频文件数量非常多切需要永久保存，固选择分布式文件系统作为存储，多副本备份。朋友圈数据结构简单，但是每天发表点赞评论数据非常多，且数据一致性并没有太高的要求，固选择 KV 分布式储存，方便横向扩展。