两阶段提交进阶

## 两阶段提交之进阶

 

上一节我们讲了，两阶段提交逻辑上的表现，其实较为肤浅，并且偏向理论，可能大家都能看懂，但是如果放入实际的mysql应用中并联系事务和日志进行分析，又会怎么样呢？

 

这次就专门分析==两阶段提交在mysql更新操作中的必要性==；（定语加的有够多的🏋️‍♂️）；

 

既然在mysql中，那必然是要知道mysql的更新操作是如何进行的，才能分析两阶段提交为何必要；

 

### mysql更新操作

 

对于一个**单体数据库**中，一个简单的mysql操作通常会分为：

 

> 1.解析sql语句并进行优化；

>

> 2.开始事务

>

> 3.加锁，对更新涉及到的数据加锁

>

> 4.执行更新操作并将操作记录到日志中，以支持回滚和恢复

>

> 5.提交事务，释放锁，返回结果；

 

 

 

可以看到在这过程中对于更新数据以及日志的操作都是在事务范围内进行的；

 

接下来分析日志在这个过程中的变化：

 

1. **二进制日志（Binary Log）的记录**：MySQL会将执行的更新操作记录到二进制日志中，这包括对数据的插入、更新和删除操作。二进制日志记录在事务提交之前。**Binlog通常用于数据的备份和复制，以及在主从复制架构中用于数据同步**。

2. **Redo日志的生成**：MySQL会生成Redo日志，记录**已经提交的事务对数据的修改**。Redo日志用于数据库的崩溃恢复，在数据库重启时，MySQL会根据Redo日志将已提交的事务重新应用到数据库中，确保数据的一致性。称为**重做日志**

3. **Undo日志的生成**：在事务进行过程中，MySQL会生成Undo日志，记录**事务对数据的修改前的状态**（记录了事务对数据库所做的修改的逆操作）。Undo日志用于事务的回滚操作，在事务回滚时，MySQL会根据Undo日志将数据恢复到事务开始之前的状态。称为**撤销日志**

 

我们接着分析，**如果使用两阶段提交协议**那么==对于一个分布式的数据库进行更新操作时，应该按照怎么样的顺序执行呢==

 

**在准备阶段**

 

- 协调者节点向所有参与者节点发送Prepare请求，要求它们准备提交事务。

- 参与者节点执行更新操作的准备工作，预留资源、写入Redo日志和Undo日志等，并向协调者节点发送准备就绪的响应。

 

如果没有两阶段提交，一旦在提交阶段发生了故障，可能会导致一些参与者节点已经准备好提交事务，而另一些参与者节点却无法准备就绪。这种情况下，数据可能会处于不一致的状态，从而破坏了数据的一致性和可靠性。

 

**crash阶段**（出现错误）：

 

- 在Prepare阶段之后，如果系统在提交事务之前发生了崩溃或者故障，就会进入Crash阶段。

- 在Crash阶段，系统会通过Redo日志和Undo日志来进行故障恢复。

- 通过Redo日志，系统可以重新应用已经提交的事务对数据的修改，以确保数据的持久性。

- 通过Undo日志，系统可以撤销未提交的事务对数据的修改，以确保数据的一致性。

 

（在这个过程中，其实redo和undo作用和单体数据库作用是一样的，都是维持单体数据库的持久性和一致性）；

 

如果没有两阶段提交，一旦在提交阶段发生了故障，可能会导致数据的更新操作部分应用到了数据库中，而另一部分未能成功应用。这种情况下，数据库可能会处于不一致的状态，从而破坏了数据的一致性和可靠性。

 

成功的话：第二阶段

 

**commit阶段**

 

- 在Commit阶段，事务会被提交，即所有的数据修改操作将被应用到数据库中。

- 在分布式环境中，可能需要将Commit请求发送给协调者节点，并等待协调者节点将Commit请求发送给各个参与者节点。

- 只有当所有参与者节点都成功提交了事务后，事务才会被视为成功提交，否则事务将被回滚。

- 在事务成功提交后，系统会确保相应的Redo日志、Undo日志和Binlog记录被正确地写入到持久化存储中，以保证数据的持久性和一致性。

 

如果没有两阶段提交，可能会导致已经提交的事务对数据的修改丢失，或者未提交的事务对数据的修改被错误地应用到了数据库中。这种情况下，数据库可能会处于不一致的状态。

 

 

 

### 扩展知识点

 

其实两阶段提交还有一个重要作用，**防止半提交发生时造成的redo日志和binlog日志不统一**

 

例：

 


 

整个过程：

 


 

从图中可看出，事务的提交过程有两个阶段，就是**将 redo log 的写入拆成了两个步骤：prepare 和 commit，中间再穿插写入binlog**，具体如下：

 

- **prepare 阶段**：将 XID（内部 XA 事务的 ID） 写入到 redo log，同时将 redo log 对应的事务状态设置为 prepare，然后将 redo log 持久化到磁盘（innodb_flush_log_at_trx_commit = 1 的作用）；

- **commit 阶段**：把 XID 写入到 binlog，然后将 binlog 持久化到磁盘（sync_binlog = 1 的作用），接着调用引擎的提交事务接口，将 redo log 状态设置为 commit，此时该状态并不需要持久化到磁盘，只需要 write 到文件系统的 page cache 中就够了，因为只要 binlog 写磁盘成功，就算 redo log 的状态还是 prepare 也没有关系，一样会被认为事务已经执行成功；