微博和知乎中的 feed 流是如何实现的？
Twitter 架构演进
Twitter 的两个主要业务是：
- 发推文: 用户可以向其粉丝发布新消息（平均 4.6k 请求 / 秒，峰值超过 12k 请求 / 秒）。(2012年[2])
- 看推文: 用户可以查阅他们关注的人发布的推文（300k 请求 / 秒）。
1. 读扩散
读扩散处理每秒 12K 次发推文还是很简单的, Twitter 的挑战主要是 300K 查看推文请求.
看推文时，首先查找关注的所有人，查询这些被关注用户发布的推文, 并按时间顺序合并
SQL 伪代码:
SELECT * FROM posts
WHERE user_id IN (SELECT user_id FROM follows WHERE follower_id = :user_id)
ORDER BY created_at DESC
[1]
2. 写扩散
- 发推文时: 查找所有粉丝, 写入所有粉丝的 timeline 中
- 看推文时: 读取 timeline
3. 演进
- 推特第一版使用读扩散, 系统很难承受 300K看推文的负载
- 推特第二版使用写扩散, 一条推文平均推送 75 个粉丝, 所以 timeline 的写压力大约 345K, 读压力是 300K
写扩散看起来很美好, 但是隐患是一些用户有超过 3000 万的粉丝, 如果该用户发推文, 那么写入 3000 万用户的 timeline (而 Twitter 尝试在 5 秒内向粉丝发送推文)
最终: Twitter 已经稳健地实现了写扩散，逐步转向了读写混合模式
Twitter 在技术分享[2]中没有透露实现细节, 下面是我的架构设计
读写混合模式 架构设计
1. 名词解释
- 粉丝收件箱/timeline: 关注页的信息流(微博、朋友圈).
- 发件箱: 作者发布的内容
- 写扩散: 作者发布消息后, 立即推送给粉丝的 "粉丝收件箱"
- 读扩散: 作者发布消息后, 不推送给粉丝. 粉丝获取信息流时, 遍历关注列表中的作者, 拉取 "发件箱" 中的新内容.
- 大V: 粉丝数超过 10 万的用户定义为大V, 大V 不可降级为小V.
2. 作者发布内容时
- 小V : 采用写扩散模式, 写入 所有粉丝 的 "粉丝收件箱"
- 大V : 仅写入 活跃粉丝 的 "粉丝收件箱", 离线粉丝通过读扩散获取
流程图:
2.1. 什么是 "活跃粉丝"?
- 粉丝登录时, 查询自己关注的所有大 V, 注册到当天的 "活跃粉丝" 中
- 大 V 发内容时, 查今天的 "活跃粉丝" 和昨天的 "活跃粉丝",合并 2 个结果作为大 V 活跃粉丝 (1-2天 内登录的都是活跃粉丝)
<---- 昨日 ---->|<---- 今日 ---->
[ 活跃粉丝 ][ 活跃粉丝 ]
<------------------------->
合并后的大V活跃粉丝 (1-2天内登录)
好处:
- 大 V 查询对 关系表 的压力降低到 0 QPS
- 减少大 V 写扩散对 "粉丝收件箱" 的压力
1-2 天登录的用户有点多, 如何减少活跃粉丝量?
缩短时间, 比如 10-20 分钟存在心跳的用户
3. 粉丝登录时
- 查询用户关注的大V列表
- 查询"发件箱"
- 写入新内容到"粉丝收件箱"
- 计算红点
流程图:
4. 粉丝读取内容时
- 查询 "粉丝收件箱"
"粉丝收件箱" 数据结构 (Redis ZSet):
# Score: 内容更新时间戳
# Value: 内容ID
content_id_1 -> 1704240000 (对应 2024-01-03 00:00:00)
content_id_2 -> 1704153600 (对应 2024-01-02 00:00:00)
...
5. 粉丝关注作者时
主线逻辑:
- 查询作者最近发布内容(大V有缓存), 写入 "粉丝收件箱" (100ms)
分支逻辑:
- 判断作者是否大V: (1ms)
- 如果是:
- 修改粉丝 followBigV 表 (1ms)
- 如果不是, 且粉丝数不超 10 万:
- 结束
- 如果不是, 且粉丝数超 10 万:
- 该作者标记为大V (1ms)
- 异步:
- 查询作者所有粉丝 (10s)
- 为每个粉丝
followBigV(关注的大V) 添加此新晋大V (100S)
6. 粉丝取消关注时
主线逻辑:
- 从粉丝收件箱删除作者内容 (大V 有缓存) (100ms)
- 如果是大 V, 从粉丝关注的大V列表删除作者
详细设计
1. 大V列表如何存储?
- 每个用户关注的大V列表, 因为数量有限, 存储在单个 key 中
- 预估: 用户关注 100 个大V, 该 key 约为 1KB
followBigV 数据结构:
{
// 用户关注的大 V ID 列表
"bigVIds": ["10001", "10002", "10003", "10004", "10005"],
// 上次登录刷新时间
"lastRefreshTime": "2024-01-01 00:00:00"
}
2. 如何降低"粉丝收件箱"的存储成本?
- 采用冷热数据分离.
冷备:
- 将 1 个月 未活跃用户的 "粉丝收件箱" 数据从 Redis 迁移到 DB, 标记冷备.
- 存在冷备标记
cold:<UserID> -> '1'表示用户数据被冷备
用户再次登录加载冷备:
- 检查冷备标记.
- 若标记存在 则从 DB 读取数据重新加载到 Redis
用户登录流程图:
3. "粉丝收件箱"的写性能优化
- 采用批量写入 (Pipeline) 能带来 1-2 个数量级的提升 (Redis 单机可达 200-300 万 QPS)
参考
[1] DDIA: http://ddia.vonng.com/#/ch1
[2] Twitter Timelines at Scale https://www.infoq.com/presentations/Twitter-Timeline-Scalability/
