两阶段提交协议

　　两阶段提交协议(Two-phase Commit，2PC)经常用来实现分布式事务，在两阶段提交协议中，系统一般包含两类节点：一类为协调者(coordinator)，通常一个系统中只有一个;另一类为事务参与者(participants)，一般包含多个。顾名思义，两阶段提交协议由两个阶段组成，如下所述：

　　阶段1：请求阶段(Prepare Phase)。在请求阶段，协调者通知事务参与者准备提交或者取消事务，然后进入表决过程。在表决过程，参与者将告知协调者自己的决策：同意(事务参与者本地执行成功，但没有提交)或者取消(事务参与者本地执行失败)。

　　阶段2：提交阶段(Commit Phase)。在提交阶段，协调者将基于第一个阶段的投票进行决策：提交或者取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行相应的操作。

　　两阶段提交协议可能面临两种故障：

　　事务参与者发生故障。给每个事务设置一个超时时间，如果某个事务参与者一直不响应，到达超时时间后整个事务失败。

　　协调者发生故障。协调者需要将事务相关信息记录到操作日志并同步到备用协调者，假如协调者发生故障，备用协调者可以接替它完成后续的工作。如果没有备用协调者，协调者又发生了永久性故障，事务参与者将无法完成事务而一直等待下去。

　　Paxos协议

　　Paxos协议用于解决多个节点之间的一致性问题。多个节点之间通过操作日志同步数据，如果只有一个节点为主节点，那么，很容易确保多个节点之间操作日志的一致性。考虑到主节点可能出现故障，系统需要选举出新的主节点。Paxos协议正是用来实现这个需求。只要保证多个节点之间操作日志的一致性，就能够在这些节点上构建高可用的全局服务，例如分布式锁服务，全局命名和配置服务等。

　　为了实现高可用，主节点往往将数据以操作日志的形式同步到备节点。如果主节点发生故障，备节点会提议自己成为主节点。这里存在的问题是网络分区的时候，可能会存在多个备节点提议(Proposer，提议者)自己成为主节点。Paxos协议保证，即使同时存在多个proposer，也能够保证所有节点最终达成一致，即选举出唯一的主节点。

　　大多数情况下，系统只有一个proposer，他的提议也总是会很快被大多数节点接受。步骤如下：

　　1)批准(accept)：Proposer发送accept消息要求所有其他节点(acceptor，接受者)接受某个提议值，acceptor可以接受或者拒绝。

　　2)确认(acknowledge)：如果超过一半的acceptor接受，意味着提议值已经生效，Proposer发送acknowledge消息通知所有的acceptor提议生效。

　　当出现网络或者其他异常时，系统中可能存在多个Proposer，他们各自发起不同的提议。这里的提议可以是一个修改操作，也可以是提议自己成为主节点。如果proposer第一次发起的accept请求没有被acceptor中的多数派批准(例如与其他proposer的提议冲突)，那么，需要完整地执行一轮Paxos协议。过程如下：

　　1)准备(prepare)：Proposer首先选择一个提议序号n给其他的acceptor节点发送prepare消息。Acceptor收到prepare消息后，如果提议的序号大于他已经回复的所有prepare消息，则acceptor将自己上次接受的提议回复给proposer，并承诺不再回复小于n的提议。

　　2)批准(accept)：Proposer收到了acceptor中的多数派对于prepare的回复后，就进入批准阶段。如果在之前的prepare阶段acceptor回复了上次接受的提议，那么，proposer选择其中序号最大的提议值发给acceptor批准;否则，proposer生成一个新的提议值发给acceptor批准。Acceptor在不违背他之前在prepare阶段的承诺的前提下，接受这个请求。

　　3)确认(acknowledge)：如果超过一半的acceptor接受，提议值生效。Proposer发送acknowledge消息通知所有的acceptor提议生效。

　　Paxos协议需要考虑两个问题：正确性，即只有一个提议值生效;可终止性，即最后总会有一个提议值生效。Paxos协议中要求每个生效的提议被acceptor中的多数派接受，并且每个acceptor不会接受两个不同的提议，因此可以保证正确性。Paxos协议并不能严格保证可终止性，但是从Paxos协议的执行过程可以看出来，只要超过一个acceptor接受了提议，proposer很快就会发现，并重新提议其中序号最大的提议值。因此，随着协议不断进行，它会往“某个提议值被多数派接受并生效”这一最终目标靠拢。

　　Paxos与2PC

　　Paxos协议和2PC协议在分布式系统中所起的作用并不相同。Paxos协议用于保证同一个数据分片的多个副本之间的数据一致性。当这些副本分布到不同的数据中心时，这个需求尤其强烈。2PC协议用于保证多个数据分片上的操作的原子性。这些数据分片可能分布在不同的服务器上，2PC协议保证多台服务器上的操作要么全部成功，要么全部失败。

　　常见的做法是，将2PC和Paxos协议结合起来，通过2PC保证多个数据分片上的操作的原子性，通过Paxos协议实现同一个数据分片的多个副本之间的一致性。另外，通过Paxos协议解决2PC协议中协调者宕机问题。当2PC协议中的协调者出现故障，通过Paxos协议选举出新的协调者继续提供服务。

　　跨机房部署

　　在分布式系统中，跨机房问题一直都是老大难问题。机房之间的网络延迟较大，且不稳定。跨机房问题主要包含两个方面：数据同步以及服务切换。跨机房部署方案有三个：集群整体切换、单个集群跨机房、Paxos选主副本。下面分别介绍。

　　1.集群整体切换

　　集群整体切换是最为常见的方案。如下图所示，假设某系统部署在两个机房：机房1和机房2。两个机房保持独立，每个机房部署单独的总控节点，且每个总控节点各有一个备份节点。当总控节点出现故障时，能够自动将机房内的备份节点切换为总控节点继续提供服务。另外，两个机房部署了相同的副本数，例如数据分片A在机房1存储的副本为A11和A12，在机房2部署的副本为A21和A22.在某个时刻，机房1为主机房，机房2为备机房。

　　机房之间的数据同步方式可能为强同步或者异步。

　　如果采用异步模式，那么备用机房的数据总是落后于主机房。当主机房整体出现故障时，有两种选择：要么将服务切换到备机房，忍受数据丢失的风险;要么停止服务，直到主机房恢复为止。因此，主备切换往往是手工的，因为需要根据业务特点选择“丢失数据”或者“停止服务”。

　　如果采用强同步模式，那么备机房的数据和主机房保持一致。当主机房出现故障时，可以通过分布式锁服务发现，并自动将备用机房切换为主机房。

　　2.单个集群跨机房

　　上一种方案的所有主副本只能同时存在于一个机房内，另一种方案是将单个集群部署到多个机房，允许不同数据分片的主副本位于不同的机房。如下图所示，每个数据分片在机房1和机房2，总共包含4个副本，其中A1、B1、C1是主副本，A1和B1在机房1，C1在机房2。整个集群只有一个总控节点，它需要同机房1和机房2的所有工作节点保持通信。当总控节点出现故障时，分布式锁服务将检测到，并将机房2的备份节点切换为总控节点。

　　如果采用这种部署方式，总控节点在执行数据分布时，需要考虑机房信息，也就是说，尽量将同一个数据分片的多个副本分布到多个机房，从而防止单个机房出现故障而影响正常服务。

　　3.Paxos选主副本

　　在前两种方案中，总控节点需要和工作节点之间保持租约(lease)，当工作节点出现故障时，自动将它上面服务的主副本切换到其他工作节点。

　　如果采用Paxos选主副本，那么，每个数据分片的多个副本构成一个Paxos复制组。如下图所示，B1、B2、B3、B4构成一个复制组，某一时刻B1为复制组的主副本，当B1出现故障时，其他副本将尝试切换为主副本，Paxos协议保证只有一个副本会成功。这样，总控节点和工作节点之间不再需要保持租约，总控节点出现故障也不会对工作节点产生影响。

　　Google后续开发的系统，包括Google Megastore以及Spanner，都采用了这种方式。它的优点在于能够降低对总控节点的依赖，缺点在于工程复杂度太高，难以在线下模拟所有的异常情况。

　　责任编辑：DJ编辑