用分布式事务中间件来保障金融级交易系统的一致性

转载自： https://yq.aliyun.com/articles/292817

摘要： 在本章节中会介绍如何通过引入蚂蚁中间件的分布式事务产品来保证金融级交易系统的一致性问题，并且会分别介绍分布式事务的两种模式：TCC模式和自动模式的使用方式。

背景介绍

本篇是北京云栖大会Tech Insight Workshop金融云主题《使用SOFA来快速构建金融级分布式交易系统》中的一个组成部分.

通过前面的篇章，我们已经借助SOFA Boot框架构建了基于微服务架构的分布式交易系统框架，以及借助数据访问代理将系统的订单库由单库单表模式改造为分库分表，便于支撑平台日益增长的数据量。

在本章节中会介绍如何通过引入蚂蚁中间件的分布式事务产品来保证金融级交易系统的一致性问题，并且会分别介绍分布式事务的两种模式：TCC模式和自动模式的使用方式。

DEMO整体架构与说明

image

实验涉及SOFA产品

分布式事务
环境准备

通过之前步骤的操作，目前分布式交易系统DEMO已经具备了交易与支付两个微服务
在这里我们依然需要基于SOFA Boot框架构建一个Core工程（facade范式）：【账务】服务，该服务将用于处理消费者和商家之前的转账操作。（具体实现代码会在审核后放出）
基于事务的视角，【支付】服务发起转账（事务）请求，【账户】服务处理实际的转账（事务）操作，那么【支付】服务在这里被视为事务的发起者，而【账户】服务被视为事务的参与者。
分布式事务被简称为DTX（Distribution Transaction）
详细步骤

基于TCC模式的代码改造

为【参与者】代码工程增加分布式事务的依赖包
image
image
image

基于facade范式构建的工程，在service模块XML文件中配置分布式事务扫描器
image
在facade中设计并参与者的从属业务（AccountTransMinus & AccountTransAdd）需要提供的TCC接口
image
在service中实现参与者的从属业务接口
image
实现了接口后就可以提供RPC服务进行发布了（生产者）
image
将会基于共享版中间件进行发布，配置相关云上共享版的账户，截止当前步骤TCC模式下的参与者代码修改已经完成
image
为【发起方】（【支付】服务）代码工程增加分布式事务的依赖包
image
image

为【支付】服务引入【账务】服务的RPC调用的依赖，以及引入对应的bean
image
image
image

模块XML文件中引入DTX扫描器
image
改造【支付】服务，开启分布式事务，调用【账务】服务的两个从属业务接口
image
至此，基于TCC模式下的分布式事务改造就完成了（当然，需要配置对应的账务数据库，相关的DDL语句与DAL代码请在DEMO源码开放出后进行参照）。
基于自动模式的代码改造

可以看到，基于TCC的分布式事务改造虽然并不复杂，但是毕竟需要对已有的业务实现进行改造。自动模式的诞生就是为了解决这个问题，它的出现很大程度上可以通过不修改已有的业务代码就可以实现事务一致性的保障。

为【参与者】工程引入分布式事务的依赖包
image
image
image

配置分布式事务的扫描器
image
通过原始业务代码中增加注解，来表示这里的业务逻辑包含事务，需要保障一致性
image
修改数据源配置
image
因为自动模式需要在参与者所使用的数据源中记录事务信息，所以需要手动在对应的业务数据库中创建两张表
CREATE TABLE dtx_row_lock (
action_id varchar(128) NOT NULL COMMENT ‘分支事务号’,
tx_id varchar(128) NOT NULL COMMENT ‘主事务号’,
table_name varchar(64) DEFAULT NULL COMMENT ‘表名称’,
row_key varchar(512) NOT NULL COMMENT ‘行唯一key’,
instance_id varchar(32) NOT NULL COMMENT ‘实例id’,
context varchar(2000) DEFAULT NULL COMMENT ‘分支上下文’,
feature varchar(2000) DEFAULT NULL COMMENT ‘扩展属性’,
gmt_create datetime NOT NULL COMMENT ‘创建时间’,
gmt_modified datetime NOT NULL COMMENT ‘修改时间’,
PRIMARY KEY (row_key,instance_id),
KEY idx_txid_action_id (action_id,tx_id,instance_id)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT=’行锁’;
CREATE TABLE dtx_branch_info (
action_id varchar(128) NOT NULL COMMENT ‘分支事务号’,
tx_id varchar(128) NOT NULL COMMENT ‘主事务号’,
status varchar(4) DEFAULT NULL COMMENT ‘事务状态’,
log_info blob COMMENT ‘undo/redo log’,
biz_type varchar(32) DEFAULT NULL COMMENT ‘发起方业务类型’,
instance_id varchar(32) DEFAULT NULL COMMENT ‘实例id’,
context varchar(2000) DEFAULT NULL COMMENT ‘分支上下文’,
feature varchar(2000) DEFAULT NULL COMMENT ‘扩展属性’,
gmt_create datetime NOT NULL COMMENT ‘创建时间’,
gmt_modified datetime NOT NULL COMMENT ‘修改时间’,
PRIMARY KEY (action_id),
KEY idx_txid_action_id (action_id,tx_id,instance_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=’分支记录日志’;
至此，自动模式下参与者的修改就完成了
进行对发起方的修改，首先是添加依赖包
image
image
image
image

增加分布式事务的扫描器
image
增加注释，以表明这里包含事务
image
修改数据源
image
至此，基于自动模式的【发起方】的代码改造也已完成。相关的DEMO源码需要在审核后对外进行发布。
结论

至此，基于SOFA这个可扩展的分布式云平台所构建的金融交易系统就创建完毕了，整个DEMO分别涉及到分布式数据库，微服务框架，分布式事务等构建金融相关应用所需的基本服务框架，整体的构建过程也比较清晰明了，便于用户的快速入手。在最后环节的分布式事务演示中可以看到，基于自动模式的分布式事务对业务的改造量非常的小，基本可以说是没有侵入性，非常适合需要低成本快速接入分布式事务来保证业务的一致性，同时对TPS以及并发要求不高的业务场景使用。
版权声明：本文内容由互联网用户自发贡献，版权归作者所有，本社区不拥有所有权，也不承担相关法律责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至：[email protected] 进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。

用云栖社区APP，舒服~
【云栖快讯】直播推荐——现在报名3月12日编程语言系列讲座，与行业资深专家一起学习Python、C++、JavaScript、Java！还可在活动页面领取红包，百分百中奖哦！ 详情请点击