分布式状态机处理并行区域时ZooKeeper集群报BadVersion错误

我来帮你分析下这个KeeperErrorCode = BadVersion问题，这在Spring State Machine结合ZooKeeper做分布式部署的场景里挺常见的，咱们一步步拆解问题根源和解决方案：

问题根源分析 #

首先，ZooKeeper的BadVersion错误本质是乐观锁冲突：当多个客户端（这里就是你的多台状态机实例）尝试更新同一个ZNode时，如果当前客户端持有的ZNode版本号和ZooKeeper集群上的实际版本号不匹配，就会抛出这个错误。

结合你的场景来看：

• 单实例时，JVM内部的synchronized锁能保证同一批次ID的状态机只有一个实例，多线程更新状态时不会有跨节点的冲突；
• 多实例部署后，你自定义的acquireDistributedStateMachine方法里的synchronized (distributedMachines)锁只在当前实例生效，完全无法阻止其他节点同时创建同一machineId的状态机实例——多个节点同时往ZooKeeper写状态数据，自然就触发了版本冲突。

另外，咱们再看你的代码细节：

1. 自定义的状态机获取逻辑丢失了DefaultStateMachineService内置的分布式锁机制，原方法是通过ZooKeeper临时节点来保证同一machineId在集群中只有一个活跃实例；
2. 并行区域的状态更新在多实例下，没有通过分布式同步机制来保证原子性，多个节点同时更新同一批次的不同区域状态，也会触发ZNode版本冲突。

具体解决方案 #

1. 修复状态机获取逻辑，添加分布式锁 #

不要自己实现无分布式锁的状态机获取逻辑，要么直接复用DefaultStateMachineService，要么基于Curator添加分布式锁：

@Override
public StateMachine<String, String> acquireDistributedStateMachine(String machineId, boolean start) {
    // 用Curator的InterProcessMutex实现分布式锁，保证同一machineId只有一个节点能创建实例
    try (InterProcessMutex lock = new InterProcessMutex(curatorClient(), "/locks/batch-machine-" + machineId)) {
        lock.acquire(); // 阻塞直到获取锁
        synchronized (distributedMachines) {
            DistributedStateMachine<String,String> distributedStateMachine = distributedMachines.get(machineId);
            if (distributedStateMachine == null) {
                StateMachine<String, String> machine = stateMachineFactory.getStateMachine(machineId);
                distributedStateMachine = (DistributedStateMachine<String, String>) machine;
                distributedMachines.put(machineId, distributedStateMachine);
            }
            return handleStart(distributedStateMachine, start);
        }
    } catch (Exception e) {
        throw new RuntimeException("Failed to acquire distributed lock for machineId: " + machineId, e);
    }
}

2. 确保ZooKeeper分布式配置的正确性 #

• 检查ZookeeperStateMachineEnsemble的根路径"/batchfoo1"，确保所有实例都使用同一个根节点；
• 生产环境不要用localhost:2181，要配置完整的ZooKeeper集群地址；
• 确保curatorClient是单实例，不要每次创建状态机都新建客户端（你的代码里是@Bean注入的，这点没问题）。

3. 并行区域状态更新的同步优化 #

因为你的状态机包含多个并行区域（对应Spring Batch的chunk），要确保：

• 同一批次的所有并行区域事件都发送到同一个状态机实例；
• 开启Spring State Machine的DEBUG日志，查看org.springframework.statemachine.distributed包下的日志，定位具体是哪个ZNode引发的版本冲突，针对性调整同步逻辑。

4. 添加冲突重试机制 #

对于短暂的并发冲突，可以用Spring Retry包裹状态机事件触发逻辑，捕获BadVersion相关异常时自动重试：

@Retryable(value = {KeeperException.BadVersionException.class}, maxAttempts = 3, backoff = @Backoff(delay = 100))
public void triggerStateMachineEvent(String machineId, String event) {
    StateMachine<String, String> machine = acquireDistributedStateMachine(machineId, true);
    machine.sendEvent(event);
}

总结 #

核心问题就是自定义状态机获取逻辑缺失分布式锁，导致多实例同时创建同一批次的状态机，引发ZooKeeper版本冲突。先修复分布式锁这块，再配合配置检查和重试机制，应该就能解决问题啦。

内容的提问来源于stack exchange，提问作者Seek Ecom