一文彻底理解Multi-Paxos
前言
《分布式协议学习——一文彻底理解共识算法之Basic Paxos》这篇文章，大家阅读后应该了解Basic Paxos只能就单个值（Value）达成共识。当需要对一系列值达成共识的时候，Basic Paxos就不管用了。
什么是Multi-Paxos
Multi-Paxos只是一种思想，不是算法。Multi-Paxos算法则是一种统称而已。它是指基于Multi-Paxos思想，通过多个Basic Paxos实例来实现一系列值的共识算法。
Basic Paxos是通过两阶段提交来达成共识的。在第一阶段，准备阶段的时候，只有接收到大多数准备响应的提议者，才能发起接受请求进入接受阶段。如下图所示：
现在，如果直接通过多次执行basic paxos实例，来实现一系列值的共识，就会存在以下几个问题：
- 多个提议者同时提交议案，可能会出现因为议案编号冲突，导致在准备阶段没有提议者接收到很多的准备响应。造成协商失败，需要重新协商。比如，一个拥有3个节点的集群，如果2个节点作为提议者同时议案，就可能发生因为没有提议者接收大多数响应而准备失败，需要重新协商。
- 准备阶段和接受阶段实际上是两轮RPC通信，在往返消息多的情况下，有可能造成大量延迟。
为了解决上述问题，考虑引入了一个新的角色节点，领导者（Leader）,把它作为唯一提议者，这样就不存议案提交冲突的问题了。
领导者的选举，是需要自己来实现的。接下来，就该考虑如何优化Basic Paxos，一般考虑省掉准备阶段，直接进入接受阶段。这样，领导者的节点，命令是最新的，不再需要通过准备请求来发现之前被大多数节点通过的议案。领导者可以独立地指定议案中的值。这样就可以直接进入接受阶段了。
从上图可以看出，Multi-Paxos 引入领导者节点之后，因为只有领导者节点一个提议者，所以不存在议案冲突。当领导者节点进入稳定状态时，就可以直接进入接受阶段，很大程度上减少了往返的消息数量，从而提升了性能，降低了延迟。下面我们通过就具体来分析一下Chubby的Multi-Paxos如何实现的。
Chubby 是如何实现Multi-Paxos的
Google Chubby是一种松耦合式的分布式系统锁服务，GFS和Big-Table都是通过它来解决分布式协作、master节点选举、元数据存储等一系列同分布式锁相关的问题。Chubby提供了粗粒度分布式锁服务。它的整个系统结构主要由服务端和客户端两部分组成，客户端通过RPC调用和服务端进行通信。它的底层一致性是以Paxos为基础的。
Chubby中的master是唯一的提议者，这样就不会出现多个提议者同时提交议案从而造成议案冲突的情况。
那么，master节点是如何产生的呢？在Chubby集群（Chubby cell）中，副本服务器通常采用Basix Paxos协议来进行投票选举出master。选举出了master，Chubby就会在一段时间内不再将其它服务器作为master节点了，这段时间称为租期（Lease）。在运行过程中，master节点会通过不断续租的方式来延长租期。比如，几天内都是同一个节点作为master节点。如果master节点故障了，那么会在租期到期后， 其他节点又发起新一轮投票选举出新的master节点。新master节点将执行新的租期。
Chubby的客户端首先过向记录有Chubby服务端机器列表的DNS来请求获取所有的Chubby服务器列表，然后逐一发起请求询问该服务器是否是master，在这个询问过程中，那些非master的服务器，则会将当前master所在的服务器标志反馈给客户端，这样客户端就能很快速的定位到master服务器了。
为了实现强一致性，只要该master服务器正常运行，那么客户端就会将所有的请求都发送到该master服务器上。所有的读请求和写请求都是由master来处理。
写请求
当master从客户端接收到写请求后，作为提议者会采用Basic Paxos协议，将该写请求广播给所有节点，并且在过半的节点接受写请求之后，再响应给客户端写请求成功。
读请求
当master接收到读请求后，主节点只需要查询本地数据，然后返回给客户端就可以了。
为了减少客户端和服务端频繁的读请求造成服务端的压力，会在客户端对文件内容和元数据进行缓存。虽然通过缓存提升了性能，但是也带来了一致性的问题，Chubby采取租期机制来保证数据的一致性。每个客户端的缓存同master租期关联，可以理解为客户端缓存都有一个租期，一旦租期到期，客户端就需要向master续订租期以继续维持缓存的有效性。