flink二阶段提交mysql_两阶段提交（2PC）与其在Flink exactly once中的应用

前言

简书快正式从小黑屋里出来了，所以是时候重启更新了。这段时间积攒了不少要写的东西，逐个击破吧。

两阶段提交(two-phase commit, 2PC)是最基础的分布式一致性协议，应用广泛。本文来介绍它的相关细节以及它在Flink中的典型应用场景。

2PC简介

先介绍两个前置概念。在分布式系统中，为了让每个节点都能够感知到其他节点的事务执行状况，需要引入一个中心节点来统一处理所有节点的执行逻辑，这个中心节点叫做协调者(coordinator)，被中心节点调度的其他业务节点叫做参与者(participant)。

接下来正式介绍2PC。顾名思义，2PC将分布式事务分成了两个阶段，两个阶段分别为提交请求(投票)和提交(执行)。协调者根据参与者的响应来决定是否需要真正地执行事务，具体流程如下。

提交请求(投票)阶段

协调者向所有参与者发送prepare请求与事务内容，询问是否可以准备事务提交，并等待参与者的响应。

参与者执行事务中包含的操作，并记录undo日志(用于回滚)和redo日志(用于重放)，但不真正提交。

参与者向协调者返回事务操作的执行结果，执行成功返回yes，否则返回no。

提交(执行)阶段

分为成功与失败两种情况。

若所有参与者都返回yes，说明事务可以提交：

协调者向所有参与者发送commit请求。

参与者收到commit请求后，将事务真正地提交上去，并释放占用的事务资源，并向协调者返回ack。

协调者收到所有参与者的ack消息，事务成功完成。

若有参与者返回no或者超时未返回，说明事务中断，需要回滚：

协调者向所有参与者发送rollback请求。

参与者收到rollback请求后，根据undo日志回滚到事务执行前的状态，释放占用的事务资源，并向协调者返回ack。

协调者收到所有参与者的ack消息，事务回滚完成。

下图分别示出这两种情况。

提交成功

提交失败

2PC的优缺点

2PC的优点在于原理非常简单，容易理解及实现。缺点主要有3个，列举如下：

协调者存在单点问题。如果协调者挂了，整个2PC逻辑就彻底不能运行。

执行过程是完全同步的。各参与者在等待其他参与者响应的过程中都处于阻塞状态，大并发下有性能问题。

仍然存在不一致风险。如果由于网络异常等意外导致只有部分参与者收到了commit请求，就会造成部分参与者提交了事务而其他参与者未提交的情况。

不过，现在人们在分布式一致性领域做了很多工作，以ZooKeeper为代表的分布式协调框架也数不胜数，2PC有了这些的加持，可靠性大大提升了，也就能够真正用在要求高的生产环境中了。下面看看2PC与Flink是怎么扯上关系的。

Flink基于2PC的事务性写入

2PC的最常见应用场景其实是关系型数据库，比如MySQL InnoDB存储引擎的XA事务