跳至主要內容

Raft算法

xuweiqiang大约 4 分钟etcdetcd

基本概念和相关术语

管理复制日志的一致性算法。本质上是管理日志的，日志决定了Leader和Follower角色以及数据副本。

  • 任期（Term）： Raft算法将时间划分为多个任期。
  • 日志（Log）： 客户端的请求以日志的形式进行记录。顺序性、每个节点存储、所有节点最终有相同的请求日志集合。
  • 状态机（State Machine）：抽象计算模型，可以认为是一些状态的计算规则。Raft通过日志等输入状态机，来确定状态管理节点状态等。
  • 节点状态：Follower（跟随者）、Candidate（候选者 - 无Leader时候Foller会转化为这个）、Leader（领导者）
  • 选举触发：Follower 在一个称为选举超时时间（election timeout）内没有收到来自 Leader 的心跳时触发。
  • 选举Leader的条件：Candidate 从大多数节点（超过集群节点总数的一半）获得了投票，它就会成为 Leader
  • 投票过程：候选者将自己任期号（Term）+1然后向其他所有节点发送请求投票（候选者当前任期号、日志条目、自己的节点ID ）。
  • 其他节点：任期号大于自己的任期号自己转变为跟随者、看候选者任期是否自己已经投给其他节点如果投了就拒绝投票、日志新旧程度新的会收到投票。
  • 候选者：收到所有其他节点的票，如果票数大于集群数量一半比如5节点收到3票，会把自己升级为Leader并且立刻发送心跳消息（AppendEntries）宣告。
  1. Leader选举过程
  • 第一阶段：所有节点都是 Follower
  • 第二阶段：Follower 转为 Candidate 并发起投票
  • 第三阶段：投票策略(候选者向所有其他节点发消息请求投票)
  • 第四阶段：Candidate 转为 Leader(自己计算如果得票超过集群数量一半) >N/2
  1. Raft算法中处理客户端请求的过程(安全性和强一致性)
  • 第一阶段：客户端请求提交到 Leader
  • 第二阶段：Leader 将 Entry(请求日志条目) 发送到其它 Follower
  • 第三阶段：Leader 等待大多数（超过集群节点总数的一半）Follower 的回应(如果没有收到会重新发送日志条目或者调整复制策略)
  • 第四阶段：Leader 回应客户端
  • 第五阶段：Leader 会向所有的 Follower 发送通知这个日志条目已提交,可以将其应用到自己状态机中

Q&A

  1. Raft选主必须获得选票 > N/2 才可以 ，那3个节点的宕机1个是不是永远无法选主了呢

    不一定。即使其中一个节点宕机，只要剩下的两个节点仍然可以获得足够的选票（即大于N/2），它们仍然可以选出新的主节点。在Raft协议中，只要仍然有大多数节点存活且可以通信，集群就可以继续正常工作。 在 Raft 算法中，如果一个由 5 个节点组成的集群中有 3 个节点宕机，那么在这种情况下确实无法选出主节点。

  2. 为什么说2个节点的集群不可能是高可用集群

    在一个只有两个节点的集群中，如果其中一个节点宕机，剩下的一个节点无法组成大多数（大于N/2），因此无法达成一致，也就无法选主。这样会导致集群无法正常工作，从而降低可用性。因此，一个只有两个节点的集群通常被认为不是高可用的，因为无法容忍单点故障。高可用集群通常是由多个节点组成，以确保即使有几个节点失效，集群仍然可以继续运行。

  3. k8s如何基于Etcd实现选主用于控制平面组件(APIServer\ControllerManager\Scheduler)

  4. Go的微服务启动3个Pod如何基于Etcd实现选主 3个Pod分别创建一个租约，然后将/leaderkey关联这个租约， 其他节点称为候选人之后监听租约，租约过期或被撤销，重新进行选主。

  5. Go微服务使用租约选主，会不会说2个同时成为leader

相关文章