版本支持：v2.16.1+

liteflow-rule-db-sql这个版本支持MySQL和MariaDB。PostgreSQL请用独立的liteflow-rule-db-postgresql，Oracle、SQL Server这些暂时不在支持范围内。

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-sql</artifactId>
    <version>2.16.1</version>
</dependency>
<!-- 数据库驱动用户自带，例如 MySQL -->
<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
</dependency>

提示

Spring Boot 4的项目请把starter换成liteflow-spring-boot4-starter，Solon项目用liteflow-solon-plugin。

两个Spring Boot starter都内置了liteflow.rule-db.*的配置绑定和IDE自动补全元数据。Solon插件支持配置绑定，但不带Spring风格的IDE元数据文件。

发布脚本时别忘了脚本插件

Rule-DB的后端模块和starter都不会自动引入脚本语言实现。比如你要用language("groovy")，就得额外引入com.yomahub:liteflow-script-groovy:2.16.1。只发布普通chain的话用不到脚本插件。

Step 2：写配置

这里要定的是两件事：插件用哪个 DataSource 连库，以及规则记在哪个隔离名下。两者没有关联，下面分开说。

先说连接。如果你的容器里只有一个 DataSource，那么一行都不用配，插件会按类型把它取出来直接用，连接池、鉴权、超时都沿用这个 bean 上的配置。Rule-DB 是否启用也和配置无关，取决于 classpath 上有没有后端模块。

如果是多数据源的项目，请指明用哪一个：

liteflow.rule-db.sql.datasource-bean-name=liteflowRuleDataSource

不指明的情况下，有 @Primary 就会用主数据源，这往往不是你想存规则的那个库；没有 @Primary 则按类型取不到，启动会报错。

规则想放到独立的数据库，就自己声明一个指向规则库的 DataSource，再用 datasource-bean-name 指过去，这样库隔离了，连接池也还在：

@Bean
public DataSource liteflowRuleDataSource() {
    HikariConfig cfg = new HikariConfig();
    cfg.setJdbcUrl("jdbc:mysql://host:3306/liteflow_rules");
    cfg.setUsername("root");
    cfg.setPassword("your-password");
    return new HikariDataSource(cfg);
}

liteflow.rule-db.sql.datasource-bean-name=liteflowRuleDataSource

不要用liteflow.rule-db.sql.url

配了url，框架就走DriverManager裸连接，每次回源都新建连接，完全没有池化，只适合临时验证。生产环境请始终复用连接池。

另外这两者是互斥的，只要url非空，插件就不会再去容器里找DataSource。

再说隔离名。liteflow.rule-db.application-name 决定规则存在哪个命名空间下，它会写进四张表的 application_name 列，同一套库里不同取值的规则互相看不到。这个配置只管隔离，和上面用哪个 DataSource 没有关系。

Spring Boot 下它留空时会取 spring.application.name，所以一般不用为 Rule-DB 再配一遍：

spring.application.name=order-service

两个都没配会回落成 default。单个应用独占一套库倒也无妨，但多个应用共用一套库时，请确保各应用的取值不同，否则会互相读写对方的规则。Solon 插件没有这个回落，需要显式配 liteflow.rule-db.application-name。

这个值还要和 Step 4 里 Publisher 的 applicationName(...) 保持一致，不一致的话规则发布进去了，执行端也读不到。

所以对单数据源的 Spring Boot 应用来说，Rule-DB 要的配置就是下面这一行，而这一行你本来就有：

spring.application.name=order-service

Step 3：建表

开发环境不用自己动手，加一个开关让插件去建：

liteflow.rule-db.sql.auto-init-table=true

启动时会执行CREATE TABLE IF NOT EXISTS把四张表建齐，表名前缀默认lf_，可以用table-prefix改。表结构是模块内置的，你不需要去翻DDL，也不需要像旧SQL插件那样把每个表名和字段名映射到配置项里。

生产环境建议反过来做，自己把四张表建好，DDL见存储结构参考，把它纳入你自己的DDL变更流程，这样执行账号可以保持只读，符合最小权限。缺表的话启动会报错，日志里会附上完整DDL，直接复制就能用。

开了自动建表就不是只读账号了

auto-init-table=true意味着执行账号必须有DDL权限。如果生产上要求最小权限，请先让DBA建表，再把这个开关关掉。

Step 4：发布第一条规则

规则的增删改都走Publisher API，不用手写SQL。版本号自增、md5重算、写变更日志、拿发布顺序锁，这几件事框架会在一个事务里做完。旧插件那种往chain表INSERT一行、再自己想办法让各个节点刷新的做法，这里不需要了。

applicationName就是Step 2里说的隔离名，必须和执行应用最终解析出来的liteflow.rule-db.application-name一致。

Publisher这边同样用dataSource(...)把连接池传进去，不要用url：

import com.yomahub.liteflow.publisher.PublishChainRequest;
import com.yomahub.liteflow.publisher.PublishResult;
import com.yomahub.liteflow.publisher.RulePublisher;
import com.yomahub.liteflow.publisher.RulePublisherFactory;
import com.yomahub.liteflow.repository.sql.SqlPublisherConfig;

try (RulePublisher publisher = RulePublisherFactory.create(
        SqlPublisherConfig.builder()
                .applicationName("order-service")
                .dataSource(ruleDataSource)   // 管理后台自己的连接池
                .build())) {
    PublishResult result = publisher.publishChain(PublishChainRequest.builder()
            .chainId("orderChain")
            .el("THEN(a, b)")
            .expectedVersion(0L) // 仅当规则不存在时创建；重复执行会明确报版本冲突
            .build());
    System.out.println("发布成功，当前版本: " + result.getVersion());
}

传进去的DataSource归调用方所有，Publisher的close()不会去关它。

一次性脚本可以例外

临时的初始化脚本、CI里的一次性导入，用.url(...).username(...).password(...)更省事，反正进程跑完就退了。常驻的管理后台还是请用dataSource(...)。

EL里的a和b就是应用内注册的普通Java组件：

@LiteflowComponent("a")
public class ACmp extends NodeComponent {
    @Override
    public void process() {
        System.out.println("a");
    }
}

@LiteflowComponent("b")
public class BCmp extends NodeComponent {
    @Override
    public void process() {
        System.out.println("b");
    }
}

每次调publish*，Publisher都在一个事务里做三件事：先拿到lf_change_lock这把发布顺序锁，然后UPSERT内容行（version = version + 1，同时重算md5），最后INSERT一条变更日志。锁会一直持有到提交或者回滚，这样变更序号的分配顺序就和事务提交顺序一致了。

Step 5：执行

应用这边照常执行，API没有任何变化：

@Resource
private FlowExecutor flowExecutor;

public void run() {
    LiteflowResponse resp = flowExecutor.execute2Resp("orderChain", null);
    // 首次执行会回源拉取EL并编译，二次执行命中缓存，没有远程调用
}

启动时只读清单来建索引，不读内容。普通chain的EL和脚本内容，是第一次执行到它的时候才回源拉取并编译的。之后命中缓存，执行热路径上就没有远程调用了。

路由模式的冷启动

executeRouteChain为了拿到route元数据，会在路由执行前把所有还没就绪的Rule-DB chain逐个回源并编译，而不是只加载最终匹配的那一条。所以清单很大又用路由模式的话，请把第一次路由请求当成一次批量冷加载来看待。详见内存与性能。