这次使用分布式事务框架过程中了学习了一些分布式事务知识，所以本文我们就来聊聊分布式事务那些事。首先我们先回顾下什么是事务。
事务什么是事务？这个作为后端开发，日常开发中只要与数据库有交互，肯定就会使用过事务。现在摘抄一段wiki的解释，解释下什么是事务。
是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成
数据库系统具有事务特性，这是其有别与文件系统重要特性。传统的文件系统，如果正在写文件，操作系统突然崩溃，此时文件可能被破坏。数据库系统引入事务特性，可以保证数据库从一种状态转换为另一种状态。在提交工作时,可以确保要么所有修改都被保存，要么所有都不保存。
通常一个事务会有多个读写操作构成。
事务具有四个基本特性，俗称ACID。
A(Atomicity):原子性。事务会被当做一个整体，要么所有语句都成功，要么都失败，不能存在部分语句成功，部分失败的情况。
C(Consistenc):一致性。数据库的状态从一种状态转变为另外一种状态，事务开始之前和是事务结束之后，数据库完整性约束不变。什么叫数据库完整性约束不变？举个例子，若一个表姓名字段为唯一约束，若在事务提交或回滚后，姓名字段变成非唯一了，这就破坏数据库的完整性约束。
I(Isolation):隔离性。多个并发事务执行，互不影响。
D(Durability):持久性。事务提交之后，其对数据库相关修改能永久保存在数据库。所以该特性需要数据库系统可以在崩溃时需要恢复时也能提交的数据都不丢失。
因此早期我们的系统只在存在一个数据源情况下，这个时候可以依靠数据库系统事务来保证业务的正确性。
但是随着业务的不断扩展，我们业务的一个单表可能就存在千万数据，在使用再使用一个数据库实例，就会可能存在性相关能问题。这个时候我们就会考虑分库分表。但是这样就有可能导致，单个应用连接多个数据源的情况。如下图示例。
上图一次购买过程，商家余额表与用户余额表处于两个单独的数据库实例中，这样单独的事务能保证扣减商家余额或用户余额要么扣减成功，要么扣减失败。但是我们却无法保证两个事务同时成功或同时失败。
还有一种情况，随着系统越来越庞大，我们会选择将系统应用拆分多个微服务，让单个应用只操作一个数据源。这个时候我们就会碰到，一次业务调用，将会调用多个应用，每个应用单独操作数据源的情况，如下图。
这种情况下我们更加不能保证所有调用都成功。
由上面的例子下我们可以看出，随着业务发展，传统的单机事务已经无法满足我们的业务的需求，这个时候我们就需要分布式事务来保证。
分布式事务摘抄一段 wiki 上解释。
A distributed transaction is a database transaction in which two or more network hosts are involved.
我们先来讲下实现分布式事务一些理论基础。
分布式事务技术理论CAP 定理。在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。
摘录极客时间从0开始学架构第22章解释
虽然 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来思考，我们会发现必须选择 P（分区容忍）要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证 C，系统需要禁止写入，当有写入请求时，系统返回 error（例如，当前系统不允许写入），这又和 A 冲突了，因为 A 要求返回 no error 和 no timeout。因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构
BASE 理论，分别是以下三个单词的缩写。
Basically Available（基本可用）：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
Soft state（软状态）：允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。
Eventually consistent（最终一致性）：最终一致是指经过一段时间后，所有节点数据都将会达到一致。