分布式事务概述 2023-06-06 默认分类 暂无评论 53 次阅读 ## 理论框架 <h3><a class="cl-offset" name="cl-1"></a>CAP 原则 </h3> CAP 原则又称 CAP 定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、 Partition tolerance（分区容错性），三者不可得兼。 <h3><a class="cl-offset" name="cl-2"></a>BASE 理论 </h3> > Basically Available Soft State Eventual Consistency 的简写： 核心思想是即便无法做到强一致性，但应该采用适合的方式保证最终一致性。 BA：Basically Available 基本可用，分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。 S：Soft State 软状态，允许系统存在中间状态，而该中间状态不会影响系统整体可用性。 E：Eventual Consistency 最终一致性，系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。 BASE 理论本质上是对 CAP 理论的延伸，是对 CAP 中 AP 方案的一个补充。 <h3><a class="cl-offset" name="cl-3"></a>分布式事务 </h3> 分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。例如在大型电商系统中，下单接口通常会扣减库存、减去优惠、生成订单 id, 而订单服务与库存、优惠、订单 id 都是不同的服务，下单接口的成功与否，不仅取决于本地的 db 操作，而且依赖第三方系统的结果，这时候分布式事务就保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 **支付过程的超时问题**  如果在上述调用的过程中出现超时 将导致用户看到的状态和实际情况不匹配 <h2><a class="cl-offset" name="cl-4"></a>常见分布式事务解决方案 </h2> - 两阶段提交（2PC, Two-phase Commit） - TCC 补偿模式 - 基于本地消息表实现最终一致性 - 最大努力通知 - 基于可靠消息最终一致性方案 <h3><a class="cl-offset" name="cl-5"></a>两阶段提交(2PC) / XA </h3> > 二阶段提交(Two-phaseCommit)是指，在计算机网络以及数据库领域内， > 为了使基于分布式系统架构下的所有节点在进行事务提交时**保持一致性**而设计的一种算法(Algorithm)。 > 通常，二阶段提交也被称为是一种协议(Protocol))。 > 在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败， 却无法知道其他节点的操作的成功或失败。 > **当一个事务跨越多个节点时**，**为了保持事务的ACID特性**， > 需要**引入一个作为协调者的组件**来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点 > 是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。 > > 因此，**二阶段提交的算法思路可以概括为：** **参与者将操作成败通知协调者， > 再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。**   存在的问题: **同步阻塞:** 当一个占用公共资源，其他参与者就只能阻塞等待资源释放 **单点故障:** 一旦事务管理器出现故障，整个系统不可用 **参与者故障**: 由于 协调者 无法收集到所有 参与者 的反馈，会陷入阻塞情况。 解决方案:引入超时机制,如果协调者在超过指定的时间还没有收到参与者的反馈, 事务就失败,向所有节点发送终止事务请求。 **协调者故障**: 解决方案:引入协调者备份,同时协调者需记录操作日志. 当检测到协调者宕机一段时间后，协调者备份取代协调者， 并读取操作日志，向所有参与者询问状态。 **数据不一致:** 在阶段二，如果事务管理器只发送了部分 commit 消息， 此时网络发生异常，那么只有部分参与者接收到 commit 消息， **不确定性**: 当协事务管理器发送 commit 之后，并且此时只有一个参与者收到了 commit， 那么当该参与者与事务管理器同时宕机之后，重新选举的事务管理器无法确定该条消息是否提交成功。 <h3><a class="cl-offset" name="cl-6"></a>TCC (补偿事务) </h3> 全称为: Try Confirm Cancel  Try 阶段： 尝试执行，完成所有业务检查（一致性）, 预留必须业务资源（准隔离性） Confirm 阶段： 确认执行真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源， Confirm 操作满足幂等性。要求具备幂等设计，Confirm 失败后需要进行重试。 Cancel 阶段： 取消执行，释放 Try 阶段预留的业务资源 Cancel 操作满足幂等性 Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致。 <h3><a class="cl-offset" name="cl-7"></a>本地消息表 </h3>   <h3><a class="cl-offset" name="cl-8"></a>可靠消息最终一致性 </h3>  [rocketmq的事务消息原理_哔哩哔哩_bilibili](https://www.bilibili.com/video/BV1aq4y1K7jB/?spm_id_from=333.337.search-card.all.click&vd_source=f1a7951aa84af4793b91a3e046fcd901) 阿里巴巴的RocketMQ的事务消息 <h2><a class="cl-offset" name="cl-9"></a>各种方案缺点 </h2> | 分布式解决方案 | 缺点 | | ------------ | ---------------------------------------------------------------------------------------- | | 2PC 两阶段提交 | 业务逻辑阻塞<br>**网络抖动导致的数据不一致**<br>**单点故障的风险** | | TCC分布式事务 | 侵入性强，每个事务都必须实现try，confirm，cancel3个方法<br>为了达到事务的一致性要求, 必须实现幂等性<br>事务管理器要记录事务日志，必定会损耗一定的性能 | | 基于本地消息的最终一致性 | 定时任务 频繁的读写消息会给数据库造成压力 | | 可靠消息的最终一致性 | 依赖RocketMQ | | 最大努力通知 | | <h2><a class="cl-offset" name="cl-10"></a>参考链接 </h2> [Java 全栈知识体系-分布式系统](https://pdai.tech/md/arch/arch-z-transection.html) [分布式事务(1)---2PC和3PC原理](https://www.cnblogs.com/qdhxhz/p/11167025.html) [分布式事务(3) :TCC 补偿式事务](https://juejin.cn/post/7031488136072921101) [慕课Go体系课: 1. CAP和BASE理论](https://www.yuque.com/bobby-zpcyu/zwo4u2/nkrg80) 文章目录 CAP 原则 BASE 理论 分布式事务 常见分布式事务解决方案 两阶段提交(2PC) / XA TCC (补偿事务) 本地消息表 可靠消息最终一致性 各种方案缺点 参考链接 标签: 分布式 转载请注明文章来源 本作品采用 知识共享署名-相同方式共享 4.0 国际许可协议 进行许可。
评论已关闭