1 数据库单机事务的实现原理
- 数据库事务的ACID特性；
- MySQL的undo和redo日志的例子；
2 经典的X/OpenDTP事务模型
如果一个事务内的SQL，要分别操作几个独立的数据库服务器上的数据，那这种事务就变成了分布式事务。于是就有技术达人制定了首个分布式事务表中规范-X/OpenDTP，此规范提出的二阶段提交模型(2PC)和“TCP三次握手”一样成为经典。
AP：应用程序。AP负责发送XA指令，触发分布式事务，由TM接收，并发送给相关的RM。
RM：数据库或者很少被使用的消息中间件。负责执行XA指令，每个RM只负责执行自己的指令。
TM：事务管理器、事务协调者，负责接收来自AP发送的XA事务指令，并且调度和协调参与事务的所有RM，确保事务正确完成或者回滚。
X/OpenDTP模型中最为知名的就是两阶段提交协议。在X/OpenDTP模型中，当一个分布式事务所涉及的SQL逻辑都执行完成，并到了RMs最后提交事务的关键时刻，为了避免分布式系统所固有的不可靠性导致事务提交失败，TM决定，实施两步走的方案：
① 先发起投票表决，通知所有RM先完成事务提交过程所涉及的各种复杂的准备工作，比如写redo、undo日志，尽量把提交过程中所有消耗时间的操作和准备都提前完成，确保后面100%成功提交事务。如果准备工作失败，则及时通知TM。
② 真正提交阶段。在该阶段，TM将基于第1阶段的投票结果进行决策，决定提交或者取消事务。当且仅当所有的RM都同意提交时，TM才通知所有RM正式提交，否则TM将通知所有RM取消事务。操作流程如下图所示：
两阶段提交的精妙之处在于，它充分考虑了分布式系统的不可靠因素，并采用非常简单的方式，将导致事务提交失败的概率降到最小。下面给出一个形象的解释过程，来说明二阶段提交时如何做到这一点的：
假如一个事务的提交过程总共需要30秒，其中Prepare阶段需要花费28秒，真正的commit阶段只需要花费2秒，那么Commit阶段发生错误的概率与Prepare阶段相比，只是2/28(7.14%)，也就是说如果Prepare阶段成功了，这Commit阶段失败的概率就很小，从而增加了分布式事务执行成功的概率。
但是二阶段提交也有明显的缺点，在实际应用中使用较少。主要原因如下：
- XA事务的介入增加了TM中间件，使系统变得更复杂了，而且大部分TM中间件都是收费的。
- XA事务应为增加了TM，导致其性能并不高。
3 互联网中分布式事务解决方案
互联网领域有几种流行的分布式解决方案，但未形成像X/OpenDTP那样标准的工业规范。常用的解决方案如下：
解决方案1：业务接口整合，避免分布式事务；
解决方案2：最终一致性方法，eBay模式；
解决方案3：X/OpenDTP模式的支付宝的DTS方案；
