---
title: "跟随者轮询间隔配置"
date: 2026-03-04
lastmod: 2026-03-04
description: "replication.follower.poll_interval 配置项用于控制跟随者轮询 Leader 集群检查新操作的间隔时间。"
tags: ["Replication", "跨集群复制", "轮询", "延迟控制"]
summary: "配置项作用 #  replication.follower.poll_interval 配置项用于控制跟随者轮询 Leader 集群检查新操作的间隔时间。
当 Follower 已经追上 Leader 的操作（没有新的操作需要复制）时，系统会等待此间隔后再次检查。此配置直接影响复制延迟和 Leader 集群的负载。
配置项属性 #   配置路径: replication.follower.poll_interval 数据类型: TimeValue（时间值，如 1ms, 100ms, 1s） 默认值: 1ms（新版本）或 50ms（旧版本） 是否可选: 是 作用域: NodeScope（节点级别） 动态更新: 是（可以动态更新，无需重启）  配置项详解 #  工作机制 #  轮询机制 有新操作时: Leader: 新操作到达 ↓ Follower: 立即获取 ✅ ↓ 处理操作 ↓ 继续检查 无新操作时: Follower: 检查 Leader ↓ Leader: 无新操作 ↓ Follower: 等待 poll_interval ↓ Follower: 再次检查 ↓ 继续轮询 poll_interval = 1ms (新版本默认): ├── 每 1 毫秒检查一次 ├── 最低延迟 ✅ └── Leader 负载高 poll_interval = 50ms (旧版本默认): ├── 每 50 毫秒检查一次 ├── 延迟适中 └── Leader 负载适中 poll_interval = 1s: ├── 每 1 秒检查一次 ├── 延迟较高 └── Leader 负载低 ✅ 代码实现 #  轮询实现逻辑 while (seqNoAlreadyRequested > observedSeqNoAtLeader && missingBatches."
---


## 配置项作用

`replication.follower.poll_interval` 配置项用于控制**跟随者轮询 Leader 集群检查新操作的间隔时间**。

当 Follower 已经追上 Leader 的操作（没有新的操作需要复制）时，系统会等待此间隔后再次检查。此配置直接影响复制延迟和 Leader 集群的负载。

## 配置项属性

- **配置路径**: `replication.follower.poll_interval`
- **数据类型**: `TimeValue`（时间值，如 `1ms`, `100ms`, `1s`）
- **默认值**: `1ms`（新版本）或 `50ms`（旧版本）
- **是否可选**: 是
- **作用域**: NodeScope（节点级别）
- **动态更新**: **是**（可以动态更新，无需重启）

## 配置项详解

## 工作机制

```
轮询机制

有新操作时:
Leader: 新操作到达
    ↓
Follower: 立即获取 ✅
    ↓
处理操作
    ↓
继续检查


无新操作时:
Follower: 检查 Leader
    ↓
Leader: 无新操作
    ↓
Follower: 等待 poll_interval
    ↓
Follower: 再次检查
    ↓
继续轮询


poll_interval = 1ms (新版本默认):
├── 每 1 毫秒检查一次
├── 最低延迟 ✅
└── Leader 负载高


poll_interval = 50ms (旧版本默认):
├── 每 50 毫秒检查一次
├── 延迟适中
└── Leader 负载适中


poll_interval = 1s:
├── 每 1 秒检查一次
├── 延迟较高
└── Leader 负载低 ✅
```

## 代码实现

```
轮询实现逻辑

while (seqNoAlreadyRequested > observedSeqNoAtLeader && missingBatches.isEmpty()) {
    delay(replicationSettings.pollDuration.millis)
}


说明:
├── seqNoAlreadyRequested: 已请求的最大序列号
├── observedSeqNoAtLeader: Leader 上的序列号
├── missingBatches: 缺失的操作批次
└── 条件: 已追上且无缺失批次


效果:
├── 追上 Leader 之前: 持续获取，无延迟 ✅
├── 追上 Leader 之后: 等待 poll_interval
└── 最小化复制延迟
```

## 版本差异

```
新版本 vs 旧版本

旧版本 (Legacy CCR):
├── 默认值: 50ms
├── 配置: poll_interval
├── 延迟: 中等
└── 负载: 中等


新版本:
├── 默认值: 1ms
├── 配置: poll_interval
├── 延迟: 最低 ✅
├── 负载: 较高
└── 推荐使用 ✅


迁移建议:
├── 使用新版本默认值 (1ms)
├── 如 Leader 负载高，可增加
├── 根据实际情况调整
└── 监控性能
```

## 配置建议

## 生产环境（默认）

```yaml
replication:
  follower:
    poll_interval: 1ms  # 新版本默认
```

**建议**: 保持新版本默认值 `1ms`。最低延迟。

## 降低 Leader 负载

```yaml
replication:
  follower:
    poll_interval: 100ms  # 增加间隔
```

**建议**: Leader 负载高或大规模集群时使用。

## 高延迟网络

```yaml
replication:
  follower:
    poll_interval: 50ms  # 适中间隔
```

**建议**: 网络延迟较高时使用，避免无谓的频繁请求。

## 测试环境

```yaml
replication:
  follower:
    poll_interval: 10ms  # 测试配置
```

**建议**: 测试环境使用适中值便于观察。

## 代码示例

## easysearch.yml 基础配置

```yaml
replication:
  follower:
    poll_interval: 1ms
```

## 低负载配置

```yaml
replication:
  follower:
    poll_interval: 100ms
```

## 完整跟随者配置

```yaml
replication:
  follower:
    poll_interval: 1ms
    concurrent_readers_per_shard: 1
    concurrent_writers_per_shard: 2
```

## 动态更新配置

```json
// 运行时更新
PUT /_cluster/settings
{
  "persistent": {
    "replication.follower.poll_interval": "50ms"
  }
}
```

## 查看复制延迟

```json
// 查看复制延迟
GET /_replication/leader_cluster/follower-index/_status

// 响应包含延迟信息
{
  "leader_index": "follower-index",
  "follower_index": "follower-index",
  "lag": "0ms"
}
```

## 相关配置

| 配置项 | 作用 | 默认值 |
|--------|------|--------|
| `poll_interval` | 操作轮询间隔 | 1ms |
| `metadata_sync_interval` | 元数据同步间隔 | 5s |
| `concurrent_readers_per_shard` | 并发读取数 | 1 |

## 性能影响分析

| poll_interval 设置 | 优点 | 缺点 |
|-------------------|------|------|
| 1ms（默认） | 最低延迟 | Leader 负载高 |
| 50ms | 适中延迟和负载 | - |
| 1s | Leader 负载低 | 复制延迟高 |

## 负载计算

```
负载计算分析

场景: 100 个复制分片

poll_interval = 1ms:
每个分片:
├── 每 1ms 轮询一次
├── 每秒 1000 次请求
└── 100 分片 = 100,000 请求/秒 ❌


poll_interval = 50ms:
每个分片:
├── 每 50ms 轮询一次
├── 每秒 20 次请求
└── 100 分片 = 2,000 请求/秒


poll_interval = 1s:
每个分片:
├── 每 1s 轮询一次
├── 每秒 1 次请求
└── 100 分片 = 100 请求/秒 ✅


公式:
总请求/秒 = 分片数 / poll_interval
```

## 使用场景

## 推荐使用默认值的场景

- **低延迟要求**: 需要最快的复制速度
- **小规模集群**: 复制分片数量不多
- **稳定网络**: 网络延迟低且稳定
- **充足资源**: Leader 有足够处理能力

## 推荐增加间隔的场景

- **大规模集群**: 大量复制分片
- **Leader 负载高**: CPU 或网络使用率高
- **高延迟网络**: 网络延迟较高
- **可接受延迟**: 稍高的复制延迟可接受

## 调优建议

```
轮询间隔调优流程

1. 评估复制数量
   ├── 统计复制分片数
   ├── 评估 Leader 容量
   └── 确定负载基线


2. 计算请求频率
   总请求/秒 = 分片数 / poll_interval


3. 测试不同配置
   ├── 1ms → 测试延迟和负载
   ├── 50ms → 测试平衡
   ├── 100ms → 测试负载优化
   └── 测量效果


4. 选择最优值
   ├── 满足延迟要求
   ├── Leader 负载可控
   ├── 网络开销合理
   └── 稳定运行


5. 持续监控
   ├── 复制延迟
   ├── Leader CPU
   ├── 网络使用
   └── 异常告警
```

## 注意事项

1. **默认值**: 新版本默认 `1ms`，旧版本默认 `50ms`。

2. **动态更新**: 可以动态更新，立即生效。

3. **追上时生效**: 只在 Follower 追上 Leader 后才等待此间隔。

4. **Leader 负载**: 减少间隔会增加 Leader 负载。

5. **网络延迟**: 高延迟网络应使用较长间隔。

6. **规模考虑**: 大规模复制应增加间隔。

7. **与 metadata_sync_interval 区别**: poll_interval 用于操作，metadata_sync_interval 用于元数据。

8. **监控建议**: 监控复制延迟和 Leader 负载。

9. **UI 显示**: UI 中可能以秒为单位显示。

10. **测试验证**: 调整后应验证延迟和负载。

## 最佳实践

```
轮询间隔最佳实践

1. 小规模集群
   poll_interval: 1ms

   ├── 最低延迟
   ├── 复制数 < 10
   └── 推荐 ✅


2. 中等规模集群
   poll_interval: 50ms

   ├── 平衡配置
   ├── 复制数 10-100
   └── 推荐 ✅


3. 大规模集群
   poll_interval: 100ms-1s

   ├── 降低负载
   ├── 复制数 > 100
   └── 必要配置


4. 高延迟网络
   poll_interval: 50ms-100ms

   ├── 避免无效请求
   ├── 网络延迟 > 10ms
   └── 优化配置


5. 调优公式
   ├── 目标: Leader CPU < 70%
   ├── 请求/秒 = 分片数 / interval
   ├── 根据目标调整 interval
   └── 验证效果
```

## 故障排查

```
常见问题排查

问题 1: Leader CPU 过高

检查:
├── poll_interval 设置
├── 复制分片数量
├── 请求频率
└── Leader CPU 使用


计算:
请求/秒 = 分片数 / poll_interval(秒)


解决:
├── 增加 poll_interval
├── 减少复制分片数
├── 增加 Leader 节点
└── 优化配置


问题 2: 复制延迟高

检查:
├── poll_interval 设置
├── 网络延迟
├── 处理延迟
└── 复制状态


解决:
├── 减少 poll_interval
├── 优化网络
├── 增加并发
└── 检查瓶颈


问题 3: 网络拥塞

检查:
├── poll_interval 设置
├── 请求频率
├── 网络带宽
└── 丢包率


解决:
├── 增加 poll_interval
├── 减少并发
├── 优化网络
└── 检查带宽
```