分布式事务：seata

目录

一、事务简介

二、本地事务

三、常见的分布式事务解决方案

分布式事务理论基础

两阶段提交协议

 两阶段提交协议的问题

AT模式（Auto Transaction）

TCC模式 

四、Seata

Seata是什么

Seata的三大角色

设计思路

设计亮点 

存在的问题

  性能损耗

  性价比

  全局锁

 Seata快速开始

  Seata Server（TC）环境搭建

db存储模式+Nacos高可用集群部署

 Seata Client环境搭建

五、参数配置

全属性

公共部分

server端

client端

---

一、事务简介

事务（Transaction）是访问并可能更新数据库中各种数据项的一个程序执行单元。在关系型数据库中，一个事务由一组sql语句组成。事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常被称为ACID特性。

原子性（atomicity）：一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。

一致性（consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态，事务的中间状态不能被观察到的。

隔离性（isolation）：一个事务的执行不能被其它事务所干扰。即一个事务内部的操作及使用的数据对并发的其它事务是隔离的，并发执行的各个事务之间不能互相干扰。隔离性又分为四个级别：读未提交（read uncommitted）、读已提交（read committed，解决脏读）、可重复读（repeatable read，解决虚读）、串行化（serializable，解决幻读）。

持久性（durability）：持久性也称为永久性，指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其有任何影响。

任何事务机制在实现时，都应该考虑事务的ACID特性，包括：本地事务，分布式事务，即使不能都很好的满足，也要考虑支持到什么程度。

---

二、本地事务

@Transaction

大多数场景下，我们的应用都只需要操作单一的数据库，这种情况下的事务被称之为本地事务（Local Transaction）。本地事务的ACID特性是数据库直接提供支持。本地事务应用架构如下所示：

 在JDBC编程中，我们通过java.sql.Connection对象来开启、关闭或者提交事务。代码如下所示：

Connection conn = ......; //获取数据库连接
conn.setAutoCommit(false); //开启事务
try{
    //执行增删改查sql
    conn.commit(); //提交事务
}catch(Exception e){
 conn.rollback(); //事务回滚  
}finally{
 conn.close(); //关闭连接
}

---

三、常见的分布式事务解决方案

1、seata阿里分布式事务框架

2、消息队列

3、saga

4、XA

他们都有一个共同点，都是"两阶段（2PC）"。两阶段是指完成整个分布式事务，划分成两个步骤完成。

实际上这四种常见的分布式事务解决方案，分别对应着分布式事务的四种模式：AT、TCC、Saga、XA；

四种分布式事务模式，都有各自的理论基础，分别在不同的时间被提出；每种模式都有他的适用场景，同样每个模式也都诞生有各自的代表产品，而这些代表产品，可能就是我们常见的（全局事务、基于可靠消息、最大努力通知、TCC）。

在看具体实现之前，先说下分布式事务的理论基础。

分布式事务理论基础

解决分布式事务，也有相应的规范和协议。分布式事务相关的协议有2PC、3PC。

由于三阶段提交协议3PC非常难实现，目前市面主流的分布式事务解决方案都是2PC协议。

有些文章分析2PC时，几乎都会用TCC两阶段的例子，第一阶段try，第二阶段完成confirm或cancel。其实2PC并不是专为实现TCC设计的，2PC具有普适性，目前绝大多数分布式事务解决方案都是以两阶段提交协议2PC为基础的。

TCC（Try-Confirm-Cancel）实际上是服务化的两阶段提交协议。

两阶段提交协议

顾名思义，分为两个阶段：Prepare和Commit。

Prepare：提交事务请求

基本流程如下图：

1.  询问：协调者向所有参与者发送事务请求，询问是否可执行事务操作，然后等待各个参与者的响应。
2. 执行：各个参与者接收到协调者事务请求后，执行事务操作（例如更新一个关系型数据库表中的记录）并将Undo和Redo信息记录事务日志中。
3. 响应：如果参与者成功执行了事务并写入Undo和Redo信息，则向协调者返回YES响应，否则返回NO响应。当然，参与者也可能宕机，从而不会返回响应。  

  Commit：执行事务提交

  执行事务提交分别两种情况，正常提交和回滚。

  正常提交事务

  流程如下图 ：

   

1.  commit请求：协调者向所有参与者发送Commit请求。
2. 事务提交：参与者收到Commit请求后，执行事务提交，提交完成后释放事务执行期占用的所有资源。
3. 反馈结果：参与者执行事务提交后向协调者发送Ack响应。
4. 完成事务：接收到所有参与者的Ack响应后，完成事务提交。

回滚事务

在执行Prepare步骤过程中，如果某些参与者执行事务失败、宕机或协调者之间的网络中断，那么协调者就无法收到参与者的YES响应，或者某个参与者返回了NO响应，此时，协调者就会进入回滚流程，对事务进行回滚。

 流程如下图：

1.  rollback请求：协调者向所有参与者发送Rallback请求。
2. 事务回滚：参与者收到Rallback请求后，使用Prepare阶段的Undo日志执行事务回滚，完成后释放事务执行期占用的所有资源。
3. 反馈结果：参与者执行事务回滚后向协调者发送Ack响应。
4. 回滚事务：接收到所有参与者的Ack响应后，完成事务回滚。

 两阶段提交协议的问题

1. 同步阻塞：参与者在等待协调者的指令时，其实是在等待其它参与者响应，在此过程中，参与者是无法进行其它操作的，也就是阻塞了其运行。倘若参与者与协调者之间网络异常导致参与者一直收不到协调者信息，那么会导致参与者一直阻塞下去。
2. 单点：在2PC中，一切请求都来自协调者，所以协调者的地位是至关重要的，如果协调者宕机，那么就会使参与者一直阻塞并一直占用资源。如果协调者也是分布式，使用选主方式提供服务，那么在一个协调者挂掉后，可以选取另一个协调者继续后续的服务，可以解决单点问题。但是，新协调者无法知道上一个事务的全部状态信息（例如已等待Prepare响应的时长等），所以也无法顺利处理上一个事务。
3. 数据不一致：Commit事务过程中，Commit/Rallback请求可能因为协调者宕机或协调者与参与者网络问题丢失，那么就导致了部分参与者没有收到Commit/Rallback请求，而其他参与者则正常收到执行了Commit/Rallback操作，没有收到请求的参与者继续阻塞。这时参与者之间的数据就不再一致了。
4. 环境可靠性依赖：协调者Prepare请求发出后，等待响应，然而如果有参与者宕机或与协调者之间的网络中断，都会导致协调者无法收到所有参与者的响应，那么在2PC中，协调者会等待一定时间，然后超时后，会触发事务回滚。在这个过程中，协调者和所有参与者都是出于阻塞的。这种机制对网络问题常见的现实环境来说太苛刻了。

下面我们分别来看4种模式的分布式事务实现。

AT模式（Auto Transaction）

AT模式是一种无侵入的分布式事务解决方案。

阿里seata框架，实现了该模式。

在AT模式下，用户只需关注自己的业务sql，用户的业务sql作为一阶段，Seata框架会自动生成事务的二阶段提交和回滚操作。

 AT模式如何做到对业务的无侵入：

• 一阶段：在一阶段，Seata会拦截业务sql，首先解析sql语义，找到业务sql要更新的业务数据，在业务数据被更新之前，将其保存成before image，然后执行业务sql更新业务数据，在业务数据更新之后，再将其保存成after image，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。
• 二阶段提交：二阶段如果是提交的话，因为业务sql在一阶段已经提交至数据库，所以Seata框架只需将一阶段保存的快照数据和行锁删除，完成数据清理即可。
• 二阶段回滚：二阶段如果是回滚的话，Seata就需要回滚一阶段已执行的业务sql，还原业务数据。回滚方式便是用before image 还原业务数据，但在还原前要首先校验脏写，对比数据库当前业务数据和after image，如果两份数据完全一致就说明没有脏写，可以还原业务数据。如果不一致，就说明有脏写，出现脏写就需要转人工处理。

AT模式的一阶段，二阶段提交和回滚都是由Seata框架自动生成，用户只需编写业务sql，便能轻松接入分布式事务，AT模式是一种对业务无任何侵入的分布式事务解决方案。 

TCC模式 

TCC模式需要用户根据自己的业务场景实现Try、Confirm和Cancel三个操作。事务发起方在一阶段执行Try方法，在二阶段提交执行Confirm方法，二阶段回滚执行Cancel方法。

优点：在整个过程中基本没有锁，性能更强。

缺点： 侵入性比较强，并且需要用户自己实现相关事务控制逻辑。

---

四、Seata

Seata是什么

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。AT模式是阿里首推的模式，阿里云上有商用版本的GTS（Global Transaction Service 全局事务服务）。

官网：https://seata.io/zh-cn/

源码：http://github.com/seata/seata

官方Demo: GitHub - seata/seata-samples: seata-samples

Seata的三大角色

在Seata的架构中，一共有三大角色：

TC（Transaction Coordinator）- 事务协调者

维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM（Transaction Manager）- 事务管理器

定义全局事务的范围：开始全局事务、提交或回滚全局事务

RM（Resource Manager）- 资源管理器

管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

其中，TC为单独部署的Server服务端，TM和RM为嵌入到应用中的Client客户端。

 在Seata中，一个分布式事务的生命周期如下：

1.  TM请求TC开启一个全局事务。TC会生成一个XID作为该全局事务的编号。XID会在微服务的调用链路中传播，保证将多个微服务的子事务关联在一起。
2. RM请求TC将本地事务注册为全局事务的分支事务，通过全局事务的XID进行关联。
3. TM请求TC告诉XID对应的全局事务是进行提交还是回滚。
4. TC驱动RM们将XID对应的自己的本地事务进行提交还是回滚。

设计思路

AT模式的核心是对业务无侵入，是一种改进后的两阶段提交，其设计思路如图：

第一阶段

业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。核心在于对业务sql

进行解析，转换成undolog，并同时入库，这是怎么做的呢？先抛出一个概念DataSourceProxy代理数据源，通过名字大家大概也能基本猜到是什么个操作，后面做具体分析。

参考官方文档：https://seata.io/zh-cn/docs/dev/mode/at-mode.html

第二阶段

分布式事务操作成功，则TC通知RM异步删除undolog 

分布式事务操作失败，TM向TC发送回滚请求，RM 收到协调器TC发来的回滚请求，通过XID和Branch ID 找到相应的回滚日志记录，通过回滚记录生成反向的更新sql 并执行，以完成分支的回滚。

设计亮点 

相比其他分布式事务框架，Seata架构的亮点主要有几个：

1. 应用层基于sql解析实现了自动补偿，从而最大程度的降低业务侵入性。
2. 将分布式事务中TC（事务协调者）独立部署，负责事务的注册、回滚。
3. 通过全局锁实现了写隔离和读隔离。

存在的问题

  性能损耗

   一条update的sql，则需要全局事务xid获取（与TC通讯）、before image（解析sql，查询一次数据库）、after image（查询一次数据库）、insert undo log（写一次数据库）、before commit（与TC通讯，判断锁冲突），这些操作都需要运行一次远程通讯RPC,而且是同步的。另外undo log写入时blob字段的插入性能也是不高的。每条写sql都会增加这么多开销，粗略估计会增加5倍响应时间。

  性价比

   为了进行自动补偿，需要对所有交易生成前后镜像并持久化，可是在实际业务场景下，这个成功率是有多高，或者说分布式事务失败需要回滚的有多少比例？按照二八原则预估，为了20%的交易回滚，需要将80%的成功交易的响应时间增加5倍，这样的代价相比于让应用开发一个补偿交易是否是值得？

  全局锁

  热点数据

   相比XA，Seata虽然在一阶段成功后会释放数据库锁，但一阶段在commit前全局锁的判定也拉长了对数据锁的占有时间。全局锁的引入实现了隔离性，但带来的问题就是阻塞，降低并发性，尤其是热点数据，这个问题会更加严重。

  回滚锁释放时间 

      Seata在回滚时，需要先删除各节点的undo log，然后才能释放TC内存中的锁，所以如果第二阶段是回滚，释放锁的时间会更长。  

  死锁问题

      Seata的引入全局锁会额外增加死锁的风险，但如果出现死锁，会不断进行重试，最后靠等待全局锁超时，这种方式并不优雅，也延长了对数据库锁的占有时间。

 Seata快速开始

  Seata Server（TC）环境搭建

  Seata部署指南

 Server端存储模式（store.mode）支持三种

• file:单机模式，全局事务会话信息内存中读写并持久化本地文件root.data,性能较高（默认）
• db:高可用模式，全局事务会话信息通过db共享，相应性能差些
• redis：Seata-Server1.3及以上版本支持，性能较高。存在事务信息丢失风险，请提前配置适合当前场景的redis持久化配置

db存储模式+Nacos高可用集群部署

步骤一：下载安装包

下载地址-1.3.0

 注：选择与SpringCloudAlibaba相对应的Seata版本

步骤二：建表(仅db)

创建数据库seata-server

打开官网，找到资源目录，点击查看 

 选择对应数据库脚本，这里使用mysql

CREATE TABLE IF NOT EXISTS `global_table`
(
    `xid`                       VARCHAR(128) NOT NULL,
    `transaction_id`            BIGINT,
    `status`                    TINYINT      NOT NULL,
    `application_id`            VARCHAR(32),
    `transaction_service_group` VARCHAR(32),
    `transaction_name`          VARCHAR(128),
    `timeout`                   INT,
    `begin_time`                BIGINT,
    `application_data`          VARCHAR(2000),
    `gmt_create`                DATETIME,
    `gmt_modified`              DATETIME,
    PRIMARY KEY (`xid`),
    KEY `idx_gmt_modified_status` (`gmt_modified`, `status`),
    KEY `idx_transaction_id` (`transaction_id`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8;

-- the table to store BranchSession data
CREATE TABLE IF NOT EXISTS `branch_table`
(
    `branch_id`         BIGINT       NOT NULL,
    `xid`               VARCHAR(128) NOT NULL,
    `transaction_id`    BIGINT,
    `resource_group_id` VARCHAR(32),
    `resource_id`       VARCHAR(256),
    `branch_type`       VARCHAR(8),
    `status`            TINYINT,
    `client_id`         VARCHAR(64),
    `application_data`  VARCHAR(2000),
    `gmt_create`        DATETIME(6),
    `gmt_modified`      DATETIME(6),
    PRIMARY KEY (`branch_id`),
    KEY `idx_xid` (`xid`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8;

-- the table to store lock data
CREATE TABLE IF NOT EXISTS `lock_table`
(
    `row_key`        VARCHAR(128) NOT NULL,
    `xid`            VARCHAR(96),
    `transaction_id` BIGINT,
    `branch_id`      BIGINT       NOT NULL,
    `resource_id`    VARCHAR(256),
    `table_name`     VARCHAR(32),
    `pk`             VARCHAR(36),
    `gmt_create`     DATETIME,
    `gmt_modified`   DATETIME,
    PRIMARY KEY (`row_key`),
    KEY `idx_branch_id` (`branch_id`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8;

  

全局事务会话信息由3块内容构成，全局事务-->分支事务-->全局锁，对应表global_table、branch_table、lock_table。

步骤三：修改store.mode

 步骤四：修改数据库连接

 步骤五：修改Server端配置注册中心

 步骤六：修改Server端配置中心

 同样在registry.conf文件中修改注册中心为nacos

步骤七：下载seata服务端源码

 解压

 找到script文件夹

 进入config-center文件夹

步骤八： 修改config.txt文件

发现默认的数据源时file

修改默认数据源为db，并修改db信息

步骤九： 配置事务分组

配置事务分组，要与客户端配置的事务分组一致。

对应的客户端配置

#事务分组配置
seata.tx-service-group=my_test_tx_group
#指定事务分组至集群映射关系（等号右侧的集群名需要与Seata-server注册到Nacos的cluster保持一致）
seata.service.vgroup-mapping.my_test_tx_group=default

my_test_tx_group可以自定义，如：service.vgroupMapping.Shanghai=default

对应的客户端配置

#事务分组配置
seata.tx-service-group=Shanghai
#指定事务分组至集群映射关系（等号右侧的集群名需要与Seata-server注册到Nacos的cluster保持一致）
seata.service.vgroup-mapping.Shanghai=default

配置事务分组主要是解决：异地机房停电容错机制。

官方详细介绍：Seata-事务分组

步骤十： 将config.txt文件中的配置导入到Nacos配置中心

打开nacos文件夹

 

启动Nacos配置中心

 nacos启动成功后，双击nacos-config.sh

打开我们的nacos控制台，发现配置列表中导入成功。

 这里我们思考一个问题，如果nacos的地址不是127.0.0.1:8848，是否会导入成功呢？很显然是不能，因为seata里边有一些默认的配置，默认的配置就是127.0.0.1:8848。如果我们想修改默认的配置，解决方案如下：

shell：

sh ${SEATAPATH}/script/config-center/nacos/nacos-config.sh -h localhost -p 8848 -g SEATA_GROUP -t 029072a9-5a32-4756-94f8-705956db764c

 参数说明

-h: host，默认值localhost

-p: port，默认值8848

-g:  配置分组，默认值为"SEATA_GROUP"

-t: 租户信息，对应Nacos的命名空间ID，默认值为空

步骤十一：启动SeataServer

命令启动： seata-server.sh -h 127.0.0.1 -p 8091 -m db -n 1 -e test

支持的启动参数

参数	全名	作用	备注
-h	--host	指定注册到注册中心的ip	不指定时获取当前ip，外部访问部署在云环境和容器中的server建议指定
-p	--port	指定server启动的端口号	默认为8091
-m	--storeMode	事务日志存储方式	支持file、db、redis，默认file，Seata-Server 1.3及以上版本支持redis
-n	--serverNode	用于指定seata-server节点ID	如1,2,3，... 默认为1
-e	--seataEnv	指定seata-server运行环境	如:dev,test等，服务启动时会使用registry-dev.conf这样的配置

集群部署，只需在启动时添加启动参数即可，其它与单机一致。

大概如下：

#节点1
seata-server.sh  -p 8091 -n 1
#节点2
seata-server.sh  -p 8092 -n 2
#节点3
seata-server.sh  -p 8093 -n 3

 启动Seata Server，双击seata-server.bat

 到nacos中查看服务列表

 Seata Client环境搭建

接入微服务应用，业务场景：

用户下单，整个业务逻辑由两个微服务构成：

• 订单服务：用户购买商品下单
• 库存服务：扣除相应商品库存数量

搭建步骤：

1.启动seata server服务端，seata server使用nacos作为注册中心和配置中心（上一步已完成）

2.微服务整合seata

• 添加pom依赖

        
        
            com.alibaba.cloud
            spring-cloud-starter-alibaba-seata
        

• 各微服务对应数据库中添加undo_log表   

CREATE TABLE IF NOT EXISTS `undo_log`
(
    `branch_id`     BIGINT(20)   NOT NULL COMMENT 'branch transaction id',
    `xid`           VARCHAR(100) NOT NULL COMMENT 'global transaction id',
    `context`       VARCHAR(128) NOT NULL COMMENT 'undo_log context,such as serialization',
    `rollback_info` LONGBLOB     NOT NULL COMMENT 'rollback info',
    `log_status`    INT(11)      NOT NULL COMMENT '0:normal status,1:defense status',
    `log_created`   DATETIME(6)  NOT NULL COMMENT 'create datetime',
    `log_modified`  DATETIME(6)  NOT NULL COMMENT 'modify datetime',
    UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`)
) ENGINE = InnoDB
  AUTO_INCREMENT = 1
  DEFAULT CHARSET = utf8 COMMENT ='AT transaction mode undo table';

•  在application.yml文件中配置事务分组，注意这里一定要和config.txt文件中配置的一致。

alibaba:
   seata:
     #配置事务分组
     tx-service-group: my_test_tx_group

• 在application.yml文件中配置seata 的注册中心和配置中心 

seata:
  #注册中心
  registry:
    #配置seata的注册中心为nacos，告诉seata client怎么去访问seata server
    type: nacos
    nacos:
      #seata server的注册地址
      server-addr: 127.0.0.1:8848
      #seata server的服务名，默认：seata-server，若没有修改则可以不配置
      application: seata-server
      username: nacos
      password: nacos
       #seata server所在的组，默认：SEATA_GROUP，若没有修改则可以不配置
      group: SEATA_GROUP
  #配置中心
  config:
    #配置seata的配置中心为nacos
    type: nacos
    nacos:
      #seata server的注册地址
      server-addr: 127.0.0.1:8848
      #seata server所在的组，默认：SEATA_GROUP，若没有修改则可以不配置
      group: SEATA_GROUP
      username: nacos
      password: nacos

• 在相应的服务上添加@GlobalTransactional注解
• 启动，测试

五、参数配置

官方配置文档：Seata 参数配置

全属性

公共部分

key	desc	remark
transport.serialization	client和server通信编解码方式	seata(ByteBuf)、protobuf、kryo、hession、fst，默认seata
transport.compressor	client和server通信数据压缩方式	none、gzip，默认none
transport.heartbeat	client和server通信心跳检测开关	默认true开启
registry.type	注册中心类型	默认file，支持file 、nacos 、eureka、redis、zk、consul、etcd3、sofa、custom
config.type	配置中心类型	默认file，支持file、nacos 、apollo、zk、consul、etcd3、custom

server端

key	desc	remark
server.undo.logSaveDays	undo保留天数	默认7天,log_status=1（附录3）和未正常清理的undo
server.undo.logDeletePeriod	undo清理线程间隔时间	默认86400000，单位毫秒
server.maxCommitRetryTimeout	二阶段提交重试超时时长	单位ms,s,m,h,d,对应毫秒,秒,分,小时,天,默认毫秒。默认值-1表示无限重试。公式: timeout>=now-globalTransactionBeginTime,true表示超时则不再重试(注: 达到超时时间后将不会做任何重试,有数据不一致风险,除非业务自行可校准数据,否者慎用)
server.maxRollbackRetryTimeout	二阶段回滚重试超时时长	同commit
server.recovery.committingRetryPeriod	二阶段提交未完成状态全局事务重试提交线程间隔时间	默认1000，单位毫秒
server.recovery.asynCommittingRetryPeriod	二阶段异步提交状态重试提交线程间隔时间	默认1000，单位毫秒
server.recovery.rollbackingRetryPeriod	二阶段回滚状态重试回滚线程间隔时间	默认1000，单位毫秒
server.recovery.timeoutRetryPeriod	超时状态检测重试线程间隔时间	默认1000，单位毫秒，检测出超时将全局事务置入回滚会话管理器
store.mode	事务会话信息存储方式	file本地文件(不支持HA)，db数据库|redis(支持HA)
store.file.dir	file模式文件存储文件夹名	默认sessionStore
store.db.datasource	db模式数据源类型	dbcp、druid、hikari；无默认值，store.mode=db时必须指定。
store.db.dbType	db模式数据库类型	mysql、oracle、db2、sqlserver、sybaee、h2、sqlite、access、postgresql、oceanbase；无默认值，store.mode=db时必须指定。
store.db.driverClassName	db模式数据库驱动	store.mode=db时必须指定
store.db.url	db模式数据库url	store.mode=db时必须指定，在使用mysql作为数据源时，建议在连接参数中加上rewriteBatchedStatements=true(详细原因请阅读附录7)
store.db.user	db模式数据库账户	store.mode=db时必须指定
store.db.password	db模式数据库账户密码	store.mode=db时必须指定
store.db.minConn	db模式数据库初始连接数	默认1
store.db.maxConn	db模式数据库最大连接数	默认20
store.db.maxWait	db模式获取连接时最大等待时间	默认5000，单位毫秒
store.db.globalTable	db模式全局事务表名	默认global_table
store.db.branchTable	db模式分支事务表名	默认branch_table
store.db.lockTable	db模式全局锁表名	默认lock_table
store.db.queryLimit	db模式查询全局事务一次的最大条数	默认100
store.redis.host	redis模式ip	默认127.0.0.1
store.redis.port	redis模式端口	默认6379
store.redis.maxConn	redis模式最大连接数	默认10
store.redis.minConn	redis模式最小连接数	默认1
store.redis.database	redis模式默认库	默认0
store.redis.password	redis模式密码(无可不填)	默认null
store.redis.queryLimit	redis模式一次查询最大条数	默认100
metrics.enabled	是否启用Metrics	默认false关闭，在False状态下，所有与Metrics相关的组件将不会被初始化，使得性能损耗最低
metrics.registryType	指标注册器类型	Metrics使用的指标注册器类型，默认为内置的compact（简易）实现，这个实现中的Meter仅使用有限内存计数，性能高足够满足大多数场景；目前只能设置一个指标注册器实现
metrics.exporterList	指标结果Measurement数据输出器列表	默认prometheus，多个输出器使用英文逗号分割，例如"prometheus,jmx"，目前仅实现了对接prometheus的输出器
metrics.exporterPrometheusPort	prometheus输出器Client端口号	默认9898

client端

key	desc	remark
seata.enabled	是否开启spring-boot自动装配	true、false,(SSBS)专有配置，默认true（附录4）
seata.enableAutoDataSourceProxy=true	是否开启数据源自动代理	true、false,seata-spring-boot-starter(SSBS)专有配置,SSBS默认会开启数据源自动代理,可通过该配置项关闭.
seata.useJdkProxy=false	是否使用JDK代理作为数据源自动代理的实现方式	true、false,(SSBS)专有配置,默认false,采用CGLIB作为数据源自动代理的实现方式
transport.enableClientBatchSendRequest	客户端事务消息请求是否批量合并发送	默认true，false单条发送
client.log.exceptionRate	日志异常输出概率	默认100，目前用于undo回滚失败时异常堆栈输出，百分之一的概率输出，回滚失败基本是脏数据，无需输出堆栈占用硬盘空间
service.vgroupMapping.my_test_tx_group	事务群组（附录1）	my_test_tx_group为分组，配置项值为TC集群名
service.default.grouplist	TC服务列表（附录2）	仅注册中心为file时使用
service.disableGlobalTransaction	全局事务开关	默认false。false为开启，true为关闭
client.tm.degradeCheck	降级开关	默认false。业务侧根据连续错误数自动降级不走seata事务(详细介绍请阅读附录6)
client.tm.degradeCheckAllowTimes	升降级达标阈值	默认10
client.tm.degradeCheckPeriod	服务自检周期	默认2000,单位ms.每2秒进行一次服务自检,来决定
client.rm.reportSuccessEnable	是否上报一阶段成功	true、false，从1.1.0版本开始,默认false.true用于保持分支事务生命周期记录完整，false可提高不少性能
client.rm.asynCommitBufferLimit	异步提交缓存队列长度	默认10000。 二阶段提交成功，RM异步清理undo队列
client.rm.lock.retryInterval	校验或占用全局锁重试间隔	默认10，单位毫秒
client.rm.lock.retryTimes	校验或占用全局锁重试次数	默认30
client.rm.lock.retryPolicyBranchRollbackOnConflict	分支事务与其它全局回滚事务冲突时锁策略	默认true，优先释放本地锁让回滚成功
client.rm.reportRetryCount	一阶段结果上报TC重试次数	默认5次
client.rm.tableMetaCheckEnable	自动刷新缓存中的表结构	默认false
client.tm.commitRetryCount	一阶段全局提交结果上报TC重试次数	默认1次，建议大于1
client.tm.rollbackRetryCount	一阶段全局回滚结果上报TC重试次数	默认1次，建议大于1
client.undo.dataValidation	二阶段回滚镜像校验	默认true开启，false关闭
client.undo.logSerialization	undo序列化方式	默认jackson
client.undo.logTable	自定义undo表名	默认undo_log
client.rm.sqlParserType	sql解析类型	默认druid,可选antlr

---