分布式事务思维导图

CAP理论是计算机科学中的一个重要理论，用于指导分布式系统的设计和实现

CAP理论指出，一个分布式系统无法同时满足一致性、可用性和分区容忍性三个特性

CAP理论在分布式系统设计中具有重要意义，帮助设计师在满足不同需求的前提下进行权衡和取舍

CAP理论概述

一致性：指分布式系统中的数据在同一时刻具有相同的值

可用性：指分布式系统在正常运行状态下，用户请求总是能够得到响应

分区容忍性：指分布式系统在遇到网络分区等异常情况时，仍能保持部分可用状态

CAP理论中各特性的定义

在设计分布式系统时，需要根据实际需求，权衡CAP理论中的三个特性，进行相应的取舍

在某些场景中，可能会牺牲一致性或可用性，以换取更高的分区容忍性

在另一些场景中，可能需要牺牲分区容忍性，以换取更高的一致性或可用性

CAP理论在实践中的应用

随着分布式系统的不断发展，CAP理论也在不断完善和扩展

新的理论，如BASE理论，提出了在满足基本可用性和软状态允许的情况下实现最终一致性的解决方案

CAP理论的发展

CAP理论

BASE理论是一种分布式系统架构理论，用于保证系统的可用性和一致性

BASE理论包括基本可用（BA）、软状态（S）和最终一致性（E）三个原则

BASE理论概述

在分布式数据库系统中，BASE理论可以用于保证数据的一致性和可用性

在微服务架构中，BASE理论可以用于处理服务之间的调用和通信问题

BASE理论应用场景

在实现BASE理论时，需要权衡系统的可用性和一致性，以实现最佳的性能和可靠性

在分布式系统中，实现最终一致性需要解决数据复制、数据同步等问题

在微服务架构中，实现BASE理论需要解决服务之间的通信协议、异常处理等问题

BASE理论实现难点

BASE理论

分布式理论基础

DTP模型是一种分布式事务处理模型，用于解决分布式系统中的事务管理问题

DTP模型由三个主要组件构成：应用程序、事务管理器和资源管理器

DTP模型通过定义一系列协议和接口，实现分布式系统中的事务管理功能

DTP模型概述

应用程序：负责定义事务操作和提交、回滚等操作

事务管理器：负责管理和协调分布式事务，包括事务的提交、回滚、隔离等

资源管理器：负责管理和提供分布式系统中的资源，如数据库、消息队列等

DTP模型的组件

应用程序通过事务管理器与资源管理器交互，完成事务操作

事务管理器负责维护事务的状态，并在必要时协调资源管理器进行提交、回滚等操作

资源管理器负责处理事务相关的操作，如数据库的读写、消息队列的发送等

DTP模型的工作原理

DTP模型提供了一种统一的分布式事务处理模型，简化了分布式系统的设计和开发

DTP模型实现了事务的隔离和一致性，提高了分布式系统的可靠性和性能

DTP模型通过定义标准接口和协议，便于不同系统和技术之间的互操作性

DTP模型的优点

DTP模型

XA规范

阶段一：TM（事务管理器）通知各个RM（资源管理器）准备提交它们的事务分支

阶段二：TM根据阶段1各个RM prepare的结果，决定是提交还是回滚事务

同步阻塞

单点故障

数据不一致

存在的问题

2PC

3PC是对2PC的改进版本

引入超时机制，协调者和参与者都引入超时机制

在第一阶段和第二阶段之间插入准备阶段

两个改动点

CanCommit

PreCommit

doCommit

3PC

强一致性模型

try阶段：调用 Try 接口，尝试执行业务，完成所有业务检查，预留业务资源

两者是互斥的只能进入其中一个，且都满足幂等性，允许失败重试

comfirm:对业务系统做确认提交，确认执行业务操作，不做其他业务检查，只使用 Try 阶段预留的业务资源

cancel:在业务执行错误，需要回滚的状态下执行业务取消，释放预留资源

      confirm/cancel失败了如何处理：TCC 中会添加事务日志，如果 Confirm 或者 Cancel 阶段出错，则会进行重试，所以这两个阶段需要支持幂等；如果重试失败，则需要人工介入进行恢复和处理等。

Confirm 或 Cancel 阶段

TCC

     异步化在分布式系统设计中随处可见，基于消息队列的最终一致性就是一种异步事务机制，在业务中广泛应用

核心思想是将分布式事务拆分成本地事务进行处理，通过消息日志的方式来异步执行。

1、上游系统通过本地事务保证业务数据和消息数据同时写入成功

2、上游系统启动定时任务扫描消息表来发送消息到下游，通过MQ服务的发送确认模式，保证消息投递到MQ中，发送成功可以删除本地消息表或设置为已完成

3、下游系统消费消息时需采用主动提交模式，确保消息消费成功，消费不成功，消息会重复投递所以下游系统需要实现幂等性

上述过程MQ很重要，确保消息不丢失，如果不信任MQ的数据保存，一种更严苛的做法是，上游系统删除消息表需要接受下游系统发送的消费完成的消息后，再删除。

本地消息表

RocketMq 事务消息

最大努力通知型( Best-effort delivery)是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果 不影响主动方的处理结果。典型的使用场景：如银行通知、商户通知等一般符合以下特点：1、不可靠消息：业务活动主动方，在完成业务处理之后，向业务活动的被动方发送消息，直到通知N次后不再通知，允许消息丢失(不可靠消息)。2、定期校对：业务活动的被动方，根据定时策略，向业务活动主动方查询(主动方提供查询接口)，恢复丢失的业务消息。

最大努力通知

可靠消息的最终一致性

Paxos

ZAB协议

Raft

Gossip

数据一致性算法

最终一致性模型

Seata

具体实现或框架

分布式事务