本地事务与分布式事务

一、本地事务

1、事务的基本性质

数据库事务的几个特性：原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)和持久性(Durabilily)，简称就是 ACID；

原子性：一系列的操作整体不可拆分，要么同时成功，要么同时失败
一致性：数据在事务的前后，业务整体一致。
- 转账 A:1000 B:1000 转 200 事务成功 A：800 B:1200
隔离性：事务之间互相隔离。
持久性：一旦事务成功，数据一定会落盘在数据库。

在以往的单体应用中，我们多个业务操作使用同一条连接操作不同的数据表，一旦有异常，我们可以很容易的整体回滚；

shiwu

Business：我们具体的业务代码

Storage：库存业务代码；扣库存

Order：订单业务代码；保存订单

Account：账号业务代码；减账户余额

比如买东西业务，扣库存，下订单，账户扣款，是一个整体；必须同时成功或者失败

一个事务开始，代表以下的所有操作都在同一个连接里面；

2、事务的隔离级别

lREAD UNCOMMITTED（读未提交）

该隔离级别的事务会读到其它未提交事务的数据，此现象也称之为脏读。
lREAD COMMITTED（读已提交）

一个事务可以读取另一个已提交的事务，多次读取会造成不一样的结果，此现象称为不可重复读问题，Oracle 和 SQL Server 的默认隔离级别。
lREPEATABLE READ（可重复读）

该隔离级别是 MySQL 默认的隔离级别，在同一个事务里，select 的结果是事务开始时时间点的状态，因此，同样的 select 操作读到的结果会是一致的，但是，会有幻读现象。MySQL 的 InnoDB 引擎可以通过 next-key locks 机制（参考下文"行锁的算法"一节）来避免幻读。
lSERIALIZABLE（序列化）

在该隔离级别下事务都是串行顺序执行的，MySQL 数据库的 InnoDB 引擎会给读操作隐式加一把读共享锁，从而避免了脏读、不可重读复读和幻读问题。

3、事务的传播行为

1、PROPAGATION_REQUIRED：如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置。
2、PROPAGATION_SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就以非事务执行。
3、PROPAGATION_MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就抛出异常。
4、PROPAGATION_REQUIRES_NEW：创建新事务，无论当前存不存在事务，都创建新事务。
5、PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
6、PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。
7、PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与 PROPAGATION_REQUIRED 类似的操作。

4、SpringBoot 事务关键点

1、事务的自动配置

TransactionAutoConfiguration

2、事务的坑

在同一个类里面，编写两个方法，内部调用的时候，会导致事务设置失效。原因是没有用到代理对象的缘故。解决：

0）、导入 spring-boot-starter-aop
1）、@EnableTransactionManagement(proxyTargetClass = true) 2）、@EnableAspectJAutoProxy(exposeProxy=true)
3）、AopContext.currentProxy() 调用方法

二、分布式事务

1、为什么有分布式事务

分布式系统经常出现的异常

机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的 TCP、存储数据丢失...

shiwu2

分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在微服务架构中，几乎可以说是无法避免。

2、CAP 定理与 BASE 理论

1、CAP 定理

CAP 原则又称 CAP 定理，指的是在一个分布式系统中

一致性（Consistency）：
- 在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（Availability）
- 在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容错性（Partition tolerance）
- 大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。

CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

shiwu3

一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到。

分布式系统中实现一致性的 raft 算法、paxos http://thesecretlivesofdata.com/raft/

2、面临的问题

对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到 99.99999%（N 个 9），即保证 P 和 A，舍弃 C。

3、BASE 理论

是对 CAP 理论的延伸，思想以采用适当的采取弱一致性是即使无法做到强一致性（CAP 的一致性就是强一致性），但可，即最终一致性。

BASE 是指

基本可用（Basically Available）
- 基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性），允许损失部分可用性。需要注意的是，基本可用绝不等价于系统不可用。
  - 响应时间上的损失：正常情况下搜索引擎需要在 0.5 秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了 1~2 秒。
  - 功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。
软状态（ Soft State）
- 软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态的体现。mysql replication 的异步复制也是一种体现。
最终一致性（ Eventual Consistency）
- 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

4、强一致性、弱一致性、最终一致性

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性

3、分布式事务几种方案

1）、2PC 模式

数据库支持的 2PC【2 phase commit 二阶提交】，又叫做 XA Transactions。 MySQL 从 5.5 版本开始支持，SQL Server 2005 开始支持，Oracle 7 开始支持。其中，XA 是一个两阶段提交协议，该协议分为以下两个阶段：

第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.

第二阶段：事务协调器要求每个数据库提交数据。

其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务中的那部分信息。

shiwu4

XA 协议比较简单，而且一旦商业数据库实现了 XA 协议，使用分布式事务的成本也比较低。
XA 性能不理想，特别是在交易下单链路，往往并发量很高，XA 无法满足高并发场景
XA 目前在商业数据库支持的比较理想，在 mysql 数据库中支持的不太理想，mysql 的XA 实现，没有记录 prepare 阶段日志，主备切换回导致主库与备库数据不一致。
许多 nosql 也没有支持 XA，这让 XA 的应用场景变得非常狭隘。
也有 3PC，引入了超时机制（无论协调者还是参与者，在向对方发送请求后，若长时间未收到回应则做出相应处理）

2）、柔性事务-TCC 事务补偿型方案

刚性事务： ACID 原则，强一致性。柔性事务：遵遵循循 BASE 理论，最终一致性；

与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致。

shiwu5

一阶段 prepare 行为：调用自定义的 prepare 逻辑。

二阶段 commit 行为：调用自定义的 commit 逻辑。

二阶段 rollback 行为：调用自定义的 rollback 逻辑。

所谓 TCC 模式，是指支持把自定义的分支事务纳入到全局事务的管理中。

shiwu6

3）、柔性事务-最大努力通知型方案

按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对。这种方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种方案也是结合 MQ 进行实现，例如：通过 MQ 发送 http 请求，设置最大通知次数。达到通知次数后即不再通知。

案例：银行通知、商户通知等（各大交易业务平台间的商户通知：多次通知、查询校对、对账文件），支付宝的支付成功异步回调

4）、柔性事务-可靠消息+最终一致性方案（异步确保型）

实现：业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不是真正的发送。业务处理服务在业务事务提交之后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才会真正发送。

防止消息丢失：

1、做好消息确认机制（ pulisher， consumer【手动 ack】）
2、每一个发送的消息都在数据库做好记录。定期将失败的消息再次发送一遍

CREATE TABLE `mq_message` (
`message_id` char(32) NOT NULL,
`content` text,
`to_exchane` varchar(255) DEFAULT NULL,
`routing_key` varchar(255) DEFAULT NULL,
`class_type` varchar(255) DEFAULT NULL,
`message_status` int(1) DEFAULT '0' COMMENT '0-新建 1-已发送 2-错误抵达 3-已抵达',
`create_time` datetime DEFAULT NULL,
`update_time` datetime DEFAULT NULL,
PRIMARY KEY (`message_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

三、使用seata整合分布式事务（上述第一种方案2pc方式）

示例仓库: seata-samples

2019 年 1 月，阿里巴巴中间件团队发起了开源项目 Fescar（Fast & EaSy Commit And Rollback），和社区一起共建开源分布式事务解决方案。Fescar 的愿景是让分布式事务的使用像本地事务的使用一样，简单和高效，并逐步解决开发者们遇到的分布式事务方面的所有难题。

Fescar 开源后，蚂蚁金服加入 Fescar 社区参与共建，并在 Fescar 0.4.0 版本中贡献了 TCC 模式。

为了打造更中立、更开放、生态更加丰富的分布式事务开源社区，经过社区核心成员的投票，大家决定对 Fescar 进行品牌升级，并更名为 Seata，意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。

Seata 融合了阿里巴巴和蚂蚁金服在分布式事务技术上的积累，并沉淀了新零售、云计算和新金融等场景下丰富的实践经验，但要实现适用于所有的分布式事务场景的愿景，仍有很长的路要走。因此，我们决定建立一个完全中立的分布式事务组织，希望更多的企业、开发者能够加入我们，一起打造 Seata。

历史：

Ant Financial

XTS：Extended Transaction Service，可扩展事务服务。蚂蚁金服中间件团队自2007年以来开发了分布式事务中间件，广泛应用于Ant Financial，解决了跨数据库和服务的数据一致性问题。

DTX：Distributed Transaction Extended。自2013年以来，XTS已在Ant Financial Cloud上发布，名称为DTX。

阿里巴巴

TXC：Taobao Transaction Constructor。阿里巴巴中间件团队自2014年起启动该项目，以解决因应用程序架构从单片机改为微服务而导致的分布式事务问题。

GTS：Global Transaction Service。 TXC作为Aliyun中间件产品，新名称GTS自2016年起发布。

Fescar：我们从2019年开始基于TXC / GTS开源开源项目Fescar，以便在未来与社区密切合作。

Seata社区

Seata：简单的可扩展自治交易架构。 Ant Financial加入Fescar，使其成为一个更加中立和开放的分布式服务社区，并将Fescar更名为Seata。

3.1. 结构

solution

Seata有3个基本组件：

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

全局事务与分支事务：

a Distributed Transaction is a Global Transaction which is made up with a batch of Branch Transaction, and normally Branch Transaction is just Local Transaction.

Seata管理分布式事务的典型生命周期：

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

至此，seata的协议机制总体上看与 XA 是一致的。但是是有差别的：

XA 方案的 RM 实际上是在数据库层，RM 本质上就是数据库自身（通过提供支持 XA 的驱动程序来供应用使用）。

而 Fescar 的 RM 是以二方包的形式作为中间件层部署在应用程序这一侧的，不依赖于数据库本身对协议的支持，当然也不需要数据库支持 XA 协议。这点对于微服务化的架构来说是非常重要的：应用层不需要为本地事务和分布式事务两类不同场景来适配两套不同的数据库驱动。

这个设计，剥离了分布式事务方案对数据库在 协议支持 上的要求。

3.2. 快速入门

中文文档：https://seata.io/zh-cn/docs/user/quickstart.html

创建 UNDO_LOG 表

SEATA AT 模式需要 UNDO_LOG 表

-- 注意此处0.3.0+ 增加唯一索引 ux_undo_log
CREATE TABLE `undo_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(100) NOT NULL,
  `context` varchar(128) NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int(11) NOT NULL,
  `log_created` datetime NOT NULL,
  `log_modified` datetime NOT NULL,
  `ext` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

下载、解压、更改、启动seata服务器

从 https://github.com/seata/seata/releases,下载服务器软件包，将其解压缩。

Snipaste_2022-03-24_15-10-41

解压后可以更改registry.conf注册中心相关配置，指定注册中心type=nacos，默认配置文件是文件来配，也可以指定用nacos配置中心,如：

Snipaste_2022-03-24_15-13-21

双击seata-server.bat启动

导入依赖

        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
        </dependency>

加入配置文件

所有想要用到分布式事务的微服务使用seata DatasourceProxy代理自己的数据源

package com.atguigu.gulimall.order.config;

import com.zaxxer.hikari.HikariDataSource;
import io.seata.rm.datasource.DataSourceProxy;
import org.springframework.boot.autoconfigure.jdbc.DataSourceProperties;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.util.StringUtils;

import javax.sql.DataSource;

/**
 * <p>Title: MySeataConfig</p>
 * Description：
 * date：2020/7/3 14:04
 */
@Configuration
public class MySeataConfig {

	@Bean
	public DataSource dataSource(DataSourceProperties dataSourceProperties){
		HikariDataSource dataSource = dataSourceProperties.initializeDataSourceBuilder().type(HikariDataSource.class).build();
		if(StringUtils.hasText(dataSourceProperties.getName())){
			dataSource.setPoolName(dataSourceProperties.getName());
		}
		return new DataSourceProxy(dataSource);
	}
}

导入文件

每个微服务，都必须导入registry.cof file.conf（conf目录下）

file.conf 的 service.vgroup_mapping 配置必须和spring.application.name一致

原file.conf

Snipaste_2022-03-24_15-28-11

更改后

Snipaste_2022-03-24_15-31-49

在 org.springframework.cloud:spring-cloud-starter-alibaba-seata 的org.springframework.cloud.alibaba.seata.GlobalTransactionAutoConfiguration 类中，默认会使用 ${spring.application.name}-fescar-service-group作为服务名注册到 Seata Server上，如果和file.conf 中的配置不一致，会提示 no available server to connect错误

也可以通过配置 spring.cloud.alibaba.seata.tx-service-group修改后缀，但是必须和file.conf中的配置保持一致

给分布式大事务的方法标注@GlobalTransactional

每一个远程的小事务用 @Transactional

四、使用RabbitMQ延时队列整合分布式事务（上述第四种方案）

RabbitMQ的一些准备工作见RabbitMQ的博客

创建交换机、队列、绑定可以直接在配置文件中直接导入@bean的方式直接注入

实现如图：

Snipaste_2022-03-24_17-11-21

加入配置文件

package com.atguigu.gulimall.order.config;

import org.springframework.amqp.core.Binding;
import org.springframework.amqp.core.Exchange;
import org.springframework.amqp.core.Queue;
import org.springframework.amqp.core.TopicExchange;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import java.util.HashMap;
import java.util.Map;

/**
 * <p>Title: MyMQConfig</p>
 * Description：容器中的所有bean都会自动创建到RabbitMQ中 [RabbitMQ没有这个队列、交换机、绑定]
 * date：2020/7/3 17:03
 */
@Configuration
public class MyMQConfig {

	@Value("${myRabbitmq.MQConfig.queues}")
	private String queues;

	@Value("${myRabbitmq.MQConfig.eventExchange}")
	private String eventExchange;

	@Value("${myRabbitmq.MQConfig.routingKey}")
	private String routingKey;

	@Value("${myRabbitmq.MQConfig.delayQueue}")
	private String delayQueue;

	@Value("${myRabbitmq.MQConfig.createOrder}")
	private String createOrder;

	@Value("${myRabbitmq.MQConfig.ReleaseOther}")
	private String ReleaseOther;

	@Value("${myRabbitmq.MQConfig.ReleaseOtherKey}")
	private String ReleaseOtherKey;

	@Value("${myRabbitmq.MQConfig.ttl}")
	private String ttl;

	/**
	 * String name, boolean durable, boolean exclusive, boolean autoDelete,  @Nullable Map<String, Object> arguments
	 */
	@Bean
	public Queue orderDelayQueue(){
		Map<String ,Object> arguments = new HashMap<>();
		arguments.put("x-dead-letter-exchange", eventExchange);
		arguments.put("x-dead-letter-routing-key", routingKey);
		arguments.put("x-message-ttl", ttl);
		Queue queue = new Queue(delayQueue, true, false, false, arguments);
		return queue;
	}

	@Bean
	public Queue orderReleaseOrderQueue(){
		Queue queue = new Queue(queues, true, false, false);
		return queue;
	}

	/**
	 * String name, boolean durable, boolean autoDelete, Map<String, Object> arguments
	 * @return
	 */
	@Bean
	public Exchange orderEventExchange(){

		return new TopicExchange(eventExchange, true, false);
	}

	/**
	 * String destination, DestinationType destinationType, String exchange, String routingKey, @Nullable Map<String, Object> arguments
	 */
	@Bean
	public Binding orderCreateOrderBinding(){

		return new Binding(delayQueue, Binding.DestinationType.QUEUE, eventExchange, createOrder, null);
	}

	@Bean
	public Binding orderReleaseOrderBinding(){

		return new Binding(queues, Binding.DestinationType.QUEUE, eventExchange, routingKey, null);
	}

	/**
	 * 订单释放直接和库存释放进行绑定
	 */
	@Bean
	public Binding orderReleaseOtherBinding(){

		return new Binding(ReleaseOther, Binding.DestinationType.QUEUE, eventExchange, ReleaseOtherKey + ".#", null);
	}

	@Bean
	public Queue orderSecKillQueue(){
		return new Queue("order.seckill.order.queue", true, false, false);
	}

	@Bean
	public Binding orderSecKillQueueBinding(){
		return new Binding("order.seckill.order.queue", Binding.DestinationType.QUEUE, "order-event-exchange", "order.seckill.order", null);
	}
}

yaml

myRabbitmq:
  queue: mall-queue
  exchange: mall-exchange
  routeKey: mall
  MQConfig:
    # 订单队列
    createOrder: order.create.order	//延时队列的路由
    delayQueue: order.delay.queue	//延时队列队列
    eventExchange: order-event-exchange	//交换机
    routingKey: order.release.order	//死信队列的路由
    queues: order.release.order.queue	//死信队列
    # 订单自动过期时间 单位:(毫秒)
    ttl: 900000
    # 库存解锁队列
    ReleaseOther: stock.release.stock.queue
    ReleaseOtherKey: order.release.other

根据业务进行处理......

posted @ 2022-03-26 17:36 chenfl 阅读(577) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

chenfl

本地事务与分布式事务

一、本地事务

1、事务的基本性质

2、事务的隔离级别

3、事务的传播行为

4、SpringBoot 事务关键点

1、事务的自动配置

2、事务的坑

二、分布式事务

1、为什么有分布式事务

2、CAP 定理与 BASE 理论

1、CAP 定理

2、面临的问题

3、BASE 理论

4、强一致性、弱一致性、最终一致性

3、分布式事务几种方案

1）、2PC 模式

2）、柔性事务-TCC 事务补偿型方案

3）、柔性事务-最大努力通知型方案

4）、柔性事务-可靠消息+最终一致性方案（异步确保型）

三、使用seata整合分布式事务（上述第一种方案2pc方式）

3.1. 结构

3.2. 快速入门

创建 UNDO_LOG 表

下载、解压、更改、启动seata服务器

导入依赖

加入配置文件

导入文件

给分布式大事务的方法标注@GlobalTransactional

每一个远程的小事务用 @Transactional

四、使用RabbitMQ延时队列整合分布式事务（上述第四种方案）

加入配置文件

yaml

公告