笔记
分布式事务
00 分钟
2023-3-2
2024-1-9
type
status
date
slug
summary
tags
category
icon
password

前言

在分布式系统中，事务处理需要保证数据的一致性和完整性。传统的关系型数据库中，采用ACID（原子性、一致性、隔离性、持久性）的事务模型，可以保证数据的一致性。但在分布式系统中，由于多个节点之间的通信可能存在延迟、丢包等问题，因此需要采用分布式事务来保证数据的一致性。
在分布式系统中，由于涉及到多个节点的操作，需要确保数据的一致性和完整性。常见的分布式事务相关概念包括：
  • ACID：指原子性、一致性、隔离性和持久性，是关系型数据库事务的基本特征；
  • CAS：指比较并交换，是一种乐观锁机制；
  • ABA：指在CAS中，由于线程A在比较并交换时被挂起，线程B将变量值由A改为B再改回A，在A恢复后继续CAS操作，导致操作成功但是实际值并未发生变化的情况；
  • CAP：指一致性、可用性和分区容错性，是分布式系统中三个基本特征，任何分布式系统只能同时满足其中两个特征；
  • BASE：指基本可用、软状态和最终一致性，是对CAP中可用性和一致性的一种妥协；
  • XA：指eXtended Architecture的缩写，是一种由IBM提出的分布式事务处理标准；
  • 2PC：指两阶段提交，是一种常见的分布式事务解决方案，包括投票和提交两个阶段；
  • 3PC：指三阶段提交，是在2PC的基础上增加了超时机制，以解决2PC存在的单点故障问题；
  • TCC：指尝试、确认和取消，是一种通过补偿事务实现的分布式事务解决方案。
在实际应用中，需要根据具体业务场景选择合适的分布式事务方案，以保证数据的一致性和完整性。

BASE

在分布式系统中，CAP原则告诉我们，分布式系统只能同时满足一致性、可用性和分区容错性中的两个。因此，在某些场景下，我们可以牺牲一致性来换取可用性和分区容错性。BASE（Basically Available, Soft state, Eventually consistent）就是这样的一种设计思想。
  • 基本可用（Basically Available）：系统能够保证基本的可用性，即在出现故障的情况下，系统仍然能够保证服务可用，但是可能无法保证服务的吞吐量和延迟。
  • 软状态（Soft state）：系统中的数据会发生中间状态，且这种中间状态的存在不会影响系统的整体可用性。例如，在分布式缓存系统中，缓存的数据可能会失效，此时系统中存在缓存和数据库中数据不一致的情况，但是这种情况不会影响系统的整体可用性。
  • 最终一致性（Eventually consistent）：系统中的数据最终会达到一致的状态。在分布式系统中，由于网络延迟等问题，系统中的数据可能会存在不一致的情况。BASE的设计思想是通过一定的手段（例如，数据版本控制和补偿机制）最终将系统中的数据达到一致的状态。
与ACID事务相比，BASE可以提供更高的可用性和扩展性，但是牺牲了一致性。在实际应用中，需要根据具体业务场景来选择合适的事务处理方案。

XA

XA事务是由IBM提出的分布式事务处理标准，其核心思想是将分布式事务划分为全局事务和局部事务两个层次。全局事务是由事务管理器（Transaction Manager）控制的，而局部事务是由本地资源管理器（Resource Manager）控制的。
在XA事务中，全局事务由应用程序发起，调用事务管理器的API开始事务。事务管理器会向所有涉及到的资源管理器发送开始事务的请求，如果所有资源管理器都能够接受该请求，则全局事务开始执行。在全局事务执行过程中，如果任何一个局部事务执行失败，则所有局部事务都会被回滚，全局事务也会被回滚。
XA事务协议相比于2PC和3PC协议，具有更高的可靠性和稳定性。但是，XA事务协议的实现比较复杂，需要支持多条数据库连接。
在实际应用中，需要根据具体业务场景选择合适的分布式事务方案，以保证数据的一致性和完整性。

2PC

2PC是最早被提出的分布式事务协议之一，它的核心思想是协调者和参与者之间的协作。2PC协议分为两个阶段：
  1. 准备阶段：协调者向所有参与者发送prepare请求，询问是否可以执行事务。参与者执行本地事务，并将事务执行结果和预提交请求反馈给协调者。
  1. 提交阶段：如果所有参与者都可以执行事务，则协调者向所有参与者发送commit请求，要求参与者正式提交事务。如果任何一个参与者不能执行事务，则协调者向所有参与者发送abort请求，要求参与者放弃事务。
2PC协议的优点是简单易懂，但缺点也是显而易见的。首先，2PC需要所有的参与者都能够接收到协调者的消息，如果有一个参与者宕机，则整个事务会被阻塞。其次，2PC需要等待所有参与者的响应，如果任何一个参与者无法响应，则整个事务会因为超时而被回滚。

3PC

为了解决2PC的问题，3PC协议在2PC的基础上进行了改进。3PC协议分为三个阶段：
  1. CanCommit阶段：协调者向所有参与者发送CanCommit请求，询问是否可以执行事务。参与者执行本地事务，并将事务执行结果和是否可以提交事务的决策反馈给协调者。
  1. PreCommit阶段：如果所有参与者都可以执行事务，则协调者向所有参与者发送PreCommit请求，要求参与者正式提交事务。如果任何一个参与者不能执行事务，则协调者向所有参与者发送Abort请求，要求参与者放弃事务。
  1. DoCommit阶段：如果所有参与者都已经准备好提交事务，则协调者向所有参与者发送DoCommit请求，要求所有参与者提交事务。
3PC协议相比于2PC协议，增加了CanCommit阶段，通过询问参与者是否可以提交事务来预防超时和宕机等问题。但是，3PC协议的实现比2PC更加复杂，并且在网络延迟较大的情况下，可能会出现不可预测的问题。
总的来说，2PC和3PC都是常见的分布式事务协议，根据实际需求选择合适的协议可以保证数据的一致性和完整性。

TCC

TCC是一种通过补偿事务实现的分布式事务解决方案。TCC是指尝试、确认和取消三个阶段。
  • 尝试（Try）阶段：在第一阶段，系统会尝试执行所有分支事务，但是不会将分支事务提交到数据库中。如果所有分支事务都执行成功，则进入确认（Confirm）阶段。否则进入取消（Cancel）阶段。
  • 确认（Confirm）阶段：在第二阶段，系统会将所有分支事务提交到数据库中，此时整个事务提交成功。如果任何一个分支事务提交失败，则进入取消阶段。
  • 取消（Cancel）阶段：在第三阶段，系统会撤销所有分支事务的执行。如果任何一个分支事务撤销失败，则需要手动处理异常。
TCC的优点是可以提供更高的性能和可用性，并且不需要支持多条数据库连接。但是，TCC的实现比较复杂，在处理各种异常情况时需要进行详细的设计和考虑。
在实际应用中，需要根据具体业务场景选择合适的分布式事务方案，以保证数据的一致性和完整性。

RocketMQ事务消息

RocketMQ的事务消息是一种特殊的消息类型，用于实现分布式事务。
RocketMQ事务消息的实现机制是先发送半消息，等待事务执行结果后再提交或回滚。半消息发送后，生产者需要执行本地事务，然后根据本地事务的执行结果来决定提交还是回滚。如果事务执行成功，则提交半消息，否则回滚半消息。
在RocketMQ中，事务消息的发送流程如下：
  1. 发送半消息：生产者发送半消息到MQ服务器。
  1. 执行本地事务：生产者执行本地事务，根据事务执行结果决定是提交还是回滚。
  1. 提交或回滚半消息：如果本地事务执行成功，则提交半消息；否则回滚半消息。
在消费端，RocketMQ会将事务消息的状态（提交或回滚）持久化到消息服务器中。消费者在消费事务消息时，可以根据消息的状态来判断是否需要进行后续的处理。
RocketMQ事务消息的实现过程相对复杂，但是也能够有效地实现分布式事务的处理。在实际应用中，需要根据具体业务场景选择合适的分布式事务方案，以保证数据的一致性和完整性。
上一篇
RocketMQ定时消息
下一篇
Redis缓存热key问题常用解决方案