好友动态时间线，通常被称为Feed流，是社交产品中最核心的功能之一。每当用户发布一条新动态，其所有关注者都应当按时间倒序看到这条内容。这个看似简单的需求，在千万级用户规模下会变得异常复杂。动态的写入量巨大，读取频率极高，还要求毫秒级延迟，传统的关系型数据库在这种高并发读写场景下往往力不从心。Redis凭借其基于内存的存储结构和丰富的数据类型，成为构建时间线系统的首选组件。
不过，用Redis实现时间线并不只是把数据塞进缓存那么简单。设计者需要权衡读写性能、存储成本、数据一致性等多个维度，在推模式和拉模式之间做出选择，甚至需要针对不同活跃度的用户采取混合策略。这篇文章将从一个完整的系统设计角度出发，逐一拆解这些核心问题。
时间线系统面临的三大核心挑战
在设计基于Redis的时间线方案之前，有必要先梳理清楚技术难点。第一个挑战是写放大的问题。假设一个用户拥有100万粉丝，他发布一条动态时，系统如果采用推模式，需要把这条动态写入100万个关注者的收件箱中，这会产生巨大的写入压力。第二个挑战是读扩散带来的性能瓶颈，也就是拉模式，用户刷新时间线时需要实时聚合所有关注者的最新动态，如果关注了上千个账号，查询开销会非常大。
第三个挑战是时间线的排序与分页。动态必须严格按照发布时间倒序排列，同时支持游标方式的分页加载。翻页过程中还不能出现重复数据或漏数据，这就要求存储结构支持高效的按时间戳排序和截取操作。Redis中的List和ZSet数据类型恰好各自擅长处理一部分需求，但它们有严格的适用边界，用错场景会导致性能急剧下降。
除了这些外部挑战，还有一个隐藏的细节：存储模型的设计。time line中的每一条记录，不能直接存储完整的动态内容，那样会浪费大量内存。更合理的做法是存储动态的ID，然后配合缓存或数据库做二次查询。这就要求在Redis内部维护一套ID生成器，并且确保ID的递增趋势与时间趋势一致，才能保证排序的正确性。
推模式与拉模式的方案对比
拉模式（Pull）的核心思路是，每个用户有一个自己的发件箱（Outbox），存储他发布的所有动态ID。当用户刷新时间线时，系统先拉取他关注的所有用户ID，再逐一查询这些用户的发件箱，最后合并排序。这种模式的写入开销极小，发布一条动态只需写入自己的发件箱，适合粉丝量巨大的头部账号。但问题也很明显，如果用户关注了500个账号，刷新一次就需要合并500个列表，延迟会显著上升。
推模式（Push）正好相反，每个用户有一个收件箱（Inbox），当某个用户发布动态后，系统立即把动态ID推送给所有关注者的收件箱里。用户在读取时间线时，只需要从自己的收件箱中读取一个List或ZSet即可，查询速度极快。但代价是写入放大，一个大V发布动态，会触发海量的写入操作，直接冲击Redis的写性能。对于活跃粉丝数百万的账号来说，这种模式在极端情况下可能导致Redis阻塞。
在真实的大型系统中，推拉结合（Hybrid）模式应用得最广泛。核心思路是区分大V和普通用户，以及区分活跃粉丝和沉默粉丝。对于普通用户的动态，使用推模式直接写入所有粉丝的收件箱；对于大V的动态，则先写入自己的发件箱，由粉丝在刷新时间线时主动拉取。同时，长时间不活跃的粉丝账户，系统会定期将其从推送名单中移除，减少无效的写入。下面给出一段推模式的发布流程伪代码：
// 用户发布动态时，推模式核心逻辑
function publishFeed($userId, $feedId, $timestamp) {
// 1. 写入自己的发件箱，维度是用户ID
$redis->zAdd("outbox:user:{$userId}", $timestamp, $feedId);
// 2. 获取该用户的全部粉丝ID，这里用游标迭代避免阻塞
$cursor = 0;
do {
$result = $redis->zScan("user:{$userId}:followers", $cursor, "*", 1000);
$cursor = $result[0];
$followers = array_keys($result[1]);
// 3. 批量写入每个粉丝的收件箱
$pipe = $redis->multi(\Redis::PIPELINE);
foreach ($followers as $followerId) {
$pipe->zAdd("inbox:user:{$followerId}", $timestamp, $feedId);
}
$pipe->exec();
} while ($cursor > 0);
}
上述代码中，ZSet结构同时承载了去重和排序两个功能。同一个动态ID只会出现一次，而score字段保存的是发布时间戳，天然保证了时间线的倒序。使用pipeline管道技术一次性批量写入，可以将网络RTT的开销降到最低。
基于ZSet的时间线读取与分页实现
时间线读取的重点在于分页。传统关系型数据库常用LIMIT offset, size的方式分页，但在Redis的ZSet中，这种方式的性能并不理想，特别是当页码很深的时候，ZREVRANGE的时间复杂度虽然是O(log(N)+M)，但offset过大会导致大量无效遍历。更推荐的方式是基于游标的分页，每次传入上一次读取到的最后一条动态的score值，用ZREVRANGEBYSCORE继续向下读取。
游标分页还有一个隐蔽的坑，就是score值重复的问题。如果两条动态的发布时间戳恰好相同，ZSet会按照member（动态ID）的字典序进行排序。这样会出现一种情况：第一页读取的末尾元素，与第二页读取的头部元素重叠。解决这个问题有一个常用的技巧，score值可以不用原始时间戳，而是用时间戳拼接一个序号，或者用Redis的INCRBY命令生成全局递增ID，确保score严格唯一。下面给出读取时间线的命令示例：
# 第一次读取，取时间线最新20条 ZREVRANGEBYSCORE inbox:user:10001 +inf -inf LIMIT 0 20 # 假设最后一条的score是1712345678901 # 第二次读取，带上minScore作为游标 ZREVRANGEBYSCORE inbox:user:10001 1712345678900 -inf LIMIT 0 20
这里把游标设置为上一次的score值减去1，可以有效避开边界重叠。读取出的结果只是动态ID列表，接下来需要通过pipeline批量查询动态的详细内容。动态本身的结构体可以存储在一个Hash中，field为feedId，value为序列化后的JSON，设置合理的过期时间以控制内存。值得注意的是，如果时间线中有动态已经被删除，查询时会拿到空值，这需要在业务层做一次过滤处理。
发件箱与收件箱的内存优化策略
一个活跃用户每天可能会产生大量动态，如果所有动态ID都永久保存在收件箱的ZSet中，内存会被迅速耗尽。常用的优化策略是限定收件箱长度。通常一个用户刷新时间线时，最多加载最近几十条数据，翻页到几百条之后基本就没有耐心继续查看了。因此可以只保留每个收件箱最近500条动态ID，超出部分直接裁剪掉。也就是说，老动态如果被挤出收件箱，用户只能通过个人主页的发件箱去查看，不会影响核心体验。
另外，使用ZSet还是List需要仔细权衡。ZSet的内存开销约为List的1.5倍左右，因为ZSet额外存储了score值，且底层用了跳表和哈希表两套索引结构。对于发件箱来说，List就足够满足需求，因为发件箱本身不会存在重复写入的场景。而对于收件箱，既要保证按时间排序，又要适应可能的动态删除操作，ZSet则更加合适。还有一个重要的内存优化手段是使用小整数ID而非长字符串作为member，将动态ID控制在int64范围内，可以显著降低内存占用。
对于Redis集群环境还需要考虑数据倾斜的问题。比如某个超级大V的粉丝收件箱如果集中存储在同一个分片，写入热度会让该分片成为瓶颈。因此key的设计必须带上粉丝用户ID做哈希散列，让不同粉丝的数据分布在不同的节点，这样写入才能做到负载均衡。
推拉结合模式与缓存一致性保障
当推模式遇到粉丝数量达到百万级别的大V时，一次动态发布就会触发百万次写操作，即使有管道优化，仍然会拖垮Redis。这时系统需要在推和拉之间寻找平衡点。实践中比较成熟的方案是：为每个用户维护一个活跃度分数，当粉丝超过一定数量阈值（如10万），就不再向粉丝的收件箱推送动态，而是让粉丝在刷时间线时主动拉取该大V的近期动态。这种方案在微博和Twitter中都有成功的落地案例。
| 方案 | 写入开销 | 读取开销 | 适用场景 |
|---|---|---|---|
| 纯拉模式 | 低 | 极高 | 关注数少、大V较多 |
| 纯推模式 | 极高 | 低 | 粉丝量小、关系链简单 |
| 推拉结合 | 中 | 中 | 大规模生产环境 |
既然收件箱中的动态ID是缓存数据，就必然面临缓存与数据库同步的问题。当动态被删除时，需要同时从发件箱和所有收件箱中移除对应的member，这个操作可以使用ZREM命令完成，代价是接收方需要知道所有粉丝的ID列表。如果这个列表过大，可以考虑采用延迟删除策略，即不立即删除粉丝收件箱中的数据，而是在粉丝刷新时，过滤掉查询结果中已被标记删除的动态ID。这样可以避免大范围的批量写入，换取更高的系统稳定性。
谈到缓存时还要特别注意Redis的淘汰策略。为了控制内存使用，生产环境通常会设置allkeys-lru或volatile-lru策略。对于时间线系统的收件箱，不应该设置过期时间，因为这些数据是长期有效的；反而应该通过限制ZSet的长度来控制内存。如果错误地设置了过期时间，一旦key被淘汰，整个用户的收件箱就全都丢失了，后果非常严重。
最后，对于一个完整的动态时间线系统，Redis通常只作为第1层缓存。真正持久化的动态内容存储在MySQL或者对象存储中，Redis里维持的是索引关系和热数据。冷启动时，如果用户的收件箱不存在，需要从数据库中异步重建，生成最近N条动态ID写入Redis。这种缓存预热策略可以保证用户在任何时间访问，都能看到完整的时间线内容。