本系列系统梳理了 Java 开发的详细知识点从基础语法到工程实践层层递进内容详实成体系建议先收藏再慢慢阅读方便日后随时回顾查阅。前言前一篇讲的是以 RabbitMQ 为代表的传统消息队列模型——Exchange 路由、Queue 收件箱。Kafka 虽然也叫消息队列但它的底层设计思路完全不同Kafka 本质上是一个分布式的、可持久化的日志Log系统消息队列只是它最常见的使用方式之一。这种设计差异决定了 Kafka 在吞吐量、消息保留方式、消费模型上和 RabbitMQ 有本质区别——这也是面试里Kafka 和 RabbitMQ 有什么区别这道题的根源。这篇就把这些原理讲清楚。1. 核心概念先建立一张全景图再逐个解释每个名词Kafka 集群多个 Broker └── Topic: order-events ├── Partition 0 [msg0, msg1, msg2, msg3, ...] ← 每个分区内部是一个有序的日志文件 ├── Partition 1 [msg0, msg1, msg2, ...] └── Partition 2 [msg0, msg1, msg2, msg3, msg4, ...] Producer ──写入──► Topic 的某个 Partition Consumer Group points-service-group ├── Consumer A ──消费── Partition 0 ├── Consumer B ──消费── Partition 1 └── Consumer C ──消费── Partition 2概念说明BrokerKafka 集群中的一台服务器一个集群通常由多台 Broker 组成Topic消息的逻辑分类类似 RabbitMQ 的 Queue但只是一个名字真正存数据的是下面的 PartitionPartition分区Topic 被切分成多个分区每个分区是一个独立的、按写入顺序排列的日志文件是 Kafka 并行处理的基本单位Offset偏移量消息在分区内的序号从0开始递增类似数组下标——一旦写入永不改变Producer生产者决定一条消息写到 Topic 的哪个 PartitionConsumer消费者从某个 Partition 按 Offset 顺序读取消息Consumer Group消费者组多个 Consumer 组成一个组一起消费同一个 Topic组内每个分区只会被组内一个 Consumer 消费2. 为什么 Kafka 吞吐量这么高这是 Kafka 区别于 RabbitMQ 最核心的部分——RabbitMQ 设计目标是灵活的路由 低延迟的小规模消息Kafka 设计目标是海量数据的高吞吐写入与读取。靠的是几个底层技巧2.1 顺序写磁盘很多人以为写磁盘慢但慢的是随机写磁头来回寻道。Kafka 的每个 Partition 在磁盘上就是一个只追加append-only的文件——新消息永远写在文件末尾这种顺序写的速度可以接近内存写入速度甚至比某些随机写的内存操作还快。Partition 0 对应的日志文件: [msg0][msg1][msg2][msg3] ← 新消息永远追加在这里不会修改/删除中间的内容2.2 页缓存Page Cache 零拷贝Zero Copy写入时Kafka 调用write()把消息写到操作系统的页缓存Page Cache可以理解成内存里的一块缓冲区就立刻返回不等真正写入磁盘。剩下的事交给操作系统——操作系统会在后台找合适的时机比如数据积累到一定量、或者过了一段时间把这些内存里的数据批量刷到磁盘上。你可以理解成Kafka 只负责把数据递给操作系统至于操作系统什么时候真正落盘Kafka 不关心、也不用等。这一步省掉的就是每条消息都要等磁盘真正写完才能继续的等待时间。读取时消费者来读消息正常流程是磁盘 → 操作系统内存 → 应用程序内存 → 网络发送缓冲区 → 网卡数据要被来回搬好几次。Kafka 用了sendfile这个系统调用后数据可以从操作系统内存直接送到网卡不用先搬进 Kafka 进程自己的内存里再搬出去——少了一趟进出应用程序的搬运过程这就是零拷贝。简化理解原来是快递先卸到你家客厅你再搬上车零拷贝相当于快递直接从仓库装上车省掉了卸到客厅这一步多余的搬运。2.3 批量发送与压缩Producer 不会来一条消息就发一次网络请求而是先把消息放进一个本地缓冲区攒成一批batch之后再一次性发出去并且可以对整个批次进行压缩如 Snappy/LZ4。批量压缩既减少了网络请求次数又减少了传输的数据量。什么时候触发发送缓冲区里的消息满足下面任一条件就会被打包发送配置作用batch.size这一批消息攒够了多少字节默认16KB攒够就发linger.ms即使没攒够最多再等多久也要发出去默认0可以调大让攒批效果更明显可以理解成攒够一车货 or 等到发车时间哪个先到就先发车——batch.size是装满的条件linger.ms是超时的条件避免消息因为一直凑不够一批而迟迟发不出去。小结一句话RabbitMQ 为了支持灵活路由和复杂特性设计更重Kafka 把模型简化成顺序写的日志文件用最朴素的数据结构换取了极高的吞吐量。3. Partition 与顺序性3.1 一条消息写到哪个 PartitionProducer 发送消息时可以指定一个key比如orderIdKafka 会用hash(key) % 分区数来决定写入哪个分区——这和 31 数据结构底层原理 里 HashMap 用hash (capacity-1)决定桶位置是同一个思路相同的 key永远落到同一个分区。如果不指定 keyKafka 会轮询各个分区尽量让数据均匀分布。3.2 顺序性分区内有序分区间不保证这是 Kafka 顺序性的关键结论也是面试常考点范围是否保证顺序同一个 Partition 内保证——消息严格按写入顺序排列Offset 递增跨 Partition不保证——Partition 0 和 Partition 1 之间的消息没有先后关系实际应用如果要求同一个订单的多条消息必须按顺序处理给消息指定key orderId这样这个订单的所有消息都会进入同一个分区分区内天然有序。这正是 30 消息队列 第8节里提到的用分区Key保证局部顺序的具体实现方式。4. Consumer Group消费者组4.1 分区与消费者的分配关系一个 Topic 的多个 Partition会被分配给同一个 Consumer Group 内的多个 Consumer——一个分区只能被组内一个消费者消费但一个消费者可以消费多个分区。下面以 Topicorder-events3 个 Partition为例看三种不同的 Consumer 数量会怎样分配结论分区数决定了一个 Consumer Group 内最大的并行消费能力——消费者数量超过分区数多出来的消费者会空闲。这也是为什么 Kafka 的 Topic 在创建时就要规划好分区数后续增加分区相对麻烦且会打乱原有的 key→分区映射。小贴士分区数是不是等于消费者数才最好不一定——更推荐分区数略多于当前消费者数关系结果分区数 消费者数并行度刚好打满没有闲置但没有扩容空间分区数 消费者数仍能打满当前并行度未来加机器时新消费者可以直接分走多余分区分区数 消费者数多出来的消费者闲置浪费资源因为分区数创建后很难修改改了会打乱 key→分区的映射破坏顺序性所以一般按未来可能扩到多少台机器留出冗余而不是卡死在刚好相等。一个 Consumer 能同时消费不同的 Topic 吗可以。一个消费者实例可以订阅多个 TopicKafkaListener(topics{order-events,payment-events},groupIdpoints-service)publicvoidhandle(ConsumerRecordString,Objectrecord){// 根据 record.topic() 判断是哪个 Topic 的消息分别处理}比如积分服务既要关心订单创建也要关心支付成功两种事件都会影响积分计算——一个消费者订阅两个 Topic 即可不需要为每个 Topic 单独起一个消费者实例。4.2 多个 Consumer Group广播效果Consumer Group 到底是什么回到 8.3 节的代码KafkaListener(groupId points-service)里的groupId就是 Consumer Group 的名字。Kafka 并不关心这个名字背后有几个实例、叫什么——它只记录一件事这个groupId在每个分区上消费到第几条Offset了记在__consumer_offsets里5.1节。所以本质上Consumer Group 一个独立的消费进度。多个 Consumer 实例如果填了同一个groupIdKafka 就认为它们是一伙的会把分区分给它们、共享同一份消费进度4.1节的分配逻辑如果填了不同的groupIdKafka 就认为这是完全独立的另一拨消费者会给它单独维护一份消费进度从头开始读。为什么需要这个设计因为 Kafka 的消息消费后不会被删除7节提到按retention保留一段时间。这意味着同一条消息理论上可以被读很多次——但读到第几条了这个进度必须有人来记录否则每次都不知道该从哪开始读。groupId就是用来回答这是谁在读、读到哪了——不同的下游服务积分、短信、数据分析各自起一个不同的groupId就能各自独立地、完整地消费同一份消息流互不影响。这正好呼应 30 消息队列 第1节讲的解耦——下游服务的数量、是否在线生产者完全不用关心。如果有多个不同的 Consumer Group都订阅了同一个 Topic每个 Group 最终都会读到完整的一份消息Topic order-events ├── Consumer Group points-service ← 自己的消费进度最终会读完所有消息 ├── Consumer Group sms-service ← 自己的消费进度最终会读完所有消息 └── Consumer Group analytics ← 自己的消费进度最终会读完所有消息不同的 Group 是同时收到消息的吗不是同时而是各自独立、各按各的节奏。消息写入 Topic 后一直躺在磁盘的日志文件里谁来读、什么时候读完全取决于每个 Group 自己的消费进度points-service处理很快可能消息一来就立刻读到了analytics这个 Group 如果是每小时批量跑一次那它可能等一小时后才一次性读取这期间积累的所有消息两者读的是同一份数据但读取的时间点完全不相关——这就是为什么说 Kafka 更像数据管道数据放在那谁什么时候来取、取多快是消费者自己的事和生产者、和其他消费者都没关系记忆方式组内是竞争消费分区分配给组内成员各消费各的一部分组间是各自独立的完整副本每个组都能读到全部消息但读取时机互不相关不是广播意义上的同时推送。4.3 Rebalance重平衡当 Consumer Group 内的消费者数量发生变化比如新增一个实例、或者某个实例宕机Kafka 会重新分配分区和消费者的对应关系这个过程叫Rebalance。Rebalance 期间该 Group 内的消费会短暂停止——这也是为什么 Kafka 消费者实例不建议频繁重启。5. Offset消费进度怎么记录Offset 是消息在分区内的序号。Consumer 消费消息后需要记录我已经消费到第几条了这样下次重启时才能从正确的位置继续而不是从头消费一遍。5.1 Offset 存在哪Kafka 自己维护了一个特殊的内部 Topic叫__consumer_offsets专门用来存储每个 Consumer Group 在每个 Partition 上消费到的 Offset。记录的形式大致是(groupId, partition) → offset比如(groupIdpoints-service, partition0) → offset105 (groupIdpoints-service, partition1) → offset98 (groupIdpoints-service, partition2) → offset112关键点每个分区只有一条进度记录记录是和groupId绑定的不是和某个具体的 Consumer 实例绑定。组内哪个实例当前负责这个分区就由哪个实例去更新这条记录——如果发生 Rebalance比如某个实例宕机分区被重新分配给另一个实例新实例会接着上次记录的 offset 继续读不会重复也不会跳过前提是之前正确提交了。不同的groupId则是完全独立的一套记录互不影响——这也是为什么 4.2 节里不同的 Consumer Group 可以各自独立地、完整地消费同一个 Topic。5.2 自动提交 vs 手动提交方式配置风险自动提交enable.auto.committrue默认每隔一段时间自动提交当前已读取到的 Offset如果消息读取到了但还没处理完就自动提交了 Offset随后处理失败/进程宕机重启后这条消息不会被重新消费——消息丢失手动提交enable.auto.commitfalse业务处理完成后调用consumer.commitSync()处理完才提交更可靠但如果提交之前处理完了又宕机重启后会重复消费这条消息这和 30 消息队列 第7节讲的幂等性是同一个问题——Kafka 默认提供的是至少一次语义业务侧仍然需要处理重复消费。6. 副本机制数据可靠性6.1 Leader 与 Follower为了防止某台 Broker 宕机导致数据丢失每个 Partition 会有多个副本Replica分布在不同的 Broker 上Partition 0: Broker 1: Leader ← Producer/Consumer 只和 Leader 交互 Broker 2: Follower ← 被动从 Leader 同步数据 Broker 3: Follower ← 被动从 Leader 同步数据所有读写请求只打到LeaderFollower 持续从 Leader 拉取数据保持同步如果 Leader 所在的 Broker 宕机Kafka 会从 Follower 中选出一个新的 Leader前提是这个 Follower 数据是同步的旁注这种一个 Leader 处理写入、Follower 同步数据、达到一定数量才算安全的模式和 ZooKeeper 的 ZAB 协议、Raft 是同一类思想。但这里的 Leader/Follower 同步是Kafka 自己实现的针对每个 PartitionZooKeeper老版本 Kafka 依赖它2.8 的 KRaft 模式已替换解决的是另一件事——集群元数据管理和谁来决定每个 Partition 的 Leader 是谁即 Controller 选举。两者思路相通但层次不同。6.2 ISRIn-Sync ReplicasISR 指的是和 Leader 数据保持同步的副本集合包括 Leader 自己。如果某个 Follower 因为网络问题、处理太慢长时间落后于 Leader会被踢出 ISR——这意味着它暂时不参与选举新 Leader和判断消息是否写入成功的过程直到追上进度重新加入。6.3 acks 参数生产者的可靠性级别Producer 发送消息时acks参数决定Broker 返回成功响应的时机直接影响可靠性 vs 延迟的权衡acks值含义可靠性延迟acks0Producer 发出去就不管了不等任何确认最低可能丢消息最低acks1默认只要 Leader 写入成功就返回确认中等——如果 Leader 刚写完就挂了还没同步给 Follower消息丢失中等acksall或-1等 ISR 中所有副本都写入成功才返回确认最高——只要 ISR 中有一个副本存活消息就不会丢最高配合min.insync.replicasISR 最少要有几个副本一起使用acksallmin.insync.replicas2是金融级场景常见的配置组合——即使丢了一台 Broker数据依然安全。一个更通用的视角acks这个参数其实是分布式系统里一个通用权衡的具体体现副本数越多、要求确认的副本越多 → 数据越不容易丢可靠性高但要等更多机器写完才能返回延迟越高。这个权衡在很多地方都能看到同样的影子场景“多确认可靠但慢” 的体现Kafkaacksacks0最快但可能丢acksall最慢但最安全MySQL 主从复制异步复制最快但主库宕机可能丢数据半同步复制至少1个从库确认更安全但主库要等从库 ack分布式锁/选举ZooKeeper/Raft写入需要过半节点确认才算成功本质也是用延迟换安全微服务里的同步调用 vs 异步消息28 微服务入门同步调用能立刻知道结果但要等下游处理完异步发消息快但成功只代表消息发出去了一句话分布式系统里几乎所有可靠性保证代价都是多等一会儿——acksall只是这个通用原则在 Kafka 里的一个具体参数化体现。7. Kafka vs RabbitMQ原理层面的对比结合前面的原理重新总结两者的核心差异维度RabbitMQKafka底层模型Exchange 路由 Queue内存/磁盘结构相对复杂分区日志文件顺序写结构极简吞吐量万级/秒百万级/秒消息有序性单个 Queue 内有序单个 Partition 内有序消息消费后默认被删除ACK后不会删除按配置的保留时间/大小保留多个消费者组可重复消费同一份数据消费方式Broker 主动推送给 ConsumerConsumer 主动拉取pull自己控制消费速度路由灵活性高Direct/Topic/Fanout 多种 Exchange低基本就是按 key 分区典型场景业务系统间解耦、任务队列日志采集、埋点数据、流处理、大数据管道一个常被忽略但很重要的区别RabbitMQ 的消息一旦被消费确认就从 Queue 里删除了Kafka 的消息消费后依然保留在磁盘上根据retention配置比如保留7天。这意味着 Kafka 里同一条消息可以被多个不同的消费者组在不同时间重复读取——这也是为什么 Kafka 常被用作数据管道上游写一次下游各个系统按自己的节奏各读各的。8. Spring Boot 基本使用8.1 依赖dependencygroupIdorg.springframework.kafka/groupIdartifactIdspring-kafka/artifactId/dependency8.2 生产者ServiceRequiredArgsConstructorpublicclassOrderEventProducer{privatefinalKafkaTemplateString,OrderkafkaTemplate;publicvoidsendOrderCreated(Orderorder){// 第一个参数是 Topic第二个参数是 key决定分区第三个是消息内容kafkaTemplate.send(order-events,String.valueOf(order.getId()),order);}}key传的是order.getId()——保证同一个订单的多条消息创建、支付、发货会进入同一个分区分区内有序。8.3 消费者ComponentpublicclassOrderEventConsumer{KafkaListener(topicsorder-events,groupIdpoints-service)publicvoidhandle(Orderorder){System.out.println(收到订单事件处理积分逻辑order.getId());}}groupId points-service就是 Consumer Group 的名字——如果另一个服务比如短信服务也订阅这个 Topic但用了不同的groupId如sms-service两个服务会各自收到完整的消息流互不影响对应第4.2节组间广播。8.4 配置spring:kafka:bootstrap-servers:localhost:9092producer:acks:all# 对应第6.3节consumer:group-id:points-serviceauto-offset-reset:earliest# 该 group 第一次消费时从最早的消息开始读enable-auto-commit:false# 对应第5.2节手动提交更可靠9. 小结主题核心要点核心模型Kafka 分布式的、可持久化的日志文件Topic 是逻辑名字Partition 是真正存数据的单位高吞吐原因顺序写磁盘 页缓存/零拷贝 批量发送压缩顺序性分区内严格有序分区间不保证用 key 让同一业务实体的消息进同一分区Consumer Group组内竞争消费一个分区只给一个消费者组间广播每个组拿到完整数据分区数的意义决定一个 Group 内的最大并行度消费者数 分区数时会有消费者闲置Offset记录消费进度存在__consumer_offsets自动提交可能丢消息手动提交可能重复消费副本与可靠性Leader/Follower ISRacks0/1/all决定生产者侧的可靠性与延迟权衡vs RabbitMQKafka吞吐量更高、消费后消息不删除、可被多组重复消费RabbitMQ路由更灵活、消费后即删除面试高频组合Kafka 和 RabbitMQ 的区别、Partition 与顺序性、Consumer Group 的分配关系、acks参数的权衡——这几个点把原理讲透了基本就能应对大部分关于 Kafka 的提问。具体的运维如何扩分区、如何调优页缓存属于用到时再查的范畴新人不必现在深究。 如果这篇文章对你有帮助别忘了点赞、收藏、关注三连关注我让你在 Java 学习的道路上不迷路持续为你带来成体系的 Java 干货~