事务详讲(本地及分布式)

本地事务在分布式的问题:

因为在分布式服务中,难免一个接口中会有很多调用远程服务的情况,这个就非常容易出现问题,以下是一个详细的例子: 例如,你为了保证事物的一致性等要求,所以,你方法上只写了@Transactional,但你的业务中又需要调用其他微服务的方法(Feign),这时就容易出现问题了,当你的远程服务调用时因为一些缘故 , 可能时间过长,timeout挂了, 异常等等 ,挂了需要回滚事务时 , 就会出现问题 为什么呢?  

这是因为已经执行的远程服务是不会回滚的, 这是分布式的一个特性,不同的微服务讲会有不同的数据库,所以这个数据库的回滚,肯定无法使得其他的数据库回滚     (这是使用的异常机制进行的事务回滚)

实际项目中的例子:

可能出错的原因:

        1 . 远程服务假失败:

                 远程服务其实调用成功  ,由于网络故障等没有返回

                导致错误: 订单回滚,库存却扣减

        2 . 远程服务执行完成,后面的其他方法出现问题

                导致错误:一致性的远程请求,坑定不能回滚

总结: 本地事务 ,再付不是系统中 ,只能控制住自己的回滚 , 控制不了其他事物的回滚

本地事务:

1、事务的基本性质

数据库事务的几个特性:原子性(Atomicity )、一致性( Consistency )、隔离性独立性( Isolation)
持久性(Durabilily),简称就是 ACID;
原子性:一系列的操作整体不可拆分,要么同时成功,要么同时失败
一致性:数据在事务的前后,业务整体一致。
例子:
        转账。A:1000;B:1000; 转 200
        事务成功; A:800  B:1200

隔离性:事务之间互相隔离。
持久性:一旦事务成功,数据一定会落盘在数据库。
在以往的单体应用中,我们多个业务操作使用同一条连接操作不同的数据表,一旦有异常,
我们可以很容易的整体回滚;
Business:我们具体的业务代码
Storage:库存业务代码;扣库存
Order:订单业务代码;保存订单
Account:账号业务代码;减账户余额
比如买东西业务,扣库存,下订单,账户扣款,是一个整体;必须同时成功或者失败
一个事务开始,代表以下的所有操作都在同一个连接里面;

2、事务的隔离级别 (MySQL的一些规范)

         1 . READ UNCOMMITTED(读未提交)
该隔离级别的事务会读到其它未提交事务的数据,此现象也称之为脏读
        2 .READ COMMITTED(读提交)
一个事务可以读取另一个已提交的事务,多次读取会造成不一样的结果,此现象称为不可重
复读问题,Oracle 和 SQL Server 的默认隔离级别
        3 . REPEATABLE READ(可重复读)
该隔离级别是 MySQL 默认的隔离级别,在同一个事务里,select 的结果是事务开始时时间
点的状态,因此,同样的 select 操作读到的结果会是一致的,但是,会有幻读现象。MySQL
的 InnoDB 引擎可以通过 next-key locks 机制(参考"行锁的算法")来避免幻读。
        4 SERIALIZABLE(序列化)
在该隔离级别下事务都是串行顺序执行的,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 、存储数据丢失 ...

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

2CAP 定理与 BASE 理论

1 CAP 定理
CAP 原则又称 CAP 定理,指的是在一个分布式系统中
一致性(Consistency):
        在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访
问同一份最新的数据副本)
可用性(Availability) :
        在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据
更新具备高可用性)
分区容错性(Partition ) :
        大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区(partition )。
分区容错的意思是,区间通信可能失败。比如,一台服务器放在中国,另一台服务
器放在美国,这就是两个区,它们之间可能无法通信。
CAP 原则指的是,这三个要素最多只能同时实现两点, 不可能三者兼顾
一般来说,分区容错无法避免,因此可以认为 CAP P 总是成立。 CAP 定理告诉我们,
剩下的 C A 无法同时做到。
分布式系统中实现一致性的 raft 算法、 paxos
http://thesecretlivesofdata.com/raft/

Raft算法

  1. 领导选举:在Raft算法中,如果一个节点没有在预定的时间内接收到任何来自领导者或候选者的心跳消息,它会从跟随者状态转变为候选者状态,并发起选举。每个候选者都会向其他节点发送请求投票(RequestVote)的消息,其中包含自己的任期号。其他节点(跟随者)如果未投票给其他候选者且认为候选者的任期号足够新,就会投票给该候选者并回应同意(VoteGranted)的消息。

  2. 日志复制:一旦一个候选者获得了超过半数节点的投票,它就成为领导者。然后,领导者开始接受客户端的请求并将它们添加到其本地的日志中。接着,领导者会将日志条目通过AppendEntries RPC(远程过程调用)广播给所有跟随者。跟随者必须响应确认,如果跟随者日志中的条目与领导者不匹配,领导者会要求跟随者删除冲突及之后的所有条目,并重新同步。

  3. 心跳机制:为了维持系统的活跃性和一致性,领导者定期向所有跟随者发送空的AppendEntries RPC(即心跳)。这不仅帮助检测跟随者是否仍然存活,还确保了跟随者日志与领导者保持同步。如果跟随者长时间未接收到任何消息,它将重新启动选举过程。

Paxos算法

  1. 准备阶段(Prepare):类似于Raft的领导选举,但更侧重于提案编号的管理。一个提议者(相当于候选者)选择一个唯一的提案编号,向接受者(相当于跟随者)发送Prepare请求,询问他们当前的最高提案编号以及已接受的提案值。接受者收到Prepare请求后,如果其提案编号小于请求中的提案编号,它将回复其当前的提案信息。

  2. 接受阶段(Accept):当提议者收到多数接受者的回复后,它会发送一个Accept请求,其中包含了最高的提案编号以及一个提案值。接受者只有在其提案编号大于等于请求中的提案编号时,才会接受这个提案,并将其存储为已接受的提案。

  3. 学习阶段(Learn):最后,一个学习者(可以是任何进程)可以查询接受者以获取最新的已接受提案,从而了解全局的一致性状态。

在CAP的延伸上,我们做了BASE理论

BASE 理论

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

BASE 是指
        基本可用(Basically Available
                1基本可用是指分布式系统在出现故障的时候,允许损失部分可用性(例如响应时间、 功能上的可用性),允许损失部分可用性。需要注意的是,基本可用绝不等价于系 统不可用。
               2 响应时间上的损失:正常情况下搜索引擎需要在 0.5 秒之内返回给用户相应的 查询结果,但由于出现故障(比如系统部分机房发生断电或断网故障),查询 结果的响应时间增加到了 1~2 秒。
                3功能上的损失:购物网站在购物高峰(如双十一)时,为了保护系统的稳定性, 部分消费者可能会被引导到一个降级页面。
        软状态( 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) 此操作,并反映是否可以提交 .
        第二阶段:事务协调器要求每个数据库提交数据。其中,如果有任何一个数据库否决此次提交,那么所有数据库都会被要求回滚它们在此事务 中的那部分信息
XA 协议比较简单,而且一旦商业数据库实现了 XA 协议,使用分布式事务的成本也比较
低。
XA 性能不理想 ,特别是在交易下单链路,往往并发量很高, XA 无法满足高并发场景
XA 目前在商业数据库支持的比较理想, mysql 数据库中支持的不太理想 mysql
XA 实现,没有记录 prepare 阶段日志,主备切换回导致主库与备库数据不一致。
许多 nosql 也没有支持 XA ,这让 XA 的应用场景变得非常狭隘。
也有 3PC ,引入了超时机制(无论协调者还是参与者,在向对方发送请求后,若长时间
未收到回应则做出相应处理)
2)、柔性事务-TCC 事务补偿型方案
刚性事务:遵循 ACID 原则,强一致性。
柔性事务:遵循 BASE 理论,最终一致性;
与刚性事务不同,柔性事务允许一定时间内,不同节点的数据不一致,但要求最终一致。
一阶段 prepare 行为:调用 自定义 的 prepare 逻辑。
二阶段 commit 行为:调用 自定义 的 commit 逻辑。
二阶段 rollback 行为:调用 自定义 的 rollback 逻辑。
所谓 TCC 模式,是指支持把 自定义 的分支事务纳入到全局事务的管理中。
3)、柔性事务-最大努力通知型方案
        按规律进行通知,不保证数据一定能通知成功,但会提供可查询操作接口进行核对 。这种
方案主要用在与第三方系统通讯时,比如:调用微信或支付宝支付后的支付结果通知。这种
方案也是结合 MQ 进行实现,例如:通过 MQ 发送 http 请求,设置最大通知次数。达到通
知次数后即不再通知。
案例:银行通知、商户通知等(各大交易业务平台间的商户通知:多次通知、查询校对、对
账文件),支付宝的支付成功异步
4)、柔性事务-可靠消息+最终一致性方案(异步确保型)
        实现:业务处理服务在业务事务提交之前,向实时消息服务请求发送消息,实时消息服务只
记录消息数据,而不是真正的发送。业务处理服务在业务事务提交之后,向实时消息服务确
认发送。只有在得到确认发送指令后,实时消息服务才会真正发送。
防止消息丢失

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/340181.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

神经网络基础

文章目录 一、神经网络的基本构成部分1.1 神经元1.2 单层神经网络1.3 多层神经网络1.4 非线性激活函数(activation functions)1.5 输出形式 二、神经网络的训练方式2.1 损失函数2.2 梯度下降法2.3 反向传播(Backpropagation) 三、…

二叉查找树

一、实验题目 (1)实验题目 二叉查找树 (2)问题描述 对于查找集合进行动态查找,为了使得元素的插入、删除和查找操作都能够很快地完成,可以采用二叉查找树作为查找结构。对于给定的查找集合,给出…

UFS协议—新手快速入门(二)【5-6】

目录 五、UFS协议栈 六、UFS技术演进与详解 1、UFS应用层 设备管理器 任务管理器 2、UFS传输层 3、UFS互联层 UFS协议—新手快速入门(一)【1-4】 五、UFS协议栈 UFS(Universal Flash Storage)协议是针对固态存储设备&…

【UE5教程】使用蓝图显示鼠标

首先,在您的项目中创建一个新的蓝图类,继承自PlayerController。在蓝图编辑器中,找到Event BeginPlay节点,并从它引出一条线。添加Set Show Mouse Cursor节点,勾选Visible,以确保鼠标在游戏开始时可见。 鼠…

SpringCloud Consul基础入门与使用实践总结

【1】Consul简介 官网地址:https://www.consul.io/intro/index.html 下载地址:https://www.consul.io/downloads.html 中文文档:https://www.springcloud.cc/spring-cloud-consul.html ① 基础概念 Consul 是一套开源的分布式服务发现和…

AI网络爬虫:对网页指定区域批量截图

对网页指定区域批量截图,可以在deepseek的代码助手中输入提示词: 你是一个Python编程专家,一步一步的思考,完成一个对网页指定区域截图的python脚本的任务,具体步骤如下: 设置User-Agent: Mozilla/5.0 (…

Visual C++2010学习版详细安装教程(超详细图文)

Visual C 介绍 Visual C(简称VC)是微软公司推出的一种集成开发环境(IDE),主要用于开发C和C语言的应用程序。它提供了强大的编辑器、编译器、调试器、库和框架支持,以及丰富的工具和选项,使得开…

Android约束布局ConstraintLayout的使用

Android引入约束布局的目的是为了减少布局层级的嵌套,从而提升渲染性能。约束布局综合线性布局、相对布局、帧布局的部分功能,缺点也很明显,就是可能要多写几行代码。所以约束布局使用时,还得综合考虑代码量。提升性能也并不一定非…

CTFHUB-技能树-web-web前置技能-HTTP协议全

目录 1.请求方式 2.302跳转 3.Cookie 4.基础认证 5.响应包源码 1.请求方式 curl -v -X http://challenge-3022c877a8dcedeb.sandbox.ctfhub.com:10800/index.php 2.302跳转 参考链接:http://t.csdnimg.cn/aqdNG 301——永久性重定向。该状态码表示请求的资源已…

LangChain知识库构建与RAG设计

RAG:检索增强生成是什么? RAG的主要流程 Retrieval-Augmented Generation: 检索增强生成 能够根据问题的特点还有上下文, 生成更加个性化和精确的回答 为LLM提供来自外部知识源的额外信息的概念。这允许它们生成更准确和有上下文的答案,同时减少幻觉(1)检索&…

初识C++ · 模拟实现stack和Queue

目录 前言: 1 Stack 1.1 双端队列 2 Queue 前言: 经历了list三个自定义类型的洗礼,来个简单的放松放松,即栈和队列: 文档记录的,栈和队列是一种容器适配器,它们不属于stl,但是它…

平板显示LED背光芯片OC6700,输入3.6V~60V,升压型 LED 恒流驱动器

概述 OC6700是一款内置60V功率NMOS高效率、高精度的升压型大功率LED恒流驱动芯片。OC6700采用固定关断时间的控制方式,关断时间可通过外部电容进行调节,工作频率可根据用户要求而改变。OC6700通过调节外置的电流采样电阻,能控制高亮度LED灯的…

LangChain v0.2介绍

LangChain v0.2介绍 LangSmith:一个开发者平台,可调试、测试、评估和监控LLM应用程序。 LangServe:用于将 LangChain 链部署为 REST API 的包。可以轻松启动并运行生产就绪的 API。 LangChain:包含构成认知架构的链、代理和检索策…

香橙派Orange AI Pro / 华为昇腾310芯片 部署自己训练的yolov8模型进行中国象棋识别

香橙派Orange AI Pro / 华为昇腾310芯片 部署自己训练的yolov8模型进行中国象棋识别 一、香橙派简介1.1、香橙派 AI Pro 硬件资源介绍1.2、华为昇腾310(Ascend310) 简介1.3、 昇腾310AI能力和CANN 简介昇腾310 NPU简介 二、远程环境配置2.1、ssh2.2、vnc…

springboot管理的各依赖版本查看

找一个springboot相关的依赖,比如这里我找mybatis 鼠标点击artifactId名称,图中蓝色字段,跳转到springboot依赖(鼠标悬停在上面变成蓝色表示可点击跳转), 点击spring-boot-dependencites,跳转到…

list(二)和_stack_queue

嗨喽大家好,时隔许久阿鑫又给大家带来了新的博客,list的模拟实现(二)以及_stack_queue,下面让我们开始今天的学习吧! list(二)和_stack_queue 1.list的构造函数 2.设计模式之适配器和迭代器 3.新容器de…

产品人生(9):从“波士顿矩阵”看“个人职业规划”

波士顿矩阵(简称BCG矩阵)是一种战略规划工具,由波士顿咨询公司的创始人布鲁斯亨德森(Bruce Henderson)于1970年代初提出的,它以两个关键指标作为分析维度:市场增长率和相对市场份额,…

k8s牛客面经篇

k8s的pod版块: k8s的网络版块: k8s的deployment版块: k8s的service版块: k8s的探针板块: k8s的控制调度板块: k8s的日志监控板块: k8s的流量转发板块: k8s的宏观版块:

【InternLM实战营第二期笔记】04:XTuner 微调 LLM:1.8B、多模态、Agent

文章目录 笔记微调基础知识Xtuner8G显存微调模型InternLM2 1.8B多模态实践环节数据微调过拟合WebUI 交互 多模态微调 作业 这回学乖了,打开本节课第一件事先不看教程而是装环境~ 笔记 微调基础知识 这里感慨一下,垂直领域的训练还是挺困难的,…

docker安装redis以及持久化

为了避免当虚拟机关机后redis数据丢失的情况,redis需要持久化。所以要挂载数据卷 创建数据和配置存放的目录 [root192 data]# pwd /root/data [root192 data]# mkdir -p /root/data/redis/conf && chmod 777 /root/data/redis/conf [root192 data]# mkdir …