事务具有四大特性:
在微服务项目中,每个服务都有其自己的数据库,当我们需要进行服务调用处理业务时,事务还能保证ACID原则吗?我们以一个分布式服务案例来验证这个问题:
案例:微服务下单业务,在下单时会调用订单服务,创建订单并写入数据库。然后订单服务调用账户服务和库存服务
Ⅰ.创建数据库heima,里面有三张表,分别对应三种服务要使用到的数据。
订单服务:
账户服务:
库存服务:
Ⅱ. 导入项目seata-demo
AccountServiceImpl
:
@Slf4j
@Service
public class AccountServiceImpl implements AccountService {
@Autowired
private AccountMapper accountMapper;
@Override
@Transactional
public void deduct(String userId, int money) {
log.info("开始扣款");
try {
accountMapper.deduct(userId, money);
} catch (Exception e) {
throw new RuntimeException("扣款失败,可能是余额不足!", e);
}
log.info("扣款成功");
}
}
AccountController
:
@RestController
@RequestMapping("account")
public class AccountController {
@Autowired
private AccountService accountService;
@PutMapping("/{userId}/{money}")
public ResponseEntity<Void> deduct(@PathVariable("userId") String userId, @PathVariable("money") Integer money){
accountService.deduct(userId, money);
return ResponseEntity.noContent().build();
}
}
② order-service(port:8082)
OrderServiceImpl
:
@Slf4j
@Service
public class OrderServiceImpl implements OrderService {
private final AccountClient accountClient;
private final StorageClient storageClient;
private final OrderMapper orderMapper;
public OrderServiceImpl(AccountClient accountClient, StorageClient storageClient, OrderMapper orderMapper) {
this.accountClient = accountClient;
this.storageClient = storageClient;
this.orderMapper = orderMapper;
}
@Override
@Transactional
public Long create(Order order) {
// 创建订单
orderMapper.insert(order);
try {
// 扣用户余额
accountClient.deduct(order.getUserId(), order.getMoney());
// 扣库存
storageClient.deduct(order.getCommodityCode(), order.getCount());
} catch (FeignException e) {
log.error("下单失败,原因:{}", e.contentUTF8(), e);
throw new RuntimeException(e.contentUTF8(), e);
}
return order.getId();
}
}
OrderController
:
@RestController
@RequestMapping("order")
public class OrderController {
private final OrderService orderService;
public OrderController(OrderService orderService) {
this.orderService = orderService;
}
@PostMapping
public ResponseEntity<Long> createOrder(Order order){
Long orderId = orderService.create(order);
return ResponseEntity.status(HttpStatus.CREATED).body(orderId);
}
}
③storage-service
StorageServiceImpl
:
@Slf4j
@Service
public class StorageServiceImpl implements StorageService {
@Autowired
private StorageMapper storageMapper;
@Transactional
@Override
public void deduct(String commodityCode, int count) {
log.info("开始扣减库存");
try {
storageMapper.deduct(commodityCode, count);
} catch (Exception e) {
throw new RuntimeException("扣减库存失败,可能是库存不足!", e);
}
log.info("扣减库存成功");
}
}
StorageController
:
@RestController
@RequestMapping("storage")
public class StorageController {
private final StorageService storageService;
public StorageController(StorageService storageService) {
this.storageService = storageService;
}
/**
* 扣减库存
* @param code 商品编号
* @param count 要扣减的数量
* @return 无
*/
@PutMapping("/{code}/{count}")
public ResponseEntity<Void> deduct(@PathVariable("code") String code,@PathVariable("count") Integer count){
storageService.deduct(code, count);
return ResponseEntity.noContent().build();
}
}
Ⅲ. 测试,发送Post请求
正常的业务我们是可以处理的。我们现在创建一个新的订单,购买10件商品(目前库存只有8件),看看事务是否能回滚。
这里500报错,我们查看数据库数据是否发生了改变:
可以看到,订单表并未添加新的数据且库存表中的库存仍然为8,但我们的账户表中的金额扣了!这显然是不对的。
在分布式系统下,一个业务跨越多个服务或数据源,每个服务都是一个分支事务,要保证所有分支事务最终状态一致,这样的事务就是分布式事务。
而在上例中,各分支事务各自提交各自的,当库存不足导致业务失败时,账户服务并未回滚,导致状态无法一致。那么如何解决分布式事务的问题呢?
加州大学的计算机科学家Eric Brewer于1998年提出,分布式系统有三个指标:
Eric Brewer说,分布式系统无法同时满足这三个指标。这个结论就叫做CAP定理。
Consistency(一致性):用户访问分布式系统中的任意节点,得到的数据必须一致。
Availability(可用性):用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝
Partition(分区):因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接,形成独立分区。
Tolerance(容错):在集群出现分区时,整个系统也要持续对外提供服务。
分布式系统节点通过网络连接,一定会出现分区问题,而分区出现时,系统的可用性和一致性就无法同时得到满足。
注:前面章节搭建的Elasticsearch集群采用的是高一致性且低可用性的CP方案
BASE理论是对CAP的一种解决思路,包含三个思想:
而分布式事务最大的问题就是各个子事务的一致性问题,因此可用借鉴CAP定理和BASE理论:
解决分布式事务,各个子系统之间必须能感知到彼此的事务状态,才能保证状态一致,因此需要一个事务协调者来协调每一个事务的参与者(子系统事务)。
这里的子系统事务,称为分支事务;有关联的各个分支事务在一起称为全局事务。
Seata事务管理中有三个重要的角色:
首先我们要下载seata-server包,地址在http://seata.io/zh-cn/blog/download.html。
下载好后解压到非中文目录。
修改conf下的registry.conf文件
registry {
# tc服务的注册中心类,这里选择nacos,也可以是eureka、zookeeper等
type = "nacos"
nacos {
# seata tc 服务注册到 nacos的服务名称,可以自定义
application = "seata-tc-server"
serverAddr = "127.0.0.1:8848"
group = "DEFAULT_GROUP"
namespace = ""
cluster = "SH"
username = "nacos"
password = "nacos"
}
}
config {
# 读取tc服务端的配置文件的方式,这里是从nacos配置中心读取,这样如果tc是集群,可以共享配置
type = "nacos"
# 配置nacos地址等信息
nacos {
serverAddr = "127.0.0.1:8848"
namespace = ""
group = "SEATA_GROUP"
username = "nacos"
password = "nacos"
dataId = "seataServer.properties"
}
}
在nacos中添加配置
让tc服务的集群可以共享配置,选择了nacos作为统一配置中心。因此服务端配置文件seataServer.properties文件需要在nacos中配好。
# 数据存储方式,db代表数据库
store.mode=db
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.cj.jdbc.Driver
store.db.url=jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true&rewriteBatchedStatements=true&serverTimezone=Asia/Shanghai
store.db.user=root
store.db.password=123456
store.db.minConn=5
store.db.maxConn=30
store.db.globalTable=global_table
store.db.branchTable=branch_table
store.db.queryLimit=100
store.db.lockTable=lock_table
store.db.maxWait=5000
# 事务、日志等配置
server.recovery.committingRetryPeriod=1000
server.recovery.asynCommittingRetryPeriod=1000
server.recovery.rollbackingRetryPeriod=1000
server.recovery.timeoutRetryPeriod=1000
server.maxCommitRetryTimeout=-1
server.maxRollbackRetryTimeout=-1
server.rollbackRetryTimeoutUnlockEnable=false
server.undo.logSaveDays=7
server.undo.logDeletePeriod=86400000
# 客户端与服务端传输方式
transport.serialization=seata
transport.compressor=none
# 关闭metrics功能,提高性能
metrics.enabled=false
metrics.registryType=compact
metrics.exporterList=prometheus
metrics.exporterPrometheusPort=9898
创建数据库表
创建数据库seata,配置如下:
SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;
-- ----------------------------
-- 分支事务表
-- ----------------------------
DROP TABLE IF EXISTS `branch_table`;
CREATE TABLE `branch_table` (
`branch_id` bigint(20) NOT NULL,
`xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`transaction_id` bigint(20) NULL DEFAULT NULL,
`resource_group_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`branch_type` varchar(8) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`status` tinyint(4) NULL DEFAULT NULL,
`client_id` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`gmt_create` datetime(6) NULL DEFAULT NULL,
`gmt_modified` datetime(6) NULL DEFAULT NULL,
PRIMARY KEY (`branch_id`) USING BTREE,
INDEX `idx_xid`(`xid`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
-- ----------------------------
-- 全局事务表
-- ----------------------------
DROP TABLE IF EXISTS `global_table`;
CREATE TABLE `global_table` (
`xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`transaction_id` bigint(20) NULL DEFAULT NULL,
`status` tinyint(4) NOT NULL,
`application_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`transaction_service_group` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`transaction_name` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`timeout` int(11) NULL DEFAULT NULL,
`begin_time` bigint(20) NULL DEFAULT NULL,
`application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`gmt_create` datetime NULL DEFAULT NULL,
`gmt_modified` datetime NULL DEFAULT NULL,
PRIMARY KEY (`xid`) USING BTREE,
INDEX `idx_gmt_modified_status`(`gmt_modified`, `status`) USING BTREE,
INDEX `idx_transaction_id`(`transaction_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
SET FOREIGN_KEY_CHECKS = 1;
启动tc服务
进入到seata文件夹下的bin目录,运行seata-server.bat即可。
启动成功后,就可以在nacos的服务列表中看到了:
步骤一:引入Seata相关的依赖
<dependency>
<groupId>com.alibaba.cloudgroupId>
<artifactId>spring-cloud-starter-alibaba-seataartifactId>
<exclusions>
<exclusion>
<artifactId>seata-spring-boot-starterartifactId>
<groupId>io.seatagroupId>
exclusion>
exclusions>
dependency>
<dependency>
<groupId>io.seatagroupId>
<artifactId>seata-spring-boot-starterartifactId>
<version>${seata.version}version>
dependency>
步骤二:配置application.yml,让微服务通过注册中心找到seata-tc-server
seata:
registry: # TC服务注册中心的配置,微服务根据这些信息去注册中心获取tc服务地址
# 参考tc服务自己的registry.conf中的配置
type: nacos
nacos: # tc
server-addr: 127.0.0.1:8848
namespace: ""
group: DEFAULT_GROUP
application: seata-tc-server # tc服务在nacos中的服务名称
username: nacos
password: nacos
tx-service-group: seata-demo # 事务组,根据这个获取tc服务的cluster名称
service:
vgroup-mapping: # 事务组与TC服务cluster的映射关系
seata-demo: LZ
在案例中的三个服务上都集成Seata,并重启服务。
XA模式原理
XA规范是X/Open组织定义的分布式事务处理(DTP,Distributed Transaction Processing)标准,XA规范描述了全局的TM与局部的RM之间的接口,几乎所有主流的数据库都对XA规范提供了支持。
Seata的XA模式
seata的XA模式做了一些调整,但大体相似:
RM一阶段的工作
TC二阶段的工作:
RM二阶段的工作:
XA模式的优缺点
优点:
缺点:
实现XA模式
Seata的starter已经完成了XA模式的自动装配,步骤如下:
Ⅰ.修改application.yml(每个参与事务的微服务),开启XA模式
seata:
data-source-proxy-mode: XA
Ⅱ. 给发起全局事务的入口方法添加@GlobalTransaction注解,此处是order-service中的OrderServiceImpl类的create方法。
@Override
@GlobalTransactional
public Long create(Order order) {
// 创建订单
orderMapper.insert(order);
try {
// 扣用户余额
accountClient.deduct(order.getUserId(), order.getMoney());
// 扣库存
storageClient.deduct(order.getCommodityCode(), order.getCount());
} catch (FeignException e) {
log.error("下单失败,原因:{}", e.contentUTF8(), e);
throw new RuntimeException(e.contentUTF8(), e);
}
return order.getId();
}
Ⅲ.重启服务并测试
注:这里使用jdbc驱动8.0.28版本500报错,换为8.0.11且加入时区后成功执行。
AT模式同样是分阶段提交的事务模型,不过弥补了XA模型中资源锁定周期过长的缺陷。
阶段一RM的工作:
记录undo-log(数据快照)
提交
阶段二提交时RM的工作:
阶段二回滚时RM的工作:
例如,一个分支业务的SQL是update tb_account set money = money - 10 where id = 1
AT模式的脏写问题
当事务1获取DB锁后,执行完业务sql并提交后,释放了DB锁。(此时money为90)
此时事务2获取DB锁,执行完业务sql并提交后,释放了DB锁。(此时money为80)
此时事务1获取了DB锁,在阶段2时根据快照恢复数据,将money恢复至100,数据就出现了问题。
针对这个问题,AT模式采用了全局锁的方式来解决。
AT模式的写隔离
全局锁由TC记录当前正在操作的某行数据的事务,此时只有该事务持有全局锁,其他事务不能对这行数据进行写操作。
当事务1获取DB锁,保存快照,执行业务sql后尝试获取全局锁,此时TC记录了这条数据由事务1具备执行权。紧接着提交事务,释放DB锁。(money值为90)
当事务2获取DB锁,保存快照,执行业务sql后尝试获取全局锁,由于TC已记录了事务1具备该数据的执行权,因此拒绝给事务2全局锁。为了事务2一直获取全局锁而导致死锁,加入了重试机制,默认30次,间隔10ms。当超时后回滚数据并释放DB锁。
紧接着事务1获取DB锁,根据快照恢复数据后释放全局锁。数据也正确的进行了回滚。
特殊情况:另一个事务不集成seata对数据进行修改
在这种情况下,保存两个快照,一个是修改前的快照,一个是修改后的快照。
当要进行回滚时会对当前数据的状态和修改后的快照的数据状态进行比对,若一致则回滚到修改前的快照;若不一致则记录异常,发送警告进行人工介入。
总结:AT模式的优缺点
优点:
缺点:
实现AT模式
Ⅰ.创建两张表,lock_table导入到TC服务关联的数据库,undo_log表导入到微服务关联的数据库。
lock_table
:
DROP TABLE IF EXISTS `lock_table`;
CREATE TABLE `lock_table` (
`row_key` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`xid` varchar(96) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`transaction_id` bigint(20) NULL DEFAULT NULL,
`branch_id` bigint(20) NOT NULL,
`resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`table_name` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`pk` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`gmt_create` datetime NULL DEFAULT NULL,
`gmt_modified` datetime NULL DEFAULT NULL,
PRIMARY KEY (`row_key`) USING BTREE,
INDEX `idx_branch_id`(`branch_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
undo_log
:
DROP TABLE IF EXISTS `undo_log`;
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;
Ⅱ.修改yml文件,将事务模式修改为AT即可
seata:
data-source-proxy-mode: AT
Ⅲ.重启服务并测试
TCC模式与AT模式非常相似,每个阶段都是独立的事务,不同的是TCC通过人工编码来实现数据恢复,需要实现三个方法:
TCC模式原理
TCC的优越点
优点:
缺点:
案例:改造account-service服务,利用TCC实现分布式事务
需求如下:
TCC的空回滚和业务悬挂
:
当某分支事务的try阶段阻塞时,可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作。此时cancel不能做回滚,这就是空回滚
。
对于已经空回滚的业务,如果以后继续执行try,就永远不可能confirm或cancel,这就是业务悬挂
。应当阻止执行空回滚后的try操作,避免悬挂。
DROP TABLE IF EXISTS `account_freeze_tbl`;
CREATE TABLE `account_freeze_tbl` (
`xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`user_id` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`freeze_money` int(11) UNSIGNED NULL DEFAULT 0,
`state` int(1) NULL DEFAULT NULL COMMENT '事务状态,0:try,1:confirm,2:cancel',
PRIMARY KEY (`xid`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = COMPACT;
声明TCC接口
TCC的Try、Confirm、Cancel方法都需要在接口中基于注解声明,语法如下:
@LocalTCC
public interface AccountTCCService {
/**
* Try逻辑,@TwoPhaseBusinessAction中的name属性名要与当前方法名一致,用于指定try逻辑对应的方法
*/
@TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")
void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
@BusinessActionContextParameter(paramName = "money") int money);
/**
* 二阶段confirm确认方法,可以另命名,但要保证与commitMethod一致
* @param ctx 上下文,可以传递try方法的参数
* @return 执行是否成功
*/
boolean confirm(BusinessActionContext ctx);
/**
* 二阶段回滚方法,要保证与rollbackMethod一致
* @param ctx
* @return
*/
boolean cancel(BusinessActionContext ctx);
}
SAGA模式是Seata提供的长事务解决方案,分为两个阶段:
SAGA模式优点:
缺点:
比较适用于跨银行转账的长事务等。