分布式事务框架以及解决方案

已于 2023-06-16 09:04:30 修改
阅读量1.5k 收藏 7
点赞数 2
分类专栏： 分布式事务 文章标签： 微服务 分布式
于 2020-11-26 15:32:03 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43875870/article/details/109982856
版权

XA Transactions

在这里插入图片描述
https://dev.mysql.com/doc/refman/5.7/en/xa.html

全局事务涉及几个本身具有事务性的操作，但是所有操作必须作为一个组同时COMMIT或者ROLLBACK，从本质上讲，这将ACID属性扩展到上一个级别，以便可以将多个ACID事务作为具有ACID属性的全局操作的组成部分一起执行。

使用全局事务的应用程序涉及一个或多个资源管理器和一个事务管理器：

  • 资源管理器（RM）提供对事务性资源的访问。数据库服务器是一种资源管理器。必须能够提交或回滚RM管理的事务。
  • 事务管理器（TM）协调作为全局事务一部分的事务。它与处理每个事务的RM通信。全局事务中的单个事务是全局事务的 “分支”。全局事务及其分支由后面描述的命名方案标识。

执行全局事务的过程使用两阶段提交（2PC）。这是在执行全局事务的分支所执行的动作之后发生的。

  • 1、在第一阶段，准备所有分支。也就是说，TM告诉他们准备提交。通常，这意味着管理分支的每个RM在稳定的存储中记录分支的动作。分支指示它们是否能够执行此操作，并将这些结果用于第二阶段。
  • 2、在第二阶段，TM告诉RM是提交还是回滚。如果所有分支在准备就绪时都表示可以提交，则通知所有分支提交。如果任何分支在准备就绪时指示无法提交，则将告知所有分支回滚。
  • 在某些情况下，全局事务可能使用一阶段提交（1PC）。例如，当事务管理器发现全局事务仅包含一个事务资源（即单个分支）时，可以告知该资源同时准备和提交。

XA事务状态：

  • 使用XA START启动一个XA事务，并把它的 ACTIVE状态。

  • 对于ACTIVEXA事务，发出组成该事务的SQL语句，然后发出一条XA END语句。 XA END将交易置于 IDLE状态。

  • 对于IDLEXA事务，可以发出一个XA PREPARE语句或一个XA COMMIT … ONE PHASE语句：

    XA PREPARE将交易置于 PREPARED状态。此时的一条 XA RECOVER语句将事务的xid值包含在其输出中，因为 XA RECOVER列出了处于该PREPARED状态的所有XA事务。 
XA COMMIT ... ONE PHASE准备并提交事务。xid未列出该 值， XA RECOVER因为事务终止。

  • 于PREPAREDXA事务，您可以发出一条XA COMMIT语句来提交和终止该事务，或者 XA ROLLBACK回滚并终止该事务。

    mysql> XA START 'xatest';
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO mytable (i) VALUES(10);
Query OK, 1 row affected (0.04 sec)

mysql> XA END 'xatest';
Query OK, 0 rows affected (0.00 sec)

mysql> XA PREPARE 'xatest';
Query OK, 0 rows affected (0.00 sec)

mysql> XA COMMIT 'xatest';
Query OK, 0 rows affected (0.00 sec)

两阶段提交（2PC）

两阶段提交又称2PC（two-phase commit protocol）,2pc是一个非常经典的强一致、中心化的原子提交协议。这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和N个参与者节点（participant）。

第一阶段（Prepare）

在这里插入图片描述

  • 事务询问：协调者 向所有的 参与者 发送事务预处理请求，称之为Prepare，并开始等待各 参与者 的响应。

  • 执行本地事务：各个 参与者 节点执行本地事务操作,但在执行完成后并不会真正提交数据库本地事务，而是先向 协调者 报告说：“我这边可以处理了/我这边不能处理”。.

  • 各参与者向协调者反馈事务询问的响应：如果 参与者 成功执行了事务操作,那么就反馈给协调者 Yes 响应,表示事务可以执行,如果没有 参与者 成功执行事务,那么就反馈给协调者 No 响应,表示事务不可以执行。

    第一阶段执行完后，会有两种可能。1、所有都返回Yes. 2、有一个或者多个返回No。

第二阶段（Commit Yes）

在这里插入图片描述

  • 所有的参与者反馈给协调者的信息都是Yes,那么就会执行事务提交，协调者 向 所有参与者 节点发出Commit请求.

  • 事务提交，参与者 收到Commit请求之后,就会正式执行本地事务Commit操作,并在完成提交之后释放整个事务执行期间占用的事务资源。

第二阶段（Commit No）

在这里插入图片描述

  • 发送回滚请求，协调者 向所有参与者节点发出 RoollBack 请求。

  • 事务回滚，参与者 接收到RoollBack请求后,会回滚本地事务。

2PC缺点

  • 性能问题。从流程上我们可以看得出，其最大缺点就在于它的执行过程中间，节点都处于阻塞状态。各个操作数据库的节点此时都占用着数据库资源，只有当所有节点准备完毕，事务协调者才会通知进行全局提交，参与者进行本地事务提交后才会释放资源。这样的过程会比较漫长，对性能影响比较大。
  • 协调者单点故障问题。事务协调者是整个XA模型的核心，一旦事务协调者节点挂掉，会导致参与者收不到提交或回滚的通知，从而导致参与者节点始终处于事务无法完成的中间状态。
    (1)协调者正常,参与者宕机	
​ 由于 协调者 无法收集到所有 参与者 的反馈，会陷入阻塞情况。	
​ 解决方案:引入超时机制,如果协调者在超过指定的时间还没有收到参与者的反馈,事务就失败,向所有节点发送终止事务请求。

(2)协调者宕机,参与者正常	
​ 无论处于哪个阶段，由于协调者宕机，无法发送提交请求，所有处于执行了操作但是未提交状态的参与者都会陷入阻塞情况.	
​ 解决方案:引入协调者备份,同时协调者需记录操作日志.当检测到协调者宕机一段时间后，协调者备份取代协调者，并读取操作日志，向所有参与者询问状态。

(3)协调者和参与者都宕机	
  a.发生在第一阶段： 因为第一阶段，所有参与者都没有真正执行commit，所以只需重新在剩余的参与者中重新选出一个协调者，新的协调者在重新执行第一阶段和第二阶段就可以了。
  b.发生在第二阶段 并且 挂了的参与者在挂掉之前没有收到协调者的指令。也就是上面的第4步挂了，这是可能协调者还没有发送第4步就挂了。这种情形下，新的协调者重新执行第一阶段和第二阶段操作。
  c.发生在第二阶段 并且 有部分参与者已经执行完commit操作。就好比这里订单服务A和支付服务B都收到协调者 发送的commit信息，开始真正执行本地事务commit，但突发情况，Acommit成功，B确挂了。这个时候目前来讲数据是不一致的。虽然这个时候可以再通过手段让他和协调者通信，再想办法把数据搞成一致的，但是，这段时间内他的数据状态已经是不一致的了！ 2PC 无法解决这个问题。
  • 丢失消息导致的数据不一致问题。在第二个阶段，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就会导致节点间数据的不一致问题。

三阶段提交(3PC)

三阶段提交又称3PC，其在两阶段提交的基础上增加了CanCommit阶段，并引入了超时机制。一旦事务参与者迟迟没有收到协调者的Commit请求，就会自动进行本地commit，这样相对有效地解决了协调者单点故障的问题。

第一阶段 (CanCommit)

在这里插入图片描述

  • 事务询问 协调者 向 参与者 发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待 参与者 的响应。
  • 响应反馈 参与者 接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No

第二阶段 (PreCommit)

在这里插入图片描述

  • 执行事务预提交：
    • 发送事务预提交请求：协调者向所有参与者节点发出PreCommit的请求，并进入Prepared阶段。
    • 执行事务预提交操作：参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。（执行但不提交）
    • 反馈事务执行的响应：如果参与者成功执行了事务操作，那么就会反馈给协调者Ack响应，同时等待最终的指令：提交（commit）或中止（abort）。
  • 中断事务：
    • 发送中断请求：协调者向所有参与者节点发出abort请求。
    • 无论是收到来自协调者的abort请求，或者是在等待协调者发送请求过程中出现超时，参与者都会中断事务。

第三阶段 (DoCommit)

在这里插入图片描述

  • 执行提交：
    • 发送提交请求：进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的Ack响应，那么它将从“预提交”状态转换到“提交”状态，并向所有的参与者发送doCommit请求。
    • 执行事务操作：参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。
    • 反馈事务提交结果：参与者在完成事务提交之后，向协调者发送Ack消息。
    • 完成事务：协调者接收到所有参与者反馈的Ack消息之后，完成事务。
  • 中断事务：任意一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。

    • 发送中断请求：协调者向所有的参与者节点发送abort请求。

    • 事务回滚：参与者接收到abort请求后，会利用其在阶段二中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。

    • 反馈事务回滚结果：参与者在完成事务回滚之后，向协调者发送Ack消息。

    • 中断事务：协调者接收到所有参与者反馈的Ack消息后，中断事务。

    • 进入第三阶段，无论是协调者和参与者故障，最终都会导致参与者无法及时接收到来自协调者的doCommit或是abort请求，针对于这样的异常情况，参与者都会在等待超时之后，继续进行事务提交。

结论

  • 相比较2PC而言，3PC对于2PC都设置了超时时间，而2PC只有协调者才拥有超时机制。

  • 这个优化点，主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。

  • 另外，通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。

  • 以上就是3PC相对于2PC的一个提高（相对缓解了2PC中的前两个问题），但是3PC依然没有完全解决数据不一致的问题。

消息队列+事件表

在这里插入图片描述

处理流程

  • 1、调用支付系统，支付系统业务处理，更新状态出入流水记录；
  • 2、插入事件表，记录状态NEW;
  • 3、定时查询事件表记录【NEW】,然后更新记录状态为SEND，同时发送消息队列；
  • 4、消息消费者接收到消息，插入事件表，记录状态NEW；
  • 5、定时任务查询记录【NEW】;
  • 6、订单系统业务处理，如果成功，更新记录状态SUCCESS,手动确认ACK;如果失败，重新消费，消费次数达到6次以上，进入死信队列，补偿处理。

问题

  • 1、定时任务瓶颈；
  • 2、不适用数据量大的系统；

LCN（ Lock、Confirm、Notify）

原理

LCN模式是通过代理Connection的方式实现对本地事务的操作，然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作，该代理的连接将由LCN连接池管理。
https://github.com/codingapi/tx-lcn/
https://www.codingapi.com/docs/txlcn-preface/

特点

  • 该模式对代码的嵌入性为低。
  • 该模式仅限于本地存在连接对象且可通过连接对象控制事务的模块。
  • 该模式下的事务提交与回滚是由本地事务方控制，对于数据一致性上有较高的保障。
  • 该模式缺陷在于代理的连接需要随事务发起方一共释放连接，增加了连接占用的时间。

原理图：

在这里插入图片描述
TX-LCN由两大模块组成, TxClient、TxManager，TxClient作为模块的依赖框架，提供TX-LCN的标准支持，TxManager作为分布式事务的控制方。事务发起方或者参与方都由TxClient端来控制。

  • pom.xml

    <dependency>
    <groupId>com.codingapi.txlcn</groupId>
    <artifactId>txlcn-tm</artifactId>
    <version>5.0.2.RELEASE</version>
</dependency>
    <!-- https://mvnrepository.com/artifact/com.codingapi.txlcn/txlcn-tc -->
<dependency>
    <groupId>com.codingapi.txlcn</groupId>
    <artifactId>txlcn-tc</artifactId>
    <version>5.0.2.RELEASE</version>
</dependency>
<!-- https://mvnrepository.com/artifact/com.codingapi.txlcn/txlcn-txmsg-netty -->
<dependency>
    <groupId>com.codingapi.txlcn</groupId>
    <artifactId>txlcn-txmsg-netty</artifactId>
    <version>5.0.2.RELEASE</version>
</dependency>

  • 表结构

    CREATE TABLE `t_tx_exception`  (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`group_id` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,
`unit_id` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,
`mod_id` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,
`transaction_state` tinyint(4) NULL DEFAULT NULL,
`registrar` tinyint(4) NULL DEFAULT NULL COMMENT '-1：未知；0：Manager 通知事务失败；1：client询问事务状态失败；2：事务发起方关闭事务组失败'
`ex_state` tinyint(4) NULL DEFAULT NULL COMMENT '0：待处理；1：已处理',
`create_time` datetime(0) NULL DEFAULT NULL,
PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 967 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = Dynamic;

CREATE TABLE `t_logger` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  `group_id` varchar(20) DEFAULT NULL,
  `unit_id` varchar(20) DEFAULT NULL,
  `tag` varchar(255) DEFAULT NULL,
  `content` varchar(255) DEFAULT NULL,
  `create_time` varchar(10) DEFAULT NULL,
  `app_name` varchar(50) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

  • TM属性配置

    spring.application.name=xxxxx
server.port=7970

# JDBC 数据库配置
spring.datasource.driver-class-name=com.mysql.jdbc.Driver
spring.datasource.url=jdbc:mysql://ip:3306/tx-manager?characterEncoding=UTF-8
spring.datasource.username=账号
spring.datasource.password=秘密

# redis 的设置信息. 线上请用Redis Cluster
spring.redis.host=127.0.0.1
spring.redis.port=6379
spring.redis.password=xxxxx

mybatis.configuration.map-underscore-to-camel-case=true
mybatis.configuration.use-generated-keys=true

# TM后台登陆密码
tx-lcn.manager.admin-key=admin

# TC连接IP, TM监听IP, 默认为 127.0.0.1
tx-lcn.manager.host=127.0.0.1

# TC连接端口，TM监听Socket端口
tx-lcn.manager.port=8070

# 心跳检测时间(ms)
#tx-lcn.manager.heart-time=15000

# 分布式事务执行总时间
#tx-lcn.manager.dtx-time=30000

#参数延迟删除时间单位ms
#tx-lcn.message.netty.attr-delay-time=10000
#tx-lcn.manager.concurrent-level=128

# 开启日志,默认为false
tx-lcn.logger.enabled=true
tx-lcn.logger.driver-class-name=${spring.datasource.driver-class-name}
tx-lcn.logger.jdbc-url=${spring.datasource.url}
tx-lcn.logger.username=${spring.datasource.username}
tx-lcn.logger.password=${spring.datasource.password}

  • TM启动类添加注解
    @EnableTransactionManagerServer

  • TC属性配置

    spring.application.name=spring-demo-d
server.port=12002
## 数据库配置
spring.datasource.type=com.alibaba.druid.pool.DruidDataSource
spring.datasource.driver-class-name=com.mysql.jdbc.Driver
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/txlcn-demo?characterEncoding=UTF-8&serverTimezone=UTC
spring.datasource.username=root
spring.datasource.password=roo

mybatis.type-aliases-package=xxx.xxx.xxx
mybatis.mapper-locations=classpath:mapper/*.xml

## tx-manager 链接配置，集群逗号分隔
tx-lcn.client.manager-address=127.0.0.1:8070

  • TC 启动类添加注解
    @EnableDistributedTransaction

  • 业务层添加注解
    @Transactional(rollbackFor = Exception.class)
    @LcnTransaction

负载与集群配置（TX-LCN）

  • 首选需要启动多个TxManager服务。
    server.port=xxxx
  • 在客户端配置TxManager服务地址。
    tx-lcn.client.manager-address=127.0.0.1:xxxx,127.0.0.1:xxxx
  • 目前TX-LCN的负载机制仅提供了随机机制。
    tx-lcn.springcloud.loadbalance.enabled=true

TCC（ Try、Confirm、Cancel）

原理

TCC事务机制是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。主要由三步操作，Try: 尝试执行业务、 Confirm:确认执行业务、 Cancel: 取消执行业务。

特点

  • 该模式对代码的嵌入性高，要求每个业务需要写三种步骤的操作。
  • 该模式对有无本地事务控制都可以支持，使用面广。
  • 数据一致性控制几乎完全由开发者控制，对业务开发难度要求高。

原理图

在这里插入图片描述

业务实现

  • 1、业务方法
    @Transactional(rollbackFor = Exception.class)
    @TccTransaction
  • 2、confirm方法
    public Object confirmXXXX(){}
  • 3、cancel方法(业务逆向处理)
    public Object cancelXXXX(){}
  • ThreadLocal tl=new ThreadLocal();处理线程数据

Seata

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

核心组件

  • Transaction Coordinator（TC）：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
  • Transaction Manager（TM）：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
  • Resource Manager（RM）：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。

原理图

在这里插入图片描述
一个典型的事务过程包括：

  • 1、TM 向 TC 申请开启（Begin）一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。
  • 2、XID 在微服务调用链路的上下文中传播。
  • 3、RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖。
  • 4、TM 向 TC 发起针对 XID 的全局提交（Commit）或回滚（Rollback）决议。
  • 5、TC 调度 XID 下管辖的全部分支事务完成提交（Commit）或回滚（Rollback）请求。

事务模式

AT模式写隔离、读隔离
在这里插入图片描述

AT 模式 RM 驱动分支事务的行为分为以下两个阶段：

  • 执行阶段：
    1、代理 JDBC 数据源，解析业务 SQL，生成更新前后的镜像数据，形成 UNDO LOG。
    2、向 TC 注册分支。
    3、分支注册成功后，把业务数据的更新和 UNDO LOG 放在同一个本地事务中提交。
  • 完成阶段：
    1、全局提交，收到 TC 的分支提交请求，异步删除相应分支的 UNDO LOG。
    2、全局回滚，收到 TC 的分支回滚请求，查询分支对应的 UNDO LOG 记录，生成补偿回滚的 SQL 语句，执行分支回滚并返回结果给 TC。

在这里插入图片描述
TCC 模式 RM 驱动分支事务的行为分为以下两个阶段：

  • 执行阶段：
    1、向 TC 注册分支。
    2、执行业务定义的 Try 方法。
    3、向 TC 上报 Try 方法执行情况：成功或失败。
  • 完成阶段：
    1、全局提交，收到 TC 的分支提交请求，执行业务定义的 Confirm 方法。
    2、全局回滚，收到 TC 的分支回滚请求，执行业务定义的 Cancel 方法。

TCC问题

  • 空回滚：try未执行，cancel执行，业务回滚，解决方案，加入记录，try的执行标记，如果try没有执行，cancel空回滚；
  • 幂等：cancel/confirm多次执行，解决方案，加入记录标记cancel/confirm的执行标记，如果有对应标记，不执行；
  • 悬挂：cancel在try之前执行，解决方案，canncel在空回滚时插入回滚记录，try继续执行时发现有回滚记录 ，空try；

在这里插入图片描述

Saga 模式 RM 驱动分支事务的行为包含以下两个阶段：

  • 执行阶段：
    1、向 TC 注册分支。
    2、执行业务方法。
    3、向 TC 上报业务方法执行情况：成功或失败。
  • 完成阶段：
    1、全局提交，RM 不需要处理。
    2、全局回滚，收到 TC 的分支回滚请求，执行业务定义的补偿回滚方法。

在这里插入图片描述
XA 模式 RM 驱动分支事务的行为包含以下两个阶段：

  • 执行阶段：
    1、向 TC 注册分支。
    2、XA Start，执行业务 SQL，XA End。
    3、XA prepare，并向 TC 上报 XA 分支的执行情况：成功或失败。
  • 完成阶段：
    1、收到 TC 的分支提交请求，XA Commit。
    2、收到 TC 的分支回滚请求，XA Rollback。

事务消息(rocketmq)

相关概念

  • 1、Half(Prepare) Message——半消息(预处理消息)
    半消息是一种特殊的消息类型，该状态的消息暂时不能被Consumer消费。当一条事务消息被成功投递到Broker上，但是Broker并没有接收到Producer发出的二次确认时，该事务消息就处于"暂时不可被消费"状态，该状态的事务消息被称为半消息。
  • 2、Message Status Check——消息状态回查
    由于网络抖动、Producer重启等原因，可能导致Producer向Broker发送的二次确认消息没有成功送达。如果Broker检测到某条事务消息长时间处于半消息状态，则会主动向Producer端发起回查操作，查询该事务消息在Producer端的事务状态(Commit 或 Rollback)。可以看出，Message Status Check主要用来解决分布式事务中的超时问题。
  • 3、消息状态

    • 1、TransactionStatus.CommitTransaction，提交事务，表示允许消费者消费（使用）这条消息

    • 2、TransactionStatus.RollbackTransaction，回滚事务，表示消息将被删除，不允许使用

    • 3、TransactionStatus.Unknown，中间状态，表示需要MQ向消息发送方进行检查以确定状态

原理图

在这里插入图片描述

执行流程

  • 1、Producer向Broker端发送Half Message；
  • 2、Broker ACK，Half Message发送成功；
  • 3、Producer执行本地事务（executeLocalTransaction）；
  • 4、本地事务完毕，根据事务的状态，Producer向Broker发送二次确认消息，确认该Half Message的Commit或者Rollback状态。Broker收到二次确认消息后，对于Commit状态，则直接发送到Consumer端执行消费逻辑，而对于Rollback则直接标记为失败，一段时间后清除，并不会发给Consumer。正常情况下，到此分布式事务已经完成，剩下要处理的就是超时问题，即一段时间后Broker仍没有收到Producer的二次确认消息；
  • 5、针对超时状态，Broker主动向Producer发起消息回查（checkLocalTransaction）；
  • 6、Producer处理回查消息，返回对应的本地事务的执行结果；
  • 7、Broker针对回查消息的结果，执行Commit或Rollback操作，同Step4。
奔跑的码农小哥
关注
  • 2
    点赞
  • 踩
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Spring+JOTM 分布式事务管理
12-18
简单易懂的JOTM实现分布式事务控制，此代码是maven项目，如果需要jar可以邮件给我，我发给你。
分布式事务——分布式事务简介、分布式事务框架 Seata（AT模式、Tcc模式、Tcc Vs AT）、分布式事务—MQ
热门推荐
qq_41824825的博客
03-14 2万+
分布式事务——分布式事务简介、分布式事务框架 Seata（AT模式、Tcc模式、Tcc Vs AT）、分布式事务——MQ
分布式事务详解【分布式事务的几种解决方案】彻底搞懂分布式事务
最新发布
yygr的博客
07-03 1032
什么是事务？举个生活中的例子：你去小卖铺买东西，“一手交钱，一手交货”就是一个事务的例子，交钱和交货必须全部成功，事务才算成功，任一个活动失败，事务将撤销所有已成功的活动。明白上述例子，再来看事务的定义：事务可以看做是一次大的活动，它由不同的小活动组成，这些活动要么全部成功，要么全部失败。2PC即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。
分布式事务学习-LCN
Piratesa的博客
07-22 515
1、什么是分布式事务？ 分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位 于不同的分布式系统的不同节点之上。 图中包含了库存和订单两个独立的微服务，每个微服务维护了自己的数据库。在交易系 统的业务逻辑中，一个商品在下单之前需要先调用库存服务，进行扣除库存，再调用订单服 务，创建订单记录。 正常情况下，两个数据库各自更新成功，两边数据维持着一致性。 如果在非正常情况下...
5大分布式事务框架详解(图文全面总结)
m0_60259116的博客
04-09 2618
5大分布式事务框架详解(图文全面总结)
SpringBoot 全局事务配置
sout-lanys
11-02 8534
传统springboot实现事务只需要在方法上添加@Transactional注解，但是需要在所有的service都加上事务，相对比较麻烦，随着项目的庞大，功能模块会随之增多，所以就需要采用AOP的方式实现全局事务处理。 全局事务配置通过AOP切面指定方法前缀切入点，从而对指定的方法统一进行事务控制，根据方法名前缀来匹配到具体方法，进行事务配置
常用的分布式事务解决方案
01-27
5. Seata（前身是FATBOY和SOFAJRaft）：阿里巴巴开源的分布式事务框架，支持TCC、Saga、AT（Automatic Transaction）等多种模式。 6. BASE理论：基本可用（Basically Available）、软状态（Soft State）、最终一致...
Dubbo分布式事务解决方案
07-20
4. **实施难度**: 大型企业通常会自主研发分布式事务框架或消息中间件，但对于中小型企业来说，这样的投入成本过高。 #### 四、分布式事务解决方案 为了解决上述挑战，本教程提出了一种轻量且灵活的分布式事务解决...
分布式事务解决方案.zip
02-04
Seata（Simple Extensible Autonomous Transaction Architecture）是阿里巴巴开源的分布式事务框架，支持AT（Automatic Transaction Mode）、TCC、Saga和XA等事务模式，提供高性能和简单易用的分布式事务解决方案。...
分布式事务框架 Seata 详解（附代码）
AhangA的博客
01-13 2281
分布式事务框架Seata学习
分布式事务及分布式框架Seata
肥柯博客
08-17 3886
分布式事务 ==分布式事务是什么？ ==》本地事务是一个单元的sql，分布式事务也是一个单元的sql，他们区别在于，分布式事务的sql分布在了不同服务上，这里的服务指微服务和数据库服务 ==？为什么强调服务是微服务和数据库服务？ 一个服务，多个数据库是分布式事务 多个服务，一个数据库是分布式事务 多个服务，多个数据库是分布式事务 总之，分布在不同服务上的不同的事务，它们各自rollback和commit，仅凭本地事务是无法保证它们一致性的 分布式事务解决方案 分布式事务的解决方案有三种，分别是全局
分布式事务（二）常见解决方案-全局事务
lishuzhen5678的博客
02-09 1277
介绍 全局事务基于DTP模型实现。DTP时由X/Open组织提出的一种分布式事务模型，它规定实现分布式事务需要三种角色; ...
事务处理 ：本地 、全局、分布式
阿哥的专栏
01-19 4206
事务处理 ：本地 、全局、分布式 单个服务使用单个数据源：本地事务 单个服务使用多个数据源：全局事务 多个服务使用单个数据源：共享事务（通常不会这么使用） 多个服务使用多个数据源：分布式事务
springboot实现全局事务管理
lucky_love816的博客
10-09 482
首先需要实现全局事务管理，你得知道事务的原理包括一些事务的基础概念。
对比7种分布式事务方案，还是偏爱阿里开源的Seata，真香！(原理+实战)
承诺不过儿戏的博客
06-02 3109
主要介绍一些目前主流的几种分布式解决方案以及阿里开源的一站式分布式解决方案Seata
【SpringCloud——Seata分布式事务管理框架】
weixin_54161577的博客
06-12 1100
分布式事务和传统形式的事务区别有什么？众所周知，我们采用微服务框架开发项目时，不同服务之间通过相互调用的方式完成业务处理，用以下案例来描述分布式业务存在的问题：假设我们此时现在有一个商城系统，其中包括下单系统、用户系统、仓库系统。当我们进行下单时，就需要创建订单信息，同时需要对用户的余额进行扣减，还需要对仓储系统的商品数量进行减少，由于每个系统分别负责一部分的业务，且其拥有独立的数据库信息，因此我们就会有三个事务，订单创建、余额扣减、商品剩余量扣减。
Seata-DTX｜分布式事务金融场景案例介绍
金融级分布式架构
06-27 1651
文｜魏陈豪（花名：无陈 Sam)蚂蚁集团 SOFAStack 产品专家本文2966字 阅读 8分钟序言今天给大家带来一篇Seata-DTX[1]商业版分布式事务在金融行业如何保证事务一致性的实践介绍。从一个全局视角出发看看一致性的保证、分别有哪些节点，事务组件在其中处在一个什么位置、担任什么工作。分布式系统下的事务问题阐述云原生应用以分布式系统为主，应用会被切分到多个分布式的微服务系统下...
【2.2 分布式事务（Seata）】Seata框架入门介绍
本本本添哥
06-13 1243
一个分布式的全局事务，整体是两阶段提交的模型。全局事务是由若干分支事务组成的，分支事务要满足两阶段提交的模型要求，即需要每个分支事务都具备自己的：一阶段prepare行为二阶段commit或rollback行为根据两阶段行为模式的不同，我们将分支事务划分为。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值