Distributed System: Consensus Algorithms

对于分布式系统的出现，是计算机系统从个人到团体的演化。所以，到团队合作之后，交流与沟通变得异常的重要。如何保持团队的步伐一致（consistency），成了一个很重要的问题。

分布式系统的consensus algorithm的演化分为以下几个步骤：

1) Two phase commitment 

在二阶段提交和三阶段提交当中，需要有一个coordinator，其余的都是participants。 两者都存在了单点问题。一旦coordinator出现了故障，会导致整个集群down掉。（三阶段提交会好一点，存在超时abort的选项，顶多就是participants一直不更新内容）

二阶段提交主要用的是以下的流程来确定是否更新内容：

1）Coordinator收到来自client的内容更新请求，接着群发给所有的Participant一个proposal，说你们能不能更新这个值啊？

2）然后participants收到的话，就提前做好更新这个值了，同时锁住整个表（mutex的对象是整个数据），不让其它读或者写，不过呢，为了预防coordinator反悔了（因为有其它的participants不同意），还写好了undo和re do的记录。如果这个participant同意了，马上就给coordinator发送同意啦。

3）接着，coordinator等着acks。然后一个个数，好，全部都同意啦。发送commit，你们全都给我执行吧。否则（有反对或者超时），发送undo，全部都回滚。

缺点：很明显，就是participant如果都在等coordinator的commit的话，大家都锁住了，造成了性能上的损耗。而且万一coordinator在发完proposal之后挂掉了，整个系统都挂了。

2) Three phase commitment

三阶段提交的优点相对于二阶段提交而言，是存在participants等待coordinator超时abort和锁住整个表的时间比二阶段少。不会像二阶段那样，那么冲动，已收到proposal就锁住整个表。

三阶段分为can-commit, pre-commit(这一步才锁)，do-commit. 

1）首先是coordinator收到client的更新要求，然后发送can-commit请求给所有的participants。接着，等待他们的答复；participants收到请求后，不会提前更新变量，而是简单回复能还是不能；

2) 然后进入了pre-commit和do-commit，如果收到了所有的能，那么就发送pre-commit的请求，真正像两阶段提交的步骤开始了；但是还有一点不同，万一coordinator挂掉了，所有participants进入超是abort机制。

3) PAXOS 

这个是传说中的最好的一致性算法。是Google的一个工程师提出的。《PAXOS made simple》是一篇最官方的学术论文。

理解PAXOS的工作机制，就像了解人类团体的协作方式一样。这个机制有四种角色：

1）Client

2) Acceptor

3）Leader

4）Follower

PAXOS的重点在于确保Paxos所有的状态机副本以相同的顺序执行相同的指令，那么所有状态机可以保证以相同的状态变化进行转移。所以PAXOS可以说一个状态机模型。通过确保proposal ID的严格递增顺序（确保每个acceptor的记录的最近accepted的ID只能比当前的ID小）。

机制是当client发送更新请求后，群体中的Leader会发起proposal，如果这个proposal被大部分的机子接受后，Leader会直接commit这个proposal. （与二阶段提交略有不同）。此时，Acceptors就会变为Follower来更新对应的内容。Zookeeper就是用的这个算法。