RL-Scheduler 中的 Master-Worker 机制可用性分析

816 words

4 minutes

RL-Scheduler 中的 Master-Worker 机制可用性分析

2026-04-11

RL-Scheduler

DB

/

Web

/

RPC

Master-Worker 可用性评估（修正版）#

一、3 个 Redis Key 的作用#

任务分派时，Master 通过 tryDispatchQueuedTaskToWorker() 依次设置：

1
  ┌───────────────────────────────┬────────────────────────────┬──────┬─────────────────┐
2
  │            Key                │            设置时机         │ TTL  │         作用    │
3
  ├───────────────────────────────┼────────────────────────────┼──────┼─────────────────┤
4
  │ worker:{id}:task=taskI        │ tryPreemptWorker() Lua     │ 120s │ Worker          │
5
  │                               │ 脚本原子写入                │      │ 正在处理哪个任务  │
6
  ├───────────────────────────────┼────────────────────────────┼──────┼──────────────────┤
7
  │task:{taskId}:workerId=workerId│ registerTaskOwner()        │ 120s │ 任务被哪个 Worker │
8
  │                               │                            │      │ 认领             │
9
  ├───────────────────────────────┼────────────────────────────┼──────┼──────────────────┤
10
  │ worker:{id}:hb                │ Worker 心跳时续期           │ 30s  │ Worker 是否存活   │
11
  └───────────────────────────────┴────────────────────────────┴──────┴──────────────────┘

二、分派时序（正常流程）#

1
  1. tryPreemptWorker() → 原子写入 worker:{id}:task = taskId (TTL 120s)
2
  2. registerTaskOwner() → 写入 task:{taskId}:workerId = workerId (TTL 120s)
3
  3. dispatchTask() → 通过 Netty 发给 Worker
4
  4. DB status → PENDING 更新为 RUNNING

三、Worker 宕机场景#

1
  Worker 崩溃
2
    → 不再发送心跳
3
    → worker:{id}:hb 在 30s 后过期
4
    → RunningTaskRecovery (每5s) 发现:
5
        - task:{taskId}:workerId 存在 ✓ (任务曾被分派)
6
        - worker:{id}:hb 不存在 → Worker 已死
7
        - worker:{id}:task 存在 → 任务孤立
8
    → 标记 PENDING + releaseTaskOwner()
9
    → PendingTaskReconciler (每2s) 发现 idle worker → 重新分发
10

11
  恢复延迟：30s (心跳TTL) + 5s (扫描间隔) ≈ 35s

四、Master 宕机场景（核心）#

场景 A：Master 在步骤 1-2 之间宕机（未设置 taskOwnerKey）#

1
  宕机前只设置了 worker:{id}:task
2
  DB 状态 = RUNNING（已在 dispatchTask 前更新）
3
  重启后 reconstructWorkerTasksFromRedis():
4
    - 发现 worker:{id}:task = taskId
5
    - 发现 task:{taskId}:workerId 不存在或不匹配
6
    → 标记 PENDING + 入队

场景 B：Master 在步骤 2-3 之间宕机（已设置 taskOwnerKey 但未收到 Worker 响应）#

1
  宕机前设置了 task:{taskId}:workerId + worker:{id}:task
2
  但 DB status = RUNNING 未变（dispatchTask 发送失败或未处理）
3
  重启后:
4
    - worker:{id}:task 存在
5
    - task:{taskId}:workerId 存在且匹配
6
    - RunningTaskRecovery: hb 存在则跳过（Worker 还在跑或刚完成）
7
    - PendingTaskReconciler: worker:{id}:task 存在则不视为 idle
8
  最终由 Worker 心跳或 checkAndFixStaleRunningTasks() 清理

场景 C：Master 在设置 taskOwnerKey 之前宕机（只设置了 Lua 脚本的 worker:{id}）#

1
  宕机前只设置了 worker:{id}:task
2
  task:{taskId}:workerId 不存在
3
  DB status = RUNNING（dispatchTask 前已更新）
4
  重启后 reconstructWorkerTasksFromRedis():
5
    - worker:{id}:task 存在
6
    - task:{taskId}:workerId 不存在或不匹配
7
    → 标记 PENDING + 入队

五、关键机制总结#

1
  ┌─────────────────────────────────┬──────────────────────────────────────────┬────────────────────┐
2
  │              组件               │                   职责                   │      扫描频率      │
3
  ├─────────────────────────────────┼──────────────────────────────────────────┼────────────────────┤
4
  │ RunningTaskRecovery             │ 检测 Worker 宕机导致的任务孤立           │ 每 5s              │
5
  ├─────────────────────────────────┼──────────────────────────────────────────┼────────────────────┤
6
  │ reconstructWorkerTasksFromRedis │ Master 重启时恢复被中断的分派            │ @PostConstruct     │
7
  │                                 │                                          │ 一次               │
8
  ├─────────────────────────────────┼──────────────────────────────────────────┼────────────────────┤
9
  │ PendingTaskReconciler           │ 将 PENDING 任务重新入队给 idle worker    │ 每 2s              │
10
  ├─────────────────────────────────┼──────────────────────────────────────────┼────────────────────┤
11
  │ checkAndFixStaleRunningTasks    │ 心跳时检测 通知丢失导致的任务卡住        │ 每次心跳           │
12
  ├─────────────────────────────────┼──────────────────────────────────────────┼────────────────────┤
13
  │ 心跳续期                        │ renewTaskOwnerTtl() 保持 taskOwnerKey    │ 每次心跳           │
14
  │                                 │ 不过期                                   │                    │
15
  └─────────────────────────────────┴──────────────────────────────────────────┴────────────────────┘

六、3 Key 的最终一致性保证#

无论 Worker 宕机还是 Master 宕机：

1
  Worker 宕机：
2
    worker:{id}:hb 过期 → RunningTaskRecovery 检测 → PENDING + 重新入队
3

4
  Master 宕机（未收到完成通知）：
5
    1. 重启时 reconstructWorkerTasksFromRedis() 修正不一致状态
6
    2. 或者 Worker 心跳时 checkAndFixStaleRunningTasks() 发现 taskKey 没了但 ownerKey 还在 → 标记
7
  COMPLETED