先讲个我经常在答疑时遇到的场景有同事指着Raft的示意图问这个Leader节点是不是就是集群里最特殊的那台机器它挂了系统是不是就瘫了说实话你要是能问出这个问题说明已经开始接近分布式共识的核心了但同时也踩在了一个常见的坑边上——把Leader理解成了“老大”而不是理解成一个“角色”。在这篇文章里我想用做分布式系统这几年的实际感受把这个Leader角色从头到尾拆开讲清楚它到底承担什么职责、为什么几乎所有主流共识算法都要围绕它转、它出现故障时系统如何自愈以及我们在设计系统时该怎么看待这个角色。适合正在磕Raft、Zab、Paxos的读者也适合那些需要在工程里选型分布式一致性方案的开发者。1. 共识中的Leader其实是个“串行化器”而不是“老大”很多人第一次接触分布式共识时最直观的理解就是“选一个Leader一切都听它的”。这个理解不能说错但会误导你后面绝大多数的判断。Leader不是拥有特权的节点它更像一个被临时授权负责“定序”的角色。它存在的根本目的不是发号施令而是解决分布式系统里最麻烦的问题多个节点同时接受写入时到底谁先谁后。1.1 为什么分布式系统需要一个“拍板的人”想象一下你有一个保存用户数据的集群三个副本同时接收写请求。如果客户端A把值改成1客户端B把值改成2不同副本接收到的顺序不同最终三个副本的值就不一致。解决这个问题的思路有两条要么让所有副本都遵守同一种排序规则要么索性指定一个节点来分配全局顺序。共识算法走的是后一条路。Leader节点负责给每一条写操作打上一个全局唯一的序号让所有副本按同样顺序执行。这样只要每个节点都按序号回放日志最终状态必然一致。与其说Leader是“老大”不如说它是一个“串行化器”——把并发的、无顺序的请求转变成一串有序的、可回放的日志条目。我印象特别深的是第一次搭etcd集群时只向Follower节点发了一个写请求结果被拒绝并返回了Leader节点的地址。当时对Leader的认知就是这么直接你要写数据就必须去找它。后来才明白这不是权限问题而是系统必须保证所有写操作经过同一个入口来分配顺序。没有这层串行化共识就无法成立。1.2 Leader与业务主节点的区别我在实际工作中注意到很多人会把共识里的Leader和传统架构里的“主节点”混为一谈。传统的主从架构里master负责调度任务、分配资源甚至完全没有多数派确认这回事主节点挂了直接人工切备。但共识里的Leader完全不同。关键区别在于共识里的Leader做的每个关键决策都必须经过多数派节点确认才能生效。它不是一个可以独断专行的角色。比如在Raft里Leader收到客户端的写请求后只是先把日志追加到自己的本地存储然后广播给所有Follower只有收到多数派节点的确认回复才能真正“提交”这条日志并向客户端返回成功。换句话说Leader的权力是受限制的它只是一个发起提案的角色最终是否生效由整个集群的多数派说了算。这个差别在故障场景下体现得最明显。传统主从架构里主节点所在的进程还活着它就会一直以主节点自居但在共识系统里一个节点哪怕内心觉得自己是Leader只要它无法获得多数派节点的认可它就什么都提交不了。Leader身份不是自我认知而是法定多数派的授权结果。1.3 数据只能从Leader流向Follower单向的权威还有一个容易忽略的细节是方向性。在Raft这类基于Leader的共识算法里日志流永远是单向的从Leader流向Follower。Follower从不主动把自己的日志推给Leader也不允许直接向客户端提供写服务。这种单向性极大简化了系统设计。如果允许双向同步日志每个节点都要处理来自其他人的日志合并冲突检测就会非常复杂。而有了Leader后所有Follower只需要做一件事等待Leader的AppendEntries请求检查日志是否匹配匹配就追加不匹配就拒绝。我后来看etcd的源码时感受最深的也是这种单向设计的优雅之处。Follower的逻辑非常简单就是一个不断接收请求并回送状态的循环。整个系统的复杂度几乎全部集中在Leader一侧。这也是理解共识算法的一个窍门看代码的时候先盯住Leader要处理哪几类事件其他节点都是它的镜像。2. 为什么几乎所有主流共识算法都离不开Leader角色你可能会想既然Leader这么重要那能不能设计一个完全没有Leader的共识算法理论上是可以的论文里的Basic Paxos就没有显式的Leader概念。但你如果真去工程里实现会发现无Leader的方案要么复杂度爆炸要么在特定场景下退化成隐式的Leader。这背后有很实在的原因。2.1 Paxos的活锁困境与“提议者协调者”熟悉Paxos的人都知道Basic Paxos有两个阶段Prepare阶段和Accept阶段。多个提议者Proposer可以同时发起提案没有谁是固定的话事人。这个设计看起来很公平但实际问题在于两个提议者同时提案时可能会不断地互相打断对方的Prepare阶段导致谁都提不出真正被选中的值。这是一个典型的活锁问题。算法不会死掉但永远无法向前推进。Lamport本人在论文里就提到为了避免这种困境实际使用中需要选出一个distinguished proposer特殊的提议者让它在正常情况下主导提案流程其他提议者只在它失败时才接管。这就很微妙了。理论上的Paxos是不需要Leader的但工程上的Paxos必须有一个事实上的主提议者。这就是为什么后来Multi-Paxos、Zab、Raft这些算法都干脆把Leader作为显式角色设计出来——与其暗中假设一个协调者不如把它变成明明白白的第一公民。2.2 Raft把Leader变成显式角色换取了可理解性Raft的论文明确提出了一个设计目标可理解性understandability。它把共识问题拆成了三个几乎独立的子问题Leader选举、日志复制、安全性。每一个子问题都围绕Leader展开。这跟工程落地的需求非常契合。我自己的体会是分布式共识的难点不在算法原理而在异常处理。无Leader的算法里每个节点都要面对各种极端情况状态空间极大而有了Leader之后整个集群在一个时间段内只有一条主线其他节点的响应都是对这条主线的反馈。调试的时候只要盯住当前任期里的Leader就能推断出绝大多数行为。这其实也是ZooKeeper的Zab协议走的路线。Zab和Raft虽然细节差异不少但核心思路高度一致依靠一个临时的Leader来接收客户端请求并广播事务崩溃后重新选举Leader并同步历史。可以说Leader化是工程共识的共识。2.3 无Leader方案的真实代价有人可能会反问Dynamo、Cassandra这种分布式系统不是支持任意节点写入吗它们也没有Leader啊。这类系统确实允许任何副本接受写请求但它们采用的是最终一致性模型通过向量时钟、版本号等手段进行冲突检测冲突的合并往往交给客户端的业务逻辑来处理。这套方案的问题是它把冲突处理的成本转移到了应用层。如果你的业务只要求在某个时间点之后看到最终结果那它可以运行得很好但如果你需要线性一致的读写语义比如分布式锁、全局唯一ID生成、配置更新让任意节点接受写入就会变成灾难。最终一致性加上复杂的冲突解决逻辑工程成本往往比维护一个共识集群还要高。所以在强一致场景下不是大家不想去掉Leader而是去掉Leader之后为了同样的语义要付出的代价更大。2.4 Multi-Paxos为什么最终也选出一个稳定LeaderMulti-Paxos是对Basic Paxos的经典优化。Basic Paxos每提议一个值都要跑完整的Prepare/Accept两阶段开销很大。Multi-Paxos的核心思路是先通过一轮Prepare把提议编号稳定下来之后就可以跳过Prepare直接进入Accept阶段。但这个优化的前提是在一段较长的时间内只有一个活跃的提议者。如果有多个提议者同时活跃Prepare阶段的冲突仍然会频繁出现。所以Multi-Paxos的实现里无论是etcd之前用的自带版本还是各种教学实现几乎都会在Phase 1完成后固定一个leader让它在后续一段时间内独占提议权。这从侧面说明了一个事实只要你想做一个高效的、线性的、强一致的共识系统Leader就是绕不开的选择。3. 任期与心跳Leader角色的生命周期管理Leader不是一个永久的身份它有一个从“当选”到“被淘汰”的完整生命周期。理解这个生命周期才能明白为什么共识系统能在节点故障时平稳切换。3.1 用任期替代物理时钟分布式世界的时间观分布式系统里最不可靠的就是物理时钟。机器上的时钟可能漂移NTP同步也可能延迟任何依赖时间的判断在极端情况下都可能出错。共识算法需要一种与物理时钟无关的方式来表示“时代”。Raft引入了任期term的概念是一个单调递增的整数。每次选举开始term加1。每个term里最多只有一个Leader。这样节点之间交流时只需要比较term就能判断消息是否过期数字大的term优先。这种设计非常巧妙它把物理世界的“时间先后”转换成了逻辑上的“序号先后”。一个请求只要携带term接收方立刻就能判断它是不是来自旧时代。我在看Raft代码时经常感叹这种设计让整个系统的状态判断变得极其轻量——不需要校准时钟不需要NTP只需要一个整数。3.2 心跳是Leader的“续命机制”Leader当选之后并不是什么也不做就能一直保持身份。它必须持续向Follower发送心跳在Raft里表现为空的AppendEntries请求告诉其他人“我还活着”。Follower会设置一个随机的选举超时时间通常是150到300毫秒。只要在超时时间内收到Leader的心跳就重置这个计时器保持Follower角色。一旦超过选举超时还没有收到心跳Follower就会认为Leader失联于是把自己的term加1发起新选举。心跳的本质是续命。Leader的心跳到达Follower等于在说“当前term的这个Leader还能工作你们不需要另起炉灶。”这个机制让我想到一个比喻Leader的身份就像在线状态不活跃就会被顶替。它没有任何“铁饭碗”可言。3.3 角色失效的多种姿势宕机、分区、超时Leader失去角色最常见的方式就是进程崩溃这没什么好说的。但更微妙的是网络分区和进程卡顿。假设集群有5个节点网络莫名其妙把Leader和另外2个节点隔开了剩下的2个节点能互相通信却联系不上Leader。对于这2个节点来说它们只能看到“心跳超时”这个事实无法区分Leader是宕机了还是被网络隔离了。于是它们会发起选举term递增形成一个只有少数派节点的“新世界”。这就是分区的恐怖之处少数派节点可能选出一个新Leader但它们申请不到多数派所以这个新Leader什么都提交不了。反过来被隔离在另一侧的旧Leader也一样它也没有多数派同样提交不了任何新日志。两个区域谁都无法推进幸好谁也都无法破坏一致性。除了网络JVM的GC停顿也是Leader失效的一个重要原因。我遇到过Java写的共识组件发生长时间的Full GC时心跳发不出去其他节点就开始选举等GC结束回到Runnable状态发现自己已经被降级成Follower了。这种“假死”在多语言实现里都非常常见。3.4 旧Leader并不一定知道自己已经被“免职”这是Leader角色最容易被人误解的地方一个节点不会在失去Leader身份的那一刻收到正式的“罢免通知”。网络分区时旧Leader依然活着它依然认为自己就是Leader继续接收客户端请求继续尝试广播日志。因为联系不上多数派它的请求无法拿到足够的确认所以这些日志不会成功提交。只有当它通过某种方式收到了来自更高term的消息才会意识到自己的时代已经结束主动转为Follower。这个设计保证了安全性即使旧Leader不知道自己已经失势它也无法违反规则提交数据。因为它必须依赖多数派的确认而多数派早就跟它没关系了。理解这一点你就能理解为什么共识系统在网络分区时不会脑裂——不是系统聪明到能识别分区而是在规则上就让少数派一方无法篡改状态。4. 选举机制拆解Raft里Leader是怎么上台的既然Leader这么重要那它到底是怎么被选出来的我把Raft的选举机制拆开看一遍里面有非常多的细节决定了系统的安全性和可用性。4.1 三个角色与角色转换的状态机Raft只定义三个角色Follower、Candidate、Leader。正常情况下集群里绝大多是节点都是Follower它们是基数是沉默的多数。Follower一旦在选举超时时间内没有收到合法Leader的消息就自增term切换到Candidate进入选举流程。Candidate的第一件事是给自己投票然后向其他节点发送RequestVote请求。如果它收到多数派节点的投票就切换成Leader开始向所有节点发送心跳。如果在这个过程中收到更高term的消息或者发现别的Candidate已经当选就乖乖退回Follower。这套状态机的转换条件非常清晰几乎没有任何模糊地带。这也是我认为Raft作为入门级共识算法如此友好的原因每个节点的状态是有限的转换条件是基于term比较的确定性逻辑不存在复杂的概率推理。4.2 投票规则的细节一任期一票、日志新旧判定选举投票的规则看起来简单魔鬼在细节里。每个节点在一个term里只能投出一张选票然后按先到先得的原则处理。但光有一张票还不够候选者还必须满足一个条件它的日志不能比投票者旧。怎么判断新旧先比较最后一条日志的termterm大的更新如果term相同再比较日志条目的索引索引大的更新。这个规则极其重要它保证了新Leader不会丢失已经提交的日志。因为任何已经提交的日志一定存在于多数派节点上而选举要获得多数派投票候选者至少要跟其中一个持有最新日志的节点“一样新”。这样选出来的Leader必然包含了全部已提交日志。我在自己实现简化版Raft时一度把日志新旧判定条件写反了结果是老节点还能选上Leader然后拼命回滚新日志数据直接错乱。这个坑踩得印象深刻。4.3 随机超时为什么能避免活锁选举时间不是固定的每个Follower的选举超时时间在150到300毫秒之间随机选择。这个随机性不是随便设计的它直接解决了活锁问题。设想一下如果所有Follower的超时时间是相同的它们大概率会同时发现问题、同时发起选举、同时把手里的票投给自己结果谁也无法获得多数派只能进入新一轮平票。这个过程可能无限重复系统永远选不出Leader。随机超时的意图就是把节点发起选举的时间错开让先到超时的节点有更多机会拿到其他节点的票。实际运行中多数选举都会在第一轮就成功因为发起者是从多个随机时间点里“脱颖而出”的那个其他节点大概率还没开始竞选可以放心把票投给它。4.4 选举期间系统还能工作吗这是很多做业务的人关心的一个问题。选举期间集群实际上处于“无主”状态没有Leader接收写请求客户端请求会被拒绝或者等待重试。这个不可用窗口的长短直接影响系统的可用性。所以工程上会尽量缩短选举时间。一方面把选举超时设置得合理不能太大否则Leader故障后恢复太慢另一方面要确保节点之间的网络延迟低消息传递快。在跨机房、跨地域部署时网络延迟高选举时间会更长。我之前在一套跨地域etcd集群上做过测试RTT在80毫秒左右时一次Leader切换造成的写请求不可用时间大概在几百毫秒到一秒之间对于很多核心链路来说是可以接受的但对那些要求5个9可用性又强一致的系统来说就必须认真调优。5. Leader上台后的日常工作日志复制与提交判定Leader选出来不是摆着看的它要开始干活了。它最重要的工作就是接收客户端请求、复制日志、推进提交状态。这一节我尽量把流程讲细因为在实际排查问题的时候很多疑难杂症都来自对日志复制细节的模糊理解。5.1 写请求的完整链路客户端到日志落盘以Raft为例一个写请求从客户端到达集群到客户端收到成功响应完整链路大致是这样的客户端把写请求发送给Leader。如果发给了FollowerFollower会拒绝写操作并返回自己知道的Leader地址。Leader收到请求后先把请求封装成一个日志条目包含三个关键字段任期号、日志索引、指令内容。然后Leader把日志追加到自己的本地存储里并行地向所有Follower发送AppendEntries消息把这条日志同步过去。每个Follower收到AppendEntries后会检查日志是否匹配匹配则追加到本地然后返回成功。Leader统计确认回执一旦发现多数派节点都已经落盘这条日志就认定这条日志“已提交”开始真正执行指令并在下一个心跳中把提交索引广播给Follower。此时Leader才向客户端返回成功。整个过程很像两阶段提交但它没有两阶段提交的阻塞问题也没有协调者单点。因为参与节点都是对等的Leader暂时充当协调者但集群不依赖它永远存活。5.2 提交规则的细节多数派与当前任期多数派确认是提交的必要条件但这里有一个非常经典的坑对于当前任期Leader来说它不能因为一条“旧任期”的日志条目已经在多数派节点上完成复制就直接把它标记为已提交。为什么因为这个多数派可能是临时凑出来的里面包含的节点不满足“包含所有已提交日志”的条件。举个具体例子Leader在term 3时当选它发现term 2有一条日志在3个节点上已经被记录了但它不能直接提交这条term 2的日志。因为term 2的日志可能是旧Leader期间由不同节点接收的当前多数派未必包含真正持有那条已提交日志的节点盲目提交可能会覆盖掉已经提交的数据。解决办法是Leader只有在当前任期里亲自创建并复制一条日志并拿到多数派确认后才能把这条日志标记为已提交同时顺带把之前任期的日志一并标记为已提交。这就是所谓的“上一任期的日志通过当前任期日志的提交而间接提交”。Raft论文里专门有一节讨论这个我在第一次实现时直接踩了这个坑导致数据分歧。如果你想自己写一遍Raft一定要把这条规则记牢。5.3 Follower日志回退与追赶正常情况下Follower的日志会紧紧跟住Leader但故障之后Follower的日志可能会跟Leader不一致。比如旧的Leader在提交前就崩溃了某个Follower可能保存了Leader没有的日志条目或者日志长度比Leader长或者中间某个位置缺少条目。Raft处理日志不一致的方式很粗暴但很有效。Leader在发送AppendEntries时会携带前一条日志的索引和任期号Follower会先检查这个位置是否匹配不匹配就直接拒绝。Leader收到拒绝后就尝试往前一个索引再试直到找到两边日志共同的那个点。找到之后把共同点之后的所有日志全部覆盖成Leader的日志。这个过程中Follower端可能被删除一部分日志。这些被删除的日志一定未提交因为已提交日志一定存在于多数派节点上而Leader包含所有已提交日志。所以删除它们不会破坏安全性。我在调试时经常用一个词追上。Leader用“回退-重放”的方式不断压缩距离直到两者完全一致。5.4 读请求也要过Leader线性一致性的代价很多人以为只有写请求需要找Leader读请求随便找哪个节点都一样。如果你的业务只要求最终一致那确实如此但如果要求线性一致性读请求也必须小心处理。Raft的论文里提到了几种线性一致读的实现方式。最简单的是让读请求也走一遍日志复制流程但这开销太大。更高效的办法是Leader需要确认自己还是当前term的合法Leader在回复读请求之前至少跟多数派核对一次心跳确保没有更新的Leader存在。这叫做ReadIndex机制。etcd里就把读区分为两种模式快速读serializable和线性一致读linearizable。前者直接在当前节点读自己状态机性能好但不保证读到最新值后者要经过一轮确认保证返回的一定是当前集群已经提交的最新状态。选型的时候要在性能与一致性之间做权衡明白背后的代价才不会在业务上出现“刚写完就读不到”的尴尬。6. 故障切换全流程Leader倒地后系统怎么自愈理解了Leader的职责与提交规则再看故障切换就会很清晰。我以一次完整的Leader故障为例把这个过程的每一步都走一遍同时结合运维中常见的预警现象来说明。6.1 故障与网络分区分布式系统的二义性难题首先要接受一个事实在分布式系统里你永远无法直接“知道”某个节点到底怎么了。一个节点收不到另一个节点的响应可能是因为对方宕机了也可能是网络在半路把消息丢了还可能是对方卡在GC里迟迟没执行。这种二义性是分布式系统一切困境的根源。所以任何故障检测本质上都是“超时判定”我规定一个时间在这个时间内没收到回应我就当它死了。这个判定可能是错的但共识算法设计得足够健壮可以容忍这种错误判定同时不破坏安全性。比如Follower可能把还活着的Leader误判为失联并发起选举但旧Leader因为拿不到多数派确认也翻不起浪花。6.2 一个完整的切主过程要经历哪几步一次典型的Leader故障切换大概会经历这几步Follower们在选举超时时间内没有收到Leader的心跳各自把term加1随机等待一小段时间后进入Candidate状态。某个Candidate率先发出RequestVote请求其他节点检查它的日志新旧度确认后投票给它。Candidate获得多数派投票切换到Leader立即开始发送心跳建立权威。新Leader在当选后的第一个任期里通常会提交一条空日志或者No-Op日志目的是“顺便”提交之前任期遗留的未提交日志。客户端带着旧term的请求到达旧Leader旧Leader发现自己的term已经过期不再处理写请求客户端重定向到新Leader。这个过程的核心就是先换身份再对齐状态然后恢复服务。大多数情况下从Follower发现Leader失联到新Leader开始处理请求只需要几百毫秒。6.3 旧Leader复活后会发生什么旧Leader从故障中恢复过来它可能还保留着大量未提交的日志。这些日志看起来像“未来数据”但实质上都是废数据因为新Leader并不包含它们。一旦旧Leader重新连接到集群它会从新Leader或者其他节点那里收到更高term的AppendEntries立刻意识到自己已经不是Leader转为Follower。然后它会对齐日志把本地那些与当前Leader不一致的未提交日志全部删除接受当前Leader的覆盖。这里有一个对客户端很重要的细节如果旧Leader在失联期间接收过一些写请求并向客户端返回了成功但这些请求因为没有多数派确认而并未真正提交那么当旧Leader恢复并回滚这些日志后客户端将永远无法读到这些数据。所以在共识系统之上客户端必须实现幂等重试同一个写请求带上唯一请求ID即使第一次超时、第二次打到新Leader也不会产生副作用。6.4 运维中需要盯的关键指标做过共识系统运维的人应该都养成了关注几个核心指标的习惯。第一个是Leader切换次数频繁切换通常意味着网络不稳定或者节点资源抖动。第二个是选举耗时分布如果经常超过1秒要考虑网络延迟和节点负载问题。第三个是心跳延迟它是衡量当前Leader与Follower之间连通性的直接信号。第四个是未提交日志的数量和积压情况这个数据如果一直居高不下说明集群写入路径有性能瓶颈。我还踩过一个典型的运维坑在用etcd做Kubernetes存储时节点被设置了过小的CPU配额导致节点进程GC频繁、心跳延迟飙升集群在业务高峰期频繁发生Leader选举整个控制面稳定性肉眼可见地下降。后来把CPU配额调大、限制后台GC频率集群才恢复稳定。这类问题在监控面板上看起来是“网络抖动”其实根因在资源限制。7. 从Leader角色出发谈谈共识系统的选型与设计谈了这么多内部机制最后落到实际工程决策上。我见过不少团队遇到“分布式一致性”问题就上共识集群结果成本和收益不成正比也见过有人因为Leader有单点风险干脆避用一切共识算法结果在数据一致性上吃大亏。平衡点到底在哪里值得系统说一说。7.1 必须用共识的场景与不那么需要的场景需要强一致、线性一致语义的场景基本躲不开共识算法分布式锁、配置管理、服务发现、分布式事务协调、全局唯一ID生成。这些场景的核心特点是写错一次比慢一点严重得多而且多副本并发的代价太高。反过来很多场景其实不需要共识。比如日志收集、监控指标聚合、离线数据统计它们天然接受最终一致。再比如缓存集群用多副本异步复制即使偶尔读旧数据也可以接受。在这些场景里硬套Raft只会增加写放大、降低吞吐、引入选主抖动属于自找麻烦。还有一种中间态设计比如“多Leader”或“主主复制”。在MySQL、Kafka等系统中都有应用它们允许每个节点独立处理写入再通过异步复制和冲突解决机制收敛。这种方式能提高写入可用性但代价是冲突概率和业务复杂度上升。真要选这条路最好对业务可容忍的分歧有清晰预期。7.2 我在工程实现中踩过的几个坑想分享几个很实际的教训都是我在实现和对齐共识系统时遇到的。第一个是节点总数问题。共识集群的规模最好是奇数。5节点可以容忍2个故障6节点其实也只能容忍2个故障但多出来的节点白白增加同步开销和故障概率。网上有些人喜欢用“3节点容忍1故障”“4节点容忍1故障”去对比不解释清楚会让新手困惑。奇数原则让多数派判定更高效也避免出现“两个多数派”这种尴尬。第二个是客户端的Leader地址缓存。我在初期做个简单的测试客户端每次都先从集群里查询当前Leader是谁再发请求结果因为频繁查询增加了大量额外请求。后来改成客户端自己缓存Leader地址仅在请求被拒绝时更新性能好一个数量级。很多官方客户端SDK默认就是这么做的。第三个是要避免在Leader的请求路径上做重活。本来共识的关键路径就是“客户端到Leader到多数派Follower”的往返任何额外开销都会直接放大到整体延迟。有次我把某些数据校验逻辑放在了Leader的同步拒绝路径上导致整个集群的写入耗时暴增。先异步化非关键逻辑再优化复制路径是我后来总结的铁律。7.3 你能记住的最重要的一句话Leader是角色不是机器把Leader理解成一个角色、一段状态而不是某一台特定的机器是理解整个共识系统的一把钥匙。角色可以被授予也可以被剥夺它不依赖任何单台设备的物理存活而依赖集群多数派对它的持续认可。这个认知在实际排障中极有指导意义。当你看到某个节点还在以Leader自居、还在接收请求不要立刻断定系统没问题先检查它是否真的能获得多数派确认。判定一个节点是不是合法Leader的唯一标准是法定多数是否认可它而不是它自己怎么想。这句话几乎可以作为分布式共识的入门心法。以我个人的经验把Leader角色想透的第二天再去看Raft、Zab甚至Paxos的论文你会觉得那些晦涩的细节突然理顺了。因为所有安全性规则本质都是在回答一个问题在某个term里到底谁有资格提交哪一条日志。而所有可用性设计则是在回答另一句当这个角色缺席时系统如何快速推出新的继任者又不破坏前任留下的承诺。能把这两件事平衡好你对分布式共识的理解就已经超过大多数人了。