版本支持：v2.16.1+

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-redis</artifactId>
    <version>2.16.1</version>
</dependency>

liteflow-rule-db-redis用的是Redisson，和旧版liteflow-rule-redis的选型一致，运维上不用重新适应。

Step 2：写配置

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

先说连接。应用里已经有Redisson了的话，一行都不用配，插件按类型把容器里的RedissonClient取出来直接用，鉴权、连接池、序列化都沿用这个bean上的配置。有多个RedissonClient时，用redisson-bean-name指明用哪个。

容器里确实没有Redisson，那就配地址让插件自己建：

liteflow.rule-db.redis.address=redis://127.0.0.1:6379
# 多地址逗号分隔；哨兵模式再加master-name；集群只填多地址、不配master-name

顺序上bean优先于address，找到了bean就不会再看address；两个都没有则启动报错。

再说隔离名。liteflow.rule-db.application-name决定规则键落在哪，默认是lf:{app}:...这组键，前缀可以用key-prefix改，不同取值互相看不到。它只管隔离，和用哪个客户端无关。

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

spring.application.name=your-app

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

Redis模式不需要任何初始化，键结构在首次发布时自动创建，具体见存储结构参考。

Redis Cluster必须配key-hash-tag

发布用的Lua脚本会触碰4个键，多键EVAL要求它们落在同一个slot里。所以在cluster模式下（也就是多地址且没配master-name），key-hash-tag是必填的，不配会在建连时直接抛ConfigErrorException。单机和哨兵模式没这个约束，可以不配。

Step 3：发布第一条规则

规则的增删改都走Publisher API，不用手写Redis命令。写内容、写索引、推seq、写changelog这四步由一段Lua原子完成。

import com.yomahub.liteflow.publisher.RulePublisher;
import com.yomahub.liteflow.publisher.RulePublisherFactory;
import com.yomahub.liteflow.publisher.PublishChainRequest;
import com.yomahub.liteflow.publisher.PublishScriptRequest;
import com.yomahub.liteflow.publisher.RemoveRuleRequest;
import com.yomahub.liteflow.repository.redis.RedisPublisherConfig;

try (RulePublisher publisher = RulePublisherFactory.create(
        RedisPublisherConfig.builder()
                .address("redis://127.0.0.1:6379")
                .applicationName("your-app")   // 多应用共库时务必各应用不同
                .build())) {

    // 发布 chain。route / namespace 可选
    long version = publisher.publishChain(PublishChainRequest.builder()
            .chainId("orderChain")
            .el("THEN(a, b)")
            .build()).getVersion();

    // 带 route（路由EL）和 namespace 的发布
    publisher.publishChain(PublishChainRequest.builder()
            .chainId("orderChain")
            .el("THEN(a, b)")
            .route("AND(a)")
            .namespace("ns1")
            .build());

    // 发布脚本；执行节点还需引入对应语言的脚本插件
    publisher.publishScript(PublishScriptRequest.builder()
            .nodeId("s1")
            .type("script")
            .language("groovy")
            .script("def a = 1; return a")
            .build());

    // 删除
    publisher.removeChain(RemoveRuleRequest.builder().targetId("orderChain").build());
    publisher.removeScript(RemoveRuleRequest.builder().targetId("s1").build());
}

这个API可以独立使用，管理后台只依赖这一个jar就能调，不需要拉起FlowExecutor，也不依赖全局的LiteflowConfig。

每次发布都是一段Lua脚本在跑：HSET内容、SADD索引、INCR seq、ZADD changelog，这四步在Redis单线程里原子完成，中间状态不会被其他客户端看到。

Redis模式没有用pub/sub推送

Redis的变更感知和SQL一样，靠seq轮询（默认3秒）加周期对账（默认60秒）两条腿。有些同类设计会用Redis的PUBLISH/SUBSCRIBE做毫秒级推送，这里没有采用。如果你想让Redis收敛得更快，可以把poll-seconds调小，代价是GET seq会更频繁。

Step 4：执行

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