分布式系统原理 之6 两阶段提交协议

分布式系统原理

两阶段提交协议

两阶段提交协议是一种经典的强一致性中心化副本控制协议[2][3]。虽然在工程中该协议有较多的问题，但研究该协议能很好的理解分布式系统的几个典型问题。

1. 问题背景

两阶段提交（two phase commit）协议是一种历史悠久的分布式控制协议。最早用于在分布式数据库中，实现分布式事务。这里有必要首先简单介绍一下两阶段提交的最初问题背景，从而能更好的理解该协议。

在经典的分布式数据库模型中，同一个数据库的各个副本运行在不同的节点上，每个副本的数据要求完全一致。数据库中的操作都是事务(transaction)，一个事务是一系列读、写操作，事务满足ACID。每个事务的最终状态要么是提交(commit)，要么是失败(abort)。一旦一个事务成功提交，那么这个事务中所有的写操作中成功，否则所有的写操作都失败。在单机上，事务靠日志技术或 MVCC等技术实现。在分布式数据库中，需要有一种控制协议，使得事务要么在所有的副本上都提交，要么在所有的副本上都失败。对同一个事务而言，虽然在所有副本上执行的事务操作都完全一样，但可能在某些副本上可以提交，在某些副本上不能提交。这是因为，在某些副本上，其他的事务可能与本事务有冲突（例如死锁），从而造成在有些副本上事务可以提交，而有些副本上事务无法提交。本文不再深入讨论事务冲突的问题，只是将问题背景介绍情况，该类问题可以通过阅读经典的数据
库系统相关资料了解。

2. 流程描述

按本文的分类，两阶段提交协议是一种典型的“中心化副本控制”协议。在该协议中，参与的节点分为两类：一个中心化协调者节点（coordinator）和 N 个参与者节点（participant）。每个参与者节点即上文背景介绍中的管理数据库副本的节点。

两阶段提交的思路比较简单，在第一阶段，协调者询问所有的参与者是否可以提交事务（请参与者投票），所有参与者向协调者投票。在第二阶段，协调者根据所有参与者的投票结果做出是否事务可以全局提交的决定，并通知所有的参与者执行该决定。在一个两阶段提交流程中，参与者不能改变自己的投票结果。两阶段提交协议的可以全局提交的前提是所有的参与者都同意提交事务，只要有一个参与者投票选择放弃(abort)事务，则事务必须被放弃。

协议流程如下：

流程 2.6.1：两阶段提交协调者流程
1. 写本地日志“begin_commit”， 并进入 WAIT 状态；
2. 向所有参与者发送“prepare 消息”；
3. 等待并接收参与者发送的对“prepare 消息”的响应；
    3.1 若收到任何一个参与者发送的“vote-abort 消息”；
        3.1.1 写本地“global-abort”日志，进入