微信朋友圈高性能复杂度分析

一.问题点

1.分析朋友圈的高性能复杂度

2.各个复杂度，画出对应的架构方案并给出设计的理由

二.业务数据情况及分析

2.1、业务数据情况

2.1.1、 朋友圈打开人数 7.8 亿(天)

2.1.2、发朋友圈人数 1.2 亿(天)

2.2、业务点分析

2.2.1、业务数据流相关的核心一般为读和写

2.2.2、结合业务本身，业务分析点为 读朋友圈、发朋友圈、评论

2.2.3、删除朋友圈、朋友圈查看权限等相对操作不多，不做业务分析。以及点/取消赞逻辑比较单一，不做业务分析点。聚焦朋友圈核心功能为主，便于思考。

2.3、业务数据复杂度分析

2.3.1、假定单人当天访问朋友圈为 10 次

7.8 亿 * 10 / 86400 = 9W QPS

2.3.2、假定单人当天发朋友圈为 1 次

1.2 亿 / 86400 = 1.4K TPS

tip：当前的 T 指的是发朋友圈整体的过程

2.3.3、假定访问朋友圈的人，没人 2 次评论

7.8 亿 * 2 / 86400 = 1.8W TPS

2.3.4、整体的峰值为平均 QPS 的 5-10 倍

2.4、朋友圈总体复杂度分析

朋友圈属于业务复杂度中，技术复杂度较高

2.5、上述逻辑，整体总结归纳

三.朋友圈具体架构图及说明

3.1、查看朋友圈架构图

3.1.1、朋友圈读取说明

1. 每个核心的运算及存储节点，都为集群模式，保证高性能，以及高可用。

2. 朋友圈内并不具备搜索的特性，查看的信息流，以时间前后为维度。本地存储的缓存，会起到比较重要的作用，当然缓存的数据，可能会被当前的朋友删除，以及新增的赞和评论，所以，本地缓存也会进行数据更新。

3. redis 的集群相对于哨兵模式，有更好的扩展性以及可用性。核心也是 redis 作为内存数据库，性能上较好，但也不用存储所有数据，存储时间线离自己较近的方案即可。

4. 数据库为最终的物理存储设备，可采用多主多从的模式，保证数据读取性能。

3.2、发送朋友圈架构图

3.2.1、发朋友圈架构说明

1. 发朋友圈中，包含的有，文字、图片、视频、url 等。主要为两种，图片、视频这种存储空间比较大的静态资源，以及文本资源。图片、视频资源，存储到 oss 当中，cdn 回源到 oss。

2. 处理的服务器，也为集群的方式。没有专门拆出来专门做图片和视频存储的服务，主要考虑到相对读来说，TPS 没有那么夸张，而且 oss 的性能当前也足够好。

3. 相对于读朋友圈的架构，引入 MQ，主要是为了减少 DB 写入数据的压力。而且即使日后发朋友圈的数量逐步增加，DB 层的压力也比较容易得到缓冲。

4. MQ 后的数据，也写入到 redis 中，是为了读取朋友圈数据的方便。读的模式，比较依赖于写的模式。

5. 本地缓存的写入，也极为重要，和上述一致。读的模式，比较依赖于写的模式。

3.3、评论朋友圈架构图

3.3.1、评论朋友圈的架构说明

1. 和上述发朋友圈逻辑基本一致，不做过多的赘述。

2. 摘除了 oss，主要为，评论功能，当前并没有开放用图片等资源进行评论。评论的数据为文本和表情。