1. 先把Kafka塞进一个具体场景里很多入门文章一上来就甩术语表Broker、Topic、Partition、Offset、Consumer Group……背完一圈回头还是不知道Kafka在干嘛。我换一个方式先搭一个具体场景再把Kafka的术语挨个对号入座。假设你在做一个电商平台每天产生三类核心数据订单数据、用户行为日志、支付流水。刚开始系统小让订单服务直接把数据写进数据库用户行为日志直接在应用内记到文件里一切都很美好。等流量涨上来你会被三件事逼疯数据库扛不住高频写入订单表和各种日志表互相抢资源。下游每个系统——风控、推荐、报表、搜索——都要拿到用户行为日志如果让应用自己给每个下游发一遍代码耦合到无法维护。高峰期瞬时流量是平时的几十倍下游服务根本消化不了你希望在流量洪峰时先把数据囤起来让下游按自己的节奏慢慢消费。Kafka存在的意义就是把这三种痛一次性解决。它是一个分布式消息系统核心职能可以概括为一句话让数据流在各个系统之间稳定、高效、可回溯地流动。你只管往里面扔消息Kafka负责把消息存好、分好再让所有需要的人按照自己的节奏来取。理解了这个定位后面的术语全都有了落点。这也就回答了最常被问到的问题Kafka和把数据写进数据库再定时批量查询有什么区别数据库的重心是存储和查询Kafka的重心是流式传输和分发。Kafka不是用来替代数据库的它是给系统之间铺管道的。术语再多本质上都在描述这条管道上的某个部件。2. 四个绕不开的角色Broker、Producer、Consumer、Consumer GroupKafka集群的物理组成很简单一堆服务器节点每个节点跑一个Kafka进程这个进程叫作Broker。你可以把Broker理解成管道里的中转站消息最终就是落在这些中转站上由它们负责接收、存储、转发。一个Kafka集群通常有多个Broker。为什么不能只用一个Broker单机意味着单点故障、带宽瓶颈和存储上限多个Broker组成集群后数据可以分散到不同机器上一台挂了别的机器还能继续服务。实际生产环境里三台Broker是最常见的起步配置既能保证基本的容错又不会让运维成本过高。消息生产者的角色叫Producer它的唯一职责就是把消息发到Kafka集群里。注意Producer不是直接把数据扔给某个消费者它只和Broker打交道发完就完了不需要关心下游谁在消费、什么时候消费。这种解耦正是Kafka的核心设计。我早期犯过一个错误试图在Producer里判断这个订单消息是否被支付服务处理完结果代码越写越乱。后来想明白了Producer和Consumer之间只通过Kafka传递数据永远不在业务上互相依赖。消息消费者叫Consumer负责从Kafka拉取消息做处理。单独一个Consumer很好理解但真实场景里通常是多个Consumer一起协作消费同一个数据流这时候就引入了Consumer Group消费组。消费组是Kafka里最容易让人糊涂的概念。一个消费组由若干Consumer实例组成它们共同消费一个主题Topic下的所有消息。组内有两个关键机制分摊一条消息只会被组内的某一个Consumer实例消费到不会重复消费。比如你开了4个消费者实例处理订单消息Kafka会把这批消息分成4份每份交给一个实例相当于负载均衡。协作扩容Consumer实例数可以动态增减。增加实例时Kafka会把原本分给其他实例的分区再重新分配这叫Rebalance后面细说减少实例时也一样。你不需要重启整个消费组Kafka会自动处理。该怎么理解Group和Topic的关系我常用一个比喻Topic是餐厅的出菜口Group是来吃饭的顾客群一个群里的顾客轮流把菜端走每道菜只上一个顾客手里但如果你开了好几个群每道菜每个群都能端走一份。用Kafka的术语说就是一个Topic可以被多个消费组独立消费同一个消费组内每个分区只被一个Consumer消费。这里有一个新手很容易踩的坑同一个Topic被多个Group消费时每个Group都会收到完整的数据副本而不是几个Group平分数据。换个角度说Kafka的消息不会被消费者拿走——它保存在Broker上每个Group从头到尾都能消费一遍互不干扰。这一点是做数据分发比如一份订单数据同时给风控、报表、搜索的基础。3. Topic与Partition消息是怎么分门别类又摊开存的**Topic主题**是Kafka里消息的分类单位相当于数据库里的表或者文件系统里的文件夹。一个Kafka集群可以同时承载很多个Topic比如订单Topic、日志Topic、支付Topic互不干扰。Producer往某个Topic发消息Consumer也指定订阅某个Topic大家通过Topic完成逻辑隔离。但Topic只是逻辑概念真正存储消息的物理单位是Partition分区。每个Topic会被分成多个Partition每个Partition是一个有序的消息序列。为什么要分区两个核心原因并行度如果Topic只有一份那无论多少个Consumer都只能排队消费完全发挥不了集群的威力。分成多个分区后不同分区可以交给不同Consumer并行处理。水平扩展单机磁盘容量有限把Topic的数据散到多个Partition、再把Partition分布到不同Broker上存储能力和吞吐量就能跟着机器数量线性增长。关于Partition有几个细节必须掰扯清楚第一Partition内部是有序的Topic整体无序。Kafka只保证同一个Partition内的消息顺序按照写入顺序不保证整个Topic的顺序。如果业务强依赖全局顺序通常的做法是把消息按某个Key比如订单ID哈希让同一个Key的消息永远路由到同一个Partition这样每个订单的消息在Partition内部严格有序。第二消息在Partition里的位置叫Offset偏移量。每条消息被写入Partition后都会获得一个从0开始递增的编号Consumer消费到哪里了就是记这个Offset。Offset是Kafka实现可回溯消费的关键——消息消费完不会立刻消失会按保留策略保留一段时间默认7天你可以把消费者的Offset重置到几天前重新消费历史消息。第三分区数是Topic创建时确定的之后可以增加但一般不建议减少。增加分区会影响同一个Key的消息分布原来同一个Key的消息可能被哈希到新分区导致顺序错乱减少分区Kafka干脆不支持。所以创建Topic时分区数要提前想清楚我的经验是结合峰值吞吐量和单分区能力来估单分区写入能力通常按每秒几万到几十万条估算然后往2倍冗余去配宁多勿少后期靠增加Consumer实例来提升消费速度分区数本身尽量不动。还有一个问题总有人问**分区越多越好吗**不是。分区多了会有额外开销——每个Partition都有一组文件句柄和内存缓冲集群里Partition总数过万后Broker的压力会明显上升。生产环境里见过一个Topic分了500个分区的性能反而比100个分区还差。分区数不是拍脑袋定的一般遵循分区数 目标吞吐量 / 单分区吞吐量的估算逻辑并留有冗余同时结合Consumer实例数保证每个Consumer至少分到1个分区、消费不至于闲置。4. 消息在Partition内部是怎么存和怎么读的这一节我们钻进Partition内部看看因为理解了存储结构你才能理解Kafka为什么快。每个Partition落到磁盘上并不是直接按一条消息一个文件存而是按Segment段滚动存储。一个Partition目录下包含多个Segment文件每个Segment文件大小默认1GB由Broker参数log.segment.bytes控制写满一个就创建下一个旧文件按策略清理。Segment内部才是真正的一条条消息每个Segment有两个配套文件.log存消息本体和.index存消息的Offset到物理位置的索引。Kafka的消息顺序读性能非常好因为磁盘顺序读写比随机读写快几个数量级Kafka设计之初就假设别怕落盘怕的是随机落盘。它把消息按顺序追加到Segment尾端消费者也是按顺序读所以能充分利用操作系统的Page Cache和磁盘顺序访问能力。我做过一个很粗糙的压测单分区持续写入的情况下Kafka吞吐量轻轻松松是同期一个关系型数据库写入路径的几倍靠的就是顺序IO。消息的读取依赖两层查找先根据目标Offset定位到对应的SegmentSegment记录了它管辖的Offset范围再在Segment内部的.index索引里做二分查找找到物理偏移量最后从.log文件里读消息。整个过程是内存索引加磁盘读的组合效率很高。讲到存储就绕不开消息保留策略。Kafka不是消息投递后就删除默认保留7天log.retention.hours到期后按Segment粒度删除。另外也支持基于大小设置保留比如Topic总容量超过10GB就删最老的Segment。如果你想长期保存消息而不消费就要调整保留策略或者配合分层存储方案。注意保留策略只影响数据还在不在和消费者的Offset没关系——只要数据还在Consumer随时能重置Offset回溯消费这是Kafka做事件溯源、离线分析的基础能力。还有一个生产环境常见的误配置把保留时间当成消费者最晚处理时间。如果某个消费组停了8天没消费默认保留策略下最老的消息已经过期删除这个Group的Offset已经指向不存在的数据位置重启后会发生什么Kafka检测到Offset超出范围会触发Offset重置策略auto.offset.reset默认情况下会从最新位置开始消费意味着那批消息被跳过了。实际业务里这个坑会造成数据丢失所以如果下游可能长时间停机要么调大保留时间要么消费组恢复后手动重置Offset。这也是我每次部署Kafka时都要反复和业务方确认的参数。5. 副本与ISR高可用的底气在哪里Kafka能成为生产环境首选消息系统副本Replica机制居功至伟。多副本的设计目标很直接任何一台Broker挂掉消息不丢、服务不停。从数据冗余的角度看每个Partition可以配置多个副本副本数记为replication.factor生产环境推荐至少2通常设为3。所有副本分两类角色Leader副本负责对外接收Producer写入、响应Consumer读取。所有读写都走Leader避免多副本数据不一致的麻烦。Follower副本只做一件事——从Leader拉取消息保持追赶以备Leader故障时顶上。为什么不搞多Leader多写原因很务实多写意味着多份数据要同时保持严格一致达成一致的成本太高、太慢。单Leader模型是牺牲一点写路径的可用性换取极简的一致性模型配合ISR机制在吞吐和可靠性之间取平衡。ISRIn-Sync Replicas同步中的副本是理解Kafka高可用的关键。ISR是Leader维护的一个同步副本集合里面是所有跟得上Leader进度的Follower。当Producer写入消息时副本同步策略有很多种可以不等待任何副本确认acks0可以等Leader写入成功就返回acks1也可以等ISR内所有副本都同步成功再返回acksall。**acksall是不是最保险的**不完全。ISR里的副本如果同步太慢会被Leader踢出ISR之后Leader只等当前ISR里的副本确认就算数。所以就算你设置了acksall也只保证返回时ISR内的副本都写入成功。如果ISR只剩Leader自己acksall和acks1就没区别了。这个细节很反直觉但很重要——分布式系统的可靠性从来不是靠一个参数解决的而是参数组合加监控兜底。Follower和Leader之间彻底失联比如Broker宕机会触发Leader选举。Kafka会从ISR里挑一个Follower提升为新Leader之后所有读写切到新Leader整个切换过程通常是秒级的。选Leader时优先考虑ISR里的副本因为ISR里的数据最全选它们能最大程度避免消息丢失。这里要提一个Trade-off单Leader模型在Leader宕机到新Leader选出的窗口期内写入会短暂不可用如果你设了acksall且ISR里只有Leader那么Leader一挂就是一段不可用时间。这是可用性和一致性之间经典的零和博弈。Kafka给了你参数去调但你必须知道自己选了什么。我见过不少生产事故是因为副本数配置不合理引起的Topic建好时replication.factor1单副本无任何容错Broker一宕机整个Topic不可用数据直接全丢或者min.insync.replicas设得太高导致写入成功率极低。这两组参数务必要配合着看我的建议是核心业务Topic副本数3min.insync.replicas2Producer设acksall。这样任意一台Broker宕机集群仍然可写可读且消息零丢失。6. Consumer与Partition的绑定关系为什么Group的成员数不能随便加Consumer和Partition的关系是Kafka消费模型里最核心的一条规则同一个消费组内每个Partition在同一时刻只能被一个Consumer实例消费但一个Consumer可以消费多个Partition。打个比方Partition是A、B、C三个窗口Consumer是窗口前排队的人。规则规定每个窗口只能同时服务一个人但一个人可以轮着去几个窗口取件。如果你有4个Consumer却只有3个Partition那么一定有1个Consumer拿不到任何分区处于闲置状态。消费者的数量超过分区数多出来的消费者不会增加消费速度只会白占资源。反过来如果Consumer实例数少于Partition数每个Consumer会承担多个分区的消费任务整体消费速度受制于最慢的那个Consumer。所以有个经验公式消费组内实例数最好等于支撑吞吐所需的分区数。想靠加Consumer实例线性提升消费速度前提是先把分区数配够否则加多少实例都是空的。这个规则的执行靠的是消费组协调器Group Coordinator它是Kafka集群里负责管理消费组的Broker端组件主要干两件事维护消费组的成员列表每个Consumer实例启动时会向协调器注册。当消费组发生变动成员加入、离开、订阅Topic变化、分区数变化时触发Rebalance再平衡。Rebalance是Kafka里人见人怕的概念我单独说一下。经历再平衡时整个消费组会进入一个短暂停顿所有Consumer停止消费放弃各自手里的分区Kafka重新计算哪个Consumer消费哪些分区算完后大家重新领取、重新开始消费。这个过程中消费是中断的而且会重复消费一些消息因为停下来的时刻有些消息已经拉取但还没处理完。**什么情况会触发Rebalance**最常见的三种Consumer实例主动加入或退出消费组比如部署新版本滚动重启服务。Consumer实例崩溃长时间没有给协调器发送心跳session.timeout.ms默认45秒。订阅的Topic分区数发生变化或者Consumer订阅的Topic集合发生变化。Rebalance最让人头疼的地方在于如果Consumer处理消息太慢或者频繁崩溃会导致长期反复再平衡——每次刚稳定下来又触发一次。我排过一个问题一个消费组里20个实例处理每条消息平均耗时5秒莫名其妙每隔几分钟就全部停一下。查了半天才发现是部分实例GC时间太长导致心跳超时被踢出Kafka一检测到成员变化就触发Rebalance恢复后又被踢循环往复。解决方案很粗暴有效调大max.poll.interval.ms同时把消息批处理缩小确保一次Poll后能快速处理完并恢复正常心跳。理解了上面这些你就懂了Kafka那句流传很广的话不要问Kafka怎么保证消息不重复你要问自己怎么处理重复消息。因为Consumer消费消息后Offset是异步提交的enable.auto.commit默认true每5秒自动提交一次。如果处理完消息但还没提交Offset时消费端崩溃重启后Kafka会从上次提交的Offset继续消费那一批消息就会被再处理一次。重复消费在Kafka里是常态业务上必须做幂等处理比如落库里加唯一索引或者业务表里判断状态。7. 用一张消息旅程把所有术语串一遍到这里Kafka基本术语已经全部出场了。我习惯在文章结尾用一个完整流程把所有概念串一遍保证读者脑子里是一张图而不是一堆词。一次完整的数据流转大概是这样业务系统作为Producer决定向某个Topic发送消息。消息带着可选的KeyProducer根据Key计算哈希决定消息落到Topic的哪个Partition没有Key则按轮询或Sticky策略分发。消息进入对应Partition后Leader副本把数据顺序追加到Segment文件并通知ISR中的Follower副本拉取同步。Producer根据acks配置决定在什么时机收到写入成功的确认。Broker把消息保存在Partition里保留策略决定这些消息存多久。文件按Segment滚动写、滚动删。Consumer启动时向消费组协调器注册协调器分配分区给组内每个Consumer实例。分配好之后每个Consumer负责从自己的Partition上拉取数据。Consumer从Partition的某个Offset位置开始顺序读取消息处理成功后提交Offset。Kafka记录了这个Offset下次从新位置继续消费。如果Broker出现故障该Broker上Partition的Leader会从ISR中选出新Leader读写自动切换到新节点消费者看到的是短暂抖动数据不丢。不同消费组可以各自独立消费同一个Topic。每个Group拥有自己的Offset记录所以同一份数据可以被报表系统从早到晚完整消费一遍也可以被风控系统只消费最近10分钟的新消息两者互不干扰。如果你把上面七步都真正理解了Kafka最经典的几个应用场景也就迎刃而解削峰填谷高并发写入Kafka下游按自己的速度消费流量洪峰被Partition和Buffer缓冲掉。数据分发一个Topic多个消费组一份数据多种用途互不影响。事件回溯Offset可以重置消息保留期内随时能从某个历史位置重新消费支撑故障修复和数据订正。系统解耦生产者不用知道下游是谁消费者不用关心数据从哪来大家只面向Topic编程。作为Kafka系列的第一篇博文这篇文章没有讲任何API细节也没贴一堆配置参数只做了一件事把Kafka的核心名词放到一个完整的业务场景里让它们各自找到自己的位置。我的经验是这些名词的底层逻辑没有内化之前直接上手现成API容易事倍功半——你自己API敲得飞起却不知道整个系统里是哪一环在帮你做到高吞吐、低延迟、可回溯。把基本的筋骨打好了后面聊生产配置、调优和源码都会轻松很多。下一篇我们顺着Producer往深处走聊聊生产端分区路由和批量发送的具体实践。
