事务的ACID特性
分布式事务是多个事务的组合，务的特征 ACID，也是分布式事务的基本特征。
原子性（Atomicity）
事务最终的状态只有两种，全部执行成功和全部不执行。
多线程中也有原子性这个概念，某个线程执行操作，其他的线程是无法看中间的这个结果。
而ACID中描述的是客户端发起的一个包含多个写操作的请求时候发生的情况。
例如写了一部分，系统发生故障。这些写操作纳入到一个原子事务，出现状况导致最终没法提交，事务就会终止，数据库丢弃更改。
在出错时中止事务，并将部分完成的写入全部丢弃。
一致性（Consistency）
事务操作前和操作后，数据的完整性保持一致或满足完整性约束。
这种一致性本质上要求应用层来维护状态一致（或者恒等），应用程序有责任正确定义事务来保持一致性。这不是数据库可以保证的事情。
隔离性（Isolation）
当系统内有多个事务并发执行时，多个事务不会相互干扰，即一个事务内部的操作及使用的数据，对其他并发事务是隔离的。
持久性（Durability）
一个事务完成了，那么它对数据库所做的更新就被永久保存下来了。
提供一个安全可靠的地方来存储数据而不用担心数据丢失。
即使存在硬件故障或数据库崩愤，事务所写入的任何数据也不会消失。
上面C所说的是强一致性。
随着分布式系统规模不断扩大，为了适应复杂业务，出现了 BASE 理论，该理论的一个关键点就是采用最终一致性代替强一致性。
强一致性和最终一致性？
刚性事务：遵循ACID原则，强一致性。
柔性事务：遵循BASE理论，最终一致性；与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致。
BASE?
BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的。
- （一）基本可用（Basically Available）：分布式系统出现故障的时候，允许损失一部分功能的可用性。
- 1.1例如双11高峰期，淘宝页面卡顿或者降级处理。
- 1.2淘宝搜索商品，正常0.2s，现在变成了2s.
- （二）柔性状态（Soft State）：在柔性事务中，允许系统存在中间状态，且这个中间状态不会影响系统整体可用性。
- 2.1 简单理解：支付场景中，支付成功，支付失败，支付中。支付中就是软状态。
- （三）最终一致性（Eventual Consistency）：事务在操作过程中可能会由于同步延迟等问题导致不一致，但最终状态下，数据都是一致的 。
- 例如：金融理财产品首页充值金额短时间的不一致。
如何实现分布式事务？
- 基于 XA 协议的二阶段提交协议方法
- 三阶段提交协议方法
- 基于消息的最终一致性方法
两段提交（ two-phase commit, 2PC）
XA协议由Tuxedo首先提出的，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。
所以XA协议有两个部分：
一部分是事务管理器（协调者），一部分是资源管理器。
两阶段提交协议的执行过程，分为投票（voting）和提交（commit）两个阶段。
- 如果所有参与者回答“是”，表示他们已准备好提交，那么协调者接下来在阶段
2会发出提交请求，提交开始实际执行。 - 如果有任何参与者回复 “否”，则协调者在阶段2中向所有节点发送放弃请求。
例子：像结婚一样，主持人询问结婚的夫妇。夫妇都回答我愿意，所有人都见证下可以结婚。
若新郎或者新娘有一个不同意。则仪式终止。
该协议有两个关键的“不归路”。
在说“我愿意”之前，新娘／新郎都有“放弃”承诺的自由， 比
如说“我不愿意 ！ ”。而在做出肯定的承诺之后，就不能随便撤销。
这种分布式事务方案，比较适合单块应用里。因为一般来说，我们的规定和规范，是要求每个服务只能操作自己对应的一个数据库。
三阶段提交方法（Three-phase commit protocol，3PC）
三阶段提交引入了超时机制和准备阶段。
3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。
CanCommit 阶段与 2PC 的投票阶段类似：协调者向参与者发送请求操作（CanCommit 请求），询问参与者是否可以执行事务提交操作，然后等待参与者的响应；参与者收到 CanCommit 请求之后，回复 Yes，表示可以顺利执行事务；否则回复 No。
PreCommit 阶段：协调者根据参与者的回复情况，来决定是否可以进行 PreCommit 操作。
DoCmmit 阶段进行真正的事务提交。
3PC解决了同步阻塞和单点故障的问题。
基于分布式消息的最终一致性方案
引入了一个消息中间件（Message Queue，MQ），用于在多个应用之间进行消息传递。
2PC和3PC是强一致性。而这种方案是最终一致性，并且是通过MQ来进行异步执行。
下单之后会有支付的地方。钱已经到了支付宝。虽然想保证事务，A成功，B系统修改状态，B修改失败。
真的打给支付宝之前，起一个线程挂起，让B修改状态，如果B修改成功。A大给钱到支付宝。如果修改失败，钱不会给支付宝。
目前来看还没有一种很简单、完美的方案可以应对所有场景。
参考：
《Designing Data-Intensive Applications》
中文版本：《数据密集型应用系统设计》
