分布式调度器多节点如何实现唯一事件选取避免重复处理

现有方案评估 #

• 你当前在用的节点IP过滤方案：核心缺陷是可用性差，一旦对应IP的节点宕机，绑定给该节点的任务会全部积压无法执行，而且节点扩容、缩容时需要手动调整分配规则，灵活性极低，仅适合节点完全固定、任务允许中断的极小众场景。
• ZooKeeper实现方案：完全可行，属于分布式调度领域解决任务唯一分配的成熟技术路线，稳定性和一致性都有保障，适合长期迭代的生产系统。

可落地的三类实现方案 #

方案1：ES原生乐观锁抢占（改造成本最低，无需引入额外组件） #

适合不想调整现有技术栈、快速解决问题的场景：

1. 给ES中的事件文档新增3个字段：status（事件状态，枚举值：待处理/处理中/处理完成）、lock_owner（当前持有任务的节点ID）、lock_expire_at（锁过期时间戳，避免节点抢到任务后宕机导致任务永久积压）
2. 拉取任务时直接调用ES的update_by_query原子接口，示例请求逻辑：

POST /your_event_index/_update_by_query
{
  "query": {
    "bool": {
      "must": [
        {"term": {"status": "pending"}},
        {"range": {"lock_expire_at": {"lt": 1710000000000 /* 当前时间戳 */}}}
      ]
    }
  },
  "script": {
    "source": "ctx._source.status = 'processing'; ctx._source.lock_owner = params.node_id; ctx._source.lock_expire_at = params.expire_ts",
    "params": {
      "node_id": "current_node_unique_id",
      "expire_ts": 1710000000000 + 300000 /* 锁有效期5分钟，按任务最大执行时长调整 */
    }
  },
  "size": 10 /* 单次拉取的任务数量 */
}

3. 接口返回的命中记录就是当前节点唯一抢到的任务，不会出现多节点重复拉取的情况。任务执行完成后再调用ES接口把对应事件的status更新为finished即可。

方案2：ZooKeeper一致性分片调度（一致性最高，适合长期迭代的生产系统） #

适合后续有节点扩容需求、对调度可靠性要求高的场景：

1. 集群节点注册：每个调度节点启动时，在ZK的/scheduler/cluster_nodes路径下创建临时有序节点，节点宕机后临时节点会自动删除，ZK实时维护当前存活的节点列表。
2. 分片规则配置：提前把事件的唯一ID按哈希取模分成固定数量的分片（分片数建议是节点数的整数倍，比如3台节点就设为3或6个分片），每个节点按自己在ZK临时有序节点的序号，认领对应范围的分片。
3. 拉取过滤：每个节点从ES拉取事件时，只拉取哈希值属于自己分片范围的待处理事件，天然避免多节点拉取重复的问题。
4. 分片自动重平衡：监听ZK的节点变化事件，一旦有节点宕机或者新节点加入，所有存活节点自动重新计算分片对应关系，不会出现任务遗漏或者重复拉取。

方案3：混合方案（兼顾性能和稳定性） #

适合事件量较大、锁抢占冲突概率高的场景：

• 平时用ZK的分片规则做预分配，降低多节点拉取同批事件的冲突概率，提升拉取性能。
• 拉取时还是加一层ES乐观锁校验，解决分片切换瞬间的边界重复拉取问题，兜底保证任务唯一性。

内容的提问来源于stack exchange，提问作者Aman Kush