数据库事务要满足几个要求：ACID
Atomic(原子性) 事务必须是原子的工作单元
Consistent(一致性) 事务完成时，必须使所有数据都保持一致状态
Isolation(隔离性) 并发事务所做的修改必须和其他事务所做的修改是隔离的
Duration（持久性） 事务完成之后，对系统的影响是永久性的
Mysql里的事务处理过程
1.记录redo和undo log文件，确保日志在磁盘上的持久化
2.更新数据记录
3.提交事务 ，redo 写入commit记录
2PC（two -phase-commit）
屏幕快照 2019-05-26 下午5.18.58.png
AP application
RM resouces manager 资源管理器。 数据库
TM transaction manager 事务管理器，事务协调者
阶段一：提交事务请求（投票）
1.TM向所有的AP发送事务内容，询问是否可以执行事务的提交操作，并等待各个AP的响应
2.执行事务
各个AP节点执行事务操作，将undo和redo信息记录到事务日志中，尽量把提交过程中所消耗时间的操作和准备都提前完成后确保后续事务提交的成功率
3.各个AP向TM反馈事务询问的响应
各个AP成功执行了事务操作，那么反馈给TM yes的response；如果AP没有成功执行事务，就反馈TM no的response
阶段二：执行事务提交
假设一个事务的提交过程总共需要30s， 其中prepare操作需要28（事务日志落地磁盘及各种io操作），而真正commit只需要2s，那么，commit阶段发生错误的概率和prepare相比， 2/28 (<10%) .只要第一个阶段成功，那么commit阶段出现失败的概率就非常小，大大增加了分布式事务的成功概率
中断事务提交
屏幕快照 2019-05-26 下午5.22.32.png
2pc存在的问题
a) 数据不一致。在二阶段提交中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。
b) 同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态
c) 二阶段无法解决的问题：协调者在发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交
d) 单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去
3PC(three phase commit)
阶段一：canCommit
阶段二：preCommit
阶段三：doCommit
改进点
a) 增加了超时机制
b) 第二阶段，如果协调者超时没有接受到参与者的反馈，则自动认为失败，发送abort命令
c) 第三阶段，如果参与者超时没有接受到协调者的反馈，则自动认为成功开始提交事务（基于概率）
3pc的问题
相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。
网友评论