Consul实现原理---Raft算法

 公司的注册中心要调研选型，不再使用Eureka，我负责这件事，先调研了Consul，Raft算法真的很巧妙，可惜的是consul的一些设计架构无法在我们公司生产环境使用。

Raft将一致性问题分解成了三个独立的部分:leader选举、日志复制、安全性。

 

一、Raft一致性的实现 复制日志

        想要实现共识性算法主要有两种方式：第一种方式称为对称式或无主式，在这种方式下，所有的服务器都有相同的角色，它们有同等的权力，它们任何时候的行为几乎都是一样的，客户端可以与任何一台服务器进行通信。第二种方式称为非对称式或基于领导者（leader），服务器在任何时候都不是对等的，只有其中的一台服务器是领导者（leader），领导者负责集群的所有操作，其他的服务器只是简单地服从领导者发出的指令，在这种系统下，客户端永远与领导者通信，只有领导者才与其他的服务器发送通信。

        Raft 就是使用上面第二种方式。它将共识性算法的问题分解成两类不同的问题，一种是在领导者正常运行下，进行的普通操作；另一种是在领导者崩溃时，需要对领导者进行重新选举，这种方式有其优势，它让普通的操作变得非常简单，不需要关心是否有多个领导者相互发生冲突，或同时发出指令，只要有一个领导者控制全局，就可以完全按照它的指令来运行。Raft 算法的复杂之处在于领导者发生变化时，因为当领导者崩溃时，会使系统处于不一致的状态，后续被选举的领导者需要对此这些不一致状态进行清理。总体上说，基于领导者的方式要比无领导者的方式简单，因为无须担心不同服务器间会出现冲突，只须关心领导者发生变化的情况。

 

Raft 算法共分成 6 个部分，首先我们要介绍的就是领导者的选举。

1. 如何从所有的服务器中选择领导者？如何在当作为领导者的服务器崩溃时能检测到故障并挑选另一个领导者来替代它？

2. 会介绍当领导者接收到客户端请求时，系统是如何处理正常操作的。这是 Raft 算法中最简单的部分。

3. 会讨论领导者发生改变的情况，这部分是 Raft 中最复杂的，也是保证整个系统行为最重要的部分。首先，会讨论什么叫做安全，如何保证安全？其次，领导者是如何识别日志的一致性的，从而可以将系统恢复到处于一致状态下。

4. 会讨论领导者发生改变时的另一个问题。如何让曾经崩溃死机的老领导者，重新回归到集群后集群的状态仍然能保持一致。