从零构建 Kafka 拆解其核心机制：为什么必须这样设计

构建一个简化版 Kafka 时，第一件事就是意识到它不是一个普通的队列服务。它的核心目标是在分布式环境下提供高吞吐、持久化且可回放的消息流。这直接决定了后续所有组件的设计：broker 必须能高效处理海量日志，partition 要支持并行消费，replication 要保证数据不丢，ISR 机制要平衡可用性和一致性，而日志存储则把一切落到了磁盘顺序写上。

从零开始写代码时，你会先搭一个最小的 broker。它其实就是一个接受 TCP 连接、解析自定义协议的服务器。生产者把消息推过来，broker 立即追加到分区对应的日志文件里，不做任何复杂的索引。整个过程强调顺序追加，避免随机写。这一步直接解释了 Kafka 为什么能达到百万 TPS：磁盘顺序写速度远超随机写，配合零拷贝技术，数据几乎不经过用户态就从网络到磁盘。

为什么不直接用数据库存消息

很多人刚接触 Kafka 时会问，为什么不用 MySQL 或 Redis 存消息。自己动手实现后答案很清楚：数据库的 B+树索引和随机 IO 在高吞吐场景下会成为瓶颈。Kafka 把每条消息简单追加到文件末尾，只维护一个 offset 指针。消费者拉取数据时，broker 直接把文件句柄对应的内存映射区域发给网络，几乎零拷贝。这套设计把存储层彻底简化成日志文件系统，代价是放弃了按任意字段查询的能力，只支持按 offset 顺序读取。

国内团队常用 RocketMQ 作为替代方案。RocketMQ 早期也采用类似日志文件方式，但它把消息按主题和队列分开存储，每个队列对应一个 CommitLog 和 ConsumeQueue。ConsumeQueue 里存的是 offset、size 和 tag 哈希，相当于轻量二级索引。这让 RocketMQ 在过滤消息时比 Kafka 原生支持更好，而 Kafka 需要消费者自己过滤或者用 Kafka Streams 做二次处理。从零实现 Kafka 后你会发现，它的日志设计更彻底，broker 几乎不维护额外索引，全部压力推给消费者，这也是它在日志型场景里性能更极致的原因。

Partition 如何实现真正并行

接下来要实现 partition。代码里你会创建一个主题对应多个日志目录，每个目录代表一个分区。生产者根据 key 做 hash 或者轮询决定发到哪个分区。消费者组里的每个消费者只能消费一个分区，这样就避免了同一分区消息乱序的问题。

这个设计直接回答了“为什么 Kafka 消费能线性扩展”。增加分区就能增加并行度，只要消费者数量不超过分区数，吞吐就能上去。自己写代码时，你会遇到一个实际问题：如何记录每个消费者当前消费到哪个 offset。简化版实现里通常用一个单独的 offset 存储服务，或者直接写在消费者本地。真实 Kafka 把这部分做成了 __consumer_offsets 内部主题，用同样的日志机制存储，做到元数据和业务数据统一。

RocketMQ 的做法不同。它引入了 Broker 侧的消费队列和 offset 管理，消费者拉取时可以指定队列和 offset。RocketMQ 的队列概念更接近传统队列，而 Kafka 的 partition 更像分布式日志的分片。这导致两者在重平衡时的行为差异很大。Kafka 重平衡时会把整个 partition 重新分配给新消费者，RocketMQ 则可以在队列层面做更细粒度的迁移。从构建角度看，Kafka 的 partition 设计更简单，状态也更少，这降低了 broker 的复杂度。

Replication 和 ISR 的取舍

实现 replication 是整个练习中最能体现 Kafka 设计哲学的部分。你需要让每个分区有一个 leader 和多个 follower。生产者只跟 leader 打交道，leader 把消息推给 follower。关键在于 follower 什么时候算同步完成。

这里引入了 ISR（In-Sync Replicas）列表。只有保持在 ISR 里的副本才被认为是同步的。leader 只有在消息被 ISR 中所有副本确认后才返回成功给生产者。这直接影响了 Kafka 的 acks 参数：acks=1 只等 leader 写完，acks=all 则等 ISR 全部确认。

从零写代码时，你会发现维护 ISR 列表需要心跳机制、故障检测和列表更新逻辑。一旦 follower 落后太多或者心跳超时，就要把它踢出 ISR。这套机制保证了在大多数副本存活时，Kafka 能提供强一致性；同时当 ISR 缩小到只剩 leader 时，仍能继续提供服务，只是此时风险变高。Kafka 选择把这个权衡暴露给用户，而不是在底层自动做更复杂的多数派仲裁。

相比之下，RocketMQ 的复制机制更接近主从同步加异步刷盘。它支持 SYNC_MASTER 和 ASYNC_MASTER 两种模式，但主从之间的复制不强制要求全部从节点都确认。这使得 RocketMQ 在某些场景下可用性更高，但也可能出现主节点宕机后少量消息丢失的情况。自己实现 Kafka 的 replication 后，你会更清楚两者在一致性模型上的区别：Kafka 把一致性窗口控制在 ISR 里，RocketMQ 更多依赖运维配置和刷盘策略。

日志存储的细节决定一切

日志存储是 Kafka 最被低估的部分。从零实现时，你通常会先用一个简单的文件追加方式：每条消息前面写 4 字节长度，再写实际内容。这样消费者就能通过 offset 直接 seek 到文件位置。

真实 Kafka 做了更多优化。它把日志切成固定大小的 segment，每个 segment 有自己的 .log、.index 和 .timeindex 文件。index 文件用稀疏索引，只记录每隔几条消息的 offset 和物理位置。这样既节省空间，又能快速定位。删除数据时也不是真正删除，而是标记 segment 为可删除，等到没有消费者读它时才物理删除。这套设计让 Kafka 天然支持长时间保留日志，适合事件溯源和流处理场景。

实现过程中你还会碰到日志压缩（log compaction）。Kafka 允许为特定主题开启 compaction，只保留每个 key 最新的 value。这时候日志不再是单纯追加，而是需要在后台线程对同一个 key 的多条消息做合并。这又引入了更多复杂度：如何在不影响正在读取的消费者情况下做压缩，怎样处理 tombstone 消息等。

RocketMQ 的存储设计则更接近数据库日志。它有单独的 CommitLog 文件，所有主题的消息顺序写到一个大文件里，再通过 ConsumeQueue 建立主题到 CommitLog 的映射。这种设计在消息量极大时对磁盘顺序写更友好，但也带来了文件锁竞争和恢复时间较长的问题。Kafka 把日志按分区完全隔离，每个分区独立文件，故障恢复时只需要扫描该分区最后一个 segment，速度更快。

消费者组重平衡的实际代价

当消费者数量变化时，Kafka 需要重新分配 partition。这就是著名的 rebalance 过程。从零实现一个简化版消费者组协调器时，你会发现这个过程远没有表面简单。需要选举一个 group coordinator，维护消费者心跳，决定分区分配策略（range、round-robin、sticky），然后把分配结果通过协议推给所有消费者。

整个过程会暂停消费，直到所有消费者都拿到新分配方案并重新 seek 到正确 offset。这就是为什么生产环境里大家尽量避免频繁增减消费者。Kafka 后来引入了 cooperative rebalance 和 incremental cooperative 策略，试图减少不必要的停止，但核心问题依然存在：partition 分配是全局的，一次重平衡会影响整个消费组。

RocketMQ 在这方面的处理相对温和。它支持广播模式和集群模式，集群模式下消费队列的分配也由 broker 协调，但单个队列的重新分配对其他队列影响较小。这使得 RocketMQ 在消费者频繁上下线场景下的抖动通常比 Kafka 小。从构建 Kafka 的经验看，它的消费者组模型更适合消费者数量相对稳定、吞吐量大的日志处理场景，而非需要快速弹性伸缩的请求-响应型消息队列。

自己动手后对 Kafka 的新理解

完成一个能跑生产者和消费者的简化版 Kafka 后，你对官方文档里那些参数的理解会完全不同。min.insync.replicas、unclean.leader.election.enable、log.segment.bytes 这些配置不再是孤立的开关，而是你亲自实现过的机制的自然延伸。

更重要的是，你会明白 Kafka 的很多“缺点”其实是它在一致性、可用性、性能三者之间做的明确取舍。它选择把复杂度留在客户端和运维侧，换取 broker 的极致简单和极高吞吐。这也是为什么它在日志、事件流、数据管道领域统治力极强，却在传统事务消息、延迟队列等场景需要额外组件或外部系统配合。

国内很多团队在选择 Kafka 还是 RocketMQ 时，经常纠结于功能列表。自己从零构建一次 Kafka 后，判断标准会变成：你的业务更接近无限追加的日志流，还是需要丰富过滤和事务能力的传统消息队列。前者 Kafka 的设计哲学更匹配，后者 RocketMQ 的工程实现可能更省事。

这个练习的真正价值不在于最后得到的代码能在生产环境使用，而在于它把 Kafka 从一个“用了很久但说不清为什么”的黑盒，变成了一个每一行设计都有清晰理由的系统。当你下次调高 replica.factor 或者把 acks 改成 -1 时，你知道自己在改的是哪一部分取舍，也知道这个改动会在可用性和一致性之间带来什么具体影响。

这就是从零构建 Kafka 最值得做的地方。它不只教你怎么用，更教你为什么这么用。

参考来源

• Building Kafka from scratch to understand its internals