版本支持：v2.16.1+

zk、etcd、Nacos这三个后端和SQL、PostgreSQL、MongoDB、Redis的区别在于变更感知的方式：前三者靠长连接监听实时推送，能做到毫秒或亚秒级，不走seq轮询。周期对账两边都有，作为兜底。

Step 1：引入依赖

<dependency>
    <groupId>com.yomahub</groupId>
    <artifactId>liteflow-spring-boot-starter</artifactId>
    <version>2.16.1</version>
</dependency>
<dependency>
    <groupId>com.yomahub</groupId>
    <artifactId>liteflow-rule-db-zk</artifactId>
    <version>2.16.1</version>
</dependency>

Step 2：写配置

这里要定两件事：插件用哪个客户端连zk，以及规则记在哪个隔离名下。两者没有关联。

先说连接。项目里已经有CuratorFramework的话，复用它就行，重试策略和认证都沿用这个bean：

liteflow.rule-db.zk.curator-bean-name=curatorFramework

要注意zk后端只按bean名查找，不做按类型的自动查找，所以想复用就必须显式写上这一行。配了它之后，connect-string、session-timeout、username、password都不再生效，连接和认证完全由这个bean决定；bean不存在则启动报错。

不复用的话，配上连接串让插件自己建，其余用默认值即可：

liteflow.rule-db.zk.connect-string=127.0.0.1:2181
# 多个地址逗号分隔
# root-path默认/liteflow，session-timeout默认60000毫秒，通常不用改

生产环境请配上digest认证，username和password要成对配置。模块创建的znode会使用CREATOR_ALL_ACL，只有持有这个身份的连接才能写。

再说隔离名。liteflow.rule-db.application-name决定规则节点挂在哪，路径是{root-path}/{app}/...，不同取值互相看不到。它只管隔离，和用哪个客户端无关。

Spring Boot下它留空时会取spring.application.name：

spring.application.name=your-app

两个都没配会回落成default，多个应用共用一套zk时请确保取值不同。Solon插件没有这个回落，需要显式配liteflow.rule-db.application-name。这个值还要和Step 3里Publisher的applicationName(...)一致。

Step 3：发布第一条规则

规则的增删改都走Publisher API，不用手工建znode，也不用自己拼编码。四棵路径由Publisher初始化，meta和content节点在一个multi-op事务里原子写入。

import com.yomahub.liteflow.publisher.RulePublisher;
import com.yomahub.liteflow.publisher.RulePublisherFactory;
import com.yomahub.liteflow.publisher.PublishChainRequest;
import com.yomahub.liteflow.repository.zk.ZkPublisherConfig;

try (RulePublisher publisher = RulePublisherFactory.create(
        ZkPublisherConfig.builder()
                .connectString("127.0.0.1:2181")
                .rootPath("/liteflow")
                .applicationName("your-app")
                .build())) {

    publisher.publishChain(PublishChainRequest.builder()
            .chainId("orderChain")
            .el("THEN(a, b)")
            .build());
}

每次发布都在一个ZooKeeper事务（multi-op）里原子完成meta节点和content节点的写入，节点的version（也就是zxid）用作变更序号。zk连接断线重连之后，watch会自动补订阅，并触发一次全量对账。

部署顺序与最小权限

请先用Publisher账号至少创建一次Publisher，让它把{root}/{app}/chains/meta、chains/content、scripts/meta、scripts/content这四棵路径初始化出来，然后再启动执行节点。

执行侧的Provider不会创建任何znode，只校验必要路径然后读取和watch。所以执行账号只需要这四棵路径及其子节点的递归READ权限，Publisher账号才需要创建、更新和删除权限。路径不存在时执行节点会直接启动失败，并提示你先用Publisher做初始化。

单条规则受1MB znode限制

chain的EL或者脚本源码，只要content znode超过约1MB（也就是jute.maxbuffer），ZK服务端就会拒绝。模块在发布前会对编码后的内容做一次大小预检，阈值是960KB，超了就抛RuleValidationException，不会写进ZK。规则确实很大的话，请拆成多条chain或脚本，或者换用SQL、PostgreSQL、MongoDB后端。

Step 4：执行

和前面一样，照常调flowExecutor.execute2Resp(...)。