一、整体背景

最近在分布式事务领域这块的了解比较少，对自己来说是一个业务盲点，所以想抽空学习以及整理下关于分布式事务的相关知识。

1、分布式事务的发展

总所周知，我们为什么要考虑分布式事务，从一开始发展来说，项目都是单体项目，举最简单基本的商城系统来说，单体架构图如下所示

一个单体系统包含订单、商品、用户模块，然后通过访问数据库，通过事务控制，我们就很容易理解，如果用上Spring框架，我们只需要@Transactional注解进行处理就能实现本地事务。

但随着业务量的增大以及项目的拆分，单体项目已经不再能满足日常的业务量了，可能项目架构就会变成如下图所示

这种情况下，我们常规的本地事务就没法解决跨服务的事务一致性问题，所以于此才引入分布式事务解决方案，说白了分布式事务就是为了解决我们跨应用数据库事务的问题而提出来的

二、常用的分布式事务解决方案对比

1、分布式协议

分布式协议按照我的理解可以理解为一种约定，或者规范，市面上的数据库厂商会遵循这种约定进行实现，为实现分布式事务奠定基础，其中协议包括如下

• 2PC（Two-Phase Commit, 2PC）
• 3PC（Three-Phase Commit, 3PC）
• TCC是一种补偿式分布式事务解决方案，通过Try-Confirm-Cancel三个阶段确保事务一致性(应用级别，需手动实现)

2、分布式具体解决方案

•  阿里中间件Seata提供的解决方案
  • ‌XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入。
  • ‌TCC模式：最终一致的分阶段事务模式，有业务侵入。
  • AT模式：最终一致的分阶段事务模式，无业务侵入，是Seata的默认模式。
  • SAGA模式：长事务模式，有业务侵入。

三、分布式事务相关理论定理

1、CAP定理

‌CAP定理是分布式系统设计中的一个基本理论，它指出在一个分布式系统中，‌一致性（Consistency）、‌可用性（Availability）和‌分区容错性（Partition tolerance）这三个关键属性最多只能同时满足两个，而无法三者兼得。这个定理对于理解和设计分布式系统具有重要指导意义。

CAP定理的基本概念

• 一致性（Consistency）：确保所有副本在更新操作后保持数据的一致状态。
• 可用性（Availability）：系统能够响应任何请求，无论成功还是失败都会返回响应。
• 分区容错性（Partition tolerance）：系统能够在网络分区的情况下继续运行，即部分节点之间的通信中断时，系统仍能提供服务。

为什么不能同时满足

在分布式系统中，由于网络延迟、故障等原因，很难保证所有节点在所有时间都保持数据一致。因此，CAP定理指出，一个分布式系统最多只能同时满足两个属性，而必须牺牲第三个属性。这种权衡取决于系统的具体需求和应用场景。

CAP定理对分布式系统设计的影响

• CA（一致性和可用性）：适用于需要强一致性的场景，如金融交易系统。
• CP（一致性和分区容错性）：适用于可以容忍一定延迟的系统，如区块链。
• AP（可用性和分区容错性）：适用于对数据一致性要求不高的场景，如社交媒体应用。

实例分析

• NoSQL数据库：许多NoSQL数据库如Cassandra和MongoDB采用AP策略，以提供高可用性和分区容错性，同时牺牲了一定程度的一致性。这种设计选择适合于需要快速响应和数据可扩展性的应用场景。

CAP定理是分布式系统设计和开发中的基础理论，它帮助开发人员根据系统的具体需求和约束做出合理的权衡和选择。在实际应用中，理解CAP定理及其对系统设计的影响是至关重要的

2、BASE理论

BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。基本可用(Basically Available)： 基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
软状态(Soft State)： 软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。MySQL Replication 的异步复制也是一种体现。
最终一致性(Eventual Consistency)： 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

五、总结

整体来说分布式事务这块对于自己来说还是没那么熟悉的领域，在工作中也算接触了大型企业系统的研发，但是也没有使用业界主流的分布式事务进行处理，更多的是靠消息的回调，定时任务的补偿达到最终一致性来解决问题，并没有做到强一致性。后续从Seata这个现有中间件下手学习，希望借此慢慢学习以及慢慢深入这块，填充自己的知识领域。