分布式之二段演变三段提交分析

斯文的程序

发布于 2020-04-30 16:00:56

7510

发布于 2020-04-30 16:00:56

文章被收录于专栏：带你回家

前言

上一篇：《分布式之事务解决方案》我们对于分布式事务解决方案有了一个汇总，分布式事务产生的原因，其解决方案。上一篇还有很多知识点没有讲到，比如二段提交，三段提交等。今天我们来一起探索一下分布式事务之二段提交三段提交算法。

本文主要对以下问题进行介绍：

二段提交原理分析。
二段提交缺陷分析。
三段提交原理分析。
二段与三段提交区别总结。

二段提交原理分析

在分布式系统中，各个物理节点相互独立，通过网络沟通协调。在关系型数据库中，存在事务机制，可以保证各个单节点的ACID。但是在分布式情况下，相互独立节点无法知道其他节点执行事务的情况。所以出现了一些解决这个问题的方案。

二段提交与三段提交是分布式事务一致性的经典算法。下面来介绍一下二段提交。

准备知识

在分布式事务的定义中，如果想让分布式部署的多台机器中的数据保持一致性，那么就要保证在所有节点的数据写操作，要么全部都执行，要么全部都不执行。但是，一台机器在执行本地事务的时候无法知道其他机器中本地事务的执行结果，节点并不知道本次事务到底应该 Commit 还是 Rollback。

在前面介绍过的几种一致性算法中，都是通过一个Leader进程进行协调，在2PC（两阶段）和3PC（三阶段）中也是一样的解决办法。二阶段和三阶段提交协议都是引入了一个协调者的组件来统一调度所有分布式节点的执行，让当前节点知道其他节点的任务执行状态，通过通知和表决的方式，决定执行 Commit 还是 Rollback 操作。

设计理念

在该分布式系统中，存在一个节点作为协调者（Coordinator），其他节点作为参与者（Participants），且节点之间可以进行网络通信；
所有节点都采用预写式日志，日志被写入后被保存在可靠的存储设备上，即使节点损坏也不会导致日志数据的丢失；
所有节点不会永久性损坏，即使损坏后仍然可以恢复。

两阶段提交中的两个阶段，指的是 「Commit-request 阶段」 和 「Commit 阶段」 ，两阶段提交的流程如下：

提交请求阶段

在提交请求阶段，协调者将通知事务参与者准备提交事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地事务执行成功）或取消（本地事务执行故障），在第一阶段，参与节点并没有进行Commit操作。

提交阶段

在提交阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消这个事务。这个结果的处理和前面基于半数以上投票的一致性算法不同，必须当且仅当所有的参与者同意提交，协调者才会通知各个参与者提交事务，否则协调者将通知各个参与者取消事务。

参与者在接收到协调者发来的消息后将执行对应的操作，也就是本地 Commit 或者 Rollback。

二段提交缺陷分析

如上图可以知道一下缺陷：

在执行过程中，所有参与节点都是事务独占状态，当参与者占有公共资源时，那么第三方节点访问公共资源会被阻塞。「资源被同步阻塞」
一旦协调者发生故障，参与者会一直阻塞下去。「协调者可能出现单点故障」
在第二阶段中，假设协调者发出了事务Commit的通知，但是由于网络问题该通知仅被一部分参与者所收到并执行Commit，其余的参与者没有收到通知，一直处于阻塞状态，那么，这段时间就产生了数据的不一致性。 「在 Commit 阶段出现数据不一致」

二段提交应用

在事务处理、数据库和计算机网络中，两阶段提交协议提供了分布式设计中的数据一致性的保障，整个事务的参与者要么一致性全部提交成功，要么全部回滚。MySQL Cluster内部数据的同步就是用的2PC协议。
MySQL 的主从复制。在MySQL中，二进制日志是server层，主要用来做主从复制和即时点恢复时使用的；而事务日志（RedoLog）是InnoDB存储引擎层，用来保证事务安全的。在数据库运行中，需要保证 Binlog 和 Redo Log 的一致性，如果顺序不一致，则意味着 Master-Slave 可能不一致。这里就是用到了二段提交。内部会自动将普通事务当做一个 XA 事务（内部分布式事务）来处理。后续会分享XA事务。