无法在事务中执行过程 sys.sp_addlogin_分布式事务学习笔记

分布式事务

事务的基本特性：

• Atomicity（原子性）:是说事务是一个不可分割的整体，所有操作要么全做，要么全不做；只要事务中有一个操作 出错，回滚到事务开始前的状态的话，那么之前已经执行的所有操作都是无效的，都应该回滚到开始前的状态。
• Consistency（一致性）：是说事务执行前后，数据从一个状态到另一个状态必须是一致的，比如A向B转账（A、B 的总金额就是一个一致性状态），不可能出现A扣了钱，B却没收到的情况发生。
• Isolation（隔离性）：多个并发事务之间相互隔离，不能互相干扰。关于事务的隔离性，可能不是特别好理解，这里的并发事务是指两个事务操作了同一份数据的情况；而对于并发事务操作同一份数据的隔离性问题，则是要求不能出现脏读、幻读的情况，即事务A不能读取事务B还没有提交的数据，或者在事务A读取数据进行更新操作时，不允许事务B率先更新掉这条数据。而为了解决这个问题，常用的手段就是加锁了，对于数据库来说就是通过数据库的相关锁机制来保证。
• Durablity（持久性）：事务完成后，对数据库的更改是永久保存的。

什么是分布式事务

其实分布式事务从实质上看与数据库事务的概念是一致的，既然是事务也就需要满足事务的基本特性（ACID），只 是分布式事务相对于本地事务而言其实分布在不同的节点上。

什么是2PC？

2PC （ Two-Phase Commit缩写）即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。 在计算机中部分关系数据库如Oracle、MySQL支持两阶段提交协议。

2pc两个阶段过程：

1. 准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事 务，并写本地的Undo/Redo日志，此时事务没有提交。 （Undo日志是记录修改前的数据，用于数据库回滚， Redo日志是记录修改后的数据，用于提交事务后写入数 据文件）。
2. 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者 发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操 作，并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。

2pc执行流程

• 阶段一:

1. 事务询问 协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
2. 执行事务 (写本地的Undo/Redo日志) 3. 各参与者向协调者反馈事务询问的响应 总结: 各个参与者进行投票是否让事务进行.

阶段二：

1. 发送提交请求： 协调者向所有参与者发出 commit 请求。
2. 事务提交： 参与者收到 commit 请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。
3. 反馈事务提交结果： 参与者在完成事务提交之后，向协调者发送 Ack 信息。
4. 完成事务： 协调者接收到所有参与者反馈的 Ack 信息后，完成事务。

2PC优点缺点

优点：原理简单，实现方便

缺点：

• 同步阻塞： 1.事务询问 协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。 2.执行事务 (写本地的Undo/Redo日志) 3. 各参与者向协调者反馈事务询问的响应 总结: 各个参与者进行投票是否让事务进行. 1. 发送回滚请求： 协调者向所有参与者发出 Rollback 请求。 2. 事务回滚： 参与者接收到 Rollback 请求后，会利用其在阶段一中记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整 个事务执行期间占用的资源。 3. 反馈事务回滚结果： 参与者在完成事务回滚之后，向协调者发送 Ack 信息。 4. 中断事务： 协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。 从上面的逻辑可以看出，二阶段提交就做了2个事情：投票，执行。 二阶段提交协议存在最明显也是最大的一个问题就是同步阻塞，在二阶段提交的执行过程中，所有参与该事务操作 的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，无法进行其他操作。这种同步阻 塞极大的限制了分布式系统的性能。
• 单点问题： 协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转，更重要的 是：其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作。 数据不一致： 假设当协调者向所有的参与者发送 commit 请求之后，发生了局部网络异常或者是协调者在尚未发送完所有 commit 请求之前自身发生了崩溃，导致最终只有部分参与者收到了 commit 请求。这将导致严重的数据不一致问题。
• 过于保守： 如果在二阶段提交的提交询问阶段中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话， 这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，显然，这种策略过于保守。换句话说，二阶段提 交协议没有设计较为完善的容错机制，任意一个节点失败都会导致整个事务的失败。

什么是三阶段提交？

3PC，全称 “three phase commit”，是 2PC 的改进版，将 2PC 的 “提交事务请求” 过程一分为二，共形成了由CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。

阶段一：CanCommit

第一个阶段： CanCommit ① 事务询问 协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各 参与者的响应。 ② 各参与者向协调者反馈事务询问的响应 参与者在接收到来自协调者的包含了事务内容的canCommit请求后，正常情况下，如果自身认为可以顺利执行事 务，则反馈Yes响应，并进入预备状态，否则反馈No响应。

阶段二：PreCommit

协调者在得到所有参与者的响应之后，会根据结果有2种执行操作的情况：执行事务预提交，或者中断事务 假如所有参与反馈的都是Yes，那么就会执行事务预提交。 1. 执行事务预提交分为 3 个步骤 ① 发送预提交请求： 协调者向所有参与者节点发出preCommit请求，并进入prepared阶段。 ② 事务预提交： 参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。 ③ 各参与者向协调者反馈事务执行的结果： 若参与者成功执行了事务操作，那么反馈Ack 若任一参与者反馈了No响应，或者在等待超时后，协调者尚无法接收到所有参与者反馈，则中断事务 2. 中断事务也分为2个步骤： ① 发送中断请求： 协调者向所有参与者发出abort请求。 ② 中断事务： 无论是收到来自协调者的abort请求或者等待协调者请求过程中超时，参与者都会中断事务

阶段三：do Commit

该阶段做真正的事务提交或者完成事务回滚，所以就会出现两种情况：

• 执行事务提交 ① 发送提交请求： 进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的Ack响应，那么他将从预提交状 态转化为提交状态，并向所有的参与者发送doCommit请求。 ② 事务提交： 参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行过程中占用的事 务资源。 ③ 反馈事务提交结果： 参与者在完成事务提交后，向协调者发送Ack响应。 ④ 完成事务： 协调者接收到所有参与者反馈的Ack消息后，完成事务。
• 中断事务 ① 发送中断请求：协调者向所有的参与者节点发送abort请求。 ② 事务回滚：参与者收到abort请求后，会根据记录的Undo信息来执行事务回滚，并在完成回滚之后释放整个 事务执行期间占用的资源。 ③ 反馈事务回滚结果：参与者在完成事务回滚后，向协调者发送Ack消息。 ④ 中断事务：协调者接收到所有参与者反馈的Ack消息后，中断事务。

注意：一旦进入阶段三，可能会出现 2 种故障： 1. 协调者出现问题 2. 协调者和参与者之间的网络故障 如果出现了任一一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求，针对这种情况，参与者 都会在等待超时之后，继续进行事务提交

2PC对比3PC

• 1.首先对于协调者和参与者都设置了超时机制（在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收 到参与者的消息则默认失败）,主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无 法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而这种机 制也侧面降低了整个事务的阻塞时间和范围。
• 2.通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较 于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的 。 3.PreCommit是一个 缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。 问题：3PC协议并没有完全解决数据不一致问题。

注：知识点来源于java高薪训练营课程。