--- title: "集群故障检测跟随者检查重试次数配置" date: 2026-02-25 lastmod: 2026-02-25 description: "cluster.fault_detection.follower_check.retry_count 配置项用于控制在将跟随者节点标记为故障之前允许的检查失败次数,避免因短暂网络问题导致节点被误判。" tags: ["集群", "故障检测", "跟随者", "高可用", "Leader选举"] summary: "配置项作用 # cluster.fault_detection.follower_check.retry_count 配置项定义了在将一个跟随者(follower)节点标记为故障之前,允许连续检查失败的最大次数。 这是 Easysearch 集群协调机制中的容错配置,用于防止因短暂的网络抖动、GC 停顿或其他临时性问题导致节点被错误地从集群中移除。 配置项属性 # 配置路径: cluster.fault_detection.follower_check.retry_count 数据类型: integer 默认值: 3 最小值: 1 是否可选: 是 配置项详解 # 故障检测机制 # 在 Easysearch 的集群协调机制中,Leader 节点会定期向所有 Follower 节点发送健康检查请求: Leader 节点 Follower 节点 │ │ │ ────── health check ──────>│ │ │ │ <──── response ─────────────│ │ │ │ (如果失败,计数器 +1) │ │ │ │ ────── health check ──────>│ (失败计数 < retry_count) │ │ 继续重试 │ │ │ (失败计数 >= retry_count) │ │ │ │ 标记节点故障,从集群移除 │ 工作原理 # 定期检查: Leader 按照配置的间隔(默认 1 秒)向 Follower 发送健康检查 失败计数: 每次检查失败时,失败计数器递增 阈值判断: 当失败计数达到 retry_count 时,才认定节点故障 成功重置: 检查成功后,失败计数器重置为 0 容错设计 # Easysearch 采用"宽松"的故障检测策略:" --- ## 配置项作用 `cluster.fault_detection.follower_check.retry_count` 配置项定义了在将一个跟随者(follower)节点标记为故障之前,允许连续检查失败的最大次数。 这是 Easysearch 集群协调机制中的容错配置,用于防止因短暂的网络抖动、GC 停顿或其他临时性问题导致节点被错误地从集群中移除。 ## 配置项属性 - **配置路径**: `cluster.fault_detection.follower_check.retry_count` - **数据类型**: `integer` - **默认值**: `3` - **最小值**: `1` - **是否可选**: 是 ## 配置项详解 ## 故障检测机制 在 Easysearch 的集群协调机制中,Leader 节点会定期向所有 Follower 节点发送健康检查请求: ``` Leader 节点 Follower 节点 │ │ │ ────── health check ──────>│ │ │ │ <──── response ─────────────│ │ │ │ (如果失败,计数器 +1) │ │ │ │ ────── health check ──────>│ (失败计数 < retry_count) │ │ 继续重试 │ │ │ (失败计数 >= retry_count) │ │ │ │ 标记节点故障,从集群移除 │ ``` ## 工作原理 1. **定期检查**: Leader 按照配置的间隔(默认 1 秒)向 Follower 发送健康检查 2. **失败计数**: 每次检查失败时,失败计数器递增 3. **阈值判断**: 当失败计数达到 `retry_count` 时,才认定节点故障 4. **成功重置**: 检查成功后,失败计数器重置为 0 ## 容错设计 Easysearch 采用"宽松"的故障检测策略: - 允许多次检查失败才认定节点故障 - 避免短暂的网络分区导致不必要的节点移除 - 防止长时间 GC 周期触发分片重新分配 - 提高集群的稳定性 ## 配置建议 ## 生产环境(标准) ```yaml cluster.fault_detection.follower_check.retry_count: 3 ``` **建议**: 保持默认值 `3`。这是经过验证的平衡值,既能及时检测真正的节点故障,又能容忍偶发的网络问题。 ## 高延迟网络环境 ```yaml cluster.fault_detection.follower_check.retry_count: 5 ``` **建议**: 增加到 `5-10`。网络延迟较高或不稳定时,需要更大的容错空间。 ## 快速故障检测要求 ```yaml cluster.fault_detection.follower_check.retry_count: 2 ``` **建议**: 减少到 `2`。当业务对节点故障极其敏感,需要快速切换时使用,但可能增加误判风险。 ## 极不稳定网络环境 ```yaml cluster.fault_detection.follower_check.retry_count: 10 ``` **建议**: 增加到 `10-15`。网络质量极差的环境,需要更大的容错阈值以避免频繁的节点状态变化。 ## 代码示例 ## easysearch.yml 配置 ```yaml # 生产环境标准配置 cluster: fault_detection: follower_check: retry_count: 3 interval: 1s timeout: 10s ``` ## 高延迟网络配置 ```yaml cluster: fault_detection: follower_check: retry_count: 8 # 增加重试次数 interval: 2s # 增加检查间隔 timeout: 30s # 增加超时时间 ``` ## 相关配置 | 配置项 | 作用 | 默认值 | |--------|------|--------| | `cluster.fault_detection.follower_check.interval` | 检查间隔时间 | 1s | | `cluster.fault_detection.follower_check.timeout` | 单次检查超时时间 | 10s | | `cluster.fault_detection.leader_check.retry_count` | Leader 检查重试次数 | 3 | ## 配置配合说明 这三个配置共同决定了故障检测的行为: - **retry_count × interval = 最大故障检测时间** - 例如:默认配置下,最多需要 3 × 1s = 3 秒才能确认节点故障 - 如果 interval=2s, retry_count=5,则最多需要 10 秒确认故障 ## 故障类型识别 根据代码实现,不同类型的失败有不同处理: | 失败类型 | 说明 | |----------|------| | 连接异常 | 网络连接失败,节点可能已下线 | | 健康检查失败 | 节点响应但健康状态异常 | | 超时 | 未在规定时间内收到响应 | | 达到重试上限 | 连续失败次数达到 retry_count | ## 性能与可靠性权衡 | retry_count 设置 | 优点 | 缺点 | |------------------|------|------| | 较小(1-2) | 快速发现和移除故障节点 | 容易误判,短暂网络问题可能导致节点移除 | | 中等(3-5) | 平衡故障检测速度和容错能力 | 故障检测有一定延迟 | | 较大(10+) | 高容错,减少误判 | 故障检测慢,集群恢复延迟大 | ## 注意事项 1. **全局生效**: 此配置在集群级别生效,通常所有节点应使用相同配置。 2. **动态更新**: 可以通过集群设置 API 动态更新,无需重启节点。 3. **与其他设置配合**: 需要与 `interval` 和 `timeout` 配合使用,确保整体故障检测策略合理。 4. **集群健康影响**: 设置过小可能导致频繁的分片重新分配;设置过大可能导致故障节点长时间未被移除,影响集群性能。 5. **监控建议**: 建议监控节点移除事件,如果频繁发生节点移除,可能需要调整此配置或检查网络质量。