--- title: "清扫器退避延迟配置" date: 2026-02-04 lastmod: 2026-02-04 description: "jobscheduler.sweeper.backoff_millis 配置项用于控制作业清扫器重试时的初始退避延迟时间。" tags: ["作业调度", "退避策略", "重试机制", "容错处理"] summary: "配置项作用 # 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." --- ## 配置项作用 `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: ├── 网关超时 ├── 可能是后端响应慢 └── 适合退避重试 ✅ ``` ## 配置建议 ## 生产环境（默认） ```yaml jobscheduler: sweeper: backoff_millis: 50ms # 默认值 ``` **建议**: 保持默认值 `50ms`。适用于大多数场景。 ## 高负载环境 ```yaml jobscheduler: sweeper: backoff_millis: 100ms # 增加退避时间 ``` **建议**: 增加到 `100-200ms`。集群负载高时使用，给系统更多恢复时间。 ## 快速恢复场景 ```yaml jobscheduler: sweeper: backoff_millis: 20ms # 减少退避时间 ``` **建议**: 减少到 `20-30ms`。需要快速重试时使用。 ## 大规模集群 ```yaml jobscheduler: sweeper: backoff_millis: 200ms # 更长退避时间 period: 10m ``` **建议**: 增加到 `200ms` 或更多。大规模集群配合更长周期使用。 ## 代码示例 ## easysearch.yml 基础配置 ```yaml jobscheduler: sweeper: backoff_millis: 50ms ``` ## 高负载配置 ```yaml jobscheduler: sweeper: backoff_millis: 100ms period: 10m retry_count: 5 ``` ## 快速恢复配置 ```yaml jobscheduler: sweeper: backoff_millis: 20ms period: 1m retry_count: 2 ``` ## 动态更新配置 ```json 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 ``` ## 使用场景 ## 推荐使用默认值的场景 - **标准环境**: 集群运行稳定 - **正常负载**: 集群负载在正常范围 - **常规容错**: 需要基本的容错能力 ## 推荐增加退避时间的场景 - **高负载环境**: 集群经常高负载 - **不稳定系统**: 系统稳定性差 - **资源紧张**: CPU、内存资源紧张 - **大规模集群**: 节点多、交互复杂 ## 推荐减少退避时间的场景 - **快速恢复**: 需要快速从故障中恢复 - **稳定环境**: 集群非常稳定 - **低延迟要求**: 对延迟敏感 - **小规模集群**: 节点少、负载轻 ## 与重试次数的配合 ``` 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) │ ↓ 新策略生效 ✅ ``` ## 注意事项 1. **默认值**: 默认值为 `50ms`，适用于大多数场景。 2. **时间格式**: 支持 `50ms`、`1s` 等时间格式。 3. **动态更新**: 支持动态更新，修改后立即生效。 4. **指数增长**: 退避时间指数增长，不是线性增长。 5. **与重试配合**: 应与 `retry_count` 配合配置。 6. **系统保护**: 适当的退避可以保护系统避免过载。 7. **故障恢复**: 退避时间过长会延迟故障恢复。 8. **监控建议**: 监控重试成功率，评估退避效果。 9. **测试验证**: 配置变更后应验证故障恢复能力。 10. **单位换算**: 确保正确理解毫秒和秒的换算。