如何保障消费者应用宕机后Redis有序集遗漏数据的可靠处理？

现有系统概述 #

• infraApp：每2分钟向Redis写入有序集合（sortedSet），键采用yyyy-MM-dd-HH:MM格式的当前时间命名，确保每2分钟生成唯一键
• processorApp：基于Cron调度的Node.js可执行文件，负责读取Redis中的sortedSet、发送至队列处理后删除对应键，但存在频繁崩溃重启问题

核心问题与约束 #

当processorApp宕机时，infraApp仍持续写入数据，需满足：

• 恢复后可靠处理宕机期间的遗漏数据，支持断点续处理
• 无数据丢失，每个sortedSet仅被处理一次
• processorApp宕机不影响infraApp正常运行

最优方案设计 #

1. 元数据追踪：统一管理待处理集合 #

• 在Redis中维护一个名为pending_sorted_sets的有序集合：
  • infraApp每次成功写入目标sortedSet后，将该键作为成员、对应的时间戳（与键的时间一致）作为分数，添加到这个有序集合中
  • 该集合作为所有待处理sortedSet的唯一入口，processorApp无需遍历Redis所有键，直接从这里获取待处理项

2. 处理流程的幂等与状态管控 #

• 启动时的断点恢复：processorApp重启后，先扫描pending_sorted_sets获取所有未处理键，同时检查processing_status哈希表中过期的“处理中”项，将这些项重新加入pending_sorted_sets
• 处理中状态标记：处理某个sortedSet前，先在processing_status哈希表中记录该键的状态为processing，并设置5分钟过期时间（超过这个时间未完成处理，视为处理失败）
• 原子化完成操作：当成功将数据发送至队列后，通过Redis Lua脚本执行以下原子操作：
  1. 删除目标sortedSet
  2. 从pending_sorted_sets中移除该键
  3. 删除processing_status中对应的状态记录

3. 替代Cron：改用常驻进程轮询 #

• 将原Cron调度改为常驻Node.js进程，每2分钟轮询一次pending_sorted_sets，按时间顺序（分数从小到大）处理待处理键
• 这样processorApp恢复后无需等待Cron下一次触发，可立即开始处理遗漏数据

适用的Redis模式与机制 #

• 有序集合（Sorted Set）作为待处理队列：利用分数的有序性保证处理时序，支持快速范围查询（如获取所有未处理的历史键）
• 哈希表（Hash）用于处理状态追踪：轻量存储每个sortedSet的处理状态，配合过期时间避免状态死锁
• Lua脚本保障原子性：将处理完成后的多步操作封装为Lua脚本执行，防止中间步骤失败导致数据不一致
• 过期键（Expire）机制：给“处理中”状态设置过期时间，确保处理器崩溃后，未完成的任务能被重新调度

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