当前位置：首页 > news >正文

Timeline Feed服务

news 2026/6/11 7:05:47

Feed流分类

推荐Feed流
关注Feed流
附近Feed流

Feed流的几种模式

拉模式

介绍：

写：只写发件箱

读：拉所有关注者发件箱 → 合并排序

优点：实现简单，存储空间小。

缺点：读延迟高，读扩散（一次用户请求会放大N倍读请求）。

推模式

写：推送到所有粉丝收件箱

读：直接读收件箱

优点：性能好。（不需要获取关注列表对象的发件箱内容）。

缺点：存储压力大，写扩散（发布一条内容，产生N个写请求）。

推拉结合模式

普通用户：推模式。（写扩散和存储压力可控，延时低）
大V：分活跃用户与非活跃用户。
- 活跃用户：采取推模式。（刷新频率高，推模式延迟低，并且基数小）
- 非活跃用户：采取拉模式。

实现TimeLine Feed流

定义：

Timeline Feed流数据要求内容按照发布时间从近到远排序，对于发布时间相同的内容，按照内容ID由大到小。

内容与用户收件箱的交互：

背景：

在推模式下，当内容发布的时候，我们需要把这些内容推送到粉丝的收件箱当中。

解耦与异步化

问题：内容发布服务与Feed分发逻辑强耦合，导致发布接口可用性降低。
方案：引入消息队列。
流程：发布服务仅发送“内容变更事件” -> 独立的Timeline消费者异步消费消息并执行推送。

可靠性保障

问题：消费者故障可能导致数据丢失。
方案：有序遍历 + 断点续传。
流程：消费者将待推送粉丝ID排序，每推送一个,就更新数据库中的“进度游标”。发生故障后，消息队列的重试机制会触发消费者重新消费，通过读取游标跳过已处理用户，实现精确续传。

并行化优化

问题：海量粉丝场景下，单线程串行遍历推送导致消息积压和高延迟。
方案：分发器-执行器模式。
流程：

分发器：将庞大的粉丝列表按粒度（如每1000人）拆分为多个子任务消息。
执行器：多个实例并行消费子任务消息。

效果：化整为零，将串行阻塞转变为并行处理，大幅提升吞吐量。

收件箱

作用：保存被推送来的数据。

数据库实现：

表结构：

字段名	类型	含义
id	BIGINT	自增主键，无特殊含义
user_id	BIGINT	用户 ID
content_id	BIGINT	内容 ID
publish_time	DATE	内容发布时间

写入：即新增一条记录

读取：

下拉：

定义：下拉用于获取当前时间最新的N条内容。

SELECT content_id, publish_time FROM inbox WHERE user_id = 111 ORDER BY publish_time DESC LIMIT N

上滑：

定义：获取已加载内容的发布时间之后的N条内容。

SELECT content_id, publish_time FROM inbox WHERE user_id = 111 AND (publish_time < ts OR (publish_time = ts AND content_id < last_content_id)) ORDER BY publish__time DE SC LIMIT N

优点：用廉价的磁盘空间assz

缺点：数据库应对高并发的能力有限

Redis的ZSET实现：

结构：

Key为“inbox_{用户ID}”，表示一个ZSET对象是哪个用户的收件箱。
Member 为内容 ID。
Score为内容发布时间。ZSET可以按照内容发布时间从小到大排列内容ID

写入：

ZADD inbox_lll 1688659398 999

读取：

下拉：

ZREVRANGE inbox_lll 0 N-l WITHSCORES

上滑：
原理：先查排名，再按排名偏移
优点：较直接，不需要依赖发布时间，可以天然覆盖多条内容在同一时间发布的场景。
缺点：
- 只适合推模式。不适合推拉结合模式。
- ZREVRANK依赖实时相对位置，当插入或删除数据的时候，位置变化，容易造成消息重复和丢失。
```
-先获取最后内容的排名 local rank = redis.call(* ZREVRANK1, KEYS[1], ARGV[1]) --如果找不到成员则返回空 if rank == false then return {} end —从最后内容的下~~位开始拉取N条内容 local res = redis . call (1 ZREVRANGE' f KEYS [1] , rank + 1, rank + ARGV[2], 1 WITHSCORES 1) return res
```
原理：以‘时间戳’为第一排序键，‘内容ID’为第二排序键。查询时，定位所有满足‘时间戳小于上次’或‘时间戳相等但内容ID小于上次’的数据。”
做法：“ZSET 的排序机制天然对应数据库的‘联合索引’。我们将‘发布时间’作为 Score，‘内容ID’作为 Member，利用 ZSET‘先比分数、后比内容ID’的特性，自动实现了与数据库完全一致的‘时间优先、ID 兜底’的全局有序性。”
问题：ZSET将Member值视为字符串类型，所以使用了字典序排列，而不是数字顺序。导致：虽然这4个成员的Score相同，但是Member 的排列结果却是10833、1673、19671、627。
解决：
String formatMember = String.format("%020d", contentId);
// %020d 含义：输出十进制整数，宽度 20，不足部分用 0 填充
- 方法1.使用上次内容ID获取
- 2.使用时间戳和内容ID获取。