Two Phase Commit (2PC) [转]

转自：http://nosql-wiki.org/foswiki/bin/view/Main/TwoPhaseCommit

2PC是工程上广泛使用的分布式一致性协议，它主要解决的问题是：一个事务，要么所有参与者都commit；要么所有参与者都abort。在没有异常的情况下，2PC是很容易理解的。理解2PC的难点在于出现异常的情况下协议如何保证事务的正确执行执行。

2PC协议中有两种身份：协调者(coordinator)和参与制(participant)。2PC包括两个阶段，每个阶段各自包含两个步骤。下面请跟着笔者的思路逐渐加深对2PC协议的理解。

理想时代：没有异常

此时，我们假设所有参与者、网络都不会出现异常，这种情况下2PC没有任何难度。

协调者向所有参与者发出VOTE_REQUEST请求，然后协调者阻塞等待所有参与者的响应
参与者在收到VOTE_REQUEST的时候，执行事务预处理，根据预处理的结果响应coordinator：VOTE_COMMIT或者VOTE_ABORT；然后参与者等待协调者的最后决定(global_decision)
协调者等待所有的参与者的响应，如果所有参与者都响应VOTE_COMMIT，那么协调者就向所有参与者发出GLOBAL_COMMIT；如果至少有一个参与者响应VOTE_ABORT，那么协调者就向所有参与者发出GLOBAL_ABORT
参与者根据协调者的决定(global_decision)在本地进行事务操作

在理想的时代，一切都是完美的，一切都是简单的。协调者的状态转移图如下：

参与者的状态转移图如下：

次理想时代：节点、网络异常会最终恢复

本节的算法摘自《Distributed Systems: Principles and Paradigms》。

Actions of Coordinator

01
write("START_2PC to local log");

02
multicast("VOTE_REQUEST to all participants");

03
while(not all votes have been collected)

04
{

05
  waitfor("any incoming vote");

06
  if(timeout)

07
  {

08
    write("GLOBAL_ABORT to local host");

09
    multicast("GLOBAL_ABORT to all participants");

10
    exit();

11
  }

12
  record(vote);

13
}

14
if(all participants send VOTE_COMMIT and coordinator votes COMMIT)

15
{

16
  write("GLOBAL_COMMIT to all participants");

17
  multicast("GLOBAL_ABORT to all participants");

18
}

19
else

20
{

21
  write("GLOBAL_ABORT to local log");

22
  multicast("GLOBAL_ABORT to all participants");

23
}

Actions of Participantsdata/Main/TwoPhaseCommit.txt

01
write("INIT to local log");

02
waitfor("VOTE_REQUEST from coordinator");

03
if(timeout)

04
{

05
  write("VOTE_ABORT to local log");

06
  exit();

07
}

08
if("participant votes COMMIT")

09
{

10
  write("VOTE_COMMIT to local log");

11
  send("VOTE_COMMIT to coordinator");

12
  waitfor("DESCISION from coordinator");

13
  if(timeout)

14
  {

15
    multicast("DECISION_REQUEST to other participants");

16
    waituntil("DECISION is received"); /// remain blocked

17
    write("DECISION to local log");

18
  }

19
  if(DECISION == "GLOBAL_COMMIT")

20
  {

21
    write("GLOBAL_COMMIT to local log");

22
  }

23
  else if(DECISION == "GLOBAL_ABORT")

24
  {

25
    write("GLOBAL_ABORT to local log");

26
  }

27
}

28
else

29
{

30
    write("GLOBAL_ABORT to local log");

31
    send("GLOBAL_ABORT to coordinator");

32
}

最糟糕的时代：协调者和参与者在死亡后无法恢复

2PC很无辜的看着大家，其实这个与我无关。听我详细道来。

算法解析

2PC这个协议本身其实本不难，难的是很多人（包括我自己）在学习算法本身的时候会思考如何把他应用在实际系统上。是想，如果我们假设任何阶段coordinator或者participant出现异常，那么整个算法就停止在那个地方一直循环等待，直到退出的节点恢复，算法才继续往前走，这个算法其实一点难度都没有。但是每个人都会思考，这样的算法在实际过程中还有用吗？实际过程中的工程师们是如何来处理这个问题的？只要一思考这些，读者就会觉得怎么都不对。其实就2PC而言，他本来就是一个阻塞的算法，在所有participant都响应VOTE_REQUEST之后，在收到DECISION之前，coordinator宕机，那么算法就会一直阻塞，因为没有人知道最后的decision是什么。既然它天生就是阻塞的，那么我们直接再弱化一下它好了，任何步骤主要出现异常，算法都阻塞。这样理解到的才是算法的实质。

可能有人会问，上面算法中有的地方在超时后会进行一些操作，然后算法可以继续；有些地方在超时后算法无法继续；这是为什么？什么时候决定算法可以继续，什么时候应该阻塞？以我对算法本身的理解，继续还是阻塞的标准是：

是否会导致事务的结果处于一种不一致的状态（一部分参与者commit，一部分参与者abort）；如果不会出现不一致的情况，那么算法可以继续；否则就必须阻塞。

可以这么理解：非阻塞的部分是算法的优化。算法继续，唯一会出现不一致状态的情况是，所有的参与者都响应了VOTE_REQUEST，在任何参与者收到decision之前coordinator宕机死亡，此时所有参与者都必须等待coordinator恢复。

有个同事的观点：所有参与者(包括协调者)都必须通过多副本的方式保证自己的高可用性，因为单副本不可用的问题不是2PC这个协议的目的，如果没有2PC这个协议，单副本的不可用性也是存在的，因此这种问题与2PC无关。可以说2PC本身不解决高可用性问题，它仅仅解决的是atomic group commit的问题，这是2PC的假设，也是理解2PC的关键。一句话：每个协议解决自己的问题，不要带着你面临的 n个问题来理解2PC(包括其他分布式协议)，这样只能使你自己陷入死角。

大家会说，那么每个协议如果这样去了解，岂不是都很简单，我作为架构师的最终目的是实现高可用的系统，而不是分开理解每个协议。呵呵，可以理解，我和大家一样由于这个想法走了很多的弯路。我会后续慢慢的告诉大家2PC如何在高可用的系统中使用。在分布式一致性这一系列文章中，我会为大家逐一解开谜底。

Large-scale Incremental Processing Using Distributed Transactions and Notifications 看google如何使用2PC实现实时搜索，通过BigTable自身的高可用性解决解决participants的高可用性问题；通过乐观锁解决coordinator不具备高可用性的问题。看了这篇分析，你会发现前面我关于2PC的分析是正确的。
Chubby一种可能的实现解析，看2PC如何与PAXOS结合实现replicated state machine，通过分布式选举解决coordinator的高可用性问题，通过replicated state machine解决participants的高可用性问题。

分析对工程实践的指导

还是从同事那里讨论得到的：如果在分布式系统中，协议包括这种逻辑：A发起一个请求给所有人；等待所有人响应之后A继续进行处理。这样的东西一看就太复杂，不靠谱，因为这相当于实现了一个2PC，有些偏复杂，如果必须这么实现，那么同学，你一定要按照2PC的理解方式去理解，去分析这个问题。

其实在分布式系统中，需要使用2pc思想指导设计的地方很多。一个很简单的例子，中心节点控制从一个数据节点拷贝一个分片到另外一个数据节点就需要这样的协议。以gfs增加block副本为例，当gfs metaserver的后台线程发现某个block的副本数量小于配置的阈值的时候，就会发起副本拷贝的任务：将block从一个chunkserver拷贝到另外一个chunkserver。这样的场景会产生如下问题：

metaserver如何监控拷贝进度？
如果拷贝的源失败如何处理？
如果拷贝的目的失败如何处理？

一个比较挫的设计方法：meta不断的去询问源或者目的，任务是否结束，根据复制的结果决定如何进行后续的操作。想一想，这个实现起来有多困难，metaserver上有上十万的block，如何处理？

看看伟大的google是如何处理的，metaserver为所有复制任务维护一个任务队列，任务队列中的任务有超时时间；后台线程发现副本数量小于配置的阈值，首先查看任务队列中是否有任务正在进行该bock的复制操作，如果有任务则不做任何事情；如果没有相应的任务，则发起任务。metaserver的工作到此为止。那么如何判断任务队列中的任务完成与否呢？这是chunkserver的事情，复制的目的会在复制任务完成后向metaserver汇报新复制的block， metaserver在收到复制完成的汇报后会把相应的任务从任务队列中删除。这样，整个协议很简单，很清晰，不易出bug。之前那种挫的设计，状态太难维护。在我们实际的工程实践中，一定要尽量少的使用一个进程去等待另外两个进程完成某项任务的协议，这样的协议太难维护了。

posted @ 2012-09-15 14:15 vivianC 阅读(523) 评论(0) 编辑收藏举报

刷新页面返回顶部

vivianC