Redis中使用HSCAN实现分页的有效性及解决方案咨询

你的顾虑是否合理？ #

你的顾虑不完全合理，Redis的HSCAN命令本身就针对迭代过程中的数据变更做了设计，不会出现游标失效的情况。

核心原因 #

• Redis哈希表采用渐进式rehash机制，迭代期间即使哈希表扩容/缩容，游标会自动适配新旧哈希表的槽位映射，不会导致遍历逻辑崩溃
• HSCAN的游标基于哈希表的槽位工作，新增或删除键值对只会影响对应槽位的遍历，不会让整个游标失效
• 官方明确：SCAN系列命令（含HSCAN）在迭代时，数据集的修改只会引发两种可预期的情况：新增元素可能被遍历到，也可能不会；已删除的元素可能仍被返回，但可在业务层自行过滤，不会出现遗漏或完全混乱的遍历结果

若业务需严格避免重复/遗漏的解决办法 #

如果你的业务场景完全无法接受遍历过程中的重复或遗漏，可采用以下方案：

• 临时快照法：迭代开始前，将目标HSET的数据分批复制到临时键（如用HSCAN原键分批读取，再HSET到临时键），之后对临时键进行分页迭代，完成后删除临时键。缺点是会占用额外内存，且无法获取迭代期间的新增数据
• 时间戳过滤法：给HSET的每个条目添加create_time字段，API首次返回数据时附带本次遍历到的最大时间戳；后续请求时，在HSCAN遍历的同时，业务层过滤出时间戳大于上次返回值的条目。这种方式能避免重复获取旧数据，新增数据也会在后续迭代中被获取
• 分区拆分法：将大型HSET拆分为多个小HSET，比如按数据的时间区间、用户ID前缀等维度拆分。分页时直接定位到对应分区的HSET进行遍历，减少单HSET的规模，同时降低全局迭代时数据变更的影响

是否需要更换存储方式？ #

如果上述方案能满足你的业务需求，不需要更换存储方式。若业务对分页的严格顺序、无重复无遗漏有极高要求（如金融场景），可考虑以下存储方式：

• 有序集合（ZSET）：给每个元素设置唯一的score（如时间戳+唯一ID），通过ZRANGE或ZSCAN实现分页，能保证严格顺序，新增元素只会按score排序插入对应位置，不会打乱已有分页逻辑。需注意ZSET每个元素仅能存储一个值，可将哈希的键值对序列化为字符串存储，或用ZSET存唯一标识、HSET存详细数据的组合方式
• 列表（LIST）：若数据是严格顺序插入的，可使用LRANGE实现分页，但LIST的随机访问效率较低，仅适合纯顺序分页的场景

内容的提问来源于stack exchange，提问作者bereal