一 总体分析

1.1 业务指标

微信十周年之际，微信创始人张小龙透露了一些数字，目前每天有 10.9 亿用户打开微信，3.3 亿用户进行视频通话；每天有 7.8 亿人进入朋友圈，1.2 亿用户发表朋友圈，其中照片 6.7 亿张，短视频 1 亿条；还有 3.6 亿用户读公众号文章，4 亿用户使用小程序。

1.2 朋友圈高性能复杂度分析

朋友圈操作, 假设 80%的用户操作来自凌晨 6 点至晚上 24 点时间

发朋友圈: 每天 1.2 亿用户, 每秒 TPS 大致 1500 左右

看朋友圈: 每天 7.8 亿人次, 每秒 QPS 大致 1 万左右

点赞/评论: 假设每 3 个用户, 就有 1 个用户操作点赞, 则 TPS 为 4500 左右

二 发朋友圈复杂度分析

2.1 复杂度分析

2.2 架构设计

架构关键设计点:

1. 朋友圈包含文字,图片或短视频, 适合使用 MongoDB 松散型数据结构文档数据库; 图片和短视频表中记录分布式存储的链接;

2. 集群任务分解, 按照用户 ID Hash 分片, 然后再按月分区, 写入到数据库中;

3. 集群任务分配: 可多级分配, 首先按照用户 IP 所属地址配置 DNS 解析就近机房, 进入不同机房后再按照轮询或者随机的任务分配;

三 看朋友圈复杂度分析

3.1 复杂度分析

3.2 架构设计

架构关键设计点:

1. 使用 redis 这类 Nosql 来加速查询

2. 将对 Redis 这类查询提前到网关, 使用业内常见的 Lua 脚本 实现网关对 Redis 的访问;

3. 网关查询不到, 再发往服务器, 查询 DB, 查询完成后, 更新 Redis 缓存;

四 朋友圈评论点赞复杂度分析

4.1 复杂度分析

4.2 架构设计

架构关键设计点:

1. 点赞评论对点赞评论人要立即可见, 直接存入 Reids, key 可以是被评论的朋友圈 id, 通过 id 直接查找 Redis;

2. Redis 中评论的数据结构是 Map 的 key 被评论的朋友圈 ID , List 是评论的列表;

3. 评论和点赞可以通过不同的 key 来区分;

五 总体架构设计

5.1 整体架构

5.2 朋友圈整体架构图

架构关键设计点:

1. 朋友圈首先存入 MongoDB 中, 短视频+图片以 URL 的方式和文字一起存;

2. 查询直接在网关通过 LUA 查询 Redis , 加快查询速度, 因为发朋友圈后, 接收人允许一定的延时收到发送人的动态; 可以使先入库, 在更新缓存;

3. 评论和点赞可以通过不同的 key 来区分;