1.提出问题
2.专业名词解释
- CAP定理的矛盾
- 解决分布式事务的思路
3.Seata
事务组映射关系
与TC服务的通信配置
RM配置
TM配置
undo日志配置
- 2.配置TC地址
4.Seata中的四种不同的事务模式（XA,TCC,AT,SAGA）
5.高可用（Seata的TC服务作为分布式事务核心，一定要保证集群的高可用性）
- 1.高可用架构模型
- 2.实现高可用

1.提出问题

1.在分布式架构中一个业务需要跨对个微服务,如何对这多个微服务执行的状态保持一致？分布式系统下的事务

2.专业名词解释

概念：指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
CP : 强一致性,弱可用性(牺牲部分机器的可用性,保证数据一致性)
AP : 强可用性,弱一致性(牺牲一致性,保证可用性)

BASE理论是对CAP的一种解决思路，包含三个思想：
- Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
- Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
- Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

Consistency(一致性): 用户访问分布式系统中的任意节点，得到的数据必须一致

Availability（可用性）: 用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。

Partition(分区): 因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
tolerance(容错): 在集群出现分区时，整个系统也要持续对外提供服务

CAP定理的矛盾

在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务有必须对外保证服务。因此Partition Tolerance不可避免。当节点接收到新的数据变更时，就会出现问题了：如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。如果此时要保证可用性，就不能等待网络恢复，那node01、node02与node03之间就会出现数据不一致。也就是说，在P一定会出现的情况下，A和C之间只能实现一个。

解决分布式事务的思路

:::info 分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路

AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者(TC)：

这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务。 :::

3.Seata

seata官网

1.Seata的架构

:::info Seata事务管理中有三个重要的角色

TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。 :::

2.Seata基于架构提供的分布式事务解决方案（无论哪种方案，都离不开TC，也就是事务的协调者。）
:::info
XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
TCC模式：最终一致的分阶段事务模式，有业务侵入
AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
SAGA模式：长事务模式，有业务侵入 :::
3.部署TC服务
部署TC服务
1.nacos配置中心配置文件
```properties
事务组映射关系
service.vgroupMapping.seata-demo=SH

service.enableDegrade=false service.disableGlobalTransaction=false

与TC服务的通信配置

transport.type=TCP transport.server=NIO transport.heartbeat=true transport.enableClientBatchSendRequest=false transport.threadFactory.bossThreadPrefix=NettyBoss transport.threadFactory.workerThreadPrefix=NettyServerNIOWorker transport.threadFactory.serverExecutorThreadPrefix=NettyServerBizHandler transport.threadFactory.shareBossWorker=false transport.threadFactory.clientSelectorThreadPrefix=NettyClientSelector transport.threadFactory.clientSelectorThreadSize=1 transport.threadFactory.clientWorkerThreadPrefix=NettyClientWorkerThread transport.threadFactory.bossThreadSize=1 transport.threadFactory.workerThreadSize=default transport.shutdown.wait=3

RM配置

client.rm.asyncCommitBufferLimit=10000 client.rm.lock.retryInterval=10 client.rm.lock.retryTimes=30 client.rm.lock.retryPolicyBranchRollbackOnConflict=true client.rm.reportRetryCount=5 client.rm.tableMetaCheckEnable=false client.rm.tableMetaCheckerInterval=60000 client.rm.sqlParserType=druid client.rm.reportSuccessEnable=false client.rm.sagaBranchRegisterEnable=false

TM配置

client.tm.commitRetryCount=5 client.tm.rollbackRetryCount=5 client.tm.defaultGlobalTransactionTimeout=60000 client.tm.degradeCheck=false client.tm.degradeCheckAllowTimes=10 client.tm.degradeCheckPeriod=2000

undo日志配置

client.undo.dataValidation=true client.undo.logSerialization=jackson client.undo.onlyCareUpdateColumns=true client.undo.logTable=undo_log client.undo.compress.enable=true client.undo.compress.type=zip client.undo.compress.threshold=64k client.log.exceptionRate=100

<a name="IJEvZ"></a>
## 4.微服务集成Seata
<a name="pWaHN"></a>
### 1.引入seata依赖
```xml
<!--seata-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <exclusions>
        <!--版本较低，1.3.0，因此排除--> 
        <exclusion>
            <artifactId>seata-spring-boot-starter</artifactId>
            <groupId>io.seata</groupId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <!--seata starter 采用1.4.2版本-->
    <version>${seata.version}</version>
</dependency>

2.配置TC地址

seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    type: nacos # 注册中心类型 nacos
    nacos:
      server-addr: 127.0.0.1:8848 # nacos地址
      namespace: "" # namespace，默认为空
      group: DEFAULT_GROUP # 分组，默认是DEFAULT_GROUP
      application: seata-tc-server # seata服务名称
      username: nacos
      password: nacos
  tx-service-group: seata-demo # 事务组名称

 #写在nacos配置里
 #  service:
 #    vgroup-mapping: # 事务组与cluster的映射关系
 #      seata-demo: SH

  data-source-proxy-mode: AT #事务模式

    #nacos配置中心
  config:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      username: nacos
      password: nacos
      group: SEATA_GROUP
      data-id: client.properties

4.Seata中的四种不同的事务模式（XA,TCC,AT,SAGA）

1.XA模式(XA 模式描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 模式提供了支持。)

1.实现的原理:两阶段提交

:::info 一阶段：

事务协调者通知每个事物参与者执行本地事务
本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁

二阶段：

事务协调者基于一阶段的报告来判断下一步操作
- 如果一阶段都成功，则通知所有事务参与者，提交事务
- 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务 :::
  2.Seata的XA模型
  :::info RM一阶段的工作：
  - 注册分支事务到TC
  - 执行分支业务sql但不提交
  - 报告执行状态到TC
  TC二阶段的工作：
TC检测各分支事务执行状态a.如果都成功，通知所有RM提交事务b.如果有失败，通知所有RM回滚事务

RM二阶段的工作：

接收TC指令，提交或回滚事务

优点

事务的强一致性，满足ACID原则。
常用数据库都支持，实现简单，并且没有代码侵入

缺点

因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
依赖关系型数据库实现事务 :::

实现XA模式（Seata的starter已经完成了XA模式的自动装配）

1.修改application.yml文件（==每个参与事务的微服务==），开启XA模式
```
seata:
data-source-proxy-mode: XA
```
2.给发起全局事务的入口方法添加@GlobalTransactional注解

2.AT模式（AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷）

1.脏写问题（在多线程并发访问AT模式的分布式事务时，有可能出现脏写问题）

解决方法：引入了全局锁的概念。在释放DB锁之前，先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。

2.由非seata事务产生的脏写（只能由人工处理，几乎不可能出现）

2.Seata的AT模型(默认的)

:::info 阶段一RM的工作：
注册分支事务
记录undo-log（数据快照）
执行业务sql并提交
报告事务状态

阶段二提交时RM的工作：

删除undo-log即可

阶段二回滚时RM的工作：

根据undo-log恢复数据到更新前

优点：

一阶段完成直接提交事务，释放数据库资源，性能比较好
利用全局锁实现读写隔离
没有代码侵入，框架自动完成回滚和提交

缺点：

两阶段之间属于软状态，属于最终一致
框架的快照功能会影响性能，但比XA模式要好很多 :::
实现AT模式（AT模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，只不过，AT模式需要一个表来记录全局锁、另一张表来记录数据快照undo_log。）
1.将lock_table导入到TC服务关联的数据库，undo_log表导入到微服务关联的数据库
``sql CREATE TABLElock_table(row_keyvarchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,xidvarchar(96) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,transaction_idbigint(20) NULL DEFAULT NULL,branch_idbigint(20) NOT NULL,resource_idvarchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,table_namevarchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,pkvarchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,gmt_createdatetime NULL DEFAULT NULL,gmt_modifieddatetime NULL DEFAULT NULL, PRIMARY KEY (row_key) USING BTREE, INDEXidx_branch_id(branch_id`) USING BTREE ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

```sql
CREATE TABLE `undo_log`  (
  `branch_id` bigint(20) NOT NULL COMMENT 'branch transaction id',
  `xid` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'global transaction id',
  `context` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci 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 INDEX `ux_undo_log`(`xid`, `branch_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci COMMENT = 'AT transaction mode undo table' ROW_FORMAT = Compact;

2.修改application.yml文件，将事务模式修改为AT模式即可

seata:
  data-source-proxy-mode: AT # 默认就是AT

3.AT与XA的区别

:::info

XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
XA模式强一致；AT模式最终一致 :::

3.TCC模式（TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复）

1.实现原理：三个方法
:::info
Try：资源的检测和预留；
Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
Cancel：预留资源释放，可以理解为try的反向操作。

举例：假设账户A原来余额是100，需要余额扣减30元

阶段一（ Try ）：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30
阶段二（Confirm)：假如要提交（Confirm），则冻结金额扣减30
阶段二(Canncel)：如果要回滚（Cancel），则冻结金额扣减30，可用余额增加30 :::
2.事务悬挂和空回滚

1.空回滚
:::info 当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。

执行cancel操作时，应当判断try是否已经执行，如果尚未执行，则应该空回滚。 :::

2.业务悬挂

:::info 对于已经空回滚的业务，之前被阻塞的try操作恢复，继续执行try，就永远不可能confirm或cancel ，事务一直处于中间状态，这就是业务悬挂。

执行try操作时，应当判断cancel是否已经执行过了，如果已经执行，应当阻止空回滚后的try操作，避免悬挂 :::

3.Seata的TCC模型（针对扣款（只对账户） Seata中的TCC模型依然延续之前的事务架构）

实现TCC模式（解决空回滚和业务悬挂问题，必须要记录当前事务状态，是在try、还是cancel）

1.定义一张事务表

CREATE TABLE `account_freeze_tbl` (
  `xid` varchar(128) NOT NULL,
  `user_id` varchar(255) DEFAULT NULL COMMENT '用户id',
  `freeze_money` int(11) unsigned DEFAULT '0' COMMENT '冻结金额',
  `state` int(1) DEFAULT NULL COMMENT '事务状态，0:try，1:confirm，2:cancel',
  PRIMARY KEY (`xid`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT;

:::info

xid：是全局事务id
freeze_money：用来记录用户冻结金额
state：用来记录事务状态

业务开怎么做呢？

Try业务：
- 记录冻结金额和事务状态到account_freeze表
- 扣减account表可用金额
Confirm业务
- 根据xid删除account_freeze表的冻结记录
Cancel业务
- 修改account_freeze表，冻结金额为0，state为2
- 修改account表，恢复可用金额
如何判断是否空回滚？
- cancel业务中，根据xid查询account_freeze，如果为null则说明try还没做，需要空回滚
如何避免业务悬挂？
- try业务中，根据xid查询account_freeze ，如果已经存在则证明Cancel已经执行，拒绝执行try业务 :::
  2.service层声明TCC接口（TCC的Try、Confirm、Cancel方法都需要在接口中基于注解来声明）
```java import io.seata.rm.tcc.api.BusinessActionContext; import io.seata.rm.tcc.api.BusinessActionContextParameter; import io.seata.rm.tcc.api.LocalTCC; import io.seata.rm.tcc.api.TwoPhaseBusinessAction;

@LocalTCC // 设置TCC模式 public interface TCCAccountService { /**

 * 从用户账户中扣款
 */
// 此注解使用在try方法上,方法名称可以自定义
// 预留冻结
@TwoPhaseBusinessAction(name = "deduct",commitMethod = "confirm",rollbackMethod = "cancel")
void deduct(
        @BusinessActionContextParameter(paramName = "userId") String userId,
        @BusinessActionContextParameter(paramName = "money") int money);
// confirm: 提交
// BusinessActionContext: 业务上下文对象
void confirm(BusinessActionContext context);
// cancel: 事务补偿
void cancel(BusinessActionContext context);

}

<a name="spCeR"></a>
#### 3.serviceimpl层编写TCC实现类
```java
import cn.itcast.account.entity.AccountFreeze;
import cn.itcast.account.mapper.AccountFreezeMapper;
import cn.itcast.account.mapper.AccountMapper;
import cn.itcast.account.service.TCCAccountService;
import io.seata.core.context.RootContext;
import io.seata.rm.tcc.api.BusinessActionContext;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class TCCAccountServiceImpl implements TCCAccountService {

    @Autowired
    private AccountMapper accountMapper;
    @Autowired
    private AccountFreezeMapper freezeMapper;

    // try阶段
    @Override
    @Transactional
    public void deduct(String userId, int money) {
        // 0.获取全局事务ID
        String xid = RootContext.getXID();
        // 1.查询account_freeze_tbl表,判断cancel是否执行
        AccountFreeze accountFreeze = freezeMapper.selectById(xid);
        if (accountFreeze!=null){
            // cancel执行过了.不再执行try
            if (accountFreeze.getState()==2){
                freezeMapper.deleteById(xid);
            }
            return;
        }
        // 1.冻结金额 -- 向冻结表中添加一条数据
        AccountFreeze freeze = new AccountFreeze();
        freeze.setUserId(userId);
        freeze.setFreezeMoney(money);
        freeze.setState(AccountFreeze.State.TRY);
        freeze.setXid(xid);
        freezeMapper.insert(freeze);
        // 2.从account表中减去冻结金额
        accountMapper.deduct(userId, money);
    }

    @Override
    @Transactional
    public void confirm(BusinessActionContext context) {
        // 删除冻结数据
        freezeMapper.deleteById(context.getXid());
    }

    @Override
    @Transactional
    public void cancel(BusinessActionContext context) {
        // 查看冻结数据状态,并执行补偿
        // 1.通过业务上下文对象获取
        String userId = context.getActionContext("userId").toString();
        Integer money = (Integer) context.getActionContext("money");
        String xid = context.getXid();
        // 2.判断try是否执行,如果未执行,则进行空回滚
        AccountFreeze accountFreeze = freezeMapper.selectById(xid);
        if (accountFreeze==null){
            // 添加一条记录,标准cancel执行过
            AccountFreeze freeze = new AccountFreeze();
            freeze.setUserId(userId);
            freeze.setFreezeMoney(money);
            freeze.setState(AccountFreeze.State.CANCEL);
            freeze.setXid(xid);
            freezeMapper.insert(freeze);
            return;
        }
        // 3.恢复可用金额
        accountMapper.refund(userId, money);
        // 4.移除冻结金额，修改事务状态
        freezeMapper.deleteById(context.getXid());
    }
}

4.web层修改TCC类的调用

import cn.itcast.account.service.AccountService;
import cn.itcast.account.service.TCCAccountService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.PutMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

/**
 * @author
 */
@RestController
@RequestMapping("account")
public class AccountController {

    //@Autowired
    //private AccountService accountService;
    @Autowired
    private TCCAccountService accountService;
    @RequestMapping("/{userId}/{money}")
    public ResponseEntity<Void> deduct(@PathVariable("userId") String userId, @PathVariable("money") Integer money){
        accountService.deduct(userId, money);
        return ResponseEntity.noContent().build();
    }
}

4.SAGA模式（Seata官网对于Saga的指南：文档链接）

1.实现原理：两个阶段

:::info 在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。

分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

Saga也分为两个阶段：

一阶段：直接提交本地事务
二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚

优点：

事务参与者可以基于事件驱动实现异步调用，吞吐高
一阶段直接提交事务，无锁，性能好
不用编写TCC中的三个阶段，实现简单

缺点：

软状态持续时间不确定，时效性差
没有锁，没有事务隔离，会有脏写 :::
5.四种模式对比

5.高可用（Seata的TC服务作为分布式事务核心，一定要保证集群的高可用性）
1.高可用架构模型
:::info 搭建TC服务集群非常简单，启动多个TC服务，注册到nacos即可。
但集群并不能确保100%安全，万一集群所在机房故障怎么办？所以如果要求较高，一般都会做异地多机房容灾。
比如一个TC集群在上海，另一个TC集群在杭州：

微服务基于事务组（tx-service-group)与TC集群的映射关系，来查找当前应该使用哪个TC集群。当SH集群故障时，只需要将vgroup-mapping中的映射关系改成HZ。则所有微服务就会切换到HZ的TC集群了。 :::

2.实现高可用

资料链接

微服务分布式事务组件Seata

1.提出问题

2.专业名词解释

CAP定理的矛盾

解决分布式事务的思路

3.Seata

1.Seata的架构

2.Seata基于架构提供的分布式事务解决方案（无论哪种方案，都离不开TC，也就是事务的协调者。）

3.部署TC服务

1.nacos配置中心配置文件

事务组映射关系

与TC服务的通信配置

RM配置

TM配置

undo日志配置

2.配置TC地址

4.Seata中的四种不同的事务模式（XA,TCC,AT,SAGA）

1.XA模式(XA 模式 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 模式 提供了支持。)

1.实现的原理:两阶段提交

2.Seata的XA模型

实现XA模式（Seata的starter已经完成了XA模式的自动装配）

1.修改application.yml文件（==每个参与事务的微服务==），开启XA模式

2.给发起全局事务的入口方法添加@GlobalTransactional注解

2.AT模式（AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷）

1.脏写问题（在多线程并发访问AT模式的分布式事务时，有可能出现脏写问题）

解决方法：引入了全局锁的概念。在释放DB锁之前，先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。

2.由非seata事务产生的脏写（只能由人工处理，几乎不可能出现）

2.Seata的AT模型(默认的)

实现AT模式（AT模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，只不过，AT模式需要一个表来记录全局锁、另一张表来记录数据快照undo_log。）

1.将lock_table导入到TC服务关联的数据库，undo_log表导入到微服务关联的数据库

2.修改application.yml文件，将事务模式修改为AT模式即可

3.AT与XA的区别

3.TCC模式（TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复）

1.实现原理：三个方法

2.事务悬挂和空回滚

1.空回滚

2.业务悬挂

3.Seata的TCC模型（针对扣款 （只对账户） Seata中的TCC模型依然延续之前的事务架构）

实现TCC模式（解决空回滚和业务悬挂问题，必须要记录当前事务状态，是在try、还是cancel）

1.定义一张事务表

2.service层声明TCC接口（TCC的Try、Confirm、Cancel方法都需要在接口中基于注解来声明）

4.web层修改TCC类的调用

4.SAGA模式（Seata官网对于Saga的指南：文档链接）

1.实现原理：两个阶段

5.四种模式对比

5.高可用（Seata的TC服务作为分布式事务核心，一定要保证集群的高可用性）

1.高可用架构模型

2.实现高可用

1.XA模式(XA 模式描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 模式提供了支持。)

3.Seata的TCC模型（针对扣款（只对账户） Seata中的TCC模型依然延续之前的事务架构）