一个自己的网站,响应式网页源码,成都市建设工程质量协会网站,抖音网站怎么做分布式事务 Seata 事务介绍分布式理论Seata 介绍Seata 部署与集成Seata TC Server 部署微服务集成 Seata XA 模式AT 模式AT 模式执行过程读写隔离写隔离读隔离 实现 AT 模式 TCC 模式TCC 模式介绍实现 TCC 模式 Saga 模式Seata 四种模式对比 事务介绍
事务#xff08;Transac… 分布式事务 Seata 事务介绍分布式理论Seata 介绍Seata 部署与集成Seata TC Server 部署微服务集成 Seata XA 模式AT 模式AT 模式执行过程读写隔离写隔离读隔离 实现 AT 模式 TCC 模式TCC 模式介绍实现 TCC 模式 Saga 模式Seata 四种模式对比 事务介绍
事务Transaction是计算机科学中的一个重要概念主要是指一个完整的、不可分割的操作序列。在关系型数据库中事务通常用于描述对数据库进行的一系列操作的执行单元。
事务的ACID特性
原子性Atomicity事务是一个原子操作要么全部执行要么全部回滚。如果事务中的任何一步操作失败那么整个事务都必须被回滚以保证数据库的一致性。一致性Consistency事务执行的结果必须使数据库从一个一致性状态变为另一个一致性状态。这意味着在事务执行期间数据库中的数据必须遵循所有的约束、规则和触发器等。隔离性Isolation多个事务同时执行时应该相互隔离即每个事务都应该独立地执行不应该受到其他事务的干扰。持久性Durability当一个事务成功提交后其结果应该永久地保存在数据库中即使发生系统故障或断电等异常情况也不会丢失。
根据不同的隔离级别事务可以分为多种类型。常见的隔离级别包括
读未提交Read Uncommitted一个事务可以读取另一个事务尚未提交的数据容易出现脏读、不可重复读和幻读等问题。读已提交Read Committed一个事务只能读取另一个事务已经提交的数据可以避免脏读问题但可能导致不可重复读和幻读等问题。可重复读Repeatable Read一个事务在执行期间所读取的数据应该保持不变即不能读取其他事务已经提交的新数据可以避免不可重复读问题但可能导致幻读问题。序列化Serializable一个事务完全串行化执行即所有并发的事务都按照一定的顺序执行可以避免所有并发问题但可能导致性能较低。
分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
分布式事务的产生是由于分库分表服务的拆分等产生的一个业务逻辑要操纵不同节点的多个数据库。
分布式理论
CAP定理 CAP理论是指在分布式系统中当出现网络故障或节点故障时系统无法同时满足以下三个特性
一致性Consistency所有节点上的数据必须保持一致性即在一个事务执行完毕后所有节点的数据都必须更新为最新的值。可用性Availability系统的响应时间必须满足用户的需求即使在部分节点出现故障的情况下系统仍然能够响应用户的请求。分区容错性Partition Tolerance当节点之间的通信出现故障时系统必须能够继续运行并且保证数据的一致性和可用性。
根据CAP理论当分布式系统出现网络故障或节点故障时分区容错性系统只能同时满足两个特性要么满足可用性舍弃一致性要么满足一致性放弃可用性。因此在设计分布式系统时需要根据具体的应用场景和需求来选择适当的特性进行权衡和取舍。 BASE理论 BASE理论也是分布式事务理论的一个重要理论。BASE理论是指在一个分布式系统中当出现网络故障或节点故障时系统应该满足以下三个特性
基本可用Basically Available系统必须保证基本的可用性即在出现故障时系统仍然能够提供有限的服务。软状态Soft State系统应该允许状态在一定时间内发生变化而不是强制要求保持一致性。最终一致性Eventually Consistency系统应该最终达到一致性状态即所有节点的数据最终都应该保持一致。
与CAP理论不同的是BASE理论强调了系统的可用性和软状态的重要性并允许系统在一定时间内存在不一致性的情况。这种理论更加适合于处理大规模的、高可用的分布式系统。
解决分布式事务各个分支事务必须能感知到彼此的事务状态才能保证状态一致因此需要一个事务协调者来协调每一个分支事务。有关联的各个分支事务在一起称为全局事务。
分布式事务最大的问题是各个子事务的一致性问题因此可以借鉴CAP定理和BASE理论
AP模式各子事务分别执行和提交允许出现结果不一致然后采用弥补措恢复数据即可实现最终一致。CP模式各个子事务执行后互相等待同时提交同时回滚达成强一致。但事务等待过程中处于弱可用状态。
最终一致思想各分支事务分别执行并提交如果有不一致的情况再想办法恢复数据 强一致思想各分支事务执行完业务不要提交等待彼此结果。而后统一提交或回滚
Seata 介绍
Seata 是一款开源的分布式事务解决方案致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式为用户打造一站式的分布式解决方案。 Seata官网其中的文档、播客中提供了大量的使用说明、源码分析。
Seata 提供了四种不同的分布式事务解决方案
XA模式强一致性分阶段事务模式牺牲了一定的可用性无业务侵入TCC模式最终一致的分阶段事务模式有业务侵入AT模式最终一致的分阶段事务模式无业务侵入也是Seata的默认模式SAGA模式长事务模式有业务侵入
Seata术语 在Seata的架构中一共有三个角色
TC (Transaction Coordinator) - 事务协调者维护全局和分支事务的状态驱动全局事务提交或回滚。TM (Transaction Manager) - 事务管理器定义全局事务的范围开始全局事务、提交或回滚全局事务。RM (Resource Manager) - 资源管理器管理分支事务处理的资源与TC交谈以注册分支事务和报告分支事务的状态并驱动分支事务提交或回滚。 在Seata中一个分布式事务的生命周期如下
TM 向 TC 申请开启一个全局事务全局事务创建成功后TC 会针对这个全局事务生成一个全局唯一的 XID此时由TM发起的全局事务已经开启XID 通过服务的调用链传递到其他服务RM 向 TC 注册一个分支事务并将其纳入 XID 对应全局事务的管辖事务参与者执行本地事务此时分支事务已经执行完成并反馈给TC执行结果。可以理解为AT模式下的第一个阶段TM 根据 TC 收集的各个分支事务的执行结果向 TC 发起全局事务提交或回滚决议事务协调者根据事务管理者的决议发送提交或回滚的调度命令可以理解为AT模式下的第二阶段TC 调度 XID 下管辖的所有分支事务完成提交或回滚操作
Seata 部署与集成
Seata TC Server下载地址 解压完成目录如下
Seata TC Server 部署
修改conf 目录下的 registry.conf 文件设置注册中心和配置中心 registry.conf
registry {# 注册中心 file 、nacos 、eureka、redis、zk、consul、etcd3、sofatype nacosnacos {application seata-serverserverAddr 127.0.0.1:8848group DEFAULT_GROUPnamespace cluster defaultusername nacospassword nacos}
}config {#配置中心 file、nacos 、apollo、zk、consul、etcd3type nacosnacos {serverAddr 127.0.0.1:8848namespace group SEATA_GROUPusername nacospassword nacosdataId seataServer.properties}
}启动 nacos在配置中心新建配置文件。dataId 与 Group 要和 registry.conf 中的名称一致。 seataServer.properties 内容 其中的数据库地址、用户名、密码都需要修改成你自己的数据库信息。
# 数据存储方式db代表数据库
store.modedb
store.db.datasourcedruid
store.db.dbTypemysql
store.db.driverClassNamecom.mysql.jdbc.Driver
store.db.urljdbc:mysql://127.0.0.1:3306/seata?useUnicodetruerewriteBatchedStatementstrue
store.db.userroot
store.db.password123456
store.db.minConn5
store.db.maxConn30
store.db.globalTableglobal_table
store.db.branchTablebranch_table
store.db.queryLimit100
store.db.lockTablelock_table
store.db.maxWait5000
# 事务、日志等配置
server.recovery.committingRetryPeriod1000
server.recovery.asynCommittingRetryPeriod1000
server.recovery.rollbackingRetryPeriod1000
server.recovery.timeoutRetryPeriod1000
server.maxCommitRetryTimeout-1
server.maxRollbackRetryTimeout-1
server.rollbackRetryTimeoutUnlockEnablefalse
server.undo.logSaveDays7
server.undo.logDeletePeriod86400000
# 客户端与服务端传输方式
transport.serializationseata
transport.compressornone
# 关闭metrics功能提高性能
metrics.enabledfalse
metrics.registryTypecompact
metrics.exporterListprometheus
metrics.exporterPrometheusPort9898创建数据库表 TC 服务在管理分布式事务时需要记录事务相关数据到数据库中需要提前创建好这些表。
SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS 0;-- ----------------------------
-- Table structure for branch_table
-- ----------------------------
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;-- ----------------------------
-- Records of branch_table
-- ------------------------------ ----------------------------
-- Table structure for global_table
-- ----------------------------
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;-- ----------------------------
-- Records of global_table
-- ------------------------------ ----------------------------
-- Records of lock_table
-- ----------------------------SET FOREIGN_KEY_CHECKS 1;点击 运行 Seata TC Server 在 nacos 中服务列表可以看到 Seata TC Server 服务已经成功注册
微服务集成 Seata
在微服务中引入 Seata 相关依赖需要使用 Seata 的每一个微服务都要进行配置。
dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-seata/artifactIdexclusions!--版本较低1.3.0因此排除--exclusionartifactIdseata-spring-boot-starter/artifactIdgroupIdio.seata/groupId/exclusion/exclusions
/dependency
dependencygroupIdio.seata/groupIdartifactIdseata-spring-boot-starter/artifactIdversion1.4.2/version
/dependency配置 application.yml让微服务通过注册中心找到 seata-tc-server。
seata:# TC服务注册中心的配置微服务根据这些信息去注册中心获取tc服务地址# 参考tc服务自己的registry.conf中的配置registry:type: nacosnacos:# 地址、namespace、group、application-name、clusterserver-addr: 127.0.0.1:8848namespace: # 默认值为 publicgroup: DEFAULT_GROUPapplication: seata-serverusername: nacospassword: nacostx-service-group: seata-demo # 事务组名称service:vgroup-mapping: # 事务组与cluster的映射关系seata-demo: defaultXA 模式
SEATA 的 XA 模式是一种基于 XA 协议的事务处理模式。XA 协议是一种由 X/Open 和 ISO 定义的分布式事务协议它规定了事务管理器Transaction ManagerTM和资源管理器Resource ManagerRM之间的交互方式。
在 SEATA 的 XA 模式下事务管理器会将事务划分为两个阶段事务开始Begin Phase和 事务提交Commit Phase。 在事务开始阶段事务管理器会锁定所有需要操作的资源并在资源管理器中注册事务。 在事务提交阶段事务管理器会通知所有资源管理器共同提交事务。
第一阶段执行各个分支事务执行成功在第二阶段所有分支事务进行提交。 在第一阶段如果有分支事务执行失败则第二阶段所有分支事务回滚。 XA 模式执行过程 RM 一阶段工作
注册分支事务到 TC执行分支业务 sql但不提交报告事务状态到 TC
TC 二阶段工作
TC检测各分支事务执行状态如果都成功通知所有 RM 提交事务如果有失败通知所有 RM 回滚事务
RM 二阶段工作
接收TC指令提交或回滚事务 XA 模式的优点
事务的一致性强由于 XA 协议的规定所有资源管理器都会在事务提交前保证事务的一致性。支持多种数据库由于 XA 协议是一种标准协议因此可以使用多种不同的资源管理器来实现事务管理。实现简单SEATA 的 XA 模式可以使用简单的 XML 配置来实现无需编写大量的代码。无代码侵入使用 SEATA 的 XA 模式可以最小化代码侵入只需在应用程序中添加少量的 SEATA 依赖项。
XA 模式的缺点
性能较差由于在事务开始阶段需要锁定所有资源因此可能会影响性能。依赖关系型数据库实现回滚如果某些资源管理器无法回滚事务那么整个事务可能会失败。
XA 模式的实现 Seata 的 starter 已经完成了 XA 模式的自动装配实现非常简单步骤如下
1.修改application.yml文件每个参与事务的微服务开启 XA模式
seata:data-source-proxy-mode: XA # 开启数据源代理的XA模式2.给发起全局事务的入口方法添加 GlobalTransactional 注解
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();
}3.重启服务测试 当库存不足时扣除的余额会回滚。
AT 模式
AT 模式执行过程
AT模式同样是分阶段提交的事务模型不过缺弥补了XA模型中资源锁定周期过长的缺陷。
在AT模式下用户只需关注自己的业务SQLSEATA框架会自动生成事务的二阶段提交和回滚操作。 在一阶段SEATA会拦截业务SQL首先解析SQL语义找到业务SQL要更新的业务数据在更新前后保存数据快照以便在二阶段回滚时使用。 在回滚阶段SEATA需要回滚一阶段已经执行的业务SQL还原业务数据。
AT模式执行过程 RM 一阶段的工作
注册分支事务到 TC记录 undo-log数据快照执行业务sql并提交报告事务状态到 TC
TC 二阶段的工作
TC检测各分支事务执行状态如果都成功通知所有 RM 提交事务如果有失败通知所有 RM 回滚事务
RM二阶段的工作
如果提交则删除 undo-log数据快照如果回滚则根据 undo-log数据快照恢复数据到更新前 AT模式与XA模式最大的区别
XA模式一阶段不提交事务锁定资源AT模式一阶段直接提交事务不锁定资源XA模式依赖数据库机制实现回滚AT模式利用数据快照实现数据回滚XA模式强一致AT模式最终一致。
AT模式的优点
一阶段完成直接提交事务释放数据库资源性能比较好利用全局锁实现读写隔离没有代码侵入框架自动完成回滚和提交
AT模式的缺点
两阶段之间属于软状态属于最终一致框架的快照功能会影响性能但比XA模式要好很多
读写隔离
脏写问题指的是在并发控制中多个事务同时更新同一行数据其中一个事务在更新数据后还没有提交或回滚之前另一个事务又对该行数据进行更新导致之前的数据被覆盖或更改从而导致数据的不一致。
事务1在一阶段提交后释放了DB锁事务2 在事务1后获得了DB锁对数据进行了更改并提交释放了DB锁。事务1 在二阶段根据数据快照进行回滚将事务2 的修改进行了覆盖。 写隔离
全局锁由 TC 记录当前正在操作某行数据的事务该事务持有全局锁具备执行权。
全局锁解决脏写问题
一阶段本地事务提交前需要确保先拿到 全局锁 。拿不到全局锁 不能提交本地事务。拿全局锁的尝试被限制在一定范围内超出范围将放弃并回滚本地事务释放本地锁。
示例 两个全局事务 tx1 和 tx2分别对 a 表的 m 字段进行更新操作m 的初始值 1000。
tx1 先开始开启本地事务拿到本地锁更新操作 m 1000 - 100 900。本地事务提交前先拿到该记录的全局锁 本地提交释放本地锁。 tx2 后开始开启本地事务拿到本地锁更新操作 m 900 - 100 800。本地事务提交前尝试拿该记录的全局锁tx1 全局提交前该记录的全局锁被 tx1 持有tx2 需要重试等待全局锁 。
tx1 二阶段全局提交释放全局锁 。tx2 拿到全局锁提交本地事务。 如果 tx1 的二阶段全局回滚则 tx1 需要重新获取该数据的本地锁进行反向补偿的更新操作实现分支的回滚。 此时如果 tx2 仍在等待该数据的全局锁同时持有本地锁则 tx1 的分支回滚会失败。分支的回滚会一直重试直到 tx2 的全局锁等锁超时放弃全局锁并回滚本地事务释放本地锁tx1 的分支回滚最终成功。 因为整个过程全局锁在 tx1 结束前一直是被 tx1 持有的所以不会发生 脏写 的问题。
读隔离
在数据库本地事务隔离级别读已提交Read Committed 或以上的基础上SeataAT 模式的默认全局隔离级别是读未提交Read Uncommitted** 。
如果应用在特定场景下必需要求全局的读已提交目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。
SELECT FOR UPDATE 语句的执行会申请全局锁 如果全局锁被其他事务持有则释放本地锁回滚 SELECT FOR UPDATE 语句的本地执行并重试。这个过程中查询是被 block 住的直到 全局锁拿到即读取的相关数据是已提交的才返回。
出于总体性能上的考虑Seata 目前的方案并没有对所有 SELECT 语句都进行代理仅针对 FOR UPDATE 的 SELECT 语句。
实现 AT 模式
lock_table表导入到 Seata TC Server 服务相关联的数据库lock_table 用来保存全局锁的信息。
-- ----------------------------
-- Table structure for 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表导入微服务相关联的数据库undo_log表用来保存数据快照信息。
-- ----------------------------
-- Table structure for 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;1.修改application.yml文件将事务模式修改为AT模式即可
seata:data-source-proxy-mode: AT # 开启数据源代理的AT模式2.给发起全局事务的入口方法添加 GlobalTransactional 注解 3.重启服务测试
TCC 模式
TCC 模式介绍
Seata TCC模式的核心思想是基于二阶段提交协议Try-Confirm-Cancel将分布式事务拆分为两个阶段Try阶段 和 Confirm/Cancel 阶段。 第一阶段Try阶段尝试执行完成所有业务检查一致性预留必须业务资源准隔离性 第二阶段Confirm/Cancel阶段确认执行真正执行业务不作任何业务检查只使用Try阶段预留的业务资源Confirm操作满足幂等性Cancel操作满足幂等性。
TCC模式与AT模式非常相似每阶段都是独立事务不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法
Try资源的检测和预留Confirm完成资源操作业务要求 Try 成功 Confirm 一定要能成功。Cancel预留资源释放可以理解为 Try 的反向操作。
TCC的工作模型图 TCC的优点
一阶段完成直接提交事务释放数据库资源性能好相比AT模型无需生成快照无需使用全局锁性能最强不依赖数据库事务而是依赖补偿操作可以用于非事务型数据库
TCC的缺点
有代码侵入需要编写 Try、Confirm 和 Cancel 接口软状态事务是最终一致需要考虑 Confirm 和 Cancel 的失败情况做好幂等处理
TCC的空回滚和业务悬挂 空回滚当某分支事务的 Try 阶段阻塞时可能导致全局事务超时而触发二阶段的 Cancel 操作。在未执行 Try 操作时先执行了 Cancel 操作。 业务悬挂对于已经空回滚的业务如果以后继续执行 Try就永远不可能 Confirm 或 Cancel这就是业务悬挂。
实现 TCC 模式
业务描述在账户表扣减余额然后去库存表扣减商品完成业务如果扣减库存失败则将账户表余额进行回滚。 在数据库中增加账户冻结表用于记录冻结的金额。
账户冻结表结构
CREATE TABLE account_freeze_tbl (xid varchar(128) NOT NULL,user_id varchar(255) DEFAULT NULL COMMENT 用户id,freeze_money int(11) unsigned DEFAULT 0 COMMENT 冻结金额,state int(1) DEFAULT NULL COMMENT 事务状态0:try1:confirm2:cancel,PRIMARY KEY (xid) USING BTREE
) ENGINEInnoDB DEFAULT CHARSETutf8 ROW_FORMATCOMPACT;Try业务添加冻结金额扣减可用金额 Confirm业务删除冻结金额 Cancel业务删除冻结金额恢复可用金额
在实现中需要保证Confirm、Cancel 接口的幂等性允许空回滚拒绝业务悬挂。
TCC的 Try、Confirm、Cancel 方法都需要在接口中基于注解来声明语法如下
LocalTCC
public interface TCCService {/*** * Try逻辑* TwoPhaseBusinessAction 中的name属性要与当前方法名一致用于指定 Try 逻辑对应的方法* BusinessActionContextParameter 设置上下文参数可以在confirmcancel方法中使用*/TwoPhaseBusinessAction(name prepare, commitMethod confirm, rollbackMethod cancel)void prepare(BusinessActionContextParameter(paramName param) String param);/**** 二阶段confirm确认方法、可以另命名但要保证与commitMethod一致* param context 上下文,可以传递Try方法的参数* return boolean 执行是否成功*/boolean confirm (BusinessActionContext context);/**** 二阶段回滚方法要保证与rollbackMethod一致*/boolean cancel (BusinessActionContext context);
}声明接口
LocalTCC
public interface AccountTCCService {TwoPhaseBusinessAction(name deduct, commitMethod confirm, rollbackMethod cancel)void deduct(BusinessActionContextParameter(paramName userId) String userId,BusinessActionContextParameter(paramName money) int money);boolean confirm(BusinessActionContext ctx);boolean cancel(BusinessActionContext ctx);
}实现类
Service
Slf4j
public class AccountTCCServiceImpl implements AccountTCCService {Autowiredprivate AccountMapper accountMapper;Autowiredprivate AccountFreezeMapper freezeMapper;OverrideTransactionalpublic void deduct(String userId, int money) {// 0.获取事务idString xid RootContext.getXID();// 判断 freeze 中是否有冻结记录如果有一定是 CANCEL执行过要拒绝执行 Try 业务AccountFreeze oldFreeze freezeMapper.selectById(xid);if (oldFreeze ! null) {// CANCEL执行过拒绝执行 Try 业务避免业务悬挂return;}// 1.扣减可用余额accountMapper.deduct(userId, money);// 2.记录冻结金额事务状态AccountFreeze freeze new AccountFreeze();freeze.setUserId(userId);freeze.setFreezeMoney(money);freeze.setState(AccountFreeze.State.TRY);freeze.setXid(xid);freezeMapper.insert(freeze);}Overridepublic boolean confirm(BusinessActionContext ctx) {// 1.获取事务idString xid ctx.getXid();// 2.根据id删除冻结记录int count freezeMapper.deleteById(xid);return count 1;}Overridepublic boolean cancel(BusinessActionContext ctx) {// 0.查询冻结记录String xid ctx.getXid();String userId ctx.getActionContext(userId).toString();AccountFreeze freeze freezeMapper.selectById(xid);// 查询冻结表存在说明已经执行过 try 逻辑不存在做空回滚AccountFreeze freeze freezeMapper.selectById(xid);if (freeze null) {// 证明 try 没执行需要空回滚freeze new AccountFreeze();freeze.setUserId(userId);freeze.setFreezeMoney(0);freeze.setState(AccountFreeze.State.CANCEL);freeze.setXid(xid);freezeMapper.insert(freeze);return true;}// 幂等判断if (freeze.getState() AccountFreeze.State.CANCEL) {//状态已经为 CANCEL 了无需重复处理return true;}// 1.恢复可用余额accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());// 2.将冻结金额清零状态改为CANCELfreeze.setFreezeMoney(0);freeze.setState(AccountFreeze.State.CANCEL);int count freezeMapper.updateById(freeze);return count 1;}
}Saga 模式
Saga模式是SEATA提供的长事务解决方案。 分为两个阶段
一阶段直接提交本地事务二阶段成功则什么都不做失败则通过编写补偿业务来回滚 Saga模式优点
事务参与者可以基于事件驱动实现异步调用吞吐高一阶段直接提交事务无锁性能好不用编写TCC中的三个阶段实现简单
Saga模式缺点
软状态持续时间不确定时效性差没有锁没有事务隔离会有脏写
Saga 模式不是很常用使用示例省略
Seata 四种模式对比
