常用的分布式事务解决方案分布式事务
2025-01-10 11:08:20 0 举报AI智能生成
常用的分布式事务解决方案分布式事务
作者其他创作
大纲/内容
XA
分阶段提交
两阶段提交
第一阶段
准备阶段 各个本地事务完成本地事务的准备工作
投票阶段
协调组询问各个事务的参与者，是否可以执行事务，每个事务参与者执行事务，写入redo和undo日志，然后反馈事务执行成功的信息agree
第二阶段
执行阶段 各个本地事务根据上个阶段执行结果，进行提交或回滚
提交阶段
协调组发现每个参与者都可以执行事务agre 于是向各个事务参与者发commit指令 各个事务参与者提交事务
第一阶段和第二阶段中间会有一个协调者
每个阶段中又会有多个参与者
缺陷
发生单点故障，比如一个阶段节点挂掉 提交阶段不知道上个阶段是否成功
遇到死锁没办法解决，资源锁定 一般用于强一致性
TCC
准备阶段
Try 资源的检测和预留
执行阶段 根据准备阶段的结果，判断下面的执行方法，所有成功Confirm 否则 Cancel
cancel 预留资源释放
Confirm 执行的业务操作提交，要求Try 成功Confirm 一定要成功
Try 、Confirm、Cancel都是独立的事务 不接受其他的参与者影响，不会阻塞等待他人，都是程序员在业务层控制 ，锁的粒度有代码控制
缺陷
代码非常复杂，需要人来编写Try confirm 和cancel阶段
成本高 三个部分都得写代码
安全性的考量 cancel动作执行失败 资源 就无法释放 需要引入重试机制 重复执行还得考虑幂等问题
可靠消息服务 把多个服务拆分成 一系列的本地服务
消息中间件的应用场景
主要作用
异步
解耦
并发缓存
时效性可以不保证 比如 转账
缺陷
代码的侵入
依赖于MQ
AT(无侵入的分布式事务解决方案Seata就是这种)
第二阶段由框架自动实现
第一阶段会有拦截的操作 看你的where条件是什么
stock 10
update tb stock set stock = stock -2 where id = 1---> before image 类似于undo 日志
select * fromtb stock where id = 1 ;
执行sql
再查询一次
select* from tb stock where id = 1;---> after image 类似 redolog
错误的时候 redolog 和数据库里不一致 就需要人工介入
update tb stock set stock = stock -2 where id = 1---> before image 类似于undo 日志
select * fromtb stock where id = 1 ;
执行sql
再查询一次
select* from tb stock where id = 1;---> after image 类似 redolog
错误的时候 redolog 和数据库里不一致 就需要人工介入
特点
跨数据源
跨服务
跨服务跨数据源
可靠性最终一致性
常用的分布式事务解决方案
本地事务
资源管理器（数据库）本地管理
单个数据库
全局事务DTP模型（标准分布式事务）
事务由全局事务管理器全局管理
事务管理器
管理全局事务状态与参与的资源，协助资源的一致提交/回滚
TX协议
应用或应用服务器与事务管理器的接口
XA协议
全局事务管理器与资源的接口
AP
应用
我们的微服务
RM
资源管理器
一般是数据库
负责和管理实际资源。
TM
事务管理器
全局事务管理器
管理事务生命周期，并且协调资源
CRM
通信资源管理器
TM和RM之间的通信中间件
在该模型中，一个分布式事务 (全局事务)可以被拆分成许多个本地事务，运行在不同的AP和RM上。每个本地事务的ACID很好实现，但是全局事务必须保证其中包含的每一个本地事务都能同时成功，若有一个本地事务失败，则所有其它事务都必须回滚。但问题是，本地事务处理过程中，并不知道其它事务的运行状态。因此，就需要通过CRM来通知各个本地事务，同步事务执行的状态。
XA
两阶段提交
TM掌控所有的RM
Base理论
BA
要保证基本业务可用（支持分区部分失败）
S
柔性状态（状态允许短时间的不同步、异步）
可查型操作
单笔操作
批量查询
操作的是唯一的，确定时间的
幂等操作
f(f(s)) = f(x)
重复调用多次产生的业务结果与调用一次产生的业务结果都是一样的
方式一：通过业务操作本身实现幂等特性
方式二：系统缓存所有的请求和处理结果、检测到重复请求的话，自动返回之前的处理结果。
TCC操作
也是两阶段提交
try执行业务
confirm
cancel
它是位于业务层，没有准备阶段，灵活性选择业务资源（灵活锁定）
可补偿性操作
真正执行业务
业务补偿
约束
Tcc中的confirm和cancel也可以看作是一种可补偿性的操作
E
最终一致性
原子性和持久性必须保证，为了可用性和性能只能降低一定的一致性和隔离性的要求
CAP定理
分布式系统中，最重要的是满足业务需求，而不是追求抽象、绝对的系统特性。以下三个性质不可能全部做到
CAP原理指出在一个分布式系统中，最多只能同时满足其中两个属性，而无法同时满足三个属性。这是由于在面对网络分区时，为了保持系统的可用性，必须允许部分节点在分区后继续处理请求，这可能导致数据的不一致性，因此无法同时满足一致性和可用性。
一致性 Consistency
可用性 Availability
分区容错性 Partition tolerance
怎样才能同时满足CA？
除非是单点架构
如何满足CP ？
对一致性要求高的场景。例如 我们的Zookeeper就是这样的，在服务节点见中间的数据同步时，服务对外不可用。
如何满足AP ？
对可用性要求较高的场景，例如：Eureka 必须保证注册中心随时可用，不然拉取不到服务器就可能出问题。
https://note.youdao.com/s/6jU61ZYi
0 条评论
下一页
