清扫器退避延迟配置

配置项作用 #

jobscheduler.sweeper.backoff_millis 配置项用于控制作业清扫器（Job Sweeper）在执行搜索请求失败时的重试退避初始延迟时间。

当清扫器遇到可重试的错误（如 502 Bad Gateway、504 Gateway Timeout、503 Service Unavailable）时，会使用指数退避策略进行重试，此配置作为退避算法的起始延迟值。

配置项属性 #

配置路径: jobscheduler.sweeper.backoff_millis
数据类型: TimeValue（时间值）
默认值: 50ms（50毫秒）
最小值: 必须大于 0
最大值: 约 24 天（Integer.MAX_VALUE 毫秒）
是否可选: 是
作用域: NodeScope（节点级别）
动态更新: 是（支持动态更新）

配置项详解 #

工作机制 #

指数退避算法

退避时间公式:
delay(n) = start + 10 × (e^(0.8×n) - 1) 毫秒

其中:
- start: backoff_millis 配置值
- n: 第 n 次重试（从 0 开始）


计算示例 (backoff_millis = 50ms):

重试 0 (第 1 次尝试):
delay = 50 + 10 × (e^0 - 1) = 50ms

重试 1 (第 2 次尝试):
delay = 50 + 10 × (e^0.8 - 1) ≈ 62ms

重试 2 (第 3 次尝试):
delay = 50 + 10 × (e^1.6 - 1) ≈ 80ms

重试 3 (第 4 次尝试):
delay = 50 + 10 × (e^2.4 - 1) ≈ 111ms

重试 4 (第 5 次尝试):
delay = 50 + 10 × (e^3.2 - 1) ≈ 161ms

重试 5 (第 6 次尝试):
delay = 50 + 10 × (e^4.0 - 1) ≈ 245ms

重试流程 #

清扫器搜索失败重试流程

retry_count = 3, backoff_millis = 50ms

搜索请求:
├── 尝试 1: 失败 (502)
│   ↓ 等待 ~50ms
├── 尝试 2: 失败 (504)
│   ↓ 等待 ~62ms
├── 尝试 3: 失败 (503)
│   ↓ 等待 ~80ms
└── 尝试 4: 失败
    ↓
  最终失败 ❌


如果任一尝试成功，立即返回 ✅

可重试的错误状态码 #

会触发退避重试的 HTTP 状态码

502 Bad Gateway:
├── 网关或代理服务器错误
├── 通常是临时性故障
└── 适合退避重试 ✅


503 Service Unavailable:
├── 服务暂时不可用
├── 可能是过载或重启
└── 适合退避重试 ✅


504 Gateway Timeout:
├── 网关超时
├── 可能是后端响应慢
└── 适合退避重试 ✅

配置建议 #

生产环境（默认） #

jobscheduler:
  sweeper:
    backoff_millis: 50ms  # 默认值

建议: 保持默认值 50ms。适用于大多数场景。

高负载环境 #

jobscheduler:
  sweeper:
    backoff_millis: 100ms  # 增加退避时间

建议: 增加到 100-200ms。集群负载高时使用，给系统更多恢复时间。

快速恢复场景 #

jobscheduler:
  sweeper:
    backoff_millis: 20ms  # 减少退避时间

建议: 减少到 20-30ms。需要快速重试时使用。

大规模集群 #

jobscheduler:
  sweeper:
    backoff_millis: 200ms  # 更长退避时间
    period: 10m

建议: 增加到 200ms 或更多。大规模集群配合更长周期使用。

代码示例 #

easysearch.yml 基础配置 #

jobscheduler:
  sweeper:
    backoff_millis: 50ms

高负载配置 #

jobscheduler:
  sweeper:
    backoff_millis: 100ms
    period: 10m
  retry_count: 5

快速恢复配置 #

jobscheduler:
  sweeper:
    backoff_millis: 20ms
    period: 1m
  retry_count: 2

动态更新配置 #

PUT /_cluster/settings
{
  "transient": {
    "jobscheduler.sweeper.backoff_millis": "100ms"
  }
}

配置项	作用	默认值
`jobscheduler.sweeper.backoff_millis`	退避初始延迟	50ms
`jobscheduler.retry_count`	重试次数	3
`jobscheduler.request_timeout`	请求超时时间	10s
`jobscheduler.sweeper.period`	清扫周期	5m

性能影响分析 #

backoff_millis 设置	优点	缺点
20ms	快速重试	可能加重负载
50ms（默认）	平衡恢复和负载	标准设置
100ms	给系统恢复时间	故障恢复稍慢
200ms+	最大程度保护系统	故障恢复慢

总退避时间对比 #

假设 retry_count = 3

backoff_millis = 20ms:
退避: 20ms, 24ms, 30ms, 38ms
总退避: ~110ms


backoff_millis = 50ms (默认):
退避: 50ms, 62ms, 80ms, 111ms
总退避: ~300ms


backoff_millis = 100ms:
退避: 100ms, 124ms, 161ms, 221ms
总退避: ~600ms


backoff_millis = 200ms:
退避: 200ms, 248ms, 321ms, 441ms
总退避: ~1.2s

使用场景 #

与重试次数的配合 #

backoff_millis 和 retry_count 的协同

配置 1: 标准配置
backoff_millis: 50ms
retry_count: 3
├── 退避: 50ms, 62ms, 80ms, 111ms
└── 总退避: ~300ms
总耗时: ~30s + 300ms (假设每次超时10s)


配置 2: 高容错配置
backoff_millis: 100ms
retry_count: 5
├── 退避: 100ms, 124ms, 161ms, 221ms, 311ms
└── 总退避: ~900ms
总耗时: ~60s + 900ms


配置 3: 快速恢复配置
backoff_millis: 20ms
retry_count: 2
├── 退避: 20ms, 24ms, 30ms
└── 总退避: ~75ms
总耗时: ~30s + 75ms

退避策略更新 #

动态更新退避策略

配置更新时:
backoff_millis: 50ms → 100ms
    │
    ↓
监听器触发
    │
    ↓
更新 sweepSearchBackoffMillis
    │
    ↓
调用 updateRetryPolicy()
    │
    ↓
重新创建 BackoffPolicy:
BackoffPolicy.exponentialBackoff(100ms, retryCount)
    │
    ↓
新策略生效 ✅

注意事项 #

默认值: 默认值为 50ms，适用于大多数场景。
时间格式: 支持 50ms、1s 等时间格式。
动态更新: 支持动态更新，修改后立即生效。
指数增长: 退避时间指数增长，不是线性增长。
与重试配合: 应与 retry_count 配合配置。
系统保护: 适当的退避可以保护系统避免过载。
故障恢复: 退避时间过长会延迟故障恢复。
监控建议: 监控重试成功率，评估退避效果。
测试验证: 配置变更后应验证故障恢复能力。
单位换算: 确保正确理解毫秒和秒的换算。

标签

作业调度退避策略重试机制容错处理