1、什么是分布式事务
分布式事务就是指事务的资源分别位于不同的分布式系统的不同节点之上的事务；
2、分布式事务产生的原因
2.1、数据库分库分表
在单库单表场景下，当业务数据量达到单库单表的极限时，就需要考虑分库分表，将之前的单库单表拆分成多库多表；
分库分表之后，原来在单个数据库上的事务操作，可能就变成跨多个数据库的操作，此时就需要使用分布式事务；
2.2、业务服务化
业务服务化即业务按照面向服务（SOA）的架构拆分整个网站系统；
比如互联网金融网站SOA拆分，分离出交易系统、账务系统、清算系统等，交易系统负责交易管理和记录交易明细，账务系统负责维护用户余额，所有的业务操作都以服务的方式对外发布；
一笔金融交易操作需要同时记录交易明细和完成用户余额的转账，此时需要分别调用交易系统的交易明细服务和账务系统的用户余额服务，这种跨应用、跨服务的操作需要使用分布式事务才能保证金融数据的一致性；
3、分布式事务原理简介
数据库本地事务（ACID）
说到数据库事务就不得不说，数据库事务中的四大特性 ACID：
A：原子性(Atomicity)，一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。
事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
就像你买东西要么交钱收货一起都执行，要么发不出货，就退钱。
C：一致性(Consistency)，事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。
如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。
如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。
I：隔离性(Isolation)，指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。
由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。
打个比方，你买东西这个事情，是不影响其他人的。
D：持久性(Durability)，指的是只要事务成功结束，它对数据库所做的更新就必须保存下来。
即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。
打个比方，你买东西的时候需要记录在账本上，即使老板忘记了那也有据可查。
分布式事务的基础
从上面来看分布式事务是随着互联网高速发展应运而生的，这是一个必然。
我们之前说过数据库的 ACID 四大特性，已经无法满足我们分布式事务，这个时候又有一些新的大佬提出一些新的理论。
CAP 理论
在分布式系统中，一致性(Consistency)、可用性(Availability)和分区容忍性(Partition Tolerance)3 个要素最多只能同时满足两个，不可兼得。其中，分区容忍性又是不可或缺的。
一致性：分布式环境下，多个节点的数据是否强一致。
可用性：分布式服务能一直保证可用状态。当用户发出一个请求后，服务能在有限时间内返回结果。
分区容忍性：特指对网络分区的容忍性。
举例：Cassandra、Dynamo 等，默认优先选择 AP，弱化 C;HBase、MongoDB 等，默认优先选择 CP，弱化 A。
BASE 理论
核心思想：
基本可用(Basically Available)：指分布式系统在出现故障时，允许损失部分的可用性来保证核心可用；
软状态(Soft state)：指允许分布式系统存在中间状态，该中间状态不会影响到系统的整体可用性；
最终一致性(Eventual consistency)：指分布式系统中的所有副本数据经过一定时间后，最终能够达到一致的状态；
原子性（A）与持久性（D）必须根本保障；
为了可用性、性能与降级服务的需要，只有降低一致性( C ) 与 隔离性( I ) 的要求；
酸碱平衡(ACID-BASE Balance)；
BASE 是对 CAP 中 AP 的一个扩展
一致性模型
数据的一致性模型可以分成以下三类：
强一致性：数据更新成功后，任意时刻所有副本中的数据都是一致的，一般采用同步的方式实现。
弱一致性：数据更新成功后，系统不承诺立即可以读到最新写入的值，也不承诺具体多久之后可以读到。
最终一致性：弱一致性的一种形式，数据更新成功后，系统不承诺立即可以返回最新写入的值，但是保证最终会返回上一次更新操作的值。
分布式系统数据的强一致性、弱一致性和最终一致性可以通过 Quorum NRW 算法分析。