Raft共识协议在NewSQL中的实现：一个村庄的议事智慧

CH-05-06-030·约 20 分钟·数据库与存储系统·更新 2026-08-10

想象你生活在一个与世隔绝的村庄里，村民们需要共同决定何时修建水坝、如何分配粮食。没有中央权威，没有远程通讯，每个人都只能通过口耳相传了解村庄大事。如果大家不能达成一致，村庄就会陷入混乱；如果消息传错了，决策就会偏离正轨。这个村庄面临的困境，正是分布式数据库系统每天都在面对的问题——多个节点需要就数据状态达成一致，但网络可能延迟、节点可能宕机、消息可能丢失。在NewSQL数据库的世界里，这个“村庄议事规则”就是Raft共识协议。它像一位睿智的村长，设计出一套简单清晰的议事流程：选出一个领导者负责记录和传达决策，其他村民只需服从和确认。这套规则让一群原本各自为政的服务器节点，能够像训练有素的团队一样，保持数据一致、推进事务处理、从故障中恢复。今天，我们将走进这个由Raft协议治理的村庄，看看村民们是如何解决共识难题的。

岗位关联

对于AI从业者而言，理解Raft共识协议是掌握分布式系统核心的钥匙——无论是构建数据管道、设计特征存储，还是部署模型服务，共识机制都决定了系统的可用性与一致性边界。这篇文章将让你从零开始，真正懂分布式系统的心脏如何跳动。

可视化演示
Raft基本概念
领导者选举
日志复制
安全性保障
NewSQL实现
性能优化
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

\u5c55\u793aRaft\u5171\u8bc6\u6d41\u7a0b(Leader\u5199\u5165+\u65e5\u5fd7\u590d\u5236+Quorum\u63d0\u4ea4)\u3001Region\u5206\u88c2\u4e0e\u8d1f\u8f7d\u5747\u8861(\u6570\u636e\u5206\u7247\u52a8\u6001\u62c6\u5206+\u8fc1\u79fb)\u3001Snapshot\u5feb\u7167\u4e0e\u526f\u672c\u540c\u6b65(\u65e5\u5fd7\u538b\u7f29+\u5feb\u901f\u6062\u590d)\uff0c\u5207\u6362\u6a21\u5f0f\u67e5\u770b\u3002

本节配有交互动效（进入视口后自动加载，约 3KB）。

Raft\u5171\u8bc6\u534f\u8bae\u6d41\u7a0b Leader\u4e32\u884c\u5316\u5199\u5165:\u6240\u6709\u5199\u8bf7\u6c42\u7ecfLeader\u8f6c\u53d1 \u65e5\u5fd7\u590d\u5236:Leader\u2192Follower\u540c\u6b65\u65e5\u5fd7\u6761\u76ee commit = majority ack (n/2+1)

Raft基本概念

在遥远的山谷中，有一个村庄叫“数据库村”。这里没有村长，村民们依靠一种古老的“口耳相传”方式来协调事务。但问题来了——如果村民A说要建一座桥，村民B却说要修一条路，大家该听谁的？如果消息传到一半，传话的人在路上摔倒了，消息怎么保证不丢？这就是分布式系统的“共识问题”：多个节点如何就同一个决策达成一致，且这个决策一旦做出就不可反悔。

Raft协议就是为解决这个问题而生的一套“议事规则”。它把事情变简单了：村子里的每个村民（节点）不是平等的，而是划分成三种角色——领导者（Leader）是村长，负责拍板决策；跟随者（Follower）是普通村民，服从村长的安排；候选人（Candidate）是想当村长的人，会在村长失联时发起竞选。Raft将共识问题分解为三个子问题：领导者选举、日志复制、安全性保证，分别对应“谁来当村长”、“村长怎么传达决策”、“如何防止决策出错”。

每个村长都有“任期”（Term），就像一届政府有任期一样。Raft把时间划分为一个个递增的任期编号，每次选举开启一个新的任期。这个简单的设计让分布式系统里的“时间”有了统一坐标，节点之间沟通时只需比较任期号，就知道谁的消息更新、谁的信息过期。当节点之间通信时，更大的任期号具有更高的权威——就像新一届政府颁布的法令高于旧政府一样。

这个设计看似简单，却蕴含着深层智慧：村庄不需要每个人都聪明，只需要一套清晰规则让所有人知道该听谁的、如何轮换、何时重选。Raft 从 Paxos 复杂数学中走出来，用“先说人话，再讲算法”的方式解决了分布式共识的经典难题。

\displaystyle \text{Term}_{new} = \text{Term}_{old} + 1 \quad \text{（每次选举发起时任期加一）}

公式通俗说明：任期号是一个只增不减的计数器。每当一个节点发起选举，当前的任期号就加 1。在 Raft 中，节点通过比较任期号判断消息的新旧，任期号大的节点拥有更高的权威。

任期递增每次选举开始时，候选人将自己的任期号加 1，表示开启一轮新的领导周期。
$\displaystyle \text{Term}_{\text{candidate}} = \text{Term}_{\text{current}} + 1$
任期比较节点收到消息时，将自己的任期号与消息中的任期号比较，如果对方的更大，说明自己是“过时的”。
$\displaystyle \text{Term}_{\text{remote}} > \text{Term}_{\text{local}} \Rightarrow \text{更新为跟随者}$
多数派判定只有获得超过半数节点的同意，候选人才能成为领导者。
$\displaystyle \text{votes} \geq \lfloor \frac{N}{2} \rfloor + 1$

领导者选举

村长突然失联了！村民们怎么知道该选新村长？Raft 设计了一套优雅的“心跳”机制。村长（领导者）每隔一段时间就向全体村民（跟随者）发一条消息：“我还在，一切正常”。这条消息就叫心跳（Heartbeat）。如果村民们在一段时间内没有收到村长的任何消息，就会认定村长可能已经“驾鹤西去”——这时，村子就进入了选举状态。

每个村民都有一个选举超时（Election Timeout）定时器，时间随机设定在 150ms 到 300ms 之间。谁的计时器先归零，谁就率先发起选举，变成候选人，然后向其他村民喊话：“我要当村长，你们投票给我吧！”这里的随机超时非常关键——如果所有人的计时器同时归零，就会同时发起选举，造成选票分散，永远选不出村长。随机性就像“错峰出行”，让村民们错开竞选时间，减少冲突。

投票规则也很有讲究。每个村民在一个任期内只能投一票，先到先得。村民在投票时会检查候选人的“资历”——候选人拥有的日志是否比自己新（即候选人的最后一个日志条目的任期号是否更大，或者任期号相同但日志索引更大）。这就像选举时选民会考虑“这个人是否有经验”——资历老的候选人更可能当选，这让系统自动偏向日志更完整的节点，减少不必要的数据回补。

当新村长诞生后，他会立刻给所有村民发送心跳消息，告知自己的存在。其他村民收到心跳后，重置自己的选举计时器，安心做好听从安排的角色。整个过程就像一场高效的“推举大会”：有人失联，有人发起，多数人同意，新村长上任，村庄恢复秩序。

\displaystyle \text{选举超时} = \text{baseTimeout} + \text{random}(0, \text{randomRange})

公式通俗说明：选举超时时间 = 基础超时（如 150ms）加上一个随机范围内的偏移量。这样每个节点的超时时间都不同，避免同时发起选举造成“票仓分裂”。

随机超时生成每个跟随者都有一个随机化的选举超时时间，保证节点不会同时发起选举。
$\displaystyle T_{\text{timeout}} = 150 + \text{rand}(0, 150) \ \text{ms}$
发起选举计时器归零后，跟随者转为候选人，任期加 1，并投票给自己。
$\displaystyle \text{vote}_{\text{self}} = \text{true}, \quad \text{Term} = \text{Term} + 1$
获得多数票候选人收到超过半数选票后，立即成为新的领导者。
$\displaystyle \text{majority} \geq \lfloor \frac{N}{2} \rfloor + 1 \Rightarrow \text{Leader}$

日志复制

村长选出来了，但他怎么让所有人都知道他做的决策呢？答案是日志（Log）。村长的每一项决策——“张三家的地多分一亩”“村口修一条水渠”——都记录在一个附加的日志条目（Log Entry）里。这个日志就像一个“决策记录本”，每个条目包含三个信息：任期号（Term）、索引号（Index，即条目在日志中的位置）和具体操作（Command）。

日志复制的流程是一个精心设计的“记账循环”：

1. 村长收到一个事务请求（比如“从A账户转100元给B”），先将这个操作追加到自己的日志里，变成一个新条目。

2. 村长向所有村民发送 AppendEntries RPC（追加日志请求），包含了新条目和之前条目的索引、任期号。

3. 村民收到请求后，先做一致性检查：检查自己的日志中，是否存有村长指定的“前一个日志条目”。如果前后匹配，村民将新条目追加到自己的日志中，并回复成功；如果不匹配，村民拒绝追加，村长不得不从更早的索引开始回退重试。

4. 当村长收到多数派（包括自己）的确认回复后，这个条目就算“提交”（Commit）了。村长提交后，在下一个心跳中告知所有村民“这个条目已经官方确认”，村民随即将该日志条目应用到状态机。

这个“追加-检查-确认-提交”的流程，就像村民们在传阅一份重要文件：每个人都有副本，但只有在村长宣布“这份文件正式生效”后，大家才会真正执行。这种设计确保了一条铁的纪律：所有节点的日志都是“前缀一致”的。村庄里不会出现两个人拿到的决策记录不一样——因为在一致性检查面前，日志必须从开头到某个位置是完全相同的。

\displaystyle \text{prevLogIndex}, \text{prevLogTerm} \quad \text{匹配} \Rightarrow \text{追加新条目}

公式通俗说明：日志复制过程中，跟随者必须验证领导者的前一个日志条目与自己日志中相同位置的条目一致。只有前后匹配，才允许追加新条目——这保证了所有节点的日志前缀完全一致。

领导者追加日志领导者收到客户端请求后，在本地日志中创建新条目。
$\displaystyle \text{entry} = \{\text{Term}_i, \text{Index}_j, \text{Command}\}$
跟随者一致性检查跟随者检查 prevLogIndex 和 prevLogTerm 是否与本地日志匹配。
$\displaystyle \text{log}_{\text{local}}[\text{prevLogIndex}].\text{Term} \stackrel{?}{=} \text{prevLogTerm}$
多数派确认提交当多数节点复制成功，领导者将条目标记为已提交。
$\displaystyle \text{commitIndex} = \text{majorityMatchedIndex}$

安全性保障

有了选举和日志复制，Raft 是否就完美了？还差一步——安全性（Safety）。就像村庄需要法律来防止权力滥用，Raft 也制定了几条“不可违背的铁律”，确保系统在任意时刻都满足一致性。

第一条铁律：选举安全性（Election Safety）。在一个任期内，只有一个领导者能胜出。这依赖于“一个节点只能投一票”以及“多数派互斥”原则——两轮选举不可能都获得多数票，因为多数派必然有重叠。

第二条铁律：领导者完整性（Leader Completeness）。已提交的日志条目一定存在于之后所有任期的领导者日志中。这通过投票时的“日志新旧比较”实现：候选人必须在日志至少和自己一样新时才能当选。这就像一个规矩——“只有资历足够老的人才能当村长”。

第三条铁律：日志提交规则（Log Matching Property）。领导者绝不覆盖已提交的条目，只会通过日志匹配删除未提交的冲突条目。如果两个日志中的条目有相同的索引和任期，则这两个条目的内容一定相同；且之前的所有条目也都相同。

这三条铁律说明了 Raft 的设计哲学：简单性优先。正如村庄治理中“法律条文清晰可查”优于“法官自由裁量”，Raft 砍掉了 Paxos 中复杂的状态机推导，用可验证的数学规则确保安全性。无论网络分区、节点宕机、还是消息乱序，这些铁律都能保证系统不出错。

\displaystyle \text{if } \exists \, \text{entry}_i = \text{entry}_j \Rightarrow \forall k < i, \text{entry}_k = \text{entry}_k'

公式通俗说明：如果两个节点在相同索引处有相同任期的日志条目，那么这两个日志之前的所有条目也都完全一致。这保证了日志的前缀一致性。

日志新旧比较候选人必须拥有比投票者更新或等新的日志。
$\displaystyle \text{if } (\text{Term}_c > \text{Term}_v) \ \text{or} \ (\text{Term}_c = \text{Term}_v \ \text{and} \ \text{Index}_c \geq \text{Index}_v) \Rightarrow \text{vote}_v = \text{true}$
提交规则只有当前任期的条目才通过计数推断提交状态。
$\displaystyle \text{commit}_{i} \Longleftrightarrow \text{存在多数派包含条目}_i$

NewSQL实现

当 Raft 走出理论殿堂，进入 NewSQL 的世界时，它就像一位优秀的村长被请去管理现代化的大城市。在 TiDB 和 CockroachDB 这些著名的 NewSQL 数据库中，Raft 协议是它们实现“分布式事务 + 强一致”的基石。

在 TiKV（TiDB 的分布式存储引擎）中，数据被自动划分为一个个的Region（区域），每个 Region 是数据的一个分片。每个 Region 的多个副本组成一个 Raft Group（复制组），这个 Group 内部独立运行 Raft 协议。就像一个大城市划分成若干社区，每个社区有自己的村委会，社区内部的事务自己管理，社区之间的事务通过更高层的调度协调。

CockroachDB 的实现思路类似。它将数据按键范围划分为多个范围（Range），每个 Range 的副本组成 Raft Group。CockroachDB 采用“调表”式架构，所有范围均匀分布在集群节点上，每个节点同时承担多个 Group 的角色——可能是这个 Group 的 Leader，也可能是那个 Group 的 Follower。

在这种架构中，一个事务可能涉及多个 Raft Group，需要跨组协调。TiDB 使用两阶段提交（2PC）配合 Raft 实现分布式事务：先通过 PD（Placement Driver）确定事务涉及的所有 Region 位置，然后在各个 Region 上执行 Raft 日志复制，最后统一提交。这个过程就像一份跨社区的文件，需要村委会A先盖章，村委会B再盖章，最后县里统一备案。

这种“分而治之”的策略让 NewSQL 数据库获得了两个核心优势：水平扩展（增加节点只需迁移和分裂 Region）和故障恢复（某个 Region 的副本失效，其他副本自动接管）。Raft 在这里不仅是“议事规则”，更是整个系统架构的“宪法”。

\displaystyle \text{Data} \xrightarrow{\text{split}} \text{Region}_1, \text{Region}_2, \ldots, \text{Region}_n \quad \text{each} \to \text{Raft Group}

公式通俗说明：数据按范围切分成多个 Region，每个 Region 的多个副本构成一个 Raft Group。Raft Group 内部通过 Raft 协议保持一致，这实现了大规模集群的横向扩展。

数据分片大表按主键范围切割为多个 Region，控制每个 Region 的副本数（默认 3）。
$\displaystyle \text{Region}_i = \{\text{key}_{\text{start}}, \text{key}_{\text{end}}\}, \quad \text{replicas} = 3$
每片独立共识每个 Region 独立运行 Raft，有自己的 Leader 和 Follower。
$\displaystyle \forall \text{Region}_i: \text{RaftGroup}_i \xrightarrow{\text{Raft}} \text{consensus}$
跨区协调跨 Region 事务通过 2PC 协调，确保事务整体提交或回滚。
$\displaystyle \text{Txn} \to \text{coordinator} \to \sum \text{Region}_i\ \text{prepare} \to \text{commit}$

性能优化

然而，Raft 的纯粹实现在性能上还有提升空间。在村庄里，村长一次只能传达一条消息，效率太低；数据库集群每秒处理成千上万的事务，延迟和吞吐量至关重要。于是，工程师们从实战出发，设计了一系列优化策略。

批量处理（Batching）：领导者将多个日志条目打包在一个 AppendEntries RPC 中发送，减少网络往返次数。就像村长一次性宣读十条公告，而不是跑十趟。

流水线复制（Pipelining）：领导者不必等待上一个 RPC 完成就发送下一个请求。网络延迟被重叠掩盖，吞吐量大幅提升。

ReadIndex 优化（Read Index）：Raft 的标准读操作需要经过完整的日志复制流程，延迟较高。ReadIndex 方案让领导者先确认自己在当前任期仍是 Leader（通过心跳确认），然后直接读本地状态机，只需一次多数派的往返。将“写入”的安全性要求和“读取”的实时性需求解耦。

Lease Read（租约读）：领导者通过心跳获得一段“租约”时间，在租约期内确信自己是 Leader，直接本地读，避免每次读取都询问多数派。就像村长在任期内有合法权威，不必每次发话都征求村民同意。

预投票（Pre-Vote）：节点在超时后先发起预投票，询问其他节点“如果我发起选举，你们会支持我吗？”获得多数派“预支持”后才正式发起选举。这避免了一个刚脱离分区、日志严重落后的节点成为新 Leader，干扰系统。

这些优化在实践中已被 TiKV、etcd 等项目普遍采用，使 Raft 不仅“正确”而且“够快”。村庄还是那个村庄，但村长现在学会了用广播、错峰出行、以及提前打招呼来提高效率——没有改变规则本身，而是在规则框架内让系统跑得更顺。

\displaystyle \text{ReadIndex:}\ \text{确认Leader} + \text{本地读} \quad \text{vs} \quad \text{标准:}\ \text{日志复制} + \text{提交} + \text{应用}

公式通俗说明：ReadIndex 优化将读操作从“写一样的全流程”简化为“确认身份 + 本地读”，大幅降低读延迟。

批量打包将多个日志条目放入同一个 RPC 消息。
$\displaystyle \text{RPC}_{\text{batch}} = \{\text{entry}_1, \text{entry}_2, \ldots, \text{entry}_n\}$
ReadIndex 流程领导者向多数派确认心跳后直接本地读取。
$\displaystyle \text{read} \Rightarrow \text{heartbeat}_{\text{majority}} \Rightarrow \text{stateMachine}.\text{read}()$
Pre-Vote 请求候选人先请求预投票，获得多数支持才正式竞选。
$\displaystyle \text{PreVote}_{\text{req}} \to \text{majority} \to \text{正式选举}$

AI 应用场景

分布式数据库元数据协调

阶段：数据基础设施层

解决的问题：在 AI 训练中，特征存储需要实时更新，元数据（如特征版本、模型版本、数据分片信息）必须跨节点一致。传统的单点协调器成为性能瓶颈和单点故障源，而基于 Raft 的协调服务（如 etcd）能够提供高可用的元数据服务。

具体案例：某推荐系统团队在训练大规模 CTR 模型时，使用 TiKV 存储线上特征，每个特征分片由独立的 Raft Group 管理。当模型更新时需要读取最新的特征版本，借助 Raft 的强一致读（ReadIndex 优化），特征读取延迟从原来的 100ms 降至 5ms，并且任何节点故障都不会导致特征服务中断。

模型参数同步与状态管理

阶段：模型训练与参数服务器

解决的问题：在分布式深度学习训练中，参数服务器需要保持各 worker 节点的参数一致。Raft 可以用于参数服务器的主备切换与状态同步，确保在任何时刻只有一个主参数服务器生效，避免脑裂。

具体案例：一家自动驾驶公司使用自研的基于 Raft 的参数服务器集群，将模型参数的更新日志通过 Raft 复制到备节点。主节点宕机后，备节点在 3 秒内自动选举成为新主节点，训练任务无缝衔接，避免了因参数不一致导致的模型发散。

Python 演示

python79 行

import randomimport threadingimport time class RaftNode:    """简化版Raft节点实现，聚焦选举与心跳机制"""     def __init__(self, node_id, peers):        self.node_id = node_id        self.peers = peers        self.term = 0        self.state = "follower"        self.voted_for = None        self.leader_id = None        self.election_timeout = random.randint(150, 300) / 1000.0        self.last_heartbeat = time.time()     def tick(self):        if self.state != "leader":            if time.time() - self.last_heartbeat > self.election_timeout:                self.start_election()     def start_election(self):        self.state = "candidate"        self.term += 1        self.voted_for = self.node_id        votes = 1        for peer in self.peers:            if peer.vote(self.term, self.node_id):                votes += 1        if votes > len(self.peers) / 2:            self.state = "leader"            self.leader_id = self.node_id     def vote(self, term, candidate_id):        if term < self.term:            return False        if self.voted_for is None or self.voted_for == candidate_id:            self.voted_for = candidate_id            self.last_heartbeat = time.time()            return True        return False     def receive_heartbeat(self, leader_id, term):        if term < self.term:            return False        self.state = "follower"        self.leader_id = leader_id        self.term = term        self.last_heartbeat = time.time()        return True  class RaftCluster:    def __init__(self, node_count=3):        self.nodes = []        for i in range(node_count):            self.nodes.append(RaftNode(i, []))        for node in self.nodes:            node.peers = [p for p in self.nodes if p.node_id != node.node_id]     def run(self, seconds=2):        for _ in range(int(seconds * 100)):            for node in self.nodes:                node.tick()            for node in self.nodes:                if node.state == "leader":                    for peer in node.peers:                        peer.receive_heartbeat(node.node_id, node.term)            time.sleep(0.01)         leader = [n for n in self.nodes if n.state == "leader"]        return leader[0].node_id if leader else None  if __name__ == "__main__":    cluster = RaftCluster(5)    leader = cluster.run(3)    print("选出领导者节点:", leader)

目的：用面向对象方式模拟 Raft 的选举与心跳机制，展示五个节点如何自动选出一个领导者，并保持集群状态稳定。

self.election_timeout = random.randint(150, 300) / 1000.0每个节点随机生成选举超时时间，避免同时发起选举。
if time.time() - self.last_heartbeat > self.election_timeout:判断领导者的心跳是否超时，超时则触发新一轮选举。
self.term += 1节点发起选举时任期号加 1，确保消息的新旧可比较。
if votes > len(self.peers) / 2:当候选人获得超过半数的选票时，登基成为领导者。
peer.receive_heartbeat(node.node_id, node.term)领导者向所有跟随者发送心跳，维持自己的领导地位。

常见误区

误区我一直以为 Raft 和很多分布式缓存一样，是最终一致性协议——数据暂时不一致没关系，反正过一会儿就同步了。毕竟网络有延迟，节点之间有延迟不是很正常吗？

正解Raft 提供的是强一致性（Linearizable Consistency，线性一致性）。一旦数据提交，任何节点上的读取都能立即看到最新的已提交值。日志提交需要多数派确认，这条规则保证了数据一旦返回给客户端就绝不会回退。这里的“提交”就像村委会通过了一项决议——在通过的那一刻，整个村庄都必须遵守，而非“过一会儿再遵守”。

为何常见：很多分布式系统（如 Cassandra、DynamoDB）确实采用最终一致性，而 Raft 的“多数派确认”看起来也像是在等待同步完成，容易混淆。

误区我拿到选票数量就能决定谁是领导者吗？是不是像班级选班长一样，谁票多谁赢，不管他之前干过什么？

正解Raft 的选举不是简单的“人气投票”。投票者会检查候选人的日志是否“足够新”——候选人的最后日志条目必须至少与投票者的日志一样新（任期号比较、索引比较）。这就像选村长时不能选一个完全不了解村庄事务的外人，必须选一个有威望的资深村民。这个限制保证了新领导者一定包含所有已提交的日志条目。

为何常见：民主选举的“多数票”心智模型太强大，容易忽略 Raft 选举中“日志完整性”这一隐含条件。

误区Raft 每次写入都要多数派确认，那节点越多，网络开销越大，吞吐量不是越低吗？所以 Raft 只能用在几个节点的小集群里吧？

正解Raft 的单组共识确实适合小规模（通常 3-5 个副本），但这不意味着整个系统只能有小规模。NewSQL 的做法是分片 + 多组：把数据切成多个 Region，每个 Region 独立跑一个 Raft Group，每个 Group 只有 3 个副本。整个集群可以有上千个节点，每个节点同时服务多个 Region 的不同副本。就像一个大城市分成多个社区自治，每个社区只有几个人议事，但整个城市可以很大。

为何常见：看到 Raft 是“多数派协议”就直觉认为“集群越大越慢”，忽略了“多组并行”的架构设计。

误区ReadIndex 不是就是牺牲了强一致才换来低延迟吗？只在 Leader 上读，万一 Leader 实际上已经废了呢？

正解ReadIndex 并没有牺牲线性一致性。它要求领导者先与多数派确认心跳（证明自己仍是合法 Leader），然后才从本地状态机读取。这相当于村长先确认“我还在任”，再发布法令。确认过程保证了读时数据是最新的，只是省去了“完整日志复制-提交-应用”的全流程，并不降低一致性保证。

为何常见：看到“优化”两个字就联想到“降级”或“牺牲”，其实 ReadIndex 只是减少冗余步骤，并非削弱语义。

面试题

Q1. 在 Raft 中，节点之间通过什么机制维持领导者的权威？

单选题 · easy

A.心跳消息（Heartbeat）← 正确答案
B.定期重新选举
C.广播所有日志条目
D.每秒钟发送快照

答案：A。领导者通过周期性发送心跳消息（AppendEntries RPC，可带空日志）来维持权威。跟随者收到心跳后重置选举超时计时器，确认领导者仍然存活。重新选举是心跳失败后的动作，不是维持机制。

Q2. Raft 中发起选举时，任期号（Term）如何处理？

单选题 · easy

A.保持不变
B.自动加 1← 正确答案
C.清零重新开始
D.随机生成新值

答案：B。每次节点发起选举（从 follower 转为 candidate 时），任期号必须加 1。任期号是一个全局单调递增的整数，用于标识“第几届政府”，让所有节点能比较消息的新旧。

Q3. 一个 5 节点的 Raft 集群，至少需要多少个节点同意才能提交日志条目？

单选题 · mid

A.2 个
B.3 个← 正确答案
C.4 个
D.5 个

答案：B。Raft 采用多数派规则，5 节点的集群需要至少 3 个节点（包括领导者自己）确认日志写入才算提交。多数派保证任何两个多数派之间必有重叠，从而避免两个领导者各自提交冲突数据。

Q4. Raft 选举中，跟随者投票时会检查候选人的什么条件？

单选题 · mid

A.候选人的网络带宽
B.候选人的 CPU 资源
C.候选人日志是否足够新← 正确答案
D.候选人的节点位置

答案：C。投票者比较候选人的最后日志条目（任期号和索引）是否比自己的日志更新或等新。这个“领导者完整性”限制确保只有包含所有已提交日志的节点才能当选，防止日志回退。

Q5. Raft 协议中，以下哪些属于节点的角色？

多选题 · mid

A.Leader（领导者）← 正确答案
B.Candidate（候选人）← 正确答案
C.Observer（观察者）
D.Follower（跟随者）← 正确答案

答案：ABD。Raft 定义了三种角色：领导者（Leader）、候选人（Candidate）、跟随者（Follower）。节点在正常情况下是 Follower，超时后成为 Candidate，获得多数选票后成为 Leader。"Observer"不是 Raft 中的节点角色。

Q6. 日志复制过程中，跟随者如何验证领导者的日志与自己一致？

单选题 · easy

A.比较日志总长度
B.检查前一个日志条目的索引和任期号← 正确答案
C.要求领导者发送完整日志
D.随机抽查几个条目

答案：B。Raft 使用“日志匹配”特性：领导者发送 AppendEntries RPC 时包含前一个日志条目的索引和任期号，跟随者检查本地日志中相同索引位置的任期号是否匹配。只有匹配才接受新条目，保证了日志前缀一致。

Q7. 关于 Raft 日志提交，以下说法正确的是？

多选题 · hard

A.日志被复制到所有节点才算提交
B.领导者复制日志到多数派即可提交← 正确答案
C.已提交日志不会因为后续任期而丢失← 正确答案
D.跟随者可自行提交日志

答案：BC。Raft 只需多数派确认即可提交，不需要全部节点。已提交的日志在后续任期中由“领导者完整性”性质保证不丢失。只有领导者能决定提交，跟随者只是被动执行。

Q8. NewSQL 中 TiKV 采用 Raft 的方式是？

单选题 · mid

A.集群级统一 Raft 单组
B.数据分片多组并行的 Raft Group← 正确答案
C.每个节点独立运行完整 Raft
D.使用 Paxos 替代 Raft

答案：B。TiKV 将数据按 Key 范围切分为多个 Region，每个 Region 的多个副本构成独立的 Raft Group。每个 Group 独立选举和复制，实现水平扩展和故障隔离。

Q9. 以下哪项不是 Raft 领导者选举中使用的机制？

单选题 · easy

A.随机选举超时
B.多数派投票判定
C.任期号比较
D.权重投票← 正确答案

答案：D。Raft 采用人人平等的“一票一权”，没有节点权重概念。随机选举超时用于错峰选举，多数派投票判定用于选出领导者，任期号用于消息新旧比较，但 Raft 不引入权重投票。

Q10. Raft 在 NewSQL 中为提升性能，常见的优化策略有哪些？

多选题 · hard

A.批量发送日志条目← 正确答案
B.流水线方式复制← 正确答案
C.ReadIndex 本地读← 正确答案
D.领导者定期切换

答案：ABC。批量发送（Batching）减少 RPC 往返次数，流水线复制（Pipelining）重叠网络延迟，ReadIndex 优化让读操作确认领导者身份后直接本地读。领导者定期切换不是优化策略，反而可能影响稳定性。