> 科技资讯 > 分布式事务

分布式事务

科技资讯 投稿 6400℃ 0 评论

分布式事务

分布式事务

一、分布式事务基础

什么是事务？

本地事物

本地事物其实可以认为是数据库提供的事务机制。说到数据库事务就不得不说，数据库事务中的四

大特性:

  • C：一致性(Consistency，在一个事务执行之前和执行之后数据库都必须处于一致性状态

  • D：持久性(Durability，指的是只要事务成功结束，它对数据库所做的更新就必须永久的保存下来

分布式事务

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

分布式事务的场景

    单体系统访问多个数据库
    多个微服务访问同一个数据库
    多个微服务访问多个数据库

二、分布式事务解决方案

全局事务

    AP: Application 应用系统 (微服务

  • RM: Resource Manager 资源管理器 (数据库

整个事务分成两个阶段:

  • 阶段二: 执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地执行提交或者回滚。

优点

    提高了数据一致性的概率，实现成本较低

缺点

  • 同步阻塞: 延迟了提交时间，加⻓了资源阻塞时间

可靠消息服务

基于可靠消息服务的方案是通过消息中间件保证上、下游应用数据操作的一致性。假设有A和B两个系统，分别可以处理任务A和任务B。此时存在一个业务流程，需要将任务A和任务B在同一个事务中处理。就可以使用消息中间件来实现这种分布式事务。

RocketMQ事务消息流程图

1事务消息发送及提交

(2 服务端响应消息写入结果
(3 根据发送结果执行本地事务(如果写入失败,此时half消息对业务不可⻅，本地逻辑不执行
(4 根据本地事务状态执行Commit或者Rollback(Commit操作生产消息索引，消息对消费者可⻅
2 事务补偿
(1 对没有Commit/Rollback的事务消息(pending状态的消息,从服务端发起一次“回查”
(2 Producer收到回查消息，检查回查消息对于的本地事务的状态
(3 根据本地事务状态，重新Commit或者Rollback
其中，补偿阶段用户解决消息Commit或者Rollback发生超时或者失效的情况
3 事务消息状态
事务消息共有三种状态，提交状态，回查状态，中间状态:

    TransactionStatus.CommitTransaction: 提交事务，它允许消费者消费此消息
  • TransactionStatus.RollbackTransaction: 回滚事务，它代表消息将被删除，不允许被消费
  • TransactionStatus.Unknown: 中间状态，它代表需要消息队列来确认状态

消息生产者实现
发送代码如下:

Message<OperateIntergralVo> message =
MessageBuilder.withPayload(vo.setHeader("orderNo",orderNo.build(;
TransactionSendResult sendResult =
rocketMQTemplate.sendMessageInTransaction("tx_group", "tx_topic", message,
orderNo;
String sendStatus = sendResult.getSendStatus(.name(;
String localTXState = sendResult.getLocalTransactionState(.name(;
og.info(">>>> send status={},localTransactionState={}
<<<<",sendStatus,localTXState;
if(sendResult.getLocalTransactionState(.equals(LocalTransactionState.COMMIT_ME
SSAGE{
return "退款成功";
}else{
return "退款失败";
}

创建事务消息生产者端的消息监听器，注意是生产者，不是消费者，我们需要实现的是RocketMQLocalTransactionListener接口，代码如下：

@RocketMQTransactionListener(txProducerGroup = "tx_group"
@Slf4j
public class OrderTXMsgListener implements RocketMQLocalTransactionListener {
@Autowired
private IOrderInfoService orderInfoService;
@Override
public RocketMQLocalTransactionState executeLocalTransaction(Message msg,
Object arg {
log.info("执行本地事务";
RocketMQLocalTransactionState result =
RocketMQLocalTransactionState.COMMIT;
try {
String orderNo = (String arg;
orderInfoService.changeOrderStatusToRefund(orderNo;
} catch (Exception e {
result = RocketMQLocalTransactionState.ROLLBACK;
}
return result;
}
@Override
public RocketMQLocalTransactionState checkLocalTransaction(Message msg {
String orderNo = (String msg.getHeaders(.get("orderNo";
if(!StringUtils.isEmpty(orderNo{
OrderInfo orderInfo = orderInfoService.getOrderStatus(orderNo;
if(OrderInfo.STATUS_REFUND.equals(orderInfo.getStatus({
return RocketMQLocalTransactionState.COMMIT;
}
}

TCC事务

TCC即为Try Confifirm Cancel，它属于补偿型分布式事务。TCC实现分布式事务一共有三个步骤：

    Try：尝试待执行的业务
    这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的全部资源
  • Confifirm：确认执行业务
    确认执行业务操作，不做任何业务检查，只使用Try阶段预留的业务资源。通常情况下，采用TCC则认为 Confifirm阶段是不会出错的。即：只要Try成功，Confifirm一定成功。若Confifirm阶段真的出错了，需引入重试机制或人工处理。
  • Cancel：取消待执行的业务
    取消Try阶段预留的业务资源。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理。
return RocketMQLocalTransactionState.ROLLBACK;
}
}

TCC两阶段提交与XA两阶段提交的区别是：

  • TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。

TCC事务的优缺点：

  • 缺点 ：TCC的Try、Confifirm和Cancel操作功能需业务提供，开发成本高。

三、Seata分布式事务解决方案

Fescar （Fast & EaSy Commit And Rollback），其愿景是让分布式事务的使用像本地事务的使用一样，简单和高效，并逐步解决开发者们遇到的分布式事务方面的所有难题。后来更名为 Seata，意为：Simple Extensible Autonomous Transaction Architecture，是一套分布式事务解决方案。
Seata的设计目标是对业务无侵入，因此从业务无侵入的2PC方案着手，在传统2PC的基础上演进。
它把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分
支事务达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据
库的本地事务。

3.1 Seata-At模式

Seata主要由三个重要组件组成：

  • TM：Transaction Manager 事务管理器，用于开启、提交或者回滚全局事务。

Seata-AT模式的执行流程如下:

  1. A服务的RM向TC注册分支事务，并及其纳入XID对应全局事务的管辖

  3. B服务的RM向TC注册分支事务，并将其纳入XID对应的全局事务的管辖

  5. 全局事务调用链处理完毕，TM根据有无异常向TC发起全局事务的提交或者回滚

Seata-AT模式实现2PC与传统2PC的差别 ：

  1. 两阶段提交方面，传统2PC无论第二阶段的决议是commit还是rollback，事务性资源的锁都要保持到Phase2完成才释放。而Seata的做法是在Phase1 就将本地事务提交，这样就可以省去Phase持锁的时间，整体提高效率。

3.2 秒杀项目集成Seata

启动Seata-server

项目集成seata配置

详情请看 集成文档/seata客户端集成文档.md

AT模式代码实现

分支分布式事务贴上@Transactional即可

3.3 Seata-TCC深度解析

TCC模型图

模型设计

业务场景

2.账户退款,用户账户金额增加

表设计

CREATE TABLE `user_account` (
`user_id` varchar( 100  NOT NULL COMMENT '用户UID',
`gmt_create` datetime NOT NULL COMMENT '创建时间',
`gmt_modified` datetime NOT NULL COMMENT '修改时间',
`amount` bigint( 20  NOT NULL COMMENT '用户余额',
PRIMARY KEY (`user_id`,
KEY `idx_gmt_create` (`gmt_create`,
KEY `idx_gmt_modified` (`gmt_modified`
 ENGINE=InnoDB DEFAULT CHARSET=utf8;
扣钱业务逻辑

场景: 账户A上有 100 元，要扣除其中的 30 元

加钱业务逻辑
业务模型总结

并发控制

Try: 检查余额，扣除其中 30 元

业务模型优化

CREATE TABLE `user_account` (
`user_id` varchar( 100  NOT NULL COMMENT '用户UID',
`gmt_create` datetime NOT NULL COMMENT '创建时间',
`gmt_modified` datetime NOT NULL COMMENT '修改时间',
`amount` bigint( 20  NOT NULL COMMENT '用户余额',
`freezed_amount` bigint( 20  unsigned DEFAULT '0',
PRIMARY KEY (`user_id`,
KEY `idx_gmt_create` (`gmt_create`,
KEY `idx_gmt_modified` (`gmt_modified`
 ENGINE=InnoDB DEFAULT CHARSET=utf8;

扣钱为例: 账户上有 100 元，要扣除其中 30 元(此时里面的可用金额=amount-freezed_amount
Try: 检查余额,扣除其中 30 元(freezed_amount=freezed_amount+30

Try: 空操作

异常处理

空回滚

出现原因:

    Try超时
  1. 分布式事务回滚，触发Cancel
  2. 未收到Try,收到Cancel
CREATE TABLE `account_transaction` (
`tx_id` varchar( 100  NOT NULL COMMENT '事务Txid',
`action_id` varchar( 100  NOT NULL COMMENT '分支事务id',
`gmt_create` datetime NOT NULL COMMENT '创建时间',
`gmt_modified` datetime NOT NULL COMMENT '修改时间',
`user_id` varchar( 100  NOT NULL COMMENT '账户Uid',
`amount` varchar( 100  NOT NULL COMMENT '变动金额',
`type` varchar( 100  NOT NULL DEFAULT '' COMMENT '变动类型',
PRIMARY KEY (`tx_id`,`action_id`
 ENGINE=InnoDB DEFAULT CHARSET=utf8;
幂等

多次调用二阶段方法

出现原因:

  • 分支事务所在服务器宕机

CREATE TABLE `account_transaction` (
`tx_id` varchar( 100  NOT NULL COMMENT '事务Txid',
`action_id` varchar( 100  NOT NULL COMMENT '分支事务id',
`gmt_create` datetime NOT NULL COMMENT '创建时间',
`gmt_modified` datetime NOT NULL COMMENT '修改时间',
`user_id` varchar( 100  NOT NULL COMMENT '账户Uid',
`amount` varchar( 100  NOT NULL COMMENT '变动金额',
`type` varchar( 100  NOT NULL DEFAULT '' COMMENT '变动类型',
`state` smallint( 4  NOT NULL COMMENT '状态: 1.初始化 2.已提交 3.已回滚',
PRIMARY KEY (`tx_id`,`action_id`
 ENGINE=InnoDB DEFAULT CHARSET=utf8;
防悬挂

Cancel比Try先执行

出现原因:

    Try超时(拥堵
  1. 分布式事务回滚触发Cancel
  2. 拥堵的Try到达

解决方案: 在Try方法中, 如果根据全局事务ID能查询出数据出来,说明在try方法之前执行了空回滚，此时
就不能进行try方法。否则就正常执行try方法。

异常处理流程图

Try方法

Comfirm方法

Cancel方法

TCC模式代码实现

分支事务需要完成下面步骤:

@LocalTCC
public interface IUsableIntegralService {
/**
* 增加积分
*/
@TwoPhaseBusinessAction(name = "incrIntergralTry", commitMethod =
"incrIntergralCommit", rollbackMethod = "incrIntergralRollback"
void incrIntergralTry(@BusinessActionContextParameter(paramName =
"operateIntergralVo" OperateIntergralVo operateIntergralVo,
BusinessActionContext context;
void incrIntergralCommit(BusinessActionContext context;
void incrIntergralRollback(BusinessActionContext context;
}

2.添加实现类，实现try,confirm,cancel方法逻辑即可

编程笔记 » 分布式事务

赞同 (35) or 分享 (0)
游客 发表我的评论   换个身份
取消评论

表情
(0)个小伙伴在吐槽