工作中用到了Consul来做服务发现，之后一段时间里，我会陆续发一些文章来讲述Consul实现原理。在前一篇文章中，我介绍了Raft算法。这篇文章会讲讲Consul是如何使用Raft算法来实现分布式一致性的。

Consul中的Raft

只有以server模式运行的Consul节点，才会被认为是Raft节点集的一部分。所有的client节点会把收到的请求转发到server节点中。这么设计的原因主要是出于性能方面的考虑：节点集中的个数越多，那么法定个数的值也就越大，这会导致leader节点可能需要等待数百个follower节点对一条log entry的agree信息。

在开始的时候，单个Consul server进入到bootstrap模式，这种模式允许它把自己选举为leader。当leader被选举出来之后，别的server就可以被加入到节点集中，从而保障了一致性和安全性。最终，当最初的几台server被加进来后，bootstrap模式可以被关闭。

consul server加入节点集之后，他们会知道哪台机器是当前的leader。当一个RPC请求到达一台非leader server上时，这个请求会被转发到leader上。如果这个请求是一个查询类型（只读），leader会基于现在的状态机生成结果。如果这个请求是一个事物类型的请求（会修改状态），leader会生成一个新的log entry，并用Raft的方法去处理它。当这个log entry被提交并且被应用到状态机上时，这个事物就算完成了。

Raft会把log entry复制到多台机器上，因此网络延迟对于性能的影响很大。因为这个原因，每个数据中心选出一个独立的leader并且维护一份不相交的节点集。数据通过数据中心的方式做分割，因此每个leader只对自己这个数据中心内的数据负责。当一个请求到达一个数据中心，这个请求会被转发到正确的leader那里。这种设计下，我们可以做到低延迟事物以及高可用，而不用牺牲一致性。

一致性模式

尽管所有的log entry的写入都会通过Raft来实现，读取却要灵活的多。为了支持开发者可能需要的多种权衡取舍，Consul对于读取，提供了三种不同的一致性模式。

这三种模式是：

default

Raft用到了leader约期的概念，意思是，在一个时间窗口中，leader认为自己的角色是稳定的。但是，如果leader节点与别的节点被分隔，即发生所谓“脑裂”现象，那么会有一个新的leader节点被选举出来。旧的leader节点将不能提交任何新的log entry， 但是如果它提供了对数据的读取，那么客户端读到的这些值可能是过期的。

默认模式是基于leader约期的，因此客户端可能读到过期的值。但是这种模式是对读取速度和一致性的一种取舍，牺牲了某些情况下的强一致性，以换取更高的读取速度。

consistent

这种模式是强一致性模式。这种模式要求leader节点每次做读和写操作时都要与法定个数的节点去确认自己仍然是leader。 牺牲读的速度，保障了强一致性。

stale

这种模式允许任何Consul server向外部提供读取操作，无论它是不是leader节点。  
这种模式特别快，但是读到过期数据的可能性非常大。这种模式允许在没有leader节点的情况下对读请求做出相应，尽管实际上这时候Raft集群已经是处于不可用状态了。

参考：

https://www.consul.io/docs/internals/consensus.html