二阶段提交在MySQL中的广义应用是怎样的-柠檬ai自媒体

本文是关于两阶段提交在MySQL中的广义应用。边肖觉得很实用，所以想分享给大家学习。希望大家看完这篇文章能有所收获。话不多说，让我们和边肖一起看看。

二阶段提交介绍

2PC的全称是Two-PhaseCommit，翻译为两阶段提交。它是分布式事务XA规范(XA规范是X/Open DTP定义的事务中间件与数据库之间的接口规范)的实现思想，符合CAP理论的CP，是一个强一致性的事务。两阶段提交将分布式事务分为两个阶段，提交-请求阶段和提交阶段。角色分为：事务发起者(AP):定义事务边界(开始和结束)并在事务边界内操作资源。

事务协调者(TM):负责管理事务(提交和回滚)，监控事务执行的进度，事务执行分为事务的唯一标识符。

事务参与者(RM):根据“事务协调器”的命令进行操作，管理本地共享资源，并记录执行日志。

表决阶段: TM:向RM发送准备指令，等待RM的确认。

RM:接收TM发送的指令，锁定资源，执行事务操作，但不提交。记录撤销日志和重做日志，如果事务执行成功，回复“是”；如果失败，请回答“否”。

提交阶段: TM:如果收到所有客户经理的“是”收据，向客户经理发送承诺；如果在超时期限内没有收到RM，或者RM回答“否”，则向RM发送回滚。

RM:根除TM发送的指令，执行提交或回滚操作。对于回滚操作，RM使用投票阶段记录的撤销日志。操作完成后，向TM发送收据“确定”。如果没有收到指示，请等待。

- 二阶段提交的应用 -

在分布式系统中，由于软件或硬件的原因，两个进程之间的数据是不一致的。不一致性问题的解决方案之一是分布式事务，两阶段提交可以满足强数据一致性的需求场景。

- MySQL中binlog和redo log的二阶段提交广义应用 -

MySQL的双日志(binlog和重做日志)记录采用两阶段提交，保证了很强的数据一致性。

Binlog由MySQL Server层记录，与任何存储引擎无关。Binlog主要记录操作日志，有三种格式：语句、行和混合级别。Binlog主要用于故障恢复和主从同步。

重做日志由Innodb存储引擎记录，磁盘最小单位为，MySQL记录以单位访问，重做日志记录修改日志。重做日志的主要用途是进程崩溃恢复，主要用于恢复上的数据。Binlog无法修复上的数据，因此重做日志无法保存它。如果不使用两阶段提交模式，会发生什么？MySQL使用了WAL机制来保证事务的持久性。在正常情况下，binlog和重做日志都有事务开始和结束标识符。如果binlog和重做日志都直接同步写入磁盘，即写入fsync。事务执行过程中，磁盘每次写一次，TPS很低，所以数据库不写。

会这么设计。binlog和redo log在事务执行期间只写内存，当前链接线程不会主动去刷新到磁盘。接收到commit请求之后，当前才将binlog和redo log刷新到磁盘。
如果是先写binlog 再写 redo log。当binlog写入成功后,redo log未写入成功，主节点宕机，此时分两个状态：

事务执行中，由于Innodb存储引擎的恢复是基于redo log的，此时master和slave都没有该数据，数据是一致的。

事务已提交，master基于redo log的恢复后的数据和slave中的数据会出现不一致问题。

如果先写redo log再写binlog。当redo log写入成功后，主节点宕机，此时分两种状态：

事务执行中，由于当前事务没有提交，基于redo log恢复，未提交的时候不会写入，slave和master都没有该数据，数据是一致的。

事务已提交，redo log的事务已提交，binlog 记录的事务没有提交，master节点重启后，该数据会写入master节点，而slave节点没有，数据不一致。

综上所述，只有事务处于已提交状态的情况下，才会出现数据不一致问题。为了保证数据一致性。事务提交时，redo log和binlog的Commit操作需要在同一个事务里，由于binlog和redo log由不同的层记录，需要分布式事务，为了保证数据一致性，二阶段提交满足这样的需求场景。

如图，可以看到redo log的写入有两个阶段，Prepare阶段和Commit阶段，Connect Client扮演事务发起者（AP），MySQL Server扮演事务协调者（TM），binlog和 redo log扮演事务参与者（RM）。redo log和 binlog既然是在同一个事务里，需要有一个事务id标识，即binlog文件中的Xid。

我们再分析一下基于二阶段提交方式的故障恢复过程。如果写redo log 处于Prepare阶段，主节点宕机（图中的①）。此时redo log 和binlog 都没有Commit标识，master崩溃恢复的时候此时事务会回滚，binlog没有写入，不会传输给slave。所以master和slave数据是一致的。

如果写binlog成功，主节点宕机（图中的②）。master崩溃恢复的时候，先判断redo log的状态（redo log处于prepare阶段时就要写入磁盘，否则崩溃无法恢复），此时没有Commit标识，会通过Xid判断当前事务在binlog中的状态，此时redo log有Commit标识（COMMIT或Xid event），直接提交。binlog已经写入，数据已同步给slave。所以master和slave的数据是一致的。

- MySQL二阶段提交特殊性 -

表决阶段：

常规二阶段提交协议中，TM发个Prepare信息给RM是串行有序的。

MySQL中，Server 先发给redo log 进行Prepare fsync操作（数据写入磁盘）

提交阶段：

常规二阶段提交协议中，TM发个Commit信息给RM是无序的，不用关注RM发送的先后顺序。

MySQL的二阶段，Server 先发给binLog 进行write + fsync进行合并操作，然后在通知redo log进行Commit。

设计优点

少一次交互(对于分布式事务来说就少一次网络io)

少一次持久化操作(少一次磁盘io)

该机制名字叫
最末参与者优化。

以上就是二阶段提交在MySQL中的广义应用是怎样的，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注行业资讯频道。

内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/46791.html