分布式事务和Seata安装和springboot AT模式集成详细教程

最新推荐文章于 2024-05-06 22:42:09 发布
最新推荐文章于 2024-05-06 22:42:09 发布
阅读量963 收藏 23
点赞数 24
分类专栏： java 文章标签： 分布式 spring boot 后端
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_64361728/article/details/136609535
版权

1.分布式事务概述

1.1.本地事务

本地事务，也就是传统的单机事务。在传统数据库事务中，必须要满足四个原则：

  1. 原子性A：事务中的操作要么全部成功要么全部失败
  2. 一致性C：要保证数据库内部的数据一致和内部的完整约束和声明性约束
  3. 隔离性I：对同一资源的操作的事务不能同时发生
  4. 持久性D：对数据库做出的一系列操作要永久保存不管是否出现故障

1.2.分布式事务

分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务，例如：

  1. 跨数据源的分布式事务
  2. 跨服务的分布式事务
  3. 综合情况

在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例：

  • 创建新订单
  • 扣减商品库存
  • 从用户账户余额扣除金额

完成上面的操作需要访问三个不同的微服务和三个不同的数据库。


订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证ACID原则。
但是当我们把三件事情看做一个"业务"，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务了。
此时ACID难以满足，这是分布式事务要解决的问题

2.理论基础

解决分布式事务问题，需要一些分布式系统的基础知识作为理论指导。

2.1.CAP定理

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。

  • Consistency（一致性）
  • Availability（可用性）
  • Partition tolerance （分区容错性）

image.png
它们的第一个字母分别是 C、A、P。
Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。

2.1.1.一致性

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。两个节点，其中的初始数据是一致的，当我们修改其中一个节点的数据时，两者的数据产生了差异：要想保住一致性，就必须实现数据同步。

2.1.2.可用性

Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
有三个节点的集群，访问任何一个都可以及时得到响应，当有部分节点因为网络故障或其它原因无法访问时，代表节点不可用，

2.1.3.分区容错

Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

2.1.4.矛盾

在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务有必须对外保证服务。因此Partition Tolerance（分区容错）不可避免。
当节点接收到新的数据变更时，就会出现问题了，
如果此时要保证一致性Consistency，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。
如果此时要保证可用性Availability，就不能等待网络恢复，之间就会出现数据不一致。
也就是说，在P一定会出现的情况下，A和C之间只能实现一个。

2.2.BASE理论

BASE理论是对CAP的 一种解决思路，包含三个思想：

  • Basically Available（基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
  • **Soft State（软状态）：**在一定时间内，允许出现中间状态，比如临时的不一致状态。
  • Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

2.3.解决分布式事务的思路

分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：

  • AP模式（保障可用性）：各子事务分别执行和提交，允许出现结果不一致（软状态），然后采用弥补措施恢复到之前数据即可，实现最终一致（最终一致性）。
  • CP模式（保障一致性）：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态（基本可用） 。

但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者(TC)：

这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务。

2.4简述base理论三个思想：

  1. 基本可用
  2. 软状态
  3. 最终一致

解决分布式事务的思想和模型：

  1. 全局事务：整个分布式事务
  2. 分支事务：分布式事务中包含的每个子系统的事务
  3. 最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据
  4. 强一致思想：各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚

3.初识Seata

Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。
官网地址：http://seata.io/，其中的文档、播客中提供了大量的使用说明、源码分析。

3.1.Seata的架构

Seata事务管理中有三个重要的角色：

  • **TC (Transaction Coordinator) -事务协调者：**维护全局和分支事务的状态，协调全局事务提交或回滚。
  • **TM (Transaction Manager) -事务管理器：**定义全局事务的范围、开始全局事务、提交或回滚全局事务。
  • **RM (Resource Manager) -资源管理器：**管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。


流程解释：
TM： 负责划分支事务的范围，确定有那些微服务参加，并提供事务入口，然后报告给TC 。然后通过TM的入口进行每个分支业务的RM 执行，
RM; 负责分支事务的注册报告 执行，当执行完后报告给TC 本分支任务执行的结果
TM: 当TM 里面全部的RM 执行完成后，通过过TM，告知TC 全部执行完毕
TC: 判断是否全部执行成功或者有无失败向TC返回相关的提交或者回滚事务的信息。

Seata基于上述架构提供了四种不同的分布式事务解决方案：

  • XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
  • TCC模式：最终一致的分阶段事务模式，有业务侵入
  • AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
  • SAGA模式：长事务模式，有业务侵入

无论哪种方案，都离不开TC，也就是事务的协调者。

3.2.Seata的四种模式

3.2.1 XA模式

XA模式：强一致性 一个不完成 其他全部回滚，（先执行判断结果后在提交）
XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。
XA是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。
正常情况：
image.png
异常情况：
image.png

一阶段：

  • 事务协调者通知每个事物参与者执行本地事务
  • 本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁

二阶段：

  • 事务协调者基于一阶段的报告来判断下一步操作
    • 如果一阶段都成功，则通知所有事务参与者，提交事务
    • 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务
Seata的XA模型

Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：
image.png
RM一阶段的工作：
① 注册分支事务到TC
② 执行分支业务sql但不提交
③ 报告执行状态到TC
TC二阶段的工作：

  • TC检测各分支事务执行状态a.如果都成功，通知所有RM提交事务b.如果有失败，通知所有RM回滚事务

RM二阶段的工作：

  • 接收TC指令，提交或回滚事务
优缺点

XA模式的优点是什么？

  • 事务的强一致性，满足ACID原则。
  • 常用数据库都支持，实现简单，并且没有代码侵入

XA模式的缺点是什么？

  • 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
  • 依赖关系型数据库实现事务

3.2.2 AT模型

AT模式: 弥补XT 模式的强一致性的最终一致性，在执行之前创建数据快照，完事直接执行和提交，然后在判断是否都成功，如果成功删除快照，不成功恢复快照
image.png
段一RM的工作：

  • 注册分支事务
  • 记录undo-log（数据快照）
  • 执行业务sql并提交
  • 报告事务状态

阶段二提交时RM的工作：

  • 删除undo-log即可

阶段二回滚时RM的工作：

  • 根据undo-log恢复数据到更新前
AT与XA的区别

简述AT模式与XA模式最大的区别是什么？

  • XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
  • XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
  • XA模式强一致；AT模式最终一致
脏写问题

在多线程并发访问AT模式的分布式事务时，有可能出现脏写问题，如图：
image.png
解决思路就是引入了全局锁的概念。在释放DB锁之前，先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。
image.png
因获取全局锁的重试时间比获取等待DB锁要快 所以不管怎样都是事务2 限制性完 ，进行回滚后释放DB锁，这是事务1获取到DB锁进行恢复

优缺点

AT模式的优点：

  • 一阶段完成直接提交事务，释放数据库资源，性能比较好
  • 利用全局锁实现读写隔离
  • 没有代码侵入，框架自动完成回滚和提交

AT模式的缺点：

  • 两阶段之间属于软状态，属于最终一致
  • 框架的快照功能会影响性能，但比XA模式要好很多

3.2.3 TCC模式

TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：

  • Try：资源的检测和预留；
  • Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
  • Cancel：预留资源释放，可以理解为try的反向操作。

一个扣减用户余额的业务。假设账户A原来余额是100，需要余额扣减30元。

  • 阶段一（ Try ）：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30

初余额：100
余额充足，可以冻结： 冻结30 可用余额70
此时，总金额 = 冻结金额 + 可用金额，数量依然是100不变。事务直接提交无需等待其它事务。

  • 阶段二（Confirm)：假如要提交（Confirm），则冻结金额扣减30

确认可以提交，不过之前可用金额已经扣减过了，这里只要清除冻结金额就好了：
此时，总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70元

  • 阶段二(Canncel)：如果要回滚（Cancel），则冻结金额扣减30，可用余额增加30

需要回滚，那么就要释放冻结金额，恢复可用金额.

Seata中的TCC模型依然延续之前的事务架构，如图：
image.png

优缺点

TCC模式的每个阶段是做什么的？

  • Try：资源检查和预留 向 TC报告事务是否成功
  • Confirm：业务执行和提交 如果成功进行提交
  • Cancel：预留资源的释放 不成功 回滚

TCC的优点是什么？

  • 一阶段完成直接提交事务，释放数据库资源，性能好 （快速释放资源）
  • 相比AT模型，无需生成快照，无需使用全局锁，性能最强 （不用各种锁锁住数据库）
  • 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库 （底层实现不依赖数据的事务本身所以任何数据库包括非事务数据库 也可以使用如reids）

TCC的缺点是什么？

  • 有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
  • 软状态，事务是最终一致
  • 需要考虑Confirm和Cancel的失败情况，做好幂等处理
业务悬挂和空回滚

当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。
对于已经空回滚的业务，之前被阻塞的try操作恢复，继续执行try，就永远不可能confirm或cancel ，事务一直处于中间状态，这就是业务悬挂。

3.2.4 SAGA模式

在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。
分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。
Saga也分为两个阶段：

  • 一阶段：直接提交本地事务 TCC 只是做资源预留
  • 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚
.优缺点

优点：

  • 事务参与者可以基于事件驱动实现异步调用，吞吐高
  • 一阶段直接提交事务，无锁，性能好
  • 不用编写TCC中的三个阶段，实现简单

缺点：

  • 软状态持续时间不确定，时效性差
  • 没有锁，没有事务隔离，会有脏写

4.部署和集成SEATA

4.1 下载

**seata-server包，地址在 **https://seata.apache.org/zh-cn/unversioned/download/seata-server
image.png

4.2 解压

在非中文目录解压缩这个zip包，其目录结构如下：
image.png

4.3 修改配置

application.yml
1.修改seata服务地址
2.修改tc 服务的配置文件地址

server:
  port: 7091
 
spring:
  application:
    name: seata-server
 
logging:
  config: classpath:logback-spring.xml
  file:
    path: F:/seata/logs/seata
  extend:
    logstash-appender:
      destination: 127.0.0.1:4560
    kafka-appender:
      bootstrap-servers: 127.0.0.1:9092
      topic: logback_to_logstash
 
console:
  user:
    username: seata
    password: seata
 
seata:
  config:
    # 配置中心类型，选择使用nacos
    type: nacos
    nacos:
      # nacos服务地址
      server-addr: ip:8848
      # nacos组
      group: DEFAULT_GROUP
      # nacos命名空间
      namespace: ""
      # 有权限读写命名空间的nacos账号密码，无鉴权不需要
      username: 
      password: 
      # Seata在nacos上读取的配置文件
      data-id: seataServer.properties
  registry:
    # 注册中心类型，选择使用nacos
    type: nacos
    nacos:
      # nacos服务地址
      server-addr: ip:8848
      # 自定义 Seata TC 服务名称，就像SpringBoot的 spring.application.name 一样
      application: seata-tc-server
      # nacos组
      group: DEFAULT_GROUP
      # nacos命名空间
      namespace: ""
      username: 
      password: 
      # 自定义Seata TC服务集群名称
      cluster: 
#  server:
#    service-port: 8091 #If not configured, the default is '${server.port} + 1000'
  security:
    secretKey: SeataSecretKey0c382ef121d778043159209298fd40bf3850a017
    tokenValidityInMilliseconds: 1800000
    ignore:
      urls: /,/**/*.css,/**/*.js,/**/*.html,/**/*.map,/**/*.svg,/**/*.png,/**/*.ico,/console-fe/public/**,/api/v1/auth/login

3.在nacos中配置 seataServer.properties文件，是一些服务端的数据文件 主要是数据库信息，为例保存以后的全局事务，分支事务等等信息保存在数据库中
其中的数据库地址、用户名、密码都需要修改成你自己的数据库信息。

# 数据存储方式，db代表数据库 store（存储数据）
store.mode=db #数据库保存
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.jdbc.Driver
store.db.url=jdbc:mysql://ip:3306/seata?useUnicode=true&rewriteBatchedStatements=true
store.db.user=
store.db.password=
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

4.4 创建数据库表

tc服务在管理分布式事务时，需要记录事务相关数据到数据库中，你需要提前创建好这些表。
新建一个名为seata的库
去到我们的seata目录下找到script/server/db/mysql.sql这个文件在seata数据库执行生成数据库表
但是sql脚本有点问题我改了一下

CREATE TABLE IF NOT EXISTS `global_table`
(
    `xid`                       VARCHAR(128) NOT NULL,
    `transaction_id`            BIGINT,
    `status`                    TINYINT      NOT NULL,
    `application_id`            VARCHAR(32),
    `transaction_service_group` VARCHAR(32),
    `transaction_name`          VARCHAR(128),
    `timeout`                   INT,
    `begin_time`                BIGINT,
    `application_data`          VARCHAR(2000),
    `gmt_create`                DATETIME,
    `gmt_modified`              DATETIME,
    PRIMARY KEY (`xid`),
    KEY `idx_status_gmt_modified` (`status` , `gmt_modified`),
    KEY `idx_transaction_id` (`transaction_id`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;
-- the table to store BranchSession data
CREATE TABLE IF NOT EXISTS `branch_table`
(
    `branch_id`         BIGINT       NOT NULL,
    `xid`               VARCHAR(128) NOT NULL,
    `transaction_id`    BIGINT,
    `resource_group_id` VARCHAR(32),
    `resource_id`       VARCHAR(256),
    `branch_type`       VARCHAR(8),
    `status`            TINYINT,
    `client_id`         VARCHAR(64),
    `application_data`  VARCHAR(2000),
    `gmt_create`        DATETIME,
    `gmt_modified`      DATETIME,
    PRIMARY KEY (`branch_id`),
    KEY `idx_xid` (`xid`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

-- the table to store lock data
CREATE TABLE IF NOT EXISTS `lock_table`
(
    `row_key`        VARCHAR(128) NOT NULL,
    `xid`            VARCHAR(128),
    `transaction_id` BIGINT,
    `branch_id`      BIGINT       NOT NULL,
    `resource_id`    VARCHAR(256),
    `table_name`     VARCHAR(32),
    `pk`             VARCHAR(36),
    `status`         TINYINT      NOT NULL DEFAULT '0' COMMENT '0:locked ,1:rollbacking',
    `gmt_create`     DATETIME,
    `gmt_modified`   DATETIME,
    PRIMARY KEY (`row_key`),
    KEY `idx_status` (`status`),
    KEY `idx_branch_id` (`branch_id`),
    KEY `idx_xid` (`xid`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

CREATE TABLE IF NOT EXISTS `distributed_lock`
(
    `lock_key`       CHAR(20) NOT NULL,
    `lock_value`     VARCHAR(20) NOT NULL,
    `expire`         BIGINT,
    primary key (`lock_key`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

INSERT INTO `distributed_lock` (lock_key, lock_value, expire) VALUES ('AsyncCommitting', ' ', 0);
INSERT INTO `distributed_lock` (lock_key, lock_value, expire) VALUES ('RetryCommitting', ' ', 0);
INSERT INTO `distributed_lock` (lock_key, lock_value, expire) VALUES ('RetryRollbacking', ' ', 0);
INSERT INTO `distributed_lock` (lock_key, lock_value, expire) VALUES ('TxTimeoutCheck', ' ', 0);

4.5启动TC 服务

进入bin目录，运行其中的seata-server.bat即可：
image.png

image.png
出现此界面就是启动成功 可以访问他的客户端 端口就是默认的 7091
image.png
日志默认输出为c盘
image.png
**访问 Seata 后台 **
地址：http://127.0.0.1:7091
账号：seata
密码：seata
账号密码在\seata\conf\application.yml 文件的 console.user 属性配置
image.png

5.微服务集成Seata 采用AT模式

AT模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，因此实现非常简单。
只不过，AT模式需要一个表来记录全局锁、另一张表来记录数据快照undo_log。
SEATA AT 模式需要 UNDO_LOG 表，在每个业务数据库中创建 UNDO_LOG 表 。需要在每个微服务相关的数据库中创建

CREATE TABLE `undo_log` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `branch_id` bigint NOT NULL COMMENT '分支事务ID',
  `xid` varchar(100) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL COMMENT '全局事务ID',
  `context` varchar(128) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL COMMENT '上下文',
  `rollback_info` longblob NOT NULL COMMENT '回滚信息',
  `log_status` int NOT NULL COMMENT '状态，0正常，1全局已完成',
  `log_created` datetime NOT NULL COMMENT '创建时间',
  `log_modified` datetime NOT NULL COMMENT '修改时间',
  `ext` varchar(100) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci DEFAULT NULL COMMENT '扩展信息',
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='AT transaction mode undo table';

在每个微服务引入依赖

<dependency>
  <groupId>com.alibaba.cloud</groupId>
  <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
  <exclusions>
    <!--版本较低，1.3.0，因此排除-->
    <exclusion>
      <artifactId>seata-spring-boot-starter</artifactId>
      <groupId>io.seata</groupId>
    </exclusion>
  </exclusions>
</dependency>
<!--seata starter 采用1.4.2版本-->
<dependency>
  <groupId>io.seata</groupId>
  <artifactId>seata-spring-boot-starter</artifactId>
  <version>1.4.2</version>
</dependency>

告诉微服务TC 服务器的地址，让微服务通过过注册中心找到seata-tc-server的地址（就是刚才下载启动的地址）
里面的namespace，group，application，cluster（集群名称），要和TC 服务端部署的yml要保持一致，不然微服务找不到。

seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    # 参考tc服务自己的registry.conf中的配置
    type: nacos
    nacos: # tc
      server-addr: ip:8848
      namespace: ""
      group: DEFAULT_GROUP
      application: seata-tc-server # tc服务在nacos中的服务名称
  tx-service-group: seata-demo # 事务组，将事务进行了分组，在以后的高可用的时候方便快速失败，
  根据这个获取tc服务的cluster名称 相当于将所在的微服务进行了了分组如下单事务组，这个事务组被下面
  的配置定义成上海集群，那么这是事务组就会被上海集群的TC 服务器管理。
  service:
    vgroup-mapping: # 事务组与TC服务cluster的映射关系
      seata-demo: 根据自己的定义
    data-source-proxy-mode: AT #事务模式

给发起全局事务的入口方法添加@GlobalTransactional注解即可



老韩不长痘
关注
  • 24
    点赞
  • 踩
  • 23
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
分布式事务-seata0.9版本(springboot-dubbo-seata-zk).zip
07-21
分布式事务解决方案，完整的demo，注册中心使用的是zk，可以自行修改为nacos或者apollo，直接运行，配置数据库就行了
Seata的分布式事务AT模式和TCC模式实现
07-05
此代码为我的Seata专栏的配套代码，主要是Seata的AT模式和TCC模式的基本使用代码。 1. 包含seata-order-8001和seata-stock-8002两个服务 2. 包含两个数据库seata-order和seata-stock对应的表的sql结构和数据 3. 基于Seata的1.4.2版本， spring-cloud-alibaba的2021.0.1.0版本
springcloud集成分布式事务seata中的AT模式
01-16
springcloud集成分布式事务seata中的AT模式
分布式事务框架seata安装教程
06-15
分布式事务框架seata安装教程
基于springcloud+springboot+nacos+openFeign的分布式事务组件seata项目源码.zip
02-27
基于springcloud+springboot+nacos+openFeign的分布式事务组件seata项目源码.zip 介绍 分布式事务组件seata的使用demo，AT模式、TCC模式，集成springboot、springcloud（nacos注册中心、openFeign服务调用、Ribbon负载均衡器）、spring jpa，数据库采用mysql demo中使用的相关版本号，具体请看代码。如果搭建个人demo不成功，验证是否是由版本导致，版本稍有变化可能出现相关组件的版本不一致便会出现许多奇怪问题 seata服务端 1.3 Nacos服务端 1.1.4 spring-cloud-alibaba-dependencies 2.1.0.RELEASE springboot 2.1.3.RELEASE springcloud Greenwich.RELEASE 软件架构 软件架构说明 springcloud-common 公共模块 springcloud-order-AT 订单服务 springcloud-product-AT 商品库存服务 springcloud-consumer-AT 消费调用者 springcloud-business-Tcc 工商银行服务 springcloud-merchants-Tcc 招商银行服务 springcloud-Pay-Tcc 消费调用者 AT模式：springcloud-order-AT，springcloud-product-AT，springcloud-consumer-AT为AT模式Dome；模拟场景用户购买商品下单； 调用流程springcloud-consumer-AT调用订单服务创建订单（新增一条数据到订单表）；在调用商品库存服务扣减商品库存数量（修改商品库存表商品数量）；最后出现异常则统一回滚，负责统一提交； 第一阶段：准备阶段（prepare）协调者通知参与者准备提交订单，参与者开始投票。协调者完成准备工作向协调者回应Yes。 第二阶段：提交(commit)/回滚(rollback)阶段协调者根据参与者的投票结果发起最终的提交指令。如果有参与者没有准备好则发起回滚指令。
Springboot整合Seata实现分布式事务
水妖
08-30 2513
这么方便的分布式事务框架，快速上手一波
分布式事务解决方案Seata实战（SpringBoot多数据源）及其原理剖析
沮丧的南瓜
12-22 3814
文章目录一、分布式解决方案Seata介绍1.1 什么是Seata1.2 Seata的三大角色1.3 AT模式设计思路第一阶段第二阶段整体执行流程1.4 设计亮点1.5 存在的问题性能损耗性价比全局锁二、Seata实战 - 快速开始2.1 Seata Server（TC）环境搭建2.2 db存储模式+Nacos(注册&配置中心)部署步骤一：下载安装包步骤二：建表(仅db模式)步骤三：修改store.mode步骤四：修改数据库连接步骤五：配置Nacos注册中心步骤六：配置Nacos配置中心步骤七：启动S
springboot dubbo seata nacos集成 分布式事务seata实现
北巷东东的专栏
07-07 718
springboot dubbo seata nacos集成 分布式事务seata实现
【分布式事务AT模式 SpringCloud集成Seata框架】分布式事务框架Seata详细讲解
Syals的博客
04-12 941
SpringCloud整合seata框架，案例demo
分布式与一致性协议之ZAB协议(四)
最新发布
Cover_sky的博客
05-06 657
首先我们来看看ZooKeeper是如何实现成员身份的？在ZooKeeper中，成员状态是在QuorumPeer.java中实现的，为枚举型变量其实，ZooKeeper没有直接定义成员身份，而是用了对应的成员状态来表示，比如，处于FOLLOWING状态的节点为跟随者。如果你想研究相关成员的功能和实现，那么可以把对应的成员状态作为切入点来研究。比如，你想研究领导者的功能实现，可以在代码中搜索LEADING关键字，然后研究相应的上下文逻辑，进而得到自己想要的答案。
【分布式 | 第五篇】何为分布式？分布式锁？和微服务关系？
踢桃的成长之路
05-06 534
何为分布式？分布式锁？和微服务关系？
分布式与一致性协议之Raft算法(三)
Cover_sky的博客
04-29 1351
你可以把Raft算法的日志复制理解成一个优化后的二阶段提交(将二阶段优化成了一阶段)。优化后减少了一半的往返消息，也就是降低了一半的消息延迟，那日志复制的具体过程又是什么呢？首先，领导者进入第一阶段，通过日志复制RPC消息将日志项复制到集群中的其他节点上。接着如果领导者接收到大多数的"复制成功"响应后，它会将日志项应用到它的状态机，并返回成功给客户端。如果领导者没有接收到大多数的"复制成功"响应，那么就返回错误给客户端。
分布式与一致性协议之ZAB协议(三)
Cover_sky的博客
05-06 478
众所周知，系统在运行中不可避免会出现各种各样的问题，比如进程崩溃了、服务器死机了，这些问题会导致很严重的后果，让系统没办法继续运行。在ZAB协议中，写请求是必须在主节点上处理的，而且提案的广播和提交也是由主节点来完成的。既然主节点那么重要，如果它突然崩溃(宕机)了，该怎么办呢？答案是选举出新的领导者(也就是新的主节点)。在我看来，领导者选举关乎节点故障容错能力和集群可用性，是ZAB协议非常核心的设计之一。想象一下，如果没有领导者选举，主节点故障了，那么整个集群将无法写入，这将是极其严重的灾难性故障。
Redis领航分布式：Java实现高效Session管理
良月柒
05-06 199
通过本文的介绍，我们深入探讨了 Redis 实现分布式 Session 登录的相关细节。通过合理的会话数据存储结构和管理流程，以及考虑到常见的安全问题，可以构建一个高效、安全的分布式会话管理系统。希望本文能够帮助你更好地理解和应用 Redis 在分布式系统中的优势，提升系统的可用性和安全性。
Spring Boot应用部署 - JAR包Docker部署
闫小甲的专栏
04-28 1217
要使用Docker部署Spring Boot应用，需要创建一个Dockerfile来定义如何构建Docker镜像，并且可能还需要在Maven构建脚本中集成Docker插件以简化构建过程。
小程序商城|基于Spring Boot的智能小程序商城的设计与实现(源码+数据库+文档)
JIngJaneIL的博客
04-29 1438
智能小程序商城使用Java语言进行编码，使用Mysql创建数据表保存本系统产生的数据。系统可以提供信息显示和相应服务，其管理智能小程序商城信息，查看智能小程序商城信息，管理智能小程序商城。总之，智能小程序商城集中管理信息，有着保密性强，效率高，存储空间大，成本低等诸多优点。它可以降低信息管理成本，实现信息管理计算机化。关键词：智能小程序商城；Java语言；Mysql。
Spring Boot 统一数据返回格式：优化前后端开发协作的利器
良月柒
04-29 752
通过本文的介绍，我们了解了Spring Boot中统一数据返回格式的重要性，以及如何设计和处理统一的数据返回格式。统一的数据返回格式可以使得接口返回的数据格式规范、统一、易于理解和处理，提高了前后端开发的效率和协作效果。希望本文能够帮助你更好地理解和应用Spring Boot中的统一数据返回格式。
java分布式事务，seata和redis哪个好
06-12
Java分布式事务中，Seata和Redis在不同的场景下有不同的优劣势。 Seata是一个专注于分布式事务的解决方案，提供了完整的事务管理能力，包括分布式事务的协调、事务日志的存储和恢复、事务补偿等功能。Seata对于支持分布式事务的数据库和消息中间件有较好的兼容性，可以很方便的集成到应用中。 Redis是一个高性能的内存数据库，支持多种数据结构和丰富的功能，如缓存、消息队列等。Redis的事务支持也比较完善，可以通过MULTI/EXEC等命令实现事务的原子性操作。但是，Redis的事务不支持回滚操作，且在并发访问时会存在竞态条件问题。 因此，如果你需要一个完整的分布式事务解决方案，建议选择Seata；如果你只需要支持简单的事务操作，且对性能有较高要求，可以考虑使用Redis。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值