分布式事务中间件 Seata学习系列之一:初识Seata

简介: 本文主要介绍了分布式事务的概念以及当前分布式事务存在的不足之处,同时着重介绍了Seata分布式事务处理机制以及的优势之处。

引言

微服务已经不是什么新鲜话题了,越来越多的公司在进行微服务改造以及相关的探索实践工作。相关的框架也比较多,例如Spring CloudDubbo等都是非常优秀的分布式框架。分布式服务在飞速发展,给我们带来减少业务耦合、独立部署等诸多优点的同时,也带来了维护成本高、系统复杂度上升等问题,其中尤为突出的就是分布式事务。当前市面上已经有一些分布式事务的解决方案,但是或多或少都存在这样或者那样的问题。本系列文章主要介绍阿里巴巴开源的分布式解决方案Seata是如何解决分布式事务痛点问题的。

  • 什么是分布式事务
  • 当前分布式事务痛点
  • Seata是何方神圣
  • 总结

一、什么是分布式事务

事务的概念大家应该都比较清楚了,这里简单回顾下。完成一项事情需要好几个操作,而事务就是将这些操作包裹成一个不可分割的执行单元,在这个执行单元中,只有当所有的操作都正常完成,这个执行单元才可以进行完整提交。但是如果该单元中有任何的操作失败,则整个单元无法提交,需要回滚至执行操作之前的状态, 可以这么说事务是天蝎座的,要么就要全部的爱,要么就不爱,从来不是半糖主义。正所谓要么什么都不做,要么就做全套(All or Nothing)。

image.png

所谓分布式事务就是事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同服务器节点之上。简单来说就是完成事务中的各个操作都是分布在不同的服务器节点上,分布式事务需要保证这些不同服务器的给个操作要么都成功,要么都失败。


分布式事务的产生主要是伴随着微服务的高速发展而来的,服务节点的不断扩充以及资源节点的分布式为分布式事务问题的产生奠定物理基础。

二、当前分布式事务痛点

既然分布式事务使我们在微服务改造以及开拓路上不得不面对的问题,那么目前针对该问题都有哪些解决方案呢?我们一起来看下。分布式事务的解决方案主要可以分为对使用方业务有侵入性的以及无侵入性的。

1、基于数据库 XA 协议的两段式提交(2PC)方案

该方案是一种业务无侵入的实现方案。它要求本地数据库支持 XA 协议,且由于 XA 协议自身的特点,它会造成事务资源长时间得不到释放,锁定周期长,而且在应用层上面无法干预,因此它性能很差,它的存在相当于七伤拳那样“伤人七分,损己三分”,因此在互联网项目中并不是很流行这种解决方案。


使用两阶段提交来完成一个全局事务, XA 规范的基础是两阶段提交协议。

第一阶段是表决阶段,所有参与者都将本事务能否成功的信息反馈发给协调者;第二阶段是执行阶段,协调者根据所有参与者的反馈,通知所有参与者,步调一致地在所有分支上提交或者回滚。

image.png

image.png

2、TCC(Try-Confirm-Cancel)方案


TCC 其实就是采用的补偿机制,其核心思想是:针对每个操作,都要注册一个与其对应的确认和补偿(撤销)操作。它分为三个阶段:


(1)try

一般都是锁定某个资源,设置一个预备类的状态,冻结部分数据,。简单的说就是通知各个业务被调方预留相关的业务资源。


(2)confirm

确认执行各个业务方的资源操作


(2)cancel

取消执行每个业务方的资源操作

三、Seata是何方神圣

1、什么是Seata

Seata(Simpe Extensible Autonomous Transcaction Architecture)那么什么样的分布式事务解决方案才是好呢,我想应该是对于现有业务无侵入同时满足高性能的解决方案。Seata`便是一种高性能、方便使用且对业务零侵入的针对微服务的一种分布式事务解决方案。


如下图所示,可以看下Seata是如何解决分布式事务的,如下所示,Seata 的设计思路是将一个分布式事务可以理解成一个全局事务,下面挂了若干个分支事务,而一个分支事务是一个满足 ACID 的本地事务,因此我们可以操作分布式事务像操作本地事务一样。

image.png

在Seata中包含了三种基本的组件来处理全局事务与分支事务的状态维护与管理,分别如下:

(1)Transaction Coordinator(TC):事务协调器。维护全局和分支事务的状态,驱动全局事务进行提交或回滚。

(2)Transaction Manager™:事务管理器。定义全局事务的范围,开启一个全局事务、提交或者回滚一个事务。

(3)Resource Manager(RM):资源管理器。管理处于运作的分支事务的资源,与事务协调器协作,包括注册分支事务以及报告分支事务的状态,驱动分支事务的提交与回滚。

如下图所示:

image.png

我们一起看下Seata中的全局事务的大致执行步骤是怎样的,如下:


(1)TM 向 TC 申请开启一个全局分布式事务,TC 创建全局事务后返回全局唯一的 XID,XID 会在涉及微服务的整个全局事务的上下文中进行传播;

(2)RM 向 TC 注册本地分支事务,该分支事务归属于拥有相同 XID 的全局事务;

(3)TM 向 TC 发起全局事务的提交或回滚,对应于响应的XID;

(4)TC 调度并且驱动 XID 下的分支事务完成提交或者回滚。

image.png

2、项目引入

在项目中进行maven引入

<seata.version>0.8.0</seata.version>
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-all</artifactId>
    <version>${seata.version}</version>
</dependency>

四、总结

本文主要介绍了分布式事务的概念以及当前分布式事务存在的不足之处,同时着重介绍了Seata分布式事务处理机制以及的优势之处。

相关文章
|
9月前
|
消息中间件 存储 Kafka
分布式消息中间件设计与实现
本文深入探讨了消息中间件的核心功能实现与高并发、高可用设计。在生产者设计中,涵盖消息构造、序列化、路由策略及可靠性保障(如ACK机制)。消费者部分分析了拉取/推送模式、分区分配与消息确认机制。同时,Broker作为核心组件,负责消息路由、存储和投递,并通过索引技术实现快速检索。 高并发设计方面,重点讨论了文件存储(顺序写入、分段存储)、日志结构存储及负载均衡策略(如哈希分区、轮询分区)。为确保高可用性,文章详细解析了主从复制、故障转移机制以及同城/异地多活容灾方案。
|
9月前
|
消息中间件 存储 中间件
分布式消息中间件基础
消息中间件是一种基于异步消息传递的分布式系统通信工具,核心功能包括消息传输、存储、路由与投递,能够实现系统解耦、异步处理和流量削峰。其主要组件包括生产者、消费者、Broker、主题/队列等,支持点对点和发布-订阅两种消息模型。主流中间件如Kafka(高吞吐)、RabbitMQ(灵活路由)、RocketMQ(事务支持)各有特色,适用于不同场景。此外,中间件还涉及多种协议(AMQP、MQTT等)、可靠性传输机制(持久化、确认机制)、顺序性与重复性问题解决以及事务支持(两阶段提交、本地消息表等)。选择中间件需根据业务需求权衡性能、功能和运维成本。
|
消息中间件 运维 数据库
Seata框架和其他分布式事务框架有什么区别
Seata框架和其他分布式事务框架有什么区别
504 153
|
存储 Java 关系型数据库
在Spring Boot中整合Seata框架实现分布式事务
可以在 Spring Boot 中成功整合 Seata 框架,实现分布式事务的管理和处理。在实际应用中,还需要根据具体的业务需求和技术架构进行进一步的优化和调整。同时,要注意处理各种可能出现的问题,以保障分布式事务的顺利执行。
1302 160
|
11月前
|
SQL
seata是怎么进行分布式事务控制的
seata是怎么进行分布式事务控制的
|
Java 关系型数据库 数据库
微服务SpringCloud分布式事务之Seata
SpringCloud+SpringCloudAlibaba的Seata实现分布式事务,步骤超详细,附带视频教程
965 1
|
6月前
|
存储 负载均衡 NoSQL
【赵渝强老师】Redis Cluster分布式集群
Redis Cluster是Redis的分布式存储解决方案,通过哈希槽(slot)实现数据分片,支持水平扩展,具备高可用性和负载均衡能力,适用于大规模数据场景。
456 2
|
6月前
|
存储 缓存 NoSQL
【📕分布式锁通关指南 12】源码剖析redisson如何利用Redis数据结构实现Semaphore和CountDownLatch
本文解析 Redisson 如何通过 Redis 实现分布式信号量(RSemaphore)与倒数闩(RCountDownLatch),利用 Lua 脚本与原子操作保障分布式环境下的同步控制,帮助开发者更好地理解其原理与应用。
408 6
|
7月前
|
存储 缓存 NoSQL
Redis核心数据结构与分布式锁实现详解
Redis 是高性能键值数据库,支持多种数据结构,如字符串、列表、集合、哈希、有序集合等,广泛用于缓存、消息队列和实时数据处理。本文详解其核心数据结构及分布式锁实现,帮助开发者提升系统性能与并发控制能力。