b)组合方式
======
在所有分布式事务场景中 不会同时具备CAP三个特性,因为在具备了P的前提下C和A是不能共存的 。
-
AP:放弃一致性,追求分区容忍性和可用性。这是 很多分布式系统设计时的选择 。Eureka集群就是采用的AP设计思想。
-
CP:放弃可用性,追求一致性和分区容错性。zookeeper集群。
-
CA:放弃分区容忍性,即不进行分区,不考虑由于网络不通或结点挂掉的问题,则可以实现一致性和可用性。那么系统将不是一个标准的分布式系统,我们最常用的关系型数据就满足了CA。
c)总结
====
CAP是一个已经被证实的理论:一个分布式系统最多只能同时满足 一致性(Consistency)、可用性(Availability)和分区容忍性(Partition tolerance)这三项中的两项 。它可以作为我们进行架构设计、技术选型的考量标准。对于多数大型互联网应用的场景,结点众多、部署分散,而且现在的集群规模越来越大,所以节点故障、网络故障是常态,而且要保证服务可用性达到N个9(99.99…%),并要达到良好的响应性能来提高用户体验,因此一般都会做出如下选择: 保证P和A,舍弃C强一致,保证最终一致性 。
2,BASE理论
========
a)强一致性与最终一致性
============
-
强一致性:CAP中的一致性要求在任何时间查询每个结点数据都必须一致,它强调的是强一致性。
-
最终一致性:允许可以 在一段时间内每个结点的数据不一致 ,但是经过一段时间每个结点的数据必须一致,它强调的是 最终数据的一致性 。
b)概念
====
BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性) 三个短语的缩写。BASE理论是对CAP中AP的一个扩展,通过牺牲强一致性来获得可用性,当出现故障允许部分不可用但要保证核心功能可用,允许数据在一段时间内是不一致的,但最终达到一致状态。满足BASE理论的事务,我们称之为“ 柔性事务 ”。
-
基本可用 :分布式系统在出现故障时,允许损失部分可用功能, 保证核心功能可用 。如,电商网站交易付款出现问题了,商品依然可以正常浏览。
-
软状态 :由于不要求强一致性,所以BASE允许系统中 存在中间状态 (也叫软状态),这个状态不影响系统可用性,如订单的 “支付中”、“数据同步中” 等状态,待数据最终一致后状态改为“成功”状态。
-
最终一致性 :最终一致是指 经过一段时间后,所有节点数据都将会达到一致 。如订单的"支付中"状态,最终会变为“支付成功”或者"支付失败",使订单状态与实际交易结果达成一致,但需要一定时间的延迟、等待。
三、解决方案之2PC
==========
1,什么是2PC
========
2PC即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段(Prepare phase)、提交阶段(commit phase),2是指两个阶段,P是指准备阶段,C是指提交阶段。
-
准备阶段(Prepare phase): 事务管理器给每个参与者发送Prepare消息 ,每个数据库参与者在本地执行事务,并写本地的Undo/Redo日志,此时事务没有提交。(Undo日志是记录修改前的数据,用于数据库回滚,Redo日志是记录修改后的数据,用于提交事务后写入数据文件)
-
提交阶段(commit phase):如果事务管理器收到了参与者的执行失败或者超时消息时,直接给每个参与者发送回滚(Rollback)消息;否则,发送提交(Commit)消息;参与者根据事务管理器的指令执行提交或者回滚操作,并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。
成功情况:
失败情况:
2,解决方案之XA
=========
2PC的 传统方案是在数据库层面 实现的,如Oracle、MySQL都支持2PC协议,为了统一标准减少行业内不必要的对接成本,需要制定标准化的处理模型及接口标准,国际开放标准组织Open Group定义了分布式事务处理模型DTP(Distributed Transaction Processing Reference Model)。
整个2PC的事务流程涉及到三个角色AP、RM、TM。AP指的是使用2PC分布式事务的 应用程序;RM指的是 资源管理器 ,它控制着分支事务;TM指的是 事务管理器 ,它控制着整个全局事务。
1)在 准备阶段 RM执行实际的业务操作,但不提交事务,资源锁定;
2)在 提交阶段 TM会接受RM在准备阶段的执行回复,只要有任一个RM执行失败,TM会通知所有RM执行回滚操作,否则,TM将会通知所有RM提交该事务。提交阶段结束资源锁释放。
XA方案的问题 :1、需要本地数据库支持XA协议。2、资源锁需要等到两个阶段结束才释放,性能较差。
3,解决方案之Seata
============
a)seata的设计思想
============
Seata的设计目标其一是对业务无侵入,因此从业务无侵入的2PC方案着手,在传统2PC的基础上演进,并解决2PC方案面临的问题。
Seata把 一个分布式事务理解成一个包含了若干分支事务的全局事务 。全局事务的职责是协调其下管辖的分支事务达成一致,要么一起成功提交,要么一起失败回滚。此外,通常分支事务本身就是一个关系数据库的本地事务,下图是全局事务与分支事务的关系图:
与 传统2PC 的模型类似,Seata定义了3个组件来协议分布式事务的处理过程:
-
Transaction Coordinator (TC): 事务协调器 ,它是独立的中间件,需要 独立部署 运行,它维护全局事务的运行状态,接收TM指令发起全局事务的提交与回滚,负责与RM通信协调各个分支事务的提交或回滚。
-
Transaction Manager ™: 事务管理器 ,TM需要嵌入应用程序中工作,它负责 开启一个全局事务 ,并最终向TC发起全局提交或全局回滚的指令。
-
Resource Manager (RM): 控制分支事务 ,负责分支注册、状态汇报,并接收事务协调器TC的指令,驱动分支(本地)事务的提交和回滚。
b)Seata的执行流程
============
-
用户服务的 TM 向 TC 申请开启一个全局事务 ,全局事务创建成功并 生成一个全局唯一的XID。
-
用户服务的 RM 向 TC 注册 分支事务 ,该分支事务在用户服务执行新增用户逻辑,并将其纳入 XID 对应全局事务的管辖 。
-
用户服务执行分支事务,向用户表插入一条记录。
-
逻辑执行到远程调用积分服务时( XID 在微服务调用链路的上下文中传播 )。积分服务的RM 向 TC 注册分支事务,该分支事务执行增加积分的逻辑,并将其纳入 XID 对应全局事务的管辖。
-
积分服务执行分支事务,向积分记录表插入一条记录,执行完毕后,返回用户服务。
-
用户服务分支事务执行完毕。
-
TM 向 TC 发起针对 XID 的全局提交或回滚决议 。
-
TC 调度 XID 下管辖的全部分支事务 完成提交或回滚请求 。
c)Seata的具体实现
============
详情见: Spring Cloud Alibaba Seata
4,Seata与传统2PC
=============
-
架构层次方面, 传统2PC 方案的 RM 实际上是在 数据库层 ,RM 本质上就是数据库自身,通过 XA 协议实现,而 Seata的 RM 是以jar包的形式作为中间件层部署 在应用程序这一侧的。
-
两阶段提交方面,传统2PC无论第二阶段的决议是commit还是rollback, 事务性资源的锁都要保持到Phase2完成才释放 。而 Seata的做法是在Phase1 就将本地事务提交 ,这样就可以省去Phase2持锁的时间,整体 提高效率 。
四、解决方案之TCC
==========
1,什么是TCC
========
TCC是Try、Confirm、Cancel三个词语的缩写,TCC要求每个分支事务实现三个操作:预处理Try、确认Confirm、撤销Cancel。Try 操作做业务检查及资源预留 , Confirm做业务确认操作 , Cancel实现一个与Try相反的操作即回滚操作 。TM首先发起所有的分支事务的try操作,任何一个分支事务的try操作执行失败,TM将会发起所有分支事务的Cancel操作,若try操作全部成功,TM将会发起所有分支事务的Confifirm操作,其中Confirm/Cancel操作若执行失败,TM会进行重试。
成功情况:
失败情况:
TCC分为三个阶段:
-
Try 阶段是做 业务检查(一致性)及资源预留(隔离) ,此阶段仅是一个初步操作,它和后续的Confirm 一起才能真正构成一个完整的业务逻辑。
-
Confirm 阶段是做 确认提交 ,Try阶段所有分支事务执行成功后开始执行 Confirm。通常情况下,采用TCC则认为 Confifirm阶段是不会出错的。即: 只要Try成功,Confirm一定成功 。若Confirm阶段真的出错了,需引入重试机制或人工处理。
-
Cancel 阶段是在业务执行错误 需要回滚的状态下执行分支事务的业务取消 ,预留 资源释放。通常情况下,采用TCC则 认为Cancel阶段也是一定成功 的。若Cancel阶段真的出错了,需引入重试机制或人工处理。
2,TCC解决方案
=========
框架名称 | Github地址 |
tcc-transaction | https://github.com/changmingxie/tcc-transaction |
Hmily | https://github.com/yu199195/hmily |
ByteTCC | https://github.com/liuyangming/ByteTCC |
EasyTransaction | https://github.com/QNJR-GROUP/EasyTransaction |
3,TCC需要注意的问题
============
a)空回滚
=====
在没有调用 TCC 资源 Try 方法的情况下,调用了二阶段的 Cancel 方法,Cancel 方法需要 识别出这是一个空回滚 ,然后直接返回成功。
出现原因:是当一个分支事务所在服务宕机或网络异常,分支事务调用记录为失败,这个时候其实是没有执行Try阶段,当故障恢复后,分布式事务进行回滚则会调用二阶段的Cancel方法,从而形成空回滚。
解决方法:识别出这个空回滚。需要知道一阶段是否执行,如果执行了,那就是正常回滚;如果没执行,那就是空回滚。前面已经说过TM在发起全局事务时生成全局事务记录,全局事务ID贯穿整个分布式事务调用链条。再额外增加一张分支事务记录表,其中有全局事务 ID 和分支事务 ID,第一阶段 Try 方法里会插入一条记录,表示一阶段执行了。
//在cancel中cancel空回滚处理,如果try没有执行,cancel不允许执行
if(accountInfoDao.isExistTry(transId)<=0){
log.info(“bank1 空回滚处理,try没有执行,不允许cancel执行,xid:{}”,transId);
return ;
}
b)幂等
====
为了保证TCC二阶段提交重试机制不会引发数据不一致,要求 TCC 的二阶段 Try、Confirm 和 Cancel 接口保证幂等,这样不会重复使用或者释放资源。如果幂等控制没有做好,很有可能导致数据不一致等严重问题。
//当前是在try中进行幂等判断 判断local_try_log表中是否有try日志记录,如果有则不再执行
if(accountInfoDao.isExistTry(transId)>0){
log.info(“bank1 try 已经执行,无需重复执行,xid:{}”,transId);
return ;
}
c)悬挂
====
悬挂就是对于一个分布式事务,其二阶段 Cancel 接口比 Try 接口先执行。
出现原因:RPC 调用分支事务try时,先注册分支事务,再执行RPC调用,如果此时 RPC 调用的网络发生拥堵,通常 RPC 调用是有超时时间的, RPC 超时 以后,TM就会通知RM 回滚 该分布式事务,可能回滚完,RPC 请求才到达参与者真正执行,而一个 Try 方法预留的业务资源。
解决思路:如果二阶段执行完成,那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下, “分支事务记录”表中是否已经有二阶段事务记录 ,如果有则不执行Try。
//try悬挂处理,如果cancel、confirm有一个已经执行了,try不再执行
if(accountInfoDao.isExistConfirm(transId)>0 || accountInfoDao.isExistCancel(transId)>0){
log.info(“bank1 try悬挂处理 cancel或confirm已经执行,不允许执行try,xid:{}”,transId);
return ;
}
4,Hmily
=======
项目源码: cloud-dtx-tcc
a)导入数据库
=======
sql文件下载地址为: dtx-tcc-sql
b)工程配置
======
涉及到分布式事务的工程均需要的配置
maven配置
=======
org.dromara
hmily‐springcloud
2.0.4‐RELEASE
application.yaml中添加hmily
org:
dromara:
hmily:
serializer: kryo
recoverDelayTime: 30
retryMax: 30
scheduledDelay: 30
scheduledThreadMax: 10
repositorySupport: db
#对于发起方的时候,把此属性设置为true。参与方为false。
started: true
hmilyDbConfig:
driverClassName: com.mysql.jdbc.Driver
url: jdbc:mysql://localhost:3306/hmily?useUnicode=true
username: root
password: 123456
注入hmily的配置Bean
@Bean
public HmilyTransactionBootstrap hmilyTransactionBootstrap(HmilyInitService hmilyInitService){
HmilyTransactionBootstrap hmilyTransactionBootstrap = new HmilyTransactionBootstrap(hmilyInitService);
hmilyTransactionBootstrap.setSerializer(env.getProperty(“org.dromara.hmily.serializer”));
hmilyTransactionBootstrap.setRecoverDelayTime(Integer.parseInt(env.getProperty(“org.dromara.hmily.recoverDelayTime”)));
hmilyTransactionBootstrap.setRetryMax(Integer.parseInt(env.getProperty(“org.dromara.hmily.retryMax”)));
hmilyTransactionBootstrap.setScheduledDelay(Integer.parseInt(env.getProperty(“org.dromara.hmily.scheduledDelay”)));
hmilyTransactionBootstrap.setScheduledThreadMax(Integer.parseInt(env.getProperty(“org.dromara.hmily.scheduledThreadMax”)));
hmilyTransactionBootstrap.setRepositorySupport(env.getProperty(“org.dromara.hmily.repositorySupport”));
hmilyTransactionBootstrap.setStarted(Boolean.parseBoolean(env.getProperty(“org.dromara.hmily.started”)));
HmilyDbConfig hmilyDbConfig = new HmilyDbConfig();
hmilyDbConfig.setDriverClassName(env.getProperty(“org.dromara.hmily.hmilyDbConfig.driverClassName”));
hmilyDbConfig.setUrl(env.getProperty(“org.dromara.hmily.hmilyDbConfig.url”));
hmilyDbConfig.setUsername(env.getProperty(“org.dromara.hmily.hmilyDbConfig.username”));
hmilyDbConfig.setPassword(env.getProperty(“org.dromara.hmily.hmilyDbConfig.password”));
hmilyTransactionBootstrap.setHmilyDbConfig(hmilyDbConfig);
return hmilyTransactionBootstrap;
}
启动类上添加注解
@ComponentScan({“org.dromara.hmily”})
c)调用方(bank1)实现
==============
代码实现: AccountInfoServiceImpl
try:
try幂等校验
try悬挂处理
检查余额是够扣减金额
扣减金额
confirm:
空
cancel
cancel幂等校验
cancel空回滚处理
增加可用余额
注意 :远程调用bank2时,在feign调用的接口上加注解 @Hmily
d)参与方(bank2)实现
==============
代码实现: AccountInfoServiceImpl
try:
空
confirm:
confirm幂等校验
正式增加金额
cancel:
空
e)小结
====
如果拿TCC事务的处理流程与2PC两阶段提交做比较, 2PC通常都是在跨库的DB层面 ,而 TCC则在应用层面的处理 ,需要通过业务逻辑来实现。这种分布式事务的实现方式的 优势 在于,可以让应用自己定义数据操作的粒度,使得 降低锁冲突、提高吞吐量 成为可能。
而 不足之处 则在于对应用的 侵入性非常强 ,业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。此外,其 实现难度也比较大 ,需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。
五、解决方案之可靠消息最终一致性
================
项目源码: cloud-dtx-txmsg
1,什么是可靠消息最终一致性
==============
可靠消息最终一致性方案是指当 事务发起方执行完成本地事务后并发出一条消息 , 事务参与方(消息消费者)一定能够接收消息并处理事务成功 ,此方案强调的是只要消息发给事务参与方最终事务要达到一致。
可靠消息需要解决的问题:
-
本地事务与消息发送的原子性问题
-
//先发消息如果数据库操作错误,消息已经发送 begin transaction; //1.发送MQ //2.数据库操作 commit transation; //如果数据库超时,此时数据库回滚,但是消息可能也已经发送 begin transaction; //1.数据库操作 //2.发送MQ commit transation;
-
事务参与方接受消息的可靠性
-
事务参与方必须能够从消息队列接收到消息,如果接收消息失败可以重复接收消息。
-
消息重复消费的问题
-
由于网络2的存在,若某一个消费节点超时但是消费成功,此时消息中间件会重复投递此消息,就导致了消息的重 复消费。 要解决消息重复消费的问题就要实现事务参与方的方法幂等性。
2,RocketMQ事务消息方案
================
-
Producer 发送事务消息 :Producer (MQ发送方)发送事务消息至MQ Server,MQ Server将消息状态标记为Prepared( 预备状态 ),注意此时这条消息消费者(MQ订阅方)是 无法消费 到的。
-
MQ Server 回应消息 发送成功 :MQ Server接收到Producer 发送给的消息则回应发送成功表示MQ已接收到消息。
-
Producer 执行 本地事务 :Producer 端执行业务代码逻辑,通过 本地数据库事务控制 。
-
消息投递 :若Producer 本地事务 执行成功 则自动向MQServer发送 commit 消息,此时MQ订阅方(积分服务)即正常消费消息;若Producer 本地事务 执行失败 则自动向MQServer发送 rollback 消息,MQ Server接收到rollback消息后 将删除”增加积分消息“ 。 MQ订阅方(积分服务)消费消息, 消费成功则向MQ回应ack ,否则将重复接收消息。这里ack默认自动回应,即程序执行正常则自动回应ack。
-
事务回查 :如果执行Producer端 本地事务过程中,执行端挂掉,或者超时 ,MQ Server将会不停的询问 同组的其他 Producer来获取事务执行状态 ,这个过程叫事务回查。MQ Server会根据事务回查结果来决定是否投递消息。
3,RocketMQ实现可靠消息最终一致性事务
=======================
a)SQL
=====
bank1
CREATE DATABASE bank1
CHARACTER
SET ‘utf8’ COLLATE ‘utf8_general_ci’;
DROP TABLE
IF EXISTS account_info
;
CREATE TABLE account_info
(
id
BIGINT (20) NOT NULL AUTO_INCREMENT,
account_name
VARCHAR (100) CHARACTER
SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT ‘户 主姓名’,
account_no
VARCHAR (100) CHARACTER
SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT ‘银行 卡号’,
account_password
VARCHAR (100) CHARACTER
SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT ‘帐户密码’,
account_balance
DOUBLE NULL DEFAULT NULL COMMENT ‘帐户余额’,
PRIMARY KEY (id
) USING BTREE
) ENGINE = INNODB AUTO_INCREMENT = 5 CHARACTER
SET = utf8 COLLATE = utf8_bin ROW_FORMAT = Dynamic;
INSERT INTO account_info
VALUES
(
2,
‘张三的账户’,
‘1’,
‘’,
10000
);
DROP TABLE
IF EXISTS de_duplication
;
CREATE TABLE de_duplication
(
tx_no
VARCHAR (64) COLLATE utf8_bin NOT NULL,
create_time
datetime (0) NULL DEFAULT NULL,
PRIMARY KEY (tx_no
) USING BTREE
) ENGINE = INNODB CHARACTER
SET = utf8 COLLATE = utf8_bin ROW_FORMAT = Dynamic;
View Code
bank2
CREATE DATABASE bank2
CHARACTER
SET ‘utf8’ COLLATE ‘utf8_general_ci’;
DROP TABLE
IF EXISTS account_info
;
CREATE TABLE account_info
(
id
BIGINT (20) NOT NULL AUTO_INCREMENT,
account_name
VARCHAR (100) CHARACTER
SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT ‘户 主姓名’,
account_no
VARCHAR (100) CHARACTER
SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT ‘银行 卡号’,
account_password
VARCHAR (100) CHARACTER
SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT ‘帐户密码’,
account_balance
DOUBLE NULL DEFAULT NULL COMMENT ‘帐户余额’,
PRIMARY KEY (id
) USING BTREE
) ENGINE = INNODB AUTO_INCREMENT = 5 CHARACTER
SET = utf8 COLLATE = utf8_bin ROW_FORMAT = Dynamic;
INSERT INTO account_info
VALUES
(
3,
‘李四的账户’,
‘2’,
NULL,
0
);
CREATE TABLE de_duplication
(
tx_no
VARCHAR (64) COLLATE utf8_bin NOT NULL,
create_time
datetime (0) NULL DEFAULT NULL,
PRIMARY KEY (tx_no
) USING BTREE
) ENGINE = INNODB CHARACTER
SET = utf8 COLLATE = utf8_bin ROW_FORMAT = Dynamic;
View Code
b)安装RocketMQ
============
c)工程配置
======
maven
org.apache.rocketmq
rocketmq-spring-boot-starter
2.0.2
properties配置
rocketmq.producer.group = producer_bank2
rocketmq.name‐server = 127.0.0.1:9876
d)bank1
=======
Service: AccountInfoServiceImpl
//两个方法
//1,向mq发送转账消息
//2,更新账户,扣减金额 (通过事务id保证幂等性)
Controller: AccountInfoController
//生成事务id,调用service的发消息接口
message: ProducerTxmsgListener
//两个方法executeLocalTransaction和checkLocalTransaction
//事务消息发送后的回调方法。此时保证本地事务,调用Service扣减金额同时将消息改为COMMIT(可消费状态),如果捕获异常,将消息改为ROLLBACK回滚
//事务回查。查询是否在调用方已经处理,如果已经处理需修改消息为COMMIT可消费,否则就是UNKOWN状态。
e)bank2
=======
Service: AccountInfoServiceImpl
//更新账户bank2,增加金额。(通过事务id保证幂等性)
message: TxmsgConsumer
======================
//监听bank1发送的消息topic,调用Service增加金额
4,总结
====
可靠消息最终一致性就是 保证消息从生产方经过消息中间件传递到消费方 的一致性,本案例使用了RocketMQ作为消息中间件,RocketMQ主要解决了两个功能:
-
本地事务与消息发送的原子性问题。
-
事务参与方接收消息的可靠性。
可靠消息最终一致性事务适合 执行周期长且实时性要求不高的场景 。引入消息机制后,同步的事务操作变为基于消息执行的 异步 操作, 避免了分布式事务中的同步阻塞操作的影响,并实现了两个服务的 解耦 。
六、解决方案之最大努力通知
=============
源码: cloud-dtx-notify