笔记
分布式事务
00 min
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问题常用解决方案