工作流引擎集群

数据库配置

有两种方法可以配置盘古引擎将使用的数据库。第一种选择是定义数据库的JDBC属性：

1、jdbcUrl：数据库的JDBC URL。

2、jdbcDriver：针对特定数据库类型的驱动程序的实现。

3、jdbcUsername：用于连接数据库的用户名。

4、jdbcPassword：连接数据库的密码。

请注意，引擎内部使用Apache MyBatis进行持久化。

基于提供的JDBC属性构造的数据源将具有默认的MyBatis连接池设置。可以选择以下属性来调整该连接池（取自MyBatis文档）：

1、jdbcMaxActiveConnections：连接池在任何给定时间可以包含的最大活动连接数。默认值是10。

2、jdbcMaxIdleConnections：连接池在任何给定时间可以包含的最大空闲连接数。

3、jdbcMaxCheckoutTime：可以强制从连接池中“检出”连接的时间（以毫秒为单位）。默认值为20000（20秒）。

4、jdbcMaxWaitTime：这是一个较低级别的设置，它使池有机会打印日志状态并在异常耗时的情况下重新尝试获取连接（以避免在池配置错误时永久性失败）。默认值为20000（20秒）。

5、jdbcStatementTimeout：JDBC驱动程序等待数据库响应的时间（以秒为单位）。默认值为null，表示没有超时。

Jdbc批处理

另一种配置- jdbcBatchProcessing设置在将SQL语句发送到数据库时是否必须使用批处理模式。关闭时，语句将一一执行。值：true（默认）， false。

批处理的已知问题：

1、批处理不适用于早于12的Oracle版本。

2、在MariaDB和DB2上使用批处理时，jdbcStatementTimeout将被忽略。

示例数据库配置

<property name="jdbcUrl" value="jdbc:h2:mem:盘古;DB_CLOSE_DELAY=1000" /><property name="jdbcDriver" value="org.h2.Driver" /><property name="jdbcUsername" value="sa" /><property name="jdbcPassword" value="" />

或者，javax.sql.DataSource可以使用一种实现方式（例如，来自Apache Commons的DBCP）：

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" >

  <property name="driverClassName" value="com.mysql.jdbc.Driver" />

  <property name="url" value="jdbc:mysql://localhost:3306/盘古" />

  <property name="username" value="盘古" />

  <property name="password" value="盘古" />

  <property name="defaultAutoCommit" value="false" /></bean><bean id="processEngineConfiguration" class="org.盘古.bpm.engine.impl.cfg.StandaloneProcessEngineConfiguration">

    <property name="dataSource" ref="dataSource" />

    ...

请注意，盘古并未随附允许定义此类数据源的库。因此，您必须确保这些库（例如，来自DBCP的库）在您的类路径中。

不管您使用的是JDBC还是数据源方法，都可以设置以下属性：

1、databaseType注意：通常不需要指定此属性，因为将从数据库连接元数据中自动分析该属性。仅在自动检测失败的情况下才应指定。可能的值：{h2，mysql，oracle，postgres，mssql，db2，mariadb}。此设置将确定将使用哪些创建/删除脚本和查询。有关支持哪些类型的概述，请参见“支持的数据库”部分。

2、databaseSchemaUpdate：允许设置策略以在流程引擎启动和关闭时处理数据库架构。

1)、true（默认）：在构建流程引擎时，将检查数据库中是否存在盘古表。如果它们不存在，则会创建它们。必须确保数据库模式的版本与流程引擎库的版本匹配，除非执行滚动更新。必须按照《更新和迁移指南》中的描述，手动完成数据库模式的更新。

2)、false：不执行任何检查，并假定数据库中存在盘古表。必须确保数据库模式的版本与流程引擎库的版本匹配，除非执行滚动更新。必须按照《更新和迁移指南》中的描述，手动完成数据库模式的更新。

3)、create-drop：在创建流程引擎时创建架构，并在关闭流程引擎时删除架构。

支持的数据库

有关支持的数据库的信息，请参阅支持的环境

以下是一些示例JDBC URL：

1、H2： jdbc:h2:tcp://localhost/盘古

2、MySQL： jdbc:mysql://localhost:3306/盘古?autoReconnect=true

3、甲骨文： jdbc:oracle:thin:@localhost:1521:xe

4、PostgreSQL： jdbc:postgresql://localhost:5432/盘古

5、DB2： jdbc:db2://localhost:50000/盘古

6.、MSSQL： jdbc:sqlserver://localhost:1433/盘古

7、MariaDB： jdbc:mariadb://localhost:3306/盘古

其他数据库架构配置

业务密钥

自盘古 BPM 7.0.0-alpha9发布以来，业务密钥的唯一约束已在运行时和历史记录表以及数据库架构创建和删除脚本中删除。如果依赖约束，则可以通过发出以下sql语句将其手动添加到架构中：

DB2

Runtime:

alter table ACT_RU_EXECUTION add UNI_BUSINESS_KEY varchar (255) not null generated always as (case when "BUSINESS_KEY_" is null then "ID_" else "BUSINESS_KEY_" end);

alter table ACT_RU_EXECUTION add UNI_PROC_DEF_ID varchar (64) not null generated always as (case when "PROC_DEF_ID_" is null then "ID_" else "PROC_DEF_ID_" end);

create unique index ACT_UNIQ_RU_BUS_KEY on ACT_RU_EXECUTION(UNI_PROC_DEF_ID, UNI_BUSINESS_KEY);

History:

alter table ACT_HI_PROCINST add UNI_BUSINESS_KEY varchar (255) not null generated always as (case when "BUSINESS_KEY_" is null then "ID_" else "BUSINESS_KEY_" end);

alter table ACT_HI_PROCINST add UNI_PROC_DEF_ID varchar (64) not null generated always as (case when "PROC_DEF_ID_" is null then "ID_" else "PROC_DEF_ID_" end);

create unique index ACT_UNIQ_HI_BUS_KEY on ACT_HI_PROCINST(UNI_PROC_DEF_ID, UNI_BUSINESS_KEY);

H2

Runtime:

alter table ACT_RU_EXECUTION add constraint ACT_UNIQ_RU_BUS_KEY unique(PROC_DEF_ID_, BUSINESS_KEY_);

History:

alter table ACT_HI_PROCINST add constraint ACT_UNIQ_HI_BUS_KEY unique(PROC_DEF_ID_, BUSINESS_KEY_);

微软SQL

Runtime:

create unique index ACT_UNIQ_RU_BUS_KEY on ACT_RU_EXECUTION (PROC_DEF_ID_, BUSINESS_KEY_) where BUSINESS_KEY_ is not null;

History:

create unique index ACT_UNIQ_HI_BUS_KEY on ACT_HI_PROCINST (PROC_DEF_ID_, BUSINESS_KEY_) where BUSINESS_KEY_ is not null;

MySQL

Runtime:

alter table ACT_RU_EXECUTION add constraint ACT_UNIQ_RU_BUS_KEY UNIQUE (PROC_DEF_ID_, BUSINESS_KEY_);

History:

alter table ACT_HI_PROCINST add constraint ACT_UNIQ_HI_BUS_KEY UNIQUE (PROC_DEF_ID_, BUSINESS_KEY_);

甲骨文

Runtime:

create unique index ACT_UNIQ_RU_BUS_KEY on ACT_RU_EXECUTION

         (case when BUSINESS_KEY_ is null then null else PROC_DEF_ID_ end,

         case when BUSINESS_KEY_ is null then null else BUSINESS_KEY_ end);

History:

create unique index ACT_UNIQ_HI_BUS_KEY on ACT_HI_PROCINST

         (case when BUSINESS_KEY_ is null then null else PROC_DEF_ID_ end,

         case when BUSINESS_KEY_ is null then null else BUSINESS_KEY_ end);

PostgreSQL的

Runtime:

alter table ACT_RU_EXECUTION add constraint ACT_UNIQ_RU_BUS_KEY UNIQUE (PROC_DEF_ID_, BUSINESS_KEY_);

History:

alter table ACT_HI_PROCINST add constraint ACT_UNIQ_HI_BUS_KEY UNIQUE (PROC_DEF_ID_, BUSINESS_KEY_);

隔离级别配置

大多数数据库管理系统提供四个不同的隔离级别来设置。例如，ANSI / USO SQL定义的级别是（从低隔离到高隔离）：

1、读未提交

2、读已提交

3、可重复读取

4、可序列化

运行盘古所需的隔离级别为READ COMMITTED，根据您的数据库系统，隔离级别的名称可能不同。已知将级别设置为“ REPEATABLE READS”会导致死锁，因此在更改隔离级别时需要小心。

Microsoft SQL Server的配置

Microsoft SQL Server实现的隔离级别READ_COMMITTED不同于大多数数据库，并且与流程引擎的乐观锁定方案无法很好地交互 。因此，在将流程引擎置于高负载下时，您可能会遇到死锁。

如果在MSSQL安装中遇到死锁，则必须执行以下语句才能启用SNAPSHOT隔离：

ALTER DATABASE [process-engine]

SET ALLOW_SNAPSHOT_ISOLATION ON

ALTER DATABASE [process-engine]

SET READ_COMMITTED_SNAPSHOT ON

其中[process-engine]包含您的数据库的名称。

MariaDB Galera群集的配置

本节介绍了受支持的MariaDB Galera Cluster配置。服务器和客户端都需要正确配置。请注意，使用Galera群集时存在一些已知限制，请参见下文。

警告

请注意，下面定义的服务器和客户端配置设置是Galera Cluster支持的唯一配置。不支持其他配置。

服务器配置

以下配置需要进入每台服务器上的“ [galera]配置”部分my.cnf.d/server.cnf：

[galera]

binlog_format=row

default_storage_engine=InnoDB

innodb_autoinc_lock_mode=2

transaction-isolation=READ-COMMITTED

wsrep_on=ON

wsrep_causal_reads = 1

wsrep_sync_wait = 7

...

注意，其它设置可存在于本节中而设置transaction-isolation，wsrep_on，wsrep_causal_reads并wsrep_sync_wait需要存在并需要具有恰好上面所示的值。

客户端配置

仅failover和sequential支持配置。像其他的客户端配置模式replication:，loadbalance:，aurora:不被支持。

以下是数据源配置中jdbcUrl属性的必需格式：

jdbc:mariadb:[failover|sequential]://[host1:port],[host2:port],.../[data-base-name]

例子：

jdbc:mariadb:failover://192.168.1.1:32980,192.168.1.2:32980,192.168.1.3:32980/process-engine

jdbc:mariadb:sequential://192.168.1.1:32980,192.168.1.2:32980,192.168.1.3:32980/process-engine

重要：在群集中运行盘古时，每个节点上的客户端配置都必须相同。

Galera群集的已知局限性

使用Galera Cluster时，存在以下已知限制：

1、需要数据库中的悲观读取锁定的API无法正常工作。受影响的API：互斥消息相关性（.correlateExclusively()）。请参阅（Javadocs ）。另一个可能的负面影响：

1）同时从两个线程部署相同资源时，已部署定义的重复

2）HistoryService#cleanUpHistoryAsync同时从两个线程调用时，历史记录清理作业重复

2、如果在群集中同时部署资源，则部署期间的重复检查将不起作用。具体影响：假设有一个盘古流程引擎集群，该集群连接到同一Galera集群。在部署新流程应用程序时，流程引擎节点将检查该流程应用程序提供的BPMN流程是否已经部署，以避免重复部署。如果在多个流程引擎节点上同时完成部署，则将在数据库上获得排他读取锁定（从技术上讲，这意味着每个节点都将执行SQL select for update查询。），以便在并发下可靠地进行重复检查。这在Galera Cluster上不起作用，并且可能导致部署同一进程的多个版本。

3、该jdbcStatementTimeout配置设置不起作用，不能使用。

 技术支持：盘古BPM工作流平台