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

朋友圈复杂度总体分析

业务本身比较简单，但是对性能要求比较高，因为是微信的一级入口，用户基数也有 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，提升数据的可靠性。