分布式事务(延时队列RabbitMQ)

最新推荐文章于 2024-04-02 12:56:08 发布

互联网底层人员

最新推荐文章于 2024-04-02 12:56:08 发布

阅读量841

点赞数 2

分类专栏： java 文章标签： rabbitmq 中间件

本文链接：https://blog.csdn.net/m0_55990500/article/details/127428422

版权

java 专栏收录该内容

24 篇文章 3 订阅

订阅专栏

动态每日更新算法题，想要学习的可以关注一下

文章目录

一、分布式事务
二、解决方案
3.RabbitMQ
总结

一、分布式事务

1.什么是分布式事务

分布式事务（Distributed transaction）：是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。一个大的操作由 N 多的小的操作共同完成，而这些小的操作又分布在不同的服务上。针对于这些操作，要么全部成功执行，要么全部不执行。

在这里插入图片描述

其实很简单:就是在分布式的场景下使用事务回滚机制，要么全部成功，要么全部不执行。

2.业务场景

在这里插入图片描述

其实很简单，就是我们在分布式场景下肯定避免不了远程服务的调用，最常见的就是feign的远程调用。

	@Transactional
	productService(){
		/**
			其他业务操作
		**/
		wareService();
		int i= 10/0;

}

在10/0肯定会抛出异常，那么因为加了本地事务，productService肯定会回滚，但是wareService属于远程服务进而不会回滚。

3.CAP 定理

在一个分布式系统中，以下三点特性无法同时满足（号称 CAP “不可能三角”）：

在这里插入图片描述

C：Consistency，一致性。在分布式系统中的所有数据备份，「在同一时刻具有同样的值」，所有节点在同一时刻读取的数据都是最新的数据副本（等同于所有节点访问同一份最新的数据副本）。
A：Availability，可用性，好的响应性能。完全的可用性指的是在「任何故障模型（集群系统中部分节点故障）下，服务都会在有限的时间内处理完成并进行响应」（对数据更新具备高可用性）。
P：Partition tolerance，分区容忍性。尽管网络上有部分消息丢失或者服务不可用，但系统仍然可继续工作、继续操作。
具体地讲在分布式系统中，在任何数据库设计中，一个 Web 应用 「至多只能同时支持上面的两个属性」。显然，任何横向扩展策略都要依赖于 数据分区。因此，设计人员必须在一致性与可用性之间做出选择：

任何分布式系统，必须依赖 P（Partition tolerance，分区容忍性）。
分布式系统可选性，要么 CP（强一致性），要么 AP（弱一致性，也叫最终一致性），三者不可兼具。
单体系统中的事务一致性，即为 AC 组合。表现为不拆分数据系统，在一个数据库的一个事务中完成所有的操作。

4.BASE 理论

在这里插入图片描述

在分布式系统中，更多追求的是可用性，它的权重比一致性要高，如何实现高可用性？那就是 BASE 理论，它是用来对 CAP 定理进行进一步扩充的。BASE 理论解决 CAP 理论提出了分布式系统的一致性和可用性不能兼得的问题。

“酸碱” 平衡理论
BASE 在英文中有 “(base)碱” 的意思，对应本篇开头的 ACID 在英文中 “(acid)酸” 的意思，基于这两个名词提出了酸碱平衡的结论。简单来说是在不同的场景下，可以分别利用 ACID 和 BASE 来解决分布式服务化系统的一致性问题。

BASE 模型与 ACID 模型截然不同，满足 CAP 理论，通过牺牲强一致性，获得可用性，一般应用在服务化系统的应用层或者大数据处理系统，通过达到最终一致性来尽量满足业务的绝大部分需求。

（1）BASE 理论三要素

BASE 理论模型包含个三个元素：

BA：Basically Available(基本可用)，系统出现了不可预知的故障，但还是能用，相比较正常的系统而言会有响应时间上的损失和功能上的损失。
S：Soft state(软状态)，状态可以有一段时间不同步。
E：Eventually consistent(最终一致性)，最终态数据是一致的就可以了，而不是时时保持强一致。
BASE 理论是对 CAP 中的一致性(CP) 和可用性(AP) 进行一个权衡的结果，理论的核心思想就是：无法做到强一致性(CP) ，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性(Eventual consistency)。

（2）什么是软状态呢？

相对于原子性（ACID）而言，要求多个节点的数据副本都是一致的，这种也称为 “硬状态”。

“软状态” 指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时同步。当然不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性（最终态）。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。

（3）最终一致性分类

在实际工程实践中，最终一致性分为 5 种：

因果一致性（Causal consistency），如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。
读己之所写一致性（Read-your-writes consistency），节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。
会话一致性（Session consistency），会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
单调读一致性（Monotonic read consistency），如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
单调写一致性（Monotonic write consistency），一个系统要能够保证来自同一个节点的写操作被顺序的执行。
在实际的实践中，这 5 种类型往往会结合使用，以构建一个具有最终一致性的分布式系统。

BASE 模型的软状态(Soft state) 是实现 BASE 理论的方法，基本可用(BA) 和最终一致(E) 是目标。按照 BASE 模型实现的系统，由于不保证强一致性，系统在处理请求的过程中，可以存在短暂的不一致，在短暂的不一致窗口请求处理处在临时状态中，系统在做每步操作的时候，通过记录每一个临时状态，在系统出现故障的时候，可以从这些中间状态继续未完成的请求处理或者退回到原始状态，最后达到一致的状态。

二、解决方案

1. 2PC(简单了解)

2PC 即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2 是指两个阶段，P 是指准备阶段，C 是指提交阶段。

举例：张三和李四好久不见，老友约起聚餐，饭店老板要求先买单，才能出票。这时张三和李四分别抱怨近况不如意，囊中羞涩，都不愿意请客，这时只能AA。只有张三和李四都付款，老板才能出票安排就餐。但由于张三和李四都是铁公鸡，形成了尴尬的一幕：

准备阶段：老板要求张三付款，张三付款。老板要求李四付款，李四付款。

提交阶段：老板出票，两人拿票纷纷落座就餐。

例子中形成了一个事务，若张三或李四其中一人拒绝付款，或钱不够，店老板都不会给出票，并且会把已收款退回。

整个事务过程由事务管理器和参与者组成，店老板就是事务管理器，张三、李四就是事务参与者，事务管理器负责决策整个分布式事务的提交和回滚，事务参与者负责自己本地事务的提交和回滚。

2.Seata 方案(不推荐不适用于高并发场景)

Seata 把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据库的本地事务。
在这里插入图片描述

Transaction Coordinator（TC）：事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收 TM 指令发起全局事务的提交与回滚，负责与 RM 通信协调各各分支事务的提交或回滚。
Transaction Manager（TM）：事务管理器，TM 需要嵌入应用程序中工作，它负责开启一个全局事务，并最终向 TC 发起全局提交或全局回滚的指令。
Resource Manager（RM）：控制分支事务，负责分支注册、状态汇报，并接收事务协调器 TC 的指令，驱动分支（本地）事务的提交和回滚。