Raft分布式共识算法学习笔记

1. Raft算法

Raft算法属于Multi-Paxos算法，它是在Multi-Paxos思想的基础上，做了一些简化和限制，比如增加了日志必须是连续的，只支持领导者、跟随者和候选人三种状态，在理解和算法实现上都相对容易许多

从本质上说，Raft算法是通过一切以领导者为准的方式，实现一系列值的共识和各节点日志的一致

原理概览

遵循Raft算法的分布式集群中每个节点扮演以下三种角色之一：

• leader：领导者，其负责和客户端通信，接收来自客户端的命令并将其转发给follower
• follower：跟随者，其一丝不苟的执行来自leader的命令
• candidate：候选者，当follower长时间没收到 leader的消息就会揭竿而起成为候选者，抢夺成为leader的资格

Raft算法是强领导者模型，集群中只能有一个领导者

1. 选举领导者的过程

在初始状态下，集群中所有的节点都是跟随者状态

Raft算法实现了随机超时时间的特性，每个节点等待领导者心跳信息的超时时间间隔是随机的。上图中，集群中没有领导者，而节点A的等待超时时间最小，它会最先因为没有等到领导者的心跳信息，发生超时

这时，节点A增加自己的任期编号，并推举自己为候选人，先给自己投上一张选票，然后向其他节点发送请求投票RPC消息，请它们选举自己为领导者

如果其他节点接收到候选人A的请求投票RPC消息，在编号为1的这届任期内，也还没有进行过投票，那么它将把选票投给节点A，并增加自己的任期编号

如果候选人在选举超时时间内赢得了大多数的选票，那么它就会成为本届任期内新的领导者

节点A当选领导者后，它将周期性地发送心跳消息，通知其他服务器我是领导者，阻止跟随者发起新的选举

2. 节点间如何通讯？

在Raft算法中，服务器节点间的沟通联络采用的是远程过程调用（RPC），在领导者选举中，需要用到这两类的RPC：

• 请求投票（RequestVote）RPC：是由候选人在选举期间发起，通知各节点进行投票
• 日志复制（AppendEntries）RPC：是由领导者发起，用来复制日志和提供心跳消息

3. 选举有哪些规则？

1. 领导者周期性地向所有跟随者发送心跳消息（即不包含日志项的日志复制RPC消息），通知大家我是领导者，组织跟随者发起新的选举

2. 如果在指定时间内，跟随者没有接收到来自领导者的消息，那么它就认为当前没有领导者，推举自己为候选人，发起领导者选举

3. 在一次选举中，赢得大多数选票的候选人，将晋升为领导者

4. 在一个任期内，领导者一直都会是领导者，直到它自身出现问题（比如宕机），或者因为网络延迟，其他节点发起一轮新的选举

5. 在一次选举中，每一个服务器节点最多会对一个任期编号投出一张选票，并且按照先来先服务的原则进行投票。比如节点C的任期编号为3，先收到了一个包含任期编号为4的投票请求（来自节点A），然后又收到了一个包含任期编号为4的投票请求（来自节点B）。那么节点C将会把唯一一张选票投给节点A，当再收到节点B的投票请求RPC消息时，对于编号为4的任期，已没有选票可投了

   

6. 日志完整性高的跟随者（也就是最后一条日志项对应的任期编号值更大，索引号更大）拒绝投票给日志完整性低的候选人。比如节点B的任期编号为3，节点C的任期编号为4，节点B的最后一条日志项对应的任期编号为3，而节点C为2，那么当节点C请求节点B投票给自己时，节点B将拒绝投票

选举是跟随者发起的，推举自己为候选人；大多数选票是指集群成员半数以上的选票；大多数选票规则的目标，是为了保证在一个给定的任期内最多只有一个领导者

3. 随机超时时间是什么？

Raft算法使用随机选举超时时间的方法，把超时时间都分散开来，在大多数情况下只有一个服务器节点先发起选举，而不是同时发起选举，这样就能减少因选票瓜分导致选举失败的情况

在Raft算法中，随机超时时间有2种含义：

1. 跟随者等待领导者心跳信息超时的时间间隔是随机的
2. 如果候选人在一个随机时间间隔内，没有赢得过半票数，那么选举就无效了，然后候选人发起新一轮的选举，也就是说，等待选举超时的时间间隔是随机的

4. Raft算法的强领导者模型选举限制和局限如下：

1. 读写请求和数据转发压力落在领导者节点，相当于单机，性能和吞吐量也会受到限制
2. 大规模跟随者的集群，领导者需要承担大量元数据维护和心跳通知的成本
3. 领导者单点问题，故障后直到新领导者选举出来期间集群不可用
4. 随着候选人规模增长，收集半数以上投票的成本更大

2. HTTP和RPC

HTTP接口和RPC接口都是生产上常用的接口，顾名思义，HTTP接口使用基于HTTP协议的URL传参调用，而RPC接口则基于远程过程调用。

RPC（即Remote Procedure Call，远程过程调用）和HTTP（HyperText Transfer Protocol，超文本传输协议），两者前者是一种方法，后者则是一种协议。两者都常用于实现服务，在这个层面最本质的区别是RPC服务主要工作在TCP协议之上（也可以在HTTP协议），而HTTP服务工作在HTTP协议之上。由于HTTP协议基于TCP协议，所以RPC服务天然比HTTP更轻量，效率更胜一筹

3. RPC接口和HTTP接口的区别与联系

RPC接口即相当于调用本地接口一样调用远程服务的接口；HTTP接口是基于http协议的post接口和get接口（等等，2.0版本协议子支持更多）。

传输协议

• RPC：可以基于TCP协议，也可以基于HTTP协议。
• HTTP：基于HTTP协议。

传输效率

• RPC：使用自定义的TCP协议，可以让请求报文体积更小，或者使用HTTP2.0协议，也可以很好地减少报文体积，提高传输效率。
• HTTP：如果时基于HTTP1.1的协议，请求中会包含很多无用的内容；如果是基于HTTP2.0，那么简单地封装一下还是可以作为一个RPC使用的，这时标准RPC框架更多是服务治理

性能消耗

• RPC：可以基于thrift实现高效的二进制传输
• HTTP：大部分是通过json实现的，字节大小和序列化耗时都比thrift要更消耗性能

负载均衡

• RPC：基本都自带了负载均衡策略
• HTTP：需要配置Nginx，HAProxy实现

服务治理（下游服务新增，重启，下线时如何不影响上游调用者）

• RPC：能做到自动通知，不影响上游
• HTTP：需要事先通知，修改Nginx/HAProxy配置

RPC主要用于公司内部服务调用，性能消耗低，传输效率高，服务治理方便。HTTP主要用于对外的异构环境，浏览器调用，APP接口调用，第三方接口调用等等。

RPC和HTTP都可以用于实现远程过程调用，如何选择

• 从速度上看，RPC比HTTP更快，虽然底层都是TCP，但是http协议的信息往往比较臃肿，不过可以采用gzip压缩
• 从难度上看，RPC实现较为复杂，http相对简单
• 从灵活性上看，HTTP更胜一筹，因为它不关心实现细节，跨平台，跨语言

两者有不同的使用场景：

• 如果对效率要求更高，并且开发过程使用统一的技术栈，那么RPC还是不错的
• 如果需要更加灵活，跨语言、跨平台，显然HTTP更合适

再插一句，最近新兴的微服务概念更加强调独立、自治、灵活，而RPC限制较多。因此微服务框架中，一般都会采用HTTP的Restful服务，像在公司内部使用hsf协议，对接外部系统使用微服务

4. HTTP1.0和HTTP1.1和HTTP2.0的区别

1. HTTP/1.0

HTTP/1.0中浏览器与服务器只保持短暂的连接，连接无法复用。也就是说每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。HTTP1.0需要使用keep-alive参数来告知服务器端要建立一个长连接。

2. HTTP/1.1

HTTP1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启长连接keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

3. HTTP/2.0

HTTP/2 为了解决HTTP/1.1中仍然存在的效率问题，HTTP/2 采用了多路复用。即在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应。能这样做有一个前提，就是HTTP/2进行了二进制分帧，即 HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码。

而这个负责拆分、组装请求和二进制帧的一层就叫做二进制分帧层。

除此之外，还有一些其他的优化，比如做Header压缩、服务端推送等。

Header压缩就是压缩老板和员工之间的对话。

4. 简单回答