分布式：保证分布式事务的一致性

文章目录

- - 保证分布式事务的一致性

本篇开始进行分布式的学习，由于时间原因，我也没有过多时间深入学习，因此打算在有时间就进行这块内容的学习，学习的切入点也是从一些问题开始进行切入学习吧

保证分布式事务的一致性

XA协议

XA协议（eXtended Architecture）是一种用于分布式事务处理的标准协议，旨在确保多个资源管理器（如数据库、消息队列等）之间的事务一致性。它提供了一种机制，使得在分布式环境中可以同时提交或回滚多个资源上的事务操作，从而保证了分布式事务的原子性、一致性、隔离性和持久性（ACID特性）。

XA协议由X/Open组织（现已并入The Open Group）制定，并得到广泛支持和应用。在XA协议中，通常包含以下几个关键角色：

事务管理器（Transaction Manager, TM）：负责协调和管理分布式事务的提交和回滚。它是全局的调度者，与所有参与者（即资源管理器）进行通信，确保事务的一致性和完整性。
资源管理器（Resource Manager, RM）：负责管理资源，如数据库、消息队列等。在XA协议中，资源管理器需要实现XA接口，以便与事务管理器进行交互。
应用程序（Application Program, AP）：负责执行具体的业务逻辑，并通过事务管理器与资源管理器进行交互，以完成分布式事务。

XA协议的工作流程大致可以分为两个阶段：

准备阶段（Prepare Phase）：
- 事务管理器向所有资源管理器发送准备请求，询问它们是否可以提交事务。
- 资源管理器执行事务操作，并记录必要的恢复信息（如撤销日志或重做日志），以便在需要时能够回滚事务。
- 如果资源管理器确定能够提交事务，则向事务管理器发送准备成功（Prepared）的响应；如果无法提交，则发送准备失败（Abort）的响应。
提交阶段（Commit Phase）：
- 如果所有资源管理器都准备成功，事务管理器会向所有资源管理器发送提交请求。
- 资源管理器收到提交请求后，执行事务的提交操作，并释放事务执行期间占用的资源。
- 如果在准备阶段有资源管理器准备失败，或者在提交阶段事务管理器没有收到所有资源管理器的成功响应，则事务管理器会指示所有已经准备好提交的资源管理器进行回滚。

XA协议通过这两个阶段的协调，确保了分布式事务的一致性和可靠性。然而，它也存在一些局限性，如单点故障（事务管理器是关键节点）、阻塞问题（在准备阶段需要等待所有资源管理器的响应）等。因此，在实际应用中，需要根据具体场景和需求来选择合适的事务处理方案。

两阶段提交

MySQL的两阶段提交 ：你提到的MySQL在复制过程中使用的两阶段提交，主要目的是为了保持主从数据的一致性。在prepare阶段，主服务器将事务写入redo log并通知从服务器开始应用binlog。在commit阶段，当主服务器确认从服务器已接收到binlog并开始应用（或者至少已经记录了binlog的接收）后，主服务器才会提交事务，并通知从服务器事务已提交。
分布式事务的两阶段提交（2PC） ：在分布式系统中，两阶段提交（2PC）是确保跨多个资源管理器（如数据库、消息队列等）的事务一致性的标准协议。它确实包括prepare和commit（或abort）两个阶段。如果在prepare阶段任何参与者失败，则协调者会发送abort消息给所有参与者，回滚事务。
三阶段提交 ：三阶段提交（3PC）是在两阶段提交的基础上增加了一个pre-commit阶段，主要用于解决在prepare和commit之间可能出现的网络分区问题，以及减少不必要的资源锁定时间。然而，3PC并未被广泛采用，因为它引入了额外的复杂性和可能的性能问题。

XA协议定义了分布式事务处理的接口和规则，而两阶段提交协议则是这些规则在具体实现时采用的一种机制。这种关系使得XA协议能够灵活地应用于不同的分布式事务处理场景，并确保事务的一致性和可靠性。

TCC模式

TCC模式是一种分布式事务处理模式，它将事务的提交过程分为三个阶段：Try、Confirm和Cancel。这三个阶段并不直接对应于三阶段提交（3PC）的canCommit、preCommit和commit/abort阶段，而是有着不同的职责和目的。

Try阶段：在这个阶段，事务的发起方会尝试锁定或预留所需的资源。这并不意味着事务已经被提交，而只是确保在后续阶段能够成功执行事务。如果Try阶段成功，系统会认为事务有很大可能成功完成；如果失败，则会进入Cancel阶段。
Confirm阶段：在Try阶段成功后，Confirm阶段会实际执行事务操作并提交数据。由于Try阶段已经确保了资源的可用性，因此Confirm阶段通常不会失败（除非发生系统级故障）。Confirm阶段完成后，事务即被视为成功提交。
Cancel阶段：如果Try阶段失败或Confirm阶段由于某种原因未能成功执行，则会进入Cancel阶段。在这个阶段，系统会释放Try阶段预留的资源，并回滚已执行的操作，以确保系统状态的一致性。

TCC模式的优点包括不需要数据库支持XA协议、性能好、锁粒度小等。然而，它也需要业务代码的支持，实现起来相对复杂，且需要处理幂等性、空回滚、防悬挂等问题。

SAGA模式

SAGA模式是一种用于处理分布式事务的长事务解决方案。与TCC模式不同，SAGA模式通过一系列本地事务和补偿操作来确保全局事务的一致性。

基本概念：在SAGA模式中，一个全局事务被分解为一系列本地事务（也称为子事务或SAGA步骤）。每个本地事务都有对应的补偿操作，用于在本地事务失败时恢复系统状态。
执行流程：全局事务的执行从第一个本地事务开始。如果当前本地事务成功，则继续执行下一个本地事务；如果失败，则执行当前本地事务的补偿操作，并尝试回滚之前的所有成功本地事务及其补偿操作（这通常是一个递归过程）。
优点：SAGA模式允许系统以更灵活的方式处理分布式事务，特别是在涉及多个服务且服务之间可能存在复杂依赖关系的场景中。此外，它不需要所有服务都同时在线或支持XA协议。
缺点：SAGA模式的实现相对复杂，需要仔细设计每个本地事务及其补偿操作，以确保在失败情况下能够正确恢复系统状态。此外，由于它依赖于补偿操作来恢复系统状态，因此在某些情况下可能会产生额外的性能开销和复杂性。