一、什么是分布式事务
在分布式系统中，为了保证数据的高可用，通常我们会将数据保留多个副本，同时这些副本会存储到不同的物理机器上，这就是分布式。
为了保证数据的一致性，需要用到分布式事务
1.1 什么是事务？
事务是指对数据的一系列操作要么全部执行要么全部不执行
1.2事务的实现步骤
1.数据库将一系列要执行的操作全部记录成日志
2.逐条执行这一系列操作
3.如果这一系列操作全部执行成功，那么提交事务，事务也就执行成功，若这一系列操作有某一个失败，则会回滚，将所有的操作全部清除，从而达到要么全部执行要么全部不执行的效果。
分布式事务可以理解为设计多个数据库的事务可以同时根据几个不同的数据库
数据库在物理机器上是相互独立的，一个数据库在执行本地事务时，不知道其他数据库事务的执行情况，为了保持所有的执行一致，引入协调者，由协调者来统一管理多个参与者数据库的执行情况。
1.3 分布式事务 实现：
1.在开启事务之后，本地事务会将所有的操作记录成日志，并且执行事务操作，若执行成功，则向协调者发执行成功的通知，如果所有参与者数据库全部发完了执行成功的通知，那么协调者知道，所有的参与者准备好了，返回提交的消息，数据库会将事务提交，从而分布式事务就能执行成功。
若某一个实例在执行一系列操作失败，则会发送失败的消息，则要求所有的数据库实例操作全部回滚，不论是操作成功还是操作失败，协调者在收到操作失败的通知，就会返回回滚的通知，并且回滚通知是发送给每一个参与者，参与者收到回滚通知后，会根据日志，将刚才所执行的事务操作全部回滚，回到事务启动之前的状态，这就是分布式事务执行失败的状况。
根据协调者的思想，在具体的实现分布式事务上，实现的二阶段提交协议和三阶段提交协议。
二、二阶段提交
一个协调者和多个参与者 参与者1,2,3 二阶段提交时协调者方式的一种实现
1.准备阶段
协调者开启事务，向参与者发出事务执行的请求，参与者收到事务操作后，会将事务操作先记录成日志，然后逐条执行事务，执行完事务之后并不提交，如果一系列操作全部执行成功就会向协调者返回一个同意到的消息，如果有操作执行失败，那么就返回一个终止的消息，在协调者收到所有参与者返回的消息之后，就进入了第二个阶段，提交阶段。
2.提交阶段
协调者会根据所有参与者返回的情况决定下一步操作
1.理想情况，若所有的参与者都返回同意的消息，那么，协调者就知道所有的参与者已经准备好，协调者就会向所有的参与者发回一个提交的消息，参与者在收到提交消息之后，会将本地事务进行提交，并且释放占用的资源，在处理完成之后，会返回一个完成的消息，分布式事务也就完成。
2.异常情况，加入某一个参与者进行一系列操作的过程中，出现了异常，那么返回的不是同意消息，而是终止消息，这个时候为了保证所有参与者数据的一致性，需要协调者将所有参与者已经执行的操作全部撤回，协调者在收到中止消息之后，会向所有的参与者发出回滚的请求，参与者收到回滚请求后，会根据之前记录的日志，将所有的操作进行撤销，所有参与者回到事务启动之前的状态，分布式事务执行失败。
缺点：
1.协调者存在单点故障
在分布式事务中，由于协调者太重要了，一旦协调者出现故障，整个分布式就没办法继续执行。
2.可能出现数据不一致
当所有参与者操作执行完成，并且向协调者发回同意的消息之后，协调者就会向所有的参与者发出提交的请求，假设者提交请求发到了参与者1，参与者2，但当发送给参与者3时，发生了网络异常，提交请求并没有到达参与者3，就会出现参与者1，参与者2都提交了，参与者3却没有提交，这个时候，整个分布式系统中就会出现数据不一致的情况。
三、三阶段提交
因为二阶段提交出现了问题，所以在二阶段的基础上，提出了三阶段提交。
三阶段提交时二阶段提交的改进版本，三个阶段如下：
预备阶段、准备阶段、提交阶段
预备阶段、准备阶段是从二阶段准备阶段拆分出来的
在三阶段中，也是一个协调者和多个参与者 参与者1,2,3
具体逻辑实现：
1.预备阶段
协调者开启事务，向参与者发出询问的请求，询问参与者是否可以执行分布式事务的请求，可以执行就会返回一个同意的消息，如果不可以执行就会返回一个中止的消息，在协调者收到所有参与者的询问相应之后，分布式事务就进入了第二个阶段——准备阶段。
2.准备阶段
假设所有的参与者返回的是同意消息，那么分布式事务开始执行，协调者会向所有参与者发出执行分布式事务的请求，在所有参与者收到请求之后，会将所有的分布式事务记录成日志，然后逐条执行分布式事务操作，执行完之后，先不提交，如果执行成功，就返回一个同意的消息，如果执行本地事务的过程中，出现了异常，返回中止消息，在所有参与者返回本地执行结果之后，分布式事务进入第三个阶段，提交阶段。
3.提交阶段
协调者会根据所有参与者返回的结果来确定下一步的操作
假设所有参与者返回的都是同意的消息，那么协调者就知道所有的参与者准备好了，也就会开始执行提交请求，在参与者收到提交请求之后，就会执行本地事务的提交，并且释放相应的资源，执行完成之后，再返回一个完成的消息，在协调者收到所有的完成消息之后，分布式事务也就执行成功了。这是执行正常的情况。
异常处理
1.在预备阶段，协调者询问参与者是否进行分布式事务时，参与者并没有准备好，参与者会返回一个中止消息。
2.在准备阶段，参与者在执行本地事务时，执行异常，那么返回的不是同意，而是中止消息。
无论是第一种情况，还是第二种情况，一旦协调者收到参与者中止消息，就会中止分布式事务，向所有的参与者发出回滚的请求，参与者在收到回滚请求后，会根据日志，将所有的请求撤销，回到分布式事务开启之前的一致状态，这样，整个分布式事务就执行失败。
三阶段提交相对于二阶段提交的改进：
在三阶段提交增加了预备阶段，一旦进入预备阶段，表示所有参与者已经准备好分布式事务，即所有参与者的本地事务是可以执行成功的，这个时候，如果参与者记录完日志，并且执行完本地事务操作之后，就差提交了，这个时候不管发生协调者异常还是网络异常，协调者提交之后，请求没有到达参与者，参与者在等待超时之后，都会默认提交分布式事务，相对于二阶段提交，若二阶段异常，是没办法继续执行的，所以三阶段提交的改进是在二阶段提交没办法继续执行的情况下，可默认将事务提交。
缺点：
当参与者1执行本地事务异常时，给协调者回复中止信号，恰好协调者也异常，这个时候协调者无法中止整个分布式事务，参与者2，参与者3的事务会默认提交，但是参与者1又是执行异常的情况，整个分布式系统也会不一致，所以三阶段提交虽然改变了二阶段提交的问题，但并没有完美实现分布式事务，不过，理论上如此，在具体的实现中，我们会根据业务，对数据进行补偿和修正，以保证业务的数据最终一致。
