hashicorpraft 介绍与源代码分析（二）： 领导人选举（二）

hashicorp/raft 介绍与源代码分析（二）： 领导人选举（二） 回顾

上章提到，基于节点的 keyCurrentTerm 、LastLogTerm 、 LastLogIndex 3 个持久化数据，在选举时，可以确定领导者

选择领导者的依据是哪个节点 log 最全，选谁

但是有附加条件的，该节点 log 最全，并且其他节点已经应用到状态机的 log ，该节点必须有

因此，不是所有情况下选举一定能成功的

最坏的情况下，找不到符合条件的 log 落地日志拥有者时，必须牺牲可用性（即拒绝服务），来保证整个集群状态被破坏

因为，如果有 log 已经应用到状态机， raft 协议没法处理回退状态机的状态

想弄明白，为啥可以根据 keyCurrentTerm 、LastLogTerm 、 LastLogIndex 3 字段数据，来选主

我们先了解下，正常流程中， log 数据如何从请求发起，到所有节点应用 log 到状态机的过程。再介绍 2 个关键字段

log 数据正常处理过程

见图：

图解说明：

客户端发起请求 leader 写 log ，持久化该日志<