📣 极限科技诚招搜索运维工程师(Elasticsearch/Easysearch)- 全职/北京 👉 : 立即申请加入

配置项作用 #

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 负载高,可增加
├── 根据实际情况调整
└── 监控性能

配置建议 #

生产环境(默认) #

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

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

降低 Leader 负载 #

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

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

高延迟网络 #

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

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

测试环境 #

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

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

代码示例 #

easysearch.yml 基础配置 #

replication:
  follower:
    poll_interval: 1ms

低负载配置 #

replication:
  follower:
    poll_interval: 100ms

完整跟随者配置 #

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

动态更新配置 #

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

查看复制延迟 #

// 查看复制延迟
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适中延迟和负载-
1sLeader 负载低复制延迟高

负载计算 #

负载计算分析

场景: 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
├── 减少并发
├── 优化网络
└── 检查带宽