分布式事务

最新推荐文章于 2024-08-07 23:13:01 发布

xiha_zhu

最新推荐文章于 2024-08-07 23:13:01 发布

阅读量100

点赞数 1

分类专栏： java 文章标签： spring

本文链接：https://blog.csdn.net/xiha_zhu/article/details/117021996

版权

java 专栏收录该内容

69 篇文章 1 订阅

订阅专栏

CAP理论

CAP理论又叫布鲁尔定理，是Consistency, Availability, Partition Tolerance三个单词的缩写。CAP理论是分布式系统的理论基础。

CAP理论是指在分布式系统中，一致性、可用性、分区容错性三个要素不能同时满足。

当前一般是通过最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。

传统SQL数据库事务是满足ACID的强事务机制，NoSQL系统注重性能和扩展性，而非事务机制，仅提供对行级别的原子性保证，也就是说同时对同一个key下的数据进行的两个操作，在实际执行的时候会串行的执行，保证了每一个key-value对不会被破坏。

BASE

BASE是Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致性）三个短语的缩写。

BASE是对CAP中一致性和可用性权衡的结果，其核心思想是即使无法做到强一致性，可以通过牺牲部分可用性、允许系统中数据存在中间状态，但该中间状态并不会影响系统的整体可用，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时，从而保证最终数据能达到一致，而不需要实时保证数据的强一致性。

分布式系统中一次操作由多个系统协同完成，这种一次事务操作涉及多个系统通过网络协同完成的过程称为分布式事务。

分布式事务的解决方案

基于XA的两阶段提交（Two-phase Commit, 2PC)
XA包含两部分：事务管理器（协调者）和本地资源管理器（参与者）。其中本地资源管理器通过数据库来实现，而事务管理器作为全局的协调者，负责各个本地资源的提交。
2PC通过引入协调者(Coordinator），来协调参与者的行为，并最终决定这些参与者是否要把事务提交。
第一阶段事务管理器要求每个涉及到事务的数据库预提交此操作，并返回是否可以提交；第二阶段事务协调器要求每个数据提交数据或者回滚数据。
XA协议存在单点问题(协调者)以及不能支持高并发(同步阻塞)
补偿事务(TCC）
TCC是基于2PC实现的业务层事务控制方案，它针对每个操作，都注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段
try阶段：对业务系统做检测及资源预留
confirm阶段：对业务系统做确认提交
cancel阶段：业务执行错误需要回滚的状态下执行业务取消，预留资源释放
TCC的实现方式没有XA协议那样把分布的资源同一管理，提高了整体的吞吐量。但TCC对于应用的侵入性非常强，业务逻辑的每个分支都需要实现try、confirm和cancel三个操作，而且confirm和cancel接口还需考虑幂等性的问题，因为confirm和cancel又可能被多次调用。
本地消息表（异步确保）消息表+MQ
该方案通过在消费者额外新建事务消息表，消费者处理业务和记录事务消息在本地事务中完成，轮询事务消息表的数据发送事务消息，提供者基于消息中间件消费事务消息表中的事务。
系统A在执行业务同时会往消息表中存放一条数据，发送MQ调用关联系统下一步操作，如果这一系列操作都成功完成，更新系统A消息表中消息状态；如果不成功，则A系统会定时扫描自己消息表，处理未处理的数据。
本地消息表依赖数据库的消息表来管理分布式事务，在高并发的情况下难以进行扩展，且实现繁琐。
MQ消息事务
RocketMQ支持消息事务。
消费者首先向MQ发送half消息。MQ将消息持久化后，向发送发ack确认消息发送成功。消费者开始执行事务逻辑。消费者根据本地事务执行结果向MQ提交二次确认或者回滚。MQ接收到commit状态则将half消息标记为可投递状态。最后服务提供者收到该消息，执行本地业务逻辑，返回处理结果。
消息数据独立存储，降低业务系统与消息系统之间的耦合。吞吐量优于本地消息表方案。
分布式事务中间件
分布式事务中间件本身并不创建事务，而是基于对本地事务的协调从而达到事务一致性的效果。如LCN分布式事务框架
LCN：锁定事务Lock、确认事务模块状态Confirm、通知事务Notify

LCN核心执行步骤：

创建事务组：在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务标示GroupId
添加事务组：参与方在执行完业务方法后，将该模块的事务信息通知给TxManager
关闭事务组：发起方执行完业务代码以后，将发起方执行结果状态通知给TxManager。

LCN是通过一个独立的微服务tx-manager作为分布式事务控制服务端（事务协调器）。需要执行分布式事务控制的微服务应用都通过远程服务调用的方式，在tx-manager上标记事务组，在执行事务处理后，将本地事务状态发送到tx-manager中对应的事务组上，tx-manager会根据具体的状态来通知相应的微服务应用提交或回滚。

# 定义事务协调器所在位置。根据具体环境定义其中的IP地址和端口。
tm.manager.url=http://127.0.0.1:8899/tx/manager/

// A服务调用B服务
// A服务代码
@Transactional
@TxTransaction(isStart=true)
public void methodA() {
    //本地调用
    daoA.save();
    //远程调用方
    serviceB.methodB();
}

// B服务代码
@Transactional
@TxTransaction
public void methodB() {
    //本地调用
    daoB.save();
}

幂等操作：重复调用多次产生的业务结果都相同。一是通过业务操作实现幂等性，二是系统缓存所有请求与处理结果，最后是检测到重复请求之后，自动返回之前的处理结果。