故障转移

故障场景

常见故障

延时队列可能遇到的故障：

1. 消费者故障
   ├─ 进程崩溃
   ├─ 网络断开
   └─ 内存溢出

2. 调度器故障
   ├─ 进程崩溃
   ├─ 领导者切换
   └─ 数据不一致

3. 存储故障
   ├─ Redis 宕机
   ├─ MySQL 宕机
   └─ Kafka 宕机

4. 网络分区
   ├─ 节点间通信失败
   ├─ 脑裂问题
   └─ 数据不一致

故障检测

心跳机制

心跳不是为了证明机器“还活着”，而是为了证明它仍然有能力继续承担某个任务范围。调度器定期写入自己的心跳时间、负责分片和处理进度；其他节点根据心跳是否过期判断是否需要接管。

判断故障时不能太激进。网络短暂抖动、GC 停顿、磁盘抖动都可能让心跳延迟。如果过期时间设置太短，系统会频繁误判故障，反而制造重复调度。生产系统通常会结合连续多次失败、任务积压和节点状态一起判断。

故障恢复

任务迁移

任务迁移的核心，是把“原来属于故障节点的任务范围”重新分给健康节点。迁移时要先确认旧节点的租约已经失效，再让新节点接手，否则两个节点可能同时处理同一批任务。

恢复过程通常分三步：

1. 标记旧节点失联，冻结它的任务范围。
2. 重新分配分片或队列，并写入新的租约版本。
3. 新节点从上次进度继续扫描，同时对处理中超时任务做补偿。

真正困难的不是发现故障，而是恢复后不丢任务、不重复执行、不让积压继续扩大。

高可用架构

主备切换

如果系统采用主调度器模式，就必须考虑主备切换。主节点负责分配任务范围，备节点持续观察主节点心跳；当主节点失联，备节点竞争成为新主节点，并接管分配工作。

主备切换最怕脑裂。两个主节点同时存在时，任务范围可能被重复分配。解决办法是让“谁是主节点”这件事有一个单一事实来源，例如带版本号的租约记录。每次续约和接管都要比较版本，旧主节点恢复后如果发现版本落后，必须主动降级。

小结

故障转移不是事故发生后的补丁，而是延时队列设计的一部分。只要任务可能等待几分钟、几小时甚至几天，系统就必须接受一个事实：等待过程中机器一定可能挂。可靠设计要让任务跟着状态走，而不是跟着某一台机器走。