写点什么

作业 - 分析一下微信朋友圈的高性能复杂度

用户头像
a1vin-tian
关注
发布于: 2021 年 04 月 18 日

朋友圈复杂度总体分析

业务本身比较简单,但是对性能要求比较高,因为是微信的一级入口,用户基数也有 10 亿。访问量每天有 100 亿次。

朋友圈高性能业务指标

截止到 2015 年 7 月,微信每月活跃用户约 5.49 亿,朋友圈每天的发表量(包括赞和评论)超过 10 亿,浏览量超过 100 亿。得益于 4G 网络的发展,以上数据仍有很快的增长,而且相对于 PC 互联网时代,移动互联网时代的峰值要来得更加凶猛。比如,2015 年元月的流量到了平时的 2 倍,而峰值则达到了平时峰值的 2 倍,相当于平时正常流量的 5 倍,这对整个系统的考验是很残酷的。

朋友圈高性能复杂度分析

首先我们把朋友圈分为发布朋友圈,刷朋友圈(刷的同时也刷出了评论),评论点赞 3 类功能。 其中发布和评论相对于刷评论会缩小 10 倍的流量,我们按照上述数据的峰值给出以下计算。



高性能方案 - 发布


架构


用户发布朋友圈时将该记录存储在独立的发布 redis 集群的发布记录表中,然后将发布记录 ID 复制到该用户以及其好用的朋友圈时间线列表中,将图片存储对象存储中,方便后续操作图片和 CDN 缓存。


高性能方案 - 评论点赞



评论往往会比发布记录要多的多,为了不影响用户因为评论加载不出来而加载不出来朋友圈,采用独立 redis 集群存储部署。

用 redis list 以发布记录 ID 为 key 进行存储,这样在查询的时候可以直接查出来该朋友圈下的所有列表。

高性能方案 - 刷朋友圈



直接查询该用户的朋友圈时间线,然后根据每条朋友圈的发布记录 ID 到对应集群查询对应的发布记录和评论列表即可。查询 3 次即可全查出来,查询出来在内存中过滤下好友规则即可。

图片通过 CDN 缓存直接查 cos,不需要走业务服务器,提升了性能。


高性能方案- 整体架构


用户体量比较大,而且业务这么重要,肯定是多机房部署了。


整个架构建议最后还是用自研的带副本的 key-value 存储代替 redis,提升数据的可靠性。


用户头像

a1vin-tian

关注

还未添加个人签名 2018.04.21 加入

还未添加个人简介

评论

发布
暂无评论
作业 - 分析一下微信朋友圈的高性能复杂度