一，业务性能指标

1.1 数据背景：

公开数据，张小龙在 2021 年微信十周年时透露的数据：

每天有 7.8 亿人进入朋友圈，1.2 亿用户发表朋友圈，其中照片 6.7 亿张，短视频 1 亿条

折算成秒为单位的话，大概是每秒有 9K 人查看朋友圈，1.4K 人进行内容发布。

1.2 性能复杂度分析

基本的朋友圈业务简单可以分为三大块：

• 主题内容发布

• 对内容进行评论点赞

• 查看朋友圈流

二，高性能方案

2.1 帖子发布

朋友圈的产品形态类似一个 feed 流，一个用户发布了自己的内容后，内容需要通过某种方式展示在他的好友的内容流里面。

基于朋友圈的场景，提出两个假设：

• 发内容的人远少于读取内容的人

• 一个人的好友关系是有限的，平均我的好友在几十人左右，最高不会超过 5K

• 发布的内容不需要特别及时的通知到好友

基于这样的假设，从提升读用户体验的角度出发，内容发布者的内容扩散到他的好友的方式，选择异步的“写扩散”。

1. 内容发布请求服务的单机高性能不涉及

2. 异步写扩散服务的单机高性能：

对于的缓存模型：利用 redis 记录用户关系

存储模型：时间流存储，类似 redis sortSet

1. 集群高性能：

计算高性能：负载均衡即可

存储高性能：按用户分片存储数据

2.2 点赞和评论

点赞和评论是针对帖子的，而且点赞和评论只会通知给帖子作者和其他评论者，写扩散的压力更加小。

1. 评论请求服务的单机高性能基本不涉及

2. 异步写扩散服务的单机高性能：

对于的缓存模型：利用 redis 记录用户关系

存储模型：时间流存储，类似 redis sortSet

1. 集群高性能：

计算高性能：负载均衡即可

存储高性能：按用户分片存储数据

2.3 内容拉取与更新

由于前面发布内容采用的是写扩散机制，那么内容拉取只需要拉取自己的流信息数据

另外，并不是每次拉取都有新的内容，可以增加一个更新状态的缓存，用于过滤无效的拉取请求。

单机高性能

缓存模型：利用 redis 记录更新状态

存储模型：时间流存储，类似 redis sortSet

集群高性能：

计算高性能：负载均衡即可

存储高性能：按用户分片存储数据