国外做黄漫的网站,临泉网站建设,3万元简装修大全,wordpress 分类信息 主题文章目录 一、分布式服务案例1.1 分布式服务 demo1.2 演示分布式事务问题 二、分布式事务的概念和理论2.1 什么是分布式事务2.2 CAP 定理2.3 BASE 理论2.4 分布式事务模型 三、分布式事务解决方案 —— Seata3.1 什么是 Seata3.2 Seata 的架构3.3 Seata 的四种分布式事务解决方… 文章目录 一、分布式服务案例1.1 分布式服务 demo1.2 演示分布式事务问题 二、分布式事务的概念和理论2.1 什么是分布式事务2.2 CAP 定理2.3 BASE 理论2.4 分布式事务模型 三、分布式事务解决方案 —— Seata3.1 什么是 Seata3.2 Seata 的架构3.3 Seata 的四种分布式事务解决方案 四、Seata 服务的部署和集成4.1 部署 Seata 的 TC 服务4.2 微服务集成 Seata 一、分布式服务案例
在了解分布式事务之前让我们通过一个微服务的案例来演示一下分布式事务存在的问题。
1.1 分布式服务 demo
首先我准备了一个微服务的 demo 项目这个项目的结构如下 在这个Spring Cloud 项目中一共有三个服务account-service 账户服务order-service 订单服务和 storage-service 库存服务。其中order-service 负责下单业务在下单时会调用订单服务创建订单并写入数据库。然后订单服务调用账户服务和库存服务
账户服务负责扣减用户余额库存服务负责扣减商品库存。
这个调用的流程图如下
目前这三个服务涉及到了三种数据库表它们的结构如下 首先是订单表 然后是账户表 最后是库存表
这三个服务的核心业务代码如下 首先是 order-service 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();
}然后是account-service 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(扣款成功);
}最后是storage-service 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(扣减库存成功);
}可以发现这三个核心的业务代码都加上了 Transactional 注解来开启事务下面就通过 Postman 来演示一下这个过程。
1.2 演示分布式事务问题
在演示之前先看看数据库中的数据 order_tbl account_tbl storage_tbl 首先是正常状态即余额和库存都充足的情况 通过 Postman 发送如下请求此时指定商品的数量为 2库存充足 最终成功执行然后让我们看一看数据库中的数据变化 order_tbl 中新增了一条订单数据 account_tbl表中该用户的余额成功扣减 200 storage_tbl表中该商品的库存数量也成功扣减 2 个 然后让我们来演示一下当库存不足的情况下是否会存在问题 现在设置要扣减的库存为 10而此时的库存数量为 8则整个过程应该执行失败 然后再让我们来看一看数据库中的数据变化 order_tbl表中没有新增订单 account_tbl表中却扣减了 200 金额 storage_tbl表中没有扣减库存
在上面的微服务中一个业务跨越多个服务或数据源每个服务都是一个分支事务要保证所有分支事务最终状态一致这样的事务就是分布式事务。
但是上面的微服务上没有实现分布式事务而只有分支事务站在分支事务的角度上来看
订单服务虽然下单成功但是因为调用库存服务库存服务因为库存不足调用失败回滚了因此订单服务作为外部事务也会回滚。账户服务在执行的时候没有问题因此执行成功了。库存服务因为库存不足业务失败因此回滚了。
因此要想保证整个业务的流程都能够正常执行那么就需要采用分布式事务即要么所有的分支事务都执行成功要么都执行失败。
二、分布式事务的概念和理论
2.1 什么是分布式事务
分布式事务是指在分布式系统中多个独立的事务操作需要协同工作以维护数据的一致性和完整性。在传统的单机事务中ACID原子性、一致性、隔离性、持久性属性可以轻松满足但在分布式系统中由于涉及多个数据存储节点实现分布式事务变得更加复杂。
关键问题包括如何协调各个参与者的事务、如何处理网络分区和节点故障、如何保证全局数据一致性等。因此分布式事务需要特殊的技术和协议来管理和维护数据一致性以确保分布式系统的正确运行。
2.2 CAP 定理
CAP 定理是分布式系统理论中的一个重要概念由计算机科学家 Eric Brewer 提出。CAP 定理指出一个分布式系统的设计不能同时满足以下三个属性 一致性Consistency所有节点看到的数据是一致的即在任何时刻系统中的所有节点都能看到相同的数据。 可用性Availability系统在任何时刻都能处理读写请求即系统保持可用状态不会出现服务不可用的情况。 分区容忍性Partition Tolerance系统能够在网络分区或节点故障的情况下继续工作即系统能够容忍部分节点无法通信或故障。
CAP 定理指出在分布式系统中最多只能满足其中的两个属性而必须牺牲其中一个。这意味着在面对网络分区或故障时要么保证一致性和可用性但失去了分区容忍性要么保证一致性和分区容忍性但失去了可用性。这对分布式系统的设计和架构提出了重要挑战。 例如ES 集群出现分区时故障节点会被剔除集群数据分片会重新分配到其它节点保证数据一致。因此是低可用性高一致性属于CP 模式。 2.3 BASE 理论
BASE 理论是对 CAP 定理的一种思考和解决方案它的名称是对以下三个核心概念的缩写
1. Basically Available基本可用性 这意味着分布式系统在出现故障时仍然能够保持基本的可用性。即使部分组件故障或数据出现不一致系统仍然可以提供有限的服务不会变得完全不可用。这允许系统在面临问题时继续对外提供核心功能确保用户体验。
2. Soft State软状态 BASE 理论承认在一定时间内分布式系统的数据可以处于不一致的中间状态。这是因为各个节点在进行数据同步或处理时可能存在延迟、不同步的情况导致数据不完全一致。允许出现软状态意味着系统可以容忍一段时间内的数据不一致但要求最终达到一致状态。
3. Eventually Consistent最终一致性 最终一致性是 BASE 理论的核心概念它强调虽然分布式系统不能保证强一致性但最终所有节点的数据将达到一致状态。系统会采取一系列措施来保证数据最终一致例如定期数据同步、修复数据不一致等。这种方法可以在面临一致性挑战的同时保持分布式系统的可用性和性能。
BASE 理论的思想在分布式系统中得到了广泛应用特别是对于大规模、高可用性的系统。它提供了一种权衡可用性和一致性的方法允许根据具体需求和应用场景来选择适当的数据一致性模型如最终一致性以满足不同业务的要求。这使得分布式系统更具弹性、可伸缩性和容错性同时在最终实现数据一致性。
因此分布式事务最大的问题是各个子事务的一致性问题因此可以借鉴 CAP 定理和 BASE 理论 AP模式各子事务分别执行和提交允许出现结果不一致然后采用弥补措施恢复数据即可实现最终一致。 CP模式各个子事务执行后互相等待同时提交同时回滚达成强一致。但事务等待过程中处于弱可用状态。
2.4 分布式事务模型
要解决分布式事务的问题各个子系统之间必须能够感知彼此的事务状态以确保状态一致性。为实现这一目标通常需要引入一个事务协调者它的职责是协调每个事务的参与者子系统内的事务。这些子系统内的事务通常被称为分支事务而涉及多个分支事务的全局事务需要协调者来确保一致性。
以上述微服务为例引入一个事务协调者后的架构如下 在这种架构中事务协调者负责协调每个分支事务的执行。当某一分支事务例如库存服务由于库存不足而导致业务失败时事务协调者可以通知所有分支事务进行回滚以确保所有事务状态的一致性。
分布式事务模型的关键点包括 事务协调者Coordinator 负责协调全局事务的执行和状态管理。它监控每个分支事务的执行情况并根据需要发出提交或回滚命令。 分支事务Branch Transaction 每个子系统内部的事务负责执行具体的业务操作。分支事务会根据协调者的指示执行提交或回滚操作。 全局事务Global Transaction 涉及多个子系统内的一组分支事务全局事务由协调者协调管理以确保所有分支事务的状态一致性。
引入事务协调者后分布式系统可以更好地处理各个子系统之间的事务一致性问题保证全局事务的正确执行。这种模型有助于应对网络故障、部分事务失败等情况以确保分布式系统的数据一致性和完整性。
三、分布式事务解决方案 —— Seata
3.1 什么是 Seata
Seata前身为Fescar是一个分布式事务解决方案最早由蚂蚁金服和阿里巴巴共同开源于2019年1月。Seata 的目标是提供高性能、简单易用的分布式事务服务旨在为用户提供一站式的分布式解决方案。
Seata的主要功能和特点包括 分布式事务协调 Seata充当分布式事务的协调者负责管理和协调多个分支事务以确保它们的一致性和完整性。 高性能 Seata通过优化事务日志存储和协调算法提供高性能的分布式事务处理能力。 简单易用 Seata提供了简单的API和配置方式使开发人员能够轻松地集成和使用分布式事务功能。 支持多种存储后端 Seata支持多种存储后端包括MySQL、Oracle、PostgreSQL等以满足不同环境的需求。 分布式事务模式 Seata支持两阶段提交2PC和补偿模式可以根据业务需求选择合适的事务模式。 跨框架和跨语言 Seata可以与各种编程语言和框架集成包括Java、Spring Cloud、Dubbo等以及Node.js、Python等非Java语言。
Seata 的官方网站http://seata.io/提供了详细的文档、博客和源码分析为用户提供了丰富的资源和支持帮助开发人员更好地理解和使用分布式事务解决方案。Seata 的开源性质使得它成为解决分布式事务挑战的重要工具之一广泛应用于云原生和微服务架构中。
3.2 Seata 的架构
Seata 的架构涉及三个重要的角色它们分别是 TC (Transaction Coordinator) - 事务协调者 TC 是 Seata 中的核心组件负责维护全局事务和分支事务的状态协调全局事务的提交或回滚。TC通过全局事务的唯一标识来管理多个分支事务确保它们的状态一致性并根据协调结果决定是提交还是回滚全局事务。 TM (Transaction Manager) - 事务管理器 TM 定义了全局事务的范围它负责启动全局事务、提交或回滚全局事务。TM 与 TC 进行通信以协调全局事务的状态和最终结果。TM可以是应用程序的一部分用于启动和管理分布式事务。 RM (Resource Manager) - 资源管理器 RM 管理分支事务处理的资源包括数据库、消息队列、缓存等。RM 与 TC 进行通信以注册分支事务、报告分支事务的状态并根据 TC 的指示来驱动分支事务的提交或回滚。RM 负责协调资源的一致性以确保全局事务的一致性。
这三个角色的架构图如下
这三个角色共同协作构成了 Seata 的分布式事务管理架构。TC 作为协调者负责全局事务的管理TM 负责事务的启动和控制RM 负责资源的管理和一致性保障。通过这种分布式事务管理架构Seata能够有效地管理分布式事务的状态和保证一致性为分布式系统提供可靠的事务支持。
3.3 Seata 的四种分布式事务解决方案
Seata 提供了四种不同的分布式事务解决方案以满足不同业务场景的需求。这些解决方案分别是 XA 模式eXtended Architecture XA模式是一种强一致性分阶段事务模式它允许分布式事务在多个资源管理器例如数据库之间进行协调。在XA模式中事务协调者TC协调多个RMResource Manager来确保事务的一致性。虽然XA模式提供了强一致性但通常会牺牲一定的可用性并且需要支持XA协议的资源管理器。XA模式不需要业务侵入。 TCC 模式Try-Confirm-Cancel TCC模式是一种最终一致性的分阶段事务模式它要求业务代码显式地定义“尝试”、“确认”和“取消”三个阶段的操作。TCC模式通过在每个参与者分支事务上执行这些操作来实现最终一致性。虽然TCC模式具有一定的业务侵入但它提供了更灵活的事务控制和适应性。 AT 模式Automatic Transaction AT模式是一种最终一致性的分阶段事务模式它无需业务代码显式地定义阶段操作而是通过自动代理来管理分支事务。AT模式是Seata的默认模式它提供了最终一致性的分布式事务解决方案并且无需业务侵入。AT模式适用于大多数业务场景。 SAGA 模式 SAGA模式是一种长事务模式它将分布式事务分解成多个连续的步骤每个步骤都是一个本地事务。SAGA模式适用于需要跨多个微服务的长时间事务。虽然SAGA模式具有业务侵入但它提供了更高级别的事务控制和业务流程管理。
这四种分布式事务解决方案使 Seata 能够适应不同的应用场景从强一致性到最终一致性从无业务侵入到有业务侵入满足了多样化的分布式事务需求。根据具体的业务要求和架构设计开发人员可以选择适当的 Seata 模式来实现分布式事务管理。
四、Seata 服务的部署和集成
4.1 部署 Seata 的 TC 服务 首先我们要下载 seata-server TC 服务压缩包下载地址http://seata.io/zh-cn/blog/download.html。这里我选择的版本是 1.4.2 将这个压缩包解压到非中文目录下其目录结构如下 修改conf目录下的registry.conf文件这里我们选择将 seata-server 服务注册到 Nacos 中 registry {# 注册中心类型file 、nacos 、eureka、redis、zk、consul、etcd3、sofatype nacosnacos {application seata-tc-serverserverAddr 127.0.0.1:8848group DEFAULT_GROUPnamespace cluster CDusername nacospassword nacos}
}config {# file、nacos 、apollo、zk、consul、etcd3type nacosnacos {serverAddr 127.0.0.1:8848namespace group SEATA_GROUPusername nacospassword nacosdataId seataServer.properties}
}在 Nacos 中添加seataServer.properties配置文件。为了让 TC 服务的集群可以共享配置所以选择了 Nacos 作为统一配置中心。因此服务端配置文件 seataServer.properties 文件需要添加到 Nacos 中。文件内容如下 # 数据存储方式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.passwordpasswd
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 服务在管理分布式事务时需要记录事务相关数据到数据库中需要提前创建好这些表。因此新建一个名为 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-server 的 bin 目录运行其中的 seata-server.bat 即可 启动成功后可以发现 seata-server默认的端口号是 8091 并且此时也应该注册到 Nacos 注册中心了。打开浏览器访问 nacos 的控制台然后进入服务列表页面可以看到 seata-tc-server 的信息
4.2 微服务集成 Seata 首先我们需要在微服务中引入 seata 依赖 dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-seata/artifactId
/dependency
dependencygroupIdio.seata/groupIdartifactIdseata-spring-boot-starter/artifactIdversion1.4.2/version
/dependency注意引入的依赖版本要和 seata-server 版本匹配。 修改配置文件需要修改所有微服务的application.yml文件添加下面的配置 seata:registry: # TC 服务注册中心的配置微服务根据这些信息去注册中心获取 tc 服务地址# 参考 tc 服务的 registry.conf 中的配置type: nacosnacos: # tcserver-addr: 127.0.0.1:8848namespace: group: DEFAULT_GROUPapplication: seata-tc-server # tc服务在nacos中的服务名称tx-service-group: seata-demo # 事务组根据这个获取 tc 服务的cluster名称service:vgroup-mapping: # 事务组与TC服务cluster的映射关系seata-demo: CD注意Seata 客户端获取 TC 服务的集群名称 cluster 是通过 tx-service-group 和 vgroup-mapping 的映射来获取的即以 tx-service-group 为 key 以 vgroup-mapping 为 value 完成了上面的所有配置之后重启这三个微服务就可以在 seata-server 的控制台中看到如下的日志 通过这些日志可以发现seata-server 成功为微服务注册了资源管理器和事务管理器了。
