raft算法理论

前言

这几天看了一下raft算法，在这里着重讲解一下raft算法的理论

介绍

• raft 是一种分布式的共识算法，其目的是要实现多个节点集群的容错性,一致性从而能够构建大规模的软件系统。
• 在raft之前，比较有名的是Paxos。但是paxos难于理解。
• raft的诞生是为了让共识算法更容易理解,在工程上更容易实现。

特点

• leader：raft中会有一个领导者具有超级权限，可以把自己的log 复制到其他节点中。
• leader election： raft每隔一段随机的时间就会进行leader的选举
• raft允许集群配置变化时正常运行。

状态机

• 状态机是分布式系统中的一个重要概念，任何一个系统的最终状态都可以看成是每一个操作的集合。因此，算法会维护一份replicated log，将每一份操作都存储起来。
• 每一个节点只要按顺序执行log中的命令，就会到达相同的最终状态。这样，即便是系统奔溃也可以快速的恢复。
• 共识算法需要保证relicated log的一致性,服务器收到客户端发出来的执行命令Command后，会将其加入到log中。
• 服务器之间会相互的交流，保证最后的log的一致性（即便服务器奔溃），即Command 会复制到其他服务器的log中，所有服务器的log是相同的，有序的。
• 其他服务器会执行此log，即会执行此命令。最后，所有的服务器都会到达同一个状态。

基础

• raft集群一般保持奇数个数量（5个节点比较普遍). 从而只要大部分节点存活，即可用。
• raft中的节点有3种状态。 leader, Candidates, follower。
• 一般的状态只会存在一个leader，其余的节点都是follower。
• leader会处理所有的客户端请求， 如果是客户端请求follower，也会被转发到leader处理。
• Candidates 是一种选举时候的过渡状态，用于自身拉票选举leader。
• 在raft中会有一个叫做term的时间周期。term是以选举leader开始的，如果Candidates选举成为了leader，那么其会成为这个term剩下时间的leader。
• 有时候，在整个term周期都没有选举出leader。这时一个新的选举会在不久后开始。
• Terms 在raft中类似于一种时间戳，后一个一定比前一个后发生，这一点和比特币中的区块链很类似。
• 每一个服务器会存储一个当前的term，其会随着时间的增加而增长。如果某一个节点的当前term小于其他节点，那么节点会更新自己的term为最大的term。
• 如果一个candidate 发现自己当前的term 过时了，那么其会立即变为follower。
• raft节点之间通过RPC（远程过程调用）来进行通信。 RequestVote 方法用于candidate在选举时候使用，AppendEntries用于leader在通知其他节点复制log时使用。同时也用于心跳检测。
• RPC 是并发的，并支持失败重试。
  

选举

• 在raft中会有一套心跳检测，只要follower收到来自leader或者Candidates的数据，那么其会保持follower的状态。
• 如果follower一段时间内没有收到RPC请求，这意味着选举超时（ election timeout ）。
• 这时follower会将current term 加1，过渡到Candidates状态。其会给自己投票，并发送RequestVote RPC请求给其他的节点，拉票！
• Candidates状态会持续，直到下面的3种情况发生:
• 当其获得了大部分节点的支持后，其赢得了选举，变为了leader。一旦其变为了leader，其会向其他节点发送 AppendEntries RPC， 确认其leader的地位，阻止选举。
• 其他节点成为了leader。如果其收到了其他节点的AppendEntries RPC. 并发现其他节点的current term比自己的大,则其变为follower状态。
• 一段时间过去任然没有参与者。
• 如果有许多的节点同时变为了candidate,则可能会出现一段时间内都没有节点能够选举成功的情况。
• 在raft中，为了快速解决并修复这个问题，规定了每一个candidate在选举前会重置一个随机的选举超时（ election timeout ）时间，此随机时间会在一个区间内（eg.150-300ms）
• 随机时间保证了在大部分的情况下，有一个唯一的节点首先选举超时，其在大部分节点选举超时前发送心跳检测，赢得了选举。
• 当一个leader在心跳检测中发现另一个节点有更高的term时，会转变为follower。否则其将一直保持leader状态。