分布式事务的理解记录_分布式事物记录-CSDN博客

本文链接：https://blog.csdn.net/flower_boboji/article/details/123524991

传统事务的基本特性

mysql中,我们可以使用begin开始事务,rollback回滚事务,commit提交事务
redolog记录变更,undolog回滚
Spring中,使用@Transaction标记事务

原子性

要么全部成功,要么全部失败,没有中间状态

一致性

指的是在执行事务前后,事务外访问数据的时候,数据是一致的,要么看到的是成功的,要么看到的是失败的结果,不会多任务查询到的数据不一样

隔离性

一个事务在未完成时,另一个事务不会影响到他

持久性

会有持久化效果,改变是永久的
如果在这几种特性当中,挑选出一个最需要的特性会是哪个?
一致性和隔离性;一致性分为两种:强一致性,弱一致性,强一致行就是数据库的acid,弱一致性就是两张表只有一张表写进去了(弱一致性可以获取高可用性);可以根据不同的业务场景进行不同的舍弃

分库分表

数据库集群/分布式存储方案在当前最主流的便是采用分库分表方案做多机存储和负载
分库分表能减少单表
在多机存储的情况下,传统的事务机制便无法正常运行了

表垂直拆分

把表的列拆分成多个部分,就是吧一张很多字段的表,拆分成多个表
减少查询时候的网络i/o
提高查询效率

表水平拆分

按行拆分,一张表里的行数越多,查询效率越低
水平拆分指定就是把原来的一张表中存放的数据按照固定行数拆分成多个表来存储
有效的提高查询效率
分表后依然可以使用本地事务,但是单机负载依然是瓶颈

分库

分库指的是
同样的表结构
不同的数据库中
每个节点中保存副本数据或分布式存储
可以把事务路由到同一库中,则可以保证事务特性,尤其是强一致性(事务路由到同一个表,这个很难做到,如果是垂直拆分,那么在操作的时候,首先要确定当前的数据库的所有的字段是否满足这次查询,如果不满足需要进行跨库查询的时候,就没有办法利用数据库本地的事务,除非只查当前的字段;那么单节点事务还是单节点事务,但是是比较难的,在设计的时候也很难预料)
当数据分散到数据集群中做跨库查询的时候,无法保证强一致性

微服务下的多库存储

回想CAP定理和BASE理论

base通过允许损失部分可用性来提高数据最终一致性

海量数据/高并发分布式事务解决方案

强一致性

强一致性会带来系统大量的损耗，存在单点故障问题，在提交事务阶段会产生阻塞，直到结束才会释放资源。高并发场景下表现并不好。
超卖和少卖这种情况就是在分布式环境下没有办法做到数据的强一致性

二阶段提交协议

二阶段提交协议可以保证数据强一致性
二阶段
准备
提交
角色：
协调者
负责收集准备信息（预提交）
准备完成，发起正式提交
参与者
数据库
二阶段提交把事务分为两个阶段，即准备阶段和提交阶段，准备阶段负责收集每个参与者提交数据的预提交信息其实是收集每个数据节点是否能够成功执行命令
如果其中某些节点无法执行，那么会反馈给协调者失败信息，然后协调者会发送回滚信息到
生成订单，订单生成后库存减一，然后就有物流信息
这三步，有一个没有成功就把这三个都回滚
在这里插入图片描述
我们可以通过编码的方式日志的方式来做到二阶段提交，第一次提交预提交先去试一下能不能够扣库存（预提交会有业务逻辑来检查事务能不能成功)需要有一个第三方的组件去收集这些节点的信息,可以把这些数据交给三方组件,三方组件来做检查在这里插入图片描述
这种方式提供的是强一致性,如果失败了全部回滚是由小五来实现的.这个时候就有一些问题,如果三方挂了,单点问题;并发问题 --同步等待;
可以记录日志

问题

三阶段提交协议

三阶段提交把准备分为两个阶段有预备阶段(不同的业务有不同的理解:可以检查节点是否存活;节点和节点之间是否有不健康的状态比如:cpu占用率过高;资源使用过高),预备阶段就是检查阶段;准备阶段需要预写入数据;提交是持久化操作

TCC模式

事务管理器

执行tcc操作
创建事务ID来记录整个事件链路
创建嵌套事务业务逻辑
执行流程
第一阶段
主业务调用所有子业务的try操作
事务管理器记录操作日志
第二阶段
所有try操作成功时,事务管理器执行confirm操作
有失败时,执行回滚cancel操作
t->cc关系绑定
T是由主业务发起的,CC操作和T操作不在一台机器上
通过配置文件
通过spring注解
try阶段进行了锁定资源操作,锁定不成功就认为是不可进行的,锁定成功就最终一定会成功

try confirm cancel 二阶段提交
幂等:就是执行一系列的写操作的时候,由于有重试的存在,接收到相同的请求是一样的话就只执行一次(事务id和分布式锁来确定隔离性)
try是主线业务去操作的,先进行try操作,操作成功进入管理框架记录事务在这里插入图片描述
主业务调起执行try,往其他分布式节点执行try,try成功了就成功了,失败了就没有下一步了,try成功后把try相关操作提交到事务管理器,之后启动分布式事务,开启上下文,生成事件id,事务管理器开始执行下面的confirm操作;confirm成功了返回消息,所有子节点都成功返回到主业务,其中如果有confirm失败后提供补偿机制
在这里插入图片描述

框架

tcc-transation
https://github.com/changmingxie/tcc-transaction
Hmily
https://dromara.org/website/zh-cn/
ByteTcc
https://github.com/liuyangming/ByteTCC
AOP
TCC通过AOP,面向切面编程来对confirm/cancel操作透明化