上周帮一个朋友准备面试他提到面试官问了一个问题“Raft 协议在 TiDB 和 Kafka 里是怎么落地的”他当时只能说出“Raft 是用来做一致性的”但具体怎么用、为什么选它、两个系统里实现有什么不同就答不上来了。这个问题其实挺典型的。Raft 作为一个共识算法很多人在学习时只记住了它的选举、日志复制这些基础概念但一到实际系统里就懵了。更关键的是不同系统对 Raft 的使用方式差异很大——有的把它当核心一致性引擎有的只用在元数据管理上有的完全遵循论文实现有的做了大量优化和裁剪。如果你也遇到过类似困惑这篇文章会帮你把 Raft 从理论落到具体系统的实现层面。我会先对比 TiDB 和 Kafka 使用 Raft 的根本动机差异然后拆解它们各自的设计取舍和工程优化最后给出一些面试中和实际工作中判断系统设计质量的思考框架。1. 为什么 TiDB 和 Kafka 都选择了 Raft但用法完全不同理解 Raft 在不同系统中的落地首先要明白一个关键点没有系统会原封不动地照搬 Raft 论文每个系统都是根据自身的数据模型、访问模式和一致性要求来做裁剪的。TiDB 和 Kafka 虽然都用 Raft但它们的核心诉求完全不同TiDB 的核心是关系型数据的一致性作为分布式数据库TiDB 需要保证跨节点的数据强一致性。Raft 在这里是数据一致性的核心保障机制每个数据变更都要通过 Raft 日志复制来确保多数节点确认。Kafka 的核心是高吞吐的消息流Kafka 早期版本使用 ZooKeeper 做元数据管理但从 Kafka 2.8 开始逐步用基于 Raft 的 KRaft 模式替代 ZooKeeper。注意这里 Raft 主要管理的是元数据如 topic、partition 信息而不是消息数据本身。这种根本差异导致了两者在 Raft 使用上的第一个重要区别TiDB 的 Raft 是数据路径Data Path的核心组件而 Kafka 的 Raft 是控制路径Control Path的元数据管理器。1.1 TiDB用 Raft 保证分布式事务的 ACIDTiDB 的存储层 TiKV 将数据划分为多个 Region默认 96MB每个 Region 都是一个 Raft 组。这意味着每个写操作都是 Raft 日志复制过程当你执行一个 INSERT 或 UPDATE 时这个操作会被封装成 Raft 日志条目在 Region 的多个副本间复制只有多数节点持久化后才返回成功。读操作可以走 Leader 或 Follower为了平衡一致性和性能TiDB 支持强一致性读只从 Leader 读和弱一致性读从 Follower 读。这种灵活性是建立在 Raft 日志复制机制之上的。Region 分裂与调度也依赖 Raft当单个 Region 数据量过大时TiDB 会自动分裂 Region这个分裂过程本身也需要通过 Raft 共识来保证一致性。从工程角度看TiDB 对 Raft 的实现做了大量优化# 简化的 TiKV Raft 处理流程概念示例 class RegionRaftGroup: def propose_write(self, data): # 1. 客户端请求到达 Leader if self.role ! leader: raise NotLeaderError(current_leaderself.leader_addr) # 2. 生成 Raft 日志条目 log_entry self._create_log_entry(data) # 3. 复制到多数节点 success_count self._replicate_to_followers(log_entry) if success_count self.quorum_size: # 4. 提交并应用到状态机 self._apply_to_state_machine(log_entry) return success else: return retry_later这种设计保证了数据的强一致性但也带来了相应的性能开销——每个写操作都需要网络往返和磁盘持久化。1.2 Kafka用 Raft 简化架构提升运维稳定性Kafka 引入 RaftKRaft 模式的主要动机是去除对 ZooKeeper 的依赖从而简化架构、提升可运维性。在 KRaft 架构下Controller 节点通过 Raft 选举产生Kafka Broker 不再需要连接 ZooKeeper 来选举 Controller而是通过内置的 Raft 协议在 Broker 之间直接选举。元数据变更通过 Raft 日志复制Topic 创建、Partition 分配、ACL 配置等元数据变更现在都通过 Raft 日志在 Controller 节点间复制。数据路径保持不变消息的生产和消费仍然直接与各个 Broker 的 Partition Leader 交互不经过 Raft 共识过程。这是与 TiDB 最根本的区别。这种设计体现了 Kafka 的务实选择对于消息数据这种高吞吐场景如果每个消息都走 Raft 共识性能会急剧下降。因此只对低频变更的元数据使用 Raft而对高频的消息数据保持原有的 Leader-Follower 复制机制。2. 从单机到分布式Raft 如何解决系统扩展中的一致性问题理解了基本差异后我们深入看看 Raft 在这两个系统中解决的具体问题。这涉及到分布式系统设计中的一个核心权衡如何在一致性、可用性、性能之间找到平衡点。2.1 TiDB 的 Multi-Raft 架构数据分片与负载均衡TiDB 面临的一个关键挑战是如何将海量数据分布到多个节点上同时保证跨节点事务的一致性答案是Multi-Raft 架构。在 TiKV 中数据被水平切分成多个 Region每个 Region 约 96MB包含一个连续的数据范围。每个 Region 都是一个独立的 Raft 组有自己的一组副本通常 3 个。PDPlacement Driver负责 Region 的调度和负载均衡当某个节点热点过高时PD 会迁移部分 Region 到其他节点。这种架构的好处是水平扩展可以通过增加节点来扩展容量和吞吐量。故障隔离单个 Region 的故障不会影响其他 Region 的可用性。细粒度负载均衡调度单位是 Region 而不是整个节点。但挑战也随之而来跨 Region 事务需要两阶段提交增加了复杂性。Raft 组数量庞大一个 1TB 的集群就有上万个 Raft 组对资源管理和监控提出了更高要求。2.2 Kafka 的元数据共识从 ZooKeeper 到 KRaftKafka 的演进过程体现了分布式系统架构的一个趋势减少外部依赖简化运维复杂度。在 ZooKeeper 时代Kafka 的架构存在几个问题ZooKeeper 成为单点瓶颈所有元数据变更都要通过 ZooKeeper。运维复杂度高需要维护两套系统Kafka 集群和 ZooKeeper 集群。扩展性受限ZooKeeper 的写性能有限制约了 Kafka 集群的规模。KRaft 模式通过内置 Raft 协议解决了这些问题元数据操作性能提升去除了到 ZooKeeper 的网络往返。架构简化只需要部署 Kafka Broker不需要单独的 ZooKeeper 集群。更好的可扩展性Raft 协议本身更适合大规模集群的元数据管理。从工程实现角度看Kafka 的 Raft 实现做了针对性优化批量日志复制将多个元数据变更批量处理减少 Raft 日志数量。快照压缩定期生成元数据快照避免日志无限增长。控制流与数据流分离确保元数据共识不影响消息传输的性能。3. 面试中如何展现对 Raft 的深度理解回到最初的面试场景当被问到“Raft 在 TiDB 和 Kafka 中的运用”时一个优秀的回答应该包含以下几个层次3.1 第一层基础概念清晰首先确保能准确描述 Raft 的核心机制Leader 选举如何通过随机超时和多数派投票避免脑裂。日志复制如何保证日志顺序和一致性。安全性如何保证选举约束和状态机安全。但不要停留在概念层面要快速过渡到具体系统的实现差异。3.2 第二层系统差异分析对比 TiDB 和 Kafka 的使用场景差异维度TiDBKafka使用目的数据一致性核心机制元数据管理共识对象用户数据变更系统元数据变更性能要求中等延迟强一致性高吞吐最终一致性架构位置数据路径Data Path控制路径Control Path这个对比能展现你对系统架构的理解深度。3.3 第三层工程实现细节提到一些关键的实现优化TiDB 的 Region 分裂与合并机制TiDB 的 Learner 节点和 Follower 读Kafka KRaft 的批量元数据操作Kafka 如何平滑从 ZooKeeper 迁移到 KRaft这些细节表明你不仅了解理论还关注实际落地。3.4 第四层设计哲学思考最高层次是能够讨论设计取舍“TiDB 选择强一致性是因为作为数据库数据正确性比性能更重要。”“Kafka 只在元数据上用 Raft 而不用在消息上体现了对高吞吐核心诉求的坚持。”“两个系统都体现了合适的技术用在合适的地方这一工程原则。”这种思考能展现你的系统设计能力。4. 从使用到设计Raft 给你的分布式系统启示无论是面试还是实际工作理解 Raft 的最终价值在于能够将这些经验应用到自己的系统设计中。以下是几个实用的启示4.1 共识算法的选择不是非黑即白Raft 不是唯一的选择也不是所有场景的最佳选择。在实际设计中需要考虑如果读写比例极高可能更适合基于 Quorum 的最终一致性方案。如果主要是配置管理可以考虑 etcd 或 Consul 等现成方案。如果需要跨地域部署可能需要考虑更复杂的共识算法如 EPaxos。关键是要明确系统的核心诉求然后选择或裁剪合适的共识机制。4.2 性能优化往往在协议之外从 TiDB 和 Kafka 的实现可以看出真正的性能优化往往不在共识算法本身而在其周边的工程实现批处理将多个操作合并为一个 Raft 日志条目。流水线重叠网络传输和磁盘持久化。异步应用Raft 日志提交后异步应用到状态机。读写分离允许从 Follower 读取数据减轻 Leader 负载。这些优化通常比算法层面的改进带来更大的性能提升。4.3 监控和可观测性至关重要分布式共识系统在生产环境中最大的挑战不是算法正确性而是运维复杂度。必须建立完善的监控体系Raft 组状态监控Leader 变化、日志复制延迟、副本健康度。性能指标提案吞吐量、提交延迟、网络带宽使用。资源使用内存、磁盘、CPU 的使用情况。没有良好的可观测性再优秀的共识算法也无法稳定运行。4.4 测试策略需要特别设计基于 Raft 的系统需要特殊的测试方法网络分区测试模拟节点间网络中断。节点故障注入随机杀死节点进程。脑裂场景验证确保不会出现数据不一致。长周期稳定性测试运行数天或数周观察是否有资源泄漏或性能衰减。这些测试能帮助发现理论正确性之外的实践问题。回到最初的面试问题现在你应该能够给出一个层次丰富的回答从 Raft 的基础机制到 TiDB 和 Kafka 的具体实现差异再到背后的设计哲学和工程考量。这种回答不仅展示了你的技术深度还体现了你的系统思维和工程实践经验。真正理解一个共识算法不是背下论文中的状态机转换图而是能够说清楚为什么不同的系统会对它做不同的裁剪以及这些裁剪如何服务于系统的核心目标。这种理解能力无论是应对面试还是解决实际工程问题都是最有价值的。