业务场景

• 用户发布朋友圈

• 用户查看用户时间线（来自用户的活动）

• 用户查看朋友圈时间线（用户联系人的活动）

• 用户评论或点赞朋友圈

• 用户搜索关键字

业务指标分析

根据网上资料可知，每天有 7.8 亿用户进入朋友圈，1.2 亿用户发表朋友圈，其中照片 6.7 亿张，短视频 1 亿条。

按照这个数据做推断，平均每天有 1.2 亿朋友圈动态进行发布，假设其中 80%发布在空闲时间，即晚上 7 点到 10 点，那么平均 TPS 为 8.8k，考虑到特殊节日或者特发时间，峰值预估为 10 倍，则为 88k TPS。

同样按平均每天有 8 亿用户进入朋友圈的数据进行，每个用户一天会多次刷新朋友圈，假设平均每人刷新 10 次，80%用户会在空闲时间刷新朋友圈，那么平均 QPS 为 60 万，峰值同样预估为 10 倍，则为 600 万 QPS。

朋友圈搜索相对来说使用频率很低，暂不在本次文章的讨论范围内。

复杂度分析

1. 发布、评论、点赞朋友圈的复杂度分析

考虑到发布、评论、点赞三种功能的请求量级都差不多，并且都是写操作的场景，所以放在一起分析。

(1) 朋友圈属于多媒体的形式，分为文本、图片、视频三种形式，其中图片和视频存放在对象存储中，并生成一个可访问的资源链接。关系型数据库，一般选取 mysql，用来存储朋友圈与用户的关联信息。数据库使用分库分表的设计，其中朋友圈数据库表使用用户 id 进行分片存储。

(2) 发布、评论、点赞三种功能除了会对用户朋友圈本身的数据进行写操作外，还会对联系人的数据进行写操作（下面会提到，会有专门的数据结构维护联系人的朋友圈时间线），尤其后者的业务逻辑会更加复杂，因此需要对这两类操作会任务分解，由两个分离的微服务进行处理。分解的逻辑通过消息队列实现，即发布/评论服务处理完请求后，会向消息队列写入一条消息，时间线服务订阅这个消息的 topic，当收到消息后便会根据联系人关系进行时间线的变更。

2. 查看朋友圈的复杂度分析

每个用户的时间线数据都会写入关系型数据库，并且会在 redis 中缓存数据，用以支撑更高的 QPS，redis 使用 list 存储，可根据朋友圈发布的先后数据进行排序。redis 缓存中只会保留每个用户时间线三天内的朋友圈数据，当用户查看 3 天前的记录，可以用 SQL 数据库重建时间线。

对于对象存储的访问，可以使用 CDN 进行加速。

整体架构图