很多人用 Kafka 用了很久Producer发消息、Consumer拉数据、topic 分分区说起来头头是道。可一旦线上出现分区不可用、消费组一直 rebalance、写入毛刺明显这些问题就很容易卡壳。原因也简单——Kafka 的所谓架构深入从来不是背几个组件名而是要把一条消息从生产到消费的完整路径、每一个环节为什么这么设计、哪些参数在什么场景下会真正起作用全部串起来。这篇文章就按我自己的理解把 Kafka 架构里最核心的部分拆开讲从生产者的分区与批量机制到 Broker 的日志存储与副本同步再到消费组的协调过程、Controller 的选举逻辑最后落到故障排查和参数调优上。适合已经跑通过 Kafka Demo、但还想往底层多走几步的读者也适合准备做生产环境选型和排障的同学参考。1. 先搭整体框架一条消息从生产到消费的完整链路1.1 这条链路上到底有哪些角色Kafka 和普通的消息队列不一样它不是Broker 收到消息推给 Consumer这么简单的模型。整条链路上有几个角色各司其职我把它们列出来后面所有细节都围绕这张图展开角色核心职责关键特征Producer序列化消息、选择分区、批量发送不关心消息最终被谁消费Broker接收消息、持久化存储、处理副本同步每个分区有 Leader 和 Follower 角色Controller集群元数据管理、分区 Leader 选举是逻辑角色一个 Broker 进程承担Consumer Group协调消费者实例、分配分区、维护消费位点一个分区同一时刻只被组内一个消费者消费这里有一个很多人容易忽略的点Kafka 的存储和消费模型并不是队列而是日志。每个分区就是一个有序的、只能追加写入的日志文件消费者通过记录自己在日志中的位置offset来读数据。正是这个日志模型决定了 Kafka 能支撑高吞吐、能回溯消费也决定了它的很多架构选择。1.2 一条消息具体的流转路径我用一个最简单的场景描述有一个order-topic3 个分区Producer 往里面发一条订单消息。第一步Producer 在客户端完成消息的序列化然后根据分区器决定的规则把这条消息放到某个分区对应的批次缓冲里。注意此时消息还在 Producer 进程内并没有发出网络。第二步Producer 端的发送线程把缓冲里的消息批量打包成请求发送给该分区 Leader 所在的 Broker。Broker 收到请求后把消息顺序追加到磁盘上的日志分段文件中然后返回确认。为了可靠性Leader 还会把消息同步给其他副本这一步的细节后面单独讲。第三步Consumer 通过poll()主动从 Broker 拉取数据。它去 Broker 查询自己当前消费到的 offset 之后的消息拿到后处理业务逻辑再定期提交 offset。整个过程看起来不复杂但每一环都有大量精细设计。比如 Producer 为什么攒一批发而不是一条一条发Broker 是怎么做到顺序写盘还足够快的Consumer 提交 offset 不丢消息又是什么机制下面顺着链路往下逐个拆。2. 生产者端的决定性问题消息发到哪个分区又该如何发2.1 分区器决定消息去向Producer 发消息时第一步不是发出去而是决定这条消息进哪个分区。这个决定由分区器完成默认分区器的规则是如果消息指定了分区号直接使用该分区。如果消息没有指定分区但有 key则对 key 的哈希值做 murmur2 哈希然后对分区数取模。如果既没有指定分区也没有 key则使用粘性分区Sticky Partition策略随机选一个分区并持续使用一段时间以提升批次的填充率。我个人在使用中的体会是key 的设计比大多数人想象的重要得多。比如你在做订单消息如果把用户 ID 作为 key那么同一个用户的所有订单消息都会进入同一个分区这样就能保证同一个用户的消息是全局有序的如果你用订单 ID 做 key那同一个用户的订单会被打散到不同分区去重、聚合类业务处理起来会更复杂。所以选 key 之前先问自己哪些消息需要保持相对顺序。2.2 批量发送与内存缓冲的配合逻辑Kafka 的高吞吐很大程度建立在攒一批再发这个设计上。Producer 端和发送相关的核心参数有三个batch.size每个分区批次缓冲的最大字节数默认 16KB。linger.ms批次缓冲最多等多久再发送默认 0。buffer.memoryProducer 端用于缓冲待发送消息的总体内存大小默认 32MB。关键点在这里batch.size并不是说攒够 16KB 才发而是批次里累计的消息大小超过 16KB 就立即发送。linger.ms0也不意味着消息会被立刻一条条发送而是指如果缓冲区一直不够满最多等 0 毫秒就发。实际运行时只要 Producer 持续有消息进来批次很快就能被填满网络利用率非常高。生产环境中如果业务消息普遍很小几百字节我一般会把batch.size适当调大。比如调到 32KB 或 64KB同时把linger.ms设为 5~10 毫秒。对于日请求量几千万的系统这 5 毫秒延迟换来的是更少的网络包、更低的 Broker 负载。前提是你的业务能接受几毫秒的额外延迟如果链路本身要求毫秒级极致响应那保持默认即可。2.3 ACK 机制与可靠性权衡acks参数是 Producer 和 Broker 之间约定什么程度算写入成功的开关有三个取值acks 取值含义风险0发出即认为成功不等 Broker 确认吞吐最高但消息可能直接丢失1Leader 落盘成功即返回确认分区 Leader 异常时可能丢消息all-1所有 ISR 副本都写入成功才返回最可靠但吞吐略降生产环境里金融、订单、支付类数据我会强约束使用acksall配合min.insync.replicas一起使用。min.insync.replicas的意思是如果 ISR 中的在线副本数少于这个值Broker 就直接拒绝写入宁可让业务报错也不要让数据在副本不足的极端情况下看似成功。常见搭配是acksallmin.insync.replicas2这样 Topic 有 3 个副本时即使 1 个 Broker 宕机消息依然能安全写入。有一个坑我在排查线上问题时遇到过只把acks设为 all但 Topic 副本数是 1min.insync.replicas也没设置。这种情况下所有副本都写入成功其实就一个副本真出事时数据照样丢。acksall只有在副本数足够时才有实际意义。2.4 幂等与事务不重复到底靠什么很多人以为enable.idempotencetrue能完全解决不重不丢其实这个机制解决的是Producer 重试导致的重复。幂等原理是Producer 每次初始化会申请一个 PIDProducer ID每条消息带上一个单调递增的 sequence number。Broker 端对同一个 PID 的分区消息做去重如果收到的 sequence number 比已写入的最大值小就丢弃。这样 Producer 因网络超时重试时消息不会在 Broker 端重复落盘。但注意PID 改变之后比如 Producer 重启幂等区间就断了。事务机制transactional.id在这基础上又加了一层跨分区原子性与状态管理让多条消息要么全部对 Consumer 可见要么全部不可见。架构上我建议这样选普通日志采集开幂等够了多表写入、订单状态流转这类需要多分区一致性的场景再上事务。3. Broker 存储层日志分段、偏移量与顺序写盘的真相3.1 分区日志在磁盘上的真实结构每个 Topic 的分区在 Broker 上对应一个目录命名规则是topic-分区号。这个目录里是一个个日志分段文件每个分段由一对文件组成.log存消息数据.index存稀疏偏移量索引。分段文件不是无限增长的。log.segment.bytes默认是 1GB当一个分段写满后Broker 会创建一个新的分段文件并把这个分段设为只读。这样做的好处在与清理——Kafka 的日志删除retention和压缩compaction都以分段为单位处理而不是一行一行删。分段足够小时过期数据的清理成本很低分段太大时清理延迟会很明显。日志文件还有一个重要特性顺序写。机械硬盘的顺序写性能可以跑到百兆每秒以上Kafka 利用的就是这一点。我们经常听说Kafka 快是因为顺序写但这只解释了一半。另一半是Kafka 写入时先在内存中做页缓存Page Cache然后异步刷盘。也就是说消息对 Consumer 可见的速度取决于写入页缓存而不是物理磁盘落盘时间。这是 Kafka 能维持极高吞吐的核心原因之一。3.2 消费者如何定位消息索引文件的作用假设 Consumer 要消费 offset 为 10000 的消息Broker 不可能把整个日志文件遍历一遍去找这条消息。它会先查构建好的偏移量索引文件.index这个索引是稀疏的每隔一定字节数记录一条offset物理位置对应关系。查的时候先找到小于等于目标 offset 最近的索引项再顺着物理位置往下扫描直到找到目标消息。这里的实际性能非常好因为一次查找最多多读几百 KB 数据而且这部分数据大概率已经在页缓存里。所以 Kafka 支持随便跳到任意 offset 消费代价很小。折中一点说之所以用稀疏索引而不是每条消息都做索引是为了在索引文件自身可以放内存和读取时定位快速之间找平衡。索引太稀疏定位要扫描更多数据索引太密集索引文件本身又太大占用页缓存空间。默认每写入约 4KB 数据记一条索引实测是合适的折中点。3.3 页缓存与刷盘策略的取舍Kafka 依赖操作系统页缓存而不是自己做一套缓存这个设计非常聪明。它带来的好处是只要内存足够读写速度都能接近内存。但副作用是如果进程崩溃Broker JVM 挂了页缓存里的数据尚未落盘消息就会丢失。针对这一点Kafka 提供了log.flush.interval.messages和log.flush.interval.ms两个参数但生产环境中一般不建议频繁刷盘。频繁刷盘等于把顺序写退化成随机写吞吐瞬间掉一个量级。实际做法是依赖副本机制兜底——如果一个 Broker 进程崩溃了它没来得及落盘的数据可能丢失但只要数据还在其他副本上消息就不会丢。这也是为什么 Kafka 高性能和数据安全并不矛盾它靠的是副本而不是刷盘保证可靠性。4. 副本与 ISR高可用架构里最容易理解偏的一环4.1 Leader 如何把消息同步给 Follower每个分区有多个副本其中一个被选为 Leader其余是 Follower。所有读写请求都走 LeaderFollower 只负责从 Leader 拉取数据、保持追赶。同步过程和 Consumer 拉取数据几乎一样每个 Follower 会主动向 Leader 发起FetchRequest告诉 Leader我已经消费到哪个 offset 了把后面的数据给我。Leader 收到请求后把对应的消息返回给 Follower。这里没有专门的主推通道也没有复杂的二阶段提交协议就是一个普通的拉取模型。副本同步涉及两个关键概念LEOLog End Offset当前分区日志里最后一条消息的下一个偏移量也就是已经写到哪里了。HWHigh Watermark已经被成功复制到所有 ISR 副本里的最新偏移量。HW 有一个重要作用它决定了哪些消息对 Consumer 可见。消费者只能消费 offset 小于 HW 的消息。这是为了防止 Leader 把单副本的数据直接给人消费结果副本还没同步完Leader 挂了消息跟着丢Consumer 读到的东西在故障后消失。4.2 ISR 机制什么样的副本才有资格参与同步如果所有副本都要确认写入一个失联的副本会把整个集群拖垮。Kafka 的解决办法是引入了 ISRIn-Sync Replicas也就是和 Leader 保持同步的副本集合。副本默认会被纳入 ISR 的条件是在replica.lag.time.max.ms默认 30 秒内Follower 一直在正常拉取数据。只要 Follower 持续跟上 Leader 的进度它就在 ISR 里。一旦某个副本超过 30 秒没有跟上网络故障、Broker 假死、Full GC它就会被踢出 ISR。acksall实际等待的是ISR 里的所有副本都写入成功而不是所有副本都写入成功。这里要明白两个容易混淆的概念ISR 收缩同步慢的副本被移出集合这是保护机制。ISR 扩张副本追上了 Leader 的进度重新被加入集合。在 ISR 缩到只剩 Leader 一个副本时如果min.insync.replicas配置小于当前 ISR 大小写入依然可以继续但此时的可靠性已经降到最低。如果这个 Topic 是重要的业务数据我强烈建议把min.insync.replicas设为 2宁可让写入报错也不能让消息悄无声息地丢。4.3 副本数到底配多少复盘过不少生产事故后我对副本数配置的结论很明确日志、监控类数据副本数 2 就够了甚至 1 也行丢了可以从源头重新采集。业务核心数据副本数 3min.insync.replicas设为 2。不建议超过 5副本数太多Leader 的同步压力会明显增大写放大严重反而拖慢吞吐。另外有个很容易被忽视的坑unclean.leader.election.enable这个参数。它默认是 false但这恰恰是关键。如果 ISR 为空比如所有副本都挂了Kafka 不会从 ISR 之外的副本选 Leader分区保持不可用而不是把可能落后很多的数据副本提上来。这样做的代价是可用性降低但避免了选出一个消息严重缺失的新 Leader导致大量数据丢失的情况。我的原则是核心业务一律保持unclean.leader.election.enablefalse。有些团队为了追求分区永远可用把它打开结果故障恢复后发现一个分区的数据落后了几个小时整个链路的数据都对不上这种事故比短暂不可用可怕得多。4.4 副本同步与生产写入的协同写入时请求到达 LeaderLeader 追加日志后要等 ISR 中的副本完成同步、更新 HW才对 Producer 返回成功。换句话说acksall 时Producer 感受到的延迟本质上是ISR 集合里最慢那个副本的同步延迟。如果某个 Follower 网络抖动同步延迟变大整个分区的写入延迟都会变大。这也是为什么副本数量不是越多越好——每加一个副本都要等一个同步节点。做过压测的读者应该能看到明显对比副本从 1 加到 3TPS 可能有 30% 的下降从 3 加到 5下降会更明显。5. 消费组与 Rebalance消费者侧的协调架构5.1 消费组到底由谁协调Consumer 不是直接连到分区读写数据而是要经过一个组协调者GroupCoordinator。每个 Broker 上都运行着协调者角色负责管理一部分消费组。协调者的职责包括管理消费组的状态初始、准备重平衡、稳定等。管理组成员的心跳。触发并完成分区分配。维护消费组的 offset 元数据。Consumer 启动时会请求 Broker 找到自己所属消费组的协调者然后向协调者注册。协调者和 Broker 的对应关系老版本中由 Zookeeper 协调新版本也同样是先查元数据然后再建立连接。5.2 Rebalance 的完整过程与触发条件所谓 Rebalance直白说就是消费组成员变化时把分区的所有权重新分配一遍。整个过程分三步第一步任何一个消费者加入或离开组都会向协调者发送请求。协调者检测到成员变化后把组状态置为 PreparingRebalance。第二步协调者向组内所有消费者发送通知要求它们重新加入JoinGroup。所有消费者停止消费、提交 offset然后重新提交自己的订阅信息。第三步协调者从组内选择一个消费者作为分配者让它根据订阅信息算出分配方案SyncGroup再把方案广播给所有成员。不难看出整个 Rebalance 是一个全体成员参与、全体暂停消费的过程。这是消费侧架构里最影响稳定性的部分。一个消费组几百个消费者一旦某台机器失联触发 Rebalance可能出现消费暂停几十秒、分区在成员间转移、原本本地缓存的数据全部作废重拉。触发 Rebalance 的常见原因有三个触发条件相关参数默认值消费者心跳超时session.timeout.ms10000ms消费者处理消息超时max.poll.interval.ms300000ms新消费者加入或主动退出无无实际排障中rebalance 频率最高的原因是max.poll.interval.ms。消费者单条消息处理太慢或者批量拉取到太多消息导致一轮处理超过 5 分钟协调者就认为它死了强制把它踢出组触发重平衡。5.3 三种分区分配策略的差异协调者选出一个消费者当分配者后这个消费者按当前组里的分配策略生成方案。常见的有三种RangeAssignor按主题顺序将分区分配给消费者。比如一个主题有 3 个分区、2 个消费者第一个消费者拿 2 个分区第二个拿 1 个。多个主题时每个主题都这样分容易倾斜。RoundRobinAssignor把组内订阅的所有主题分区按环形轮流分配给消费者尽量平均但重平衡时容易变化。StickyAssignor在尽量保持之前分配结果的前提下做平衡rebalance 时不会大量转移分区是目前默认配置。我实际使用中的建议是如果每个消费者订阅的主题相同、数量多Sticky 是首选如果业务上确实需要某个消费者只负责特定分区那就不要依赖自动分配直接手动给消费者指定分区列表。5.4 如何减少 Rebalance 的影响以我多年排障的经验治理 rebalance 主要从三个方向下手调参把session.timeout.ms调大比如 15000msheartbeat.interval.ms保持为session.timeout.ms的三分之一给短时网络抖动留余量。改逻辑Consumer 处理消息和poll()分开把耗时的业务操作放到单独的线程池去做保证主线程能持续 poll避免max.poll.interval.ms超时。升级协议启用增量再平衡协议Cooperative Incremental Rebalance它允许部分配属稳定的消费者不中断消费只在需要调整的消费者间转移分区。Kafka 2.4 之后默认支持开启后重平衡的影响面会小很多。6. Controller 与集群元数据Kafka 的分布式大脑6.1 Controller 是谁干什么活Kafka 集群里有一个逻辑上的主控角色叫 Controller。它实际由某个 Broker 进程承担负责全局元数据管理。Controller 的核心职责有分区 Leader 选举、分区分配与迁移、副本变化处理、集群 Broker 上下线感知、向所有 Broker 广播元数据变更。可以这样说数据读写不经过 Controller但谁当 Leader、哪个分区在哪个 Broker 上、Broker 挂了之后怎么恢复都由 Controller 拍板。如果 Controller 所在的 Broker 宕机其他 Broker 会通过内部的选举机制重新选出一个 Controller。选举过程不用人工干预整个集群会自动恢复。6.2 分区 Leader 的选举逻辑正常情况下的 Leader 选举规则是优先选择 ARAssigned Replicas列表里靠前的、并且存活副本中的第一个作为 Leader。这里有一个配置叫auto.leader.rebalance.enable它保证集群在运行一段时间后会尽量把 Leader 平衡到各个 Broker避免 Leader 都堆在同一个 Broker 上。故障选举和正常选举不同。分区当前 Leader 失联了Controller 会根据自己的元数据从 ISR 里挑一个副本作为新 Leader。如果unclean.leader.election.enablefalse则执行严格的规则ISR 为空时分区不可用等原 Leader 恢复。实践中区分正常与异常选举很重要。正常选举几乎无感知异常选举如果没有打开 unclean 选举就表现为分区 Write/Read 不可用这时候不要急着改配置让分区立刻可用先看看能不能把原 Leader 拉起来或确认 ISR 之外的副本数据是否完整。数据完整性永远排在可用性前面。6.3 新架构Controller 和元数据管理的演进早期版本的 Kafka 重度依赖外部协调组件来管理元数据和 Controller 选举。集群元数据Topic 列表、分区分配、Broker 存活状态都存在这个外部系统里Controller 选举也由它控制。这套机制虽然成熟但多了一套外部依赖运维成本和故障点都变多了。较新的版本逐步引入了自己的内部元数据机制KRaft即 Kafka Raft。这个模式下Kafka 不再依赖外部协调组件而是自己通过 Raft 协议管理元数据。Controller 仍然是核心角色但元数据被记录在专用的内部主题中由 Controller Quorum 共同维护。从架构演进角度看Kafka 是在把协调外部化变成协调内部化。这带来的实际好处是部署组件更少、元数据恢复更快、运维复杂度更低。目前不少新部署已直接采用 KRaft 模式老集群迁移则要评估现有工具链和管理脚本是否兼容。我在带团队做新业务选型时对新集群直接建议使用 KRaft 模式。不是因为新而是因为部署和维护成本低了一个量级也不存在外部协调组件出问题时整个 Kafka 不可用的连锁故障。7. 故障排查实战架构知识怎么用在关键时刻7.1 分区不可用的排查思路线上最常遇到的告警是分区不可用OfflinePartitions。从架构角度看这类故障的根源基本都是 ISR 为空、没有可用的 Leader。排查路径如下查看哪些分区离线登录 Broker 用命令确认分区副本分布情况、确认 ISR 列表。正常状态下 ISR 里应该有多个副本如果 ISR 为空说明所有副本都不健康。找原因分别检查副本所在的 Broker 是否存活、磁盘是否写满、网络是否隔离、Broker 是否处于 Full GC。看监控。如果只是某个 Broker 的副本被踢出 ISR重点查这个 Broker 的 GC 时间、磁盘延迟、CPU 负载。如果是跨机房的网络抖动导致整体 ISR 收缩优先查网络质量。根据原因恢复而不是盲目重启。磁盘满就清理或扩容GC 问题就调 JVM 堆和 GC 策略网络问题就报给网络团队处理后等 ISR 自动恢复。7.2 ISR 频繁收缩的隐蔽原因ISR 收缩是最让运维头疼的问题之一因为它的表现是数据不丢写入延迟偶尔飙高过一会儿又自己恢复。常见原因包括Broker 的页缓存不足Follower 拉取速度跟不上。磁盘 IO 被其他业务挤占比如和其他高 IO 组件部署在一起。副本同步线程数不足默认的num.replica.fetchers是 1多副本时同步能力可能不够。消息体过大单条消息几十 MBFollower 拉取一次要写很久。排查 ISR 收缩时kafka-topics.sh的--describe是最好用的诊断工具。它能看到每个分区的 Leader、ISR、副本分布以及 ISR 里有没有少副本。如果某个 Broker 上的副本频繁不在 ISR 里这个 Broker 大概率有问题。7.3 消费延迟与堆积怎么定位是消费者还是 Broker消费延迟的排查第一步是用kafka-consumer-groups.sh --describe --group 组名看每个分区的当前 offset 与 log-end-offset 的差距。如果所有分区都有延迟且消费组所有成员都在运行那问题在消费者侧性能单条消息处理太慢、处理逻辑里有远程调用或锁竞争、消费者线程数不足。如果只有个别分区有明显延迟问题可能是分区分配不均衡。比如某个消费者被分配了多个消息量大的分区而其他消费者很空闲。这时需要看分配方案和 Sticky 策略是否真的打散了热点。还有一个经常被忽略的原因Consumer 拉取到的消息量太大单次 poll 返回几千条业务处理不过来然后一直循环拉取-处理-拉取max.poll.interval.ms超时被踢出组又触发 rebalance重平衡期间消费停止延迟进一步扩大。形成一个恶性循环。这种情况要调整的不是并发数而是max.poll.records把单次拉取量降到几百条让每次处理都在超时时间以内。7.4 常用工具与参数速查我把排障中用得最多的几个工具和参数整理成表方便大家直接参考工具/参数用途常用命令或配置示例kafka-topics.sh查看分区、副本、ISR 状态--describe --topic order-topickafka-consumer-groups.sh查看消费组状态、位点、延迟--describe --group order-groupkafka-configs.sh修改或查看 Topic 级配置--alter --entity-type topics --entity-name t --add-config min.insync.replicas2num.replica.fetchers控制副本同步线程数Broker 配置建议 2~4min.insync.replicas控制写入可用副本的下限Topic 级或 Broker 级业务核心数据建议 2replica.lag.time.max.ms控制副本被踢出 ISR 的超时默认 30000ms按网络质量调整排障接近尾声的时候还有一个小技巧分享给大家Kafka 的监控指标一般都会暴露UnderReplicatedPartitions和OfflinePartitionsCount。前者是副本同步落后的实时值后者是分区无 Leader的计数。我通常会把这两条指标设为高优先级告警只要它们一抬头就立即开始排查而不是等用户报障。8. 关于架构深入的一点个人体会把 Kafka 架构从头到尾过一遍之后你会发现它没有任何一个环节是为了复杂而复杂。分区模型是为了水平扩展ISR 是为了在性能和可靠之间动态平衡消费组协调是为了让多个消费者安全地分摊数据Controller 是为了让集群具备自治能力。理解这些设计意图远比记住某个参数默认值重要。如果在读这篇文章的你也正在维护 Kafka 集群我建议你下次再遇到问题时不要急着翻参数文档。先问自己三个问题这条链路里哪个环节做了取舍我看到的指标和这个环节有没有直接关系如果我调整参数是在调整哪个取舍的天平想清楚这三个问题大部分故障的原因和解决方案已经清晰了一半。 
长河君 · 2026/10/13 23:52:00 · 阅读 1.2k Kafka架构深度拆解：从分区、副本到消费组与故障排查
很多人用 Kafka 用了很久Producer发消息、Consumer拉数据、topic 分分区说起来头头是道。可一旦线上出现分区不可用、消费组一直 rebalance、写入毛刺明显这些问题就很容易卡壳。原因也简单——Kafka 的所谓架构深入从来不是背几个组件名而是要把一条消息从生产到消费的完整路径、每一个环节为什么这么设计、哪些参数在什么场景下会真正起作用全部串起来。这篇文章就按我自己的理解把 Kafka 架构里最核心的部分拆开讲从生产者的分区与批量机制到 Broker 的日志存储与副本同步再到消费组的协调过程、Controller 的选举逻辑最后落到故障排查和参数调优上。适合已经跑通过 Kafka Demo、但还想往底层多走几步的读者也适合准备做生产环境选型和排障的同学参考。1. 先搭整体框架一条消息从生产到消费的完整链路1.1 这条链路上到底有哪些角色Kafka 和普通的消息队列不一样它不是Broker 收到消息推给 Consumer这么简单的模型。整条链路上有几个角色各司其职我把它们列出来后面所有细节都围绕这张图展开角色核心职责关键特征Producer序列化消息、选择分区、批量发送不关心消息最终被谁消费Broker接收消息、持久化存储、处理副本同步每个分区有 Leader 和 Follower 角色Controller集群元数据管理、分区 Leader 选举是逻辑角色一个 Broker 进程承担Consumer Group协调消费者实例、分配分区、维护消费位点一个分区同一时刻只被组内一个消费者消费这里有一个很多人容易忽略的点Kafka 的存储和消费模型并不是队列而是日志。每个分区就是一个有序的、只能追加写入的日志文件消费者通过记录自己在日志中的位置offset来读数据。正是这个日志模型决定了 Kafka 能支撑高吞吐、能回溯消费也决定了它的很多架构选择。1.2 一条消息具体的流转路径我用一个最简单的场景描述有一个order-topic3 个分区Producer 往里面发一条订单消息。第一步Producer 在客户端完成消息的序列化然后根据分区器决定的规则把这条消息放到某个分区对应的批次缓冲里。注意此时消息还在 Producer 进程内并没有发出网络。第二步Producer 端的发送线程把缓冲里的消息批量打包成请求发送给该分区 Leader 所在的 Broker。Broker 收到请求后把消息顺序追加到磁盘上的日志分段文件中然后返回确认。为了可靠性Leader 还会把消息同步给其他副本这一步的细节后面单独讲。第三步Consumer 通过poll()主动从 Broker 拉取数据。它去 Broker 查询自己当前消费到的 offset 之后的消息拿到后处理业务逻辑再定期提交 offset。整个过程看起来不复杂但每一环都有大量精细设计。比如 Producer 为什么攒一批发而不是一条一条发Broker 是怎么做到顺序写盘还足够快的Consumer 提交 offset 不丢消息又是什么机制下面顺着链路往下逐个拆。2. 生产者端的决定性问题消息发到哪个分区又该如何发2.1 分区器决定消息去向Producer 发消息时第一步不是发出去而是决定这条消息进哪个分区。这个决定由分区器完成默认分区器的规则是如果消息指定了分区号直接使用该分区。如果消息没有指定分区但有 key则对 key 的哈希值做 murmur2 哈希然后对分区数取模。如果既没有指定分区也没有 key则使用粘性分区Sticky Partition策略随机选一个分区并持续使用一段时间以提升批次的填充率。我个人在使用中的体会是key 的设计比大多数人想象的重要得多。比如你在做订单消息如果把用户 ID 作为 key那么同一个用户的所有订单消息都会进入同一个分区这样就能保证同一个用户的消息是全局有序的如果你用订单 ID 做 key那同一个用户的订单会被打散到不同分区去重、聚合类业务处理起来会更复杂。所以选 key 之前先问自己哪些消息需要保持相对顺序。2.2 批量发送与内存缓冲的配合逻辑Kafka 的高吞吐很大程度建立在攒一批再发这个设计上。Producer 端和发送相关的核心参数有三个batch.size每个分区批次缓冲的最大字节数默认 16KB。linger.ms批次缓冲最多等多久再发送默认 0。buffer.memoryProducer 端用于缓冲待发送消息的总体内存大小默认 32MB。关键点在这里batch.size并不是说攒够 16KB 才发而是批次里累计的消息大小超过 16KB 就立即发送。linger.ms0也不意味着消息会被立刻一条条发送而是指如果缓冲区一直不够满最多等 0 毫秒就发。实际运行时只要 Producer 持续有消息进来批次很快就能被填满网络利用率非常高。生产环境中如果业务消息普遍很小几百字节我一般会把batch.size适当调大。比如调到 32KB 或 64KB同时把linger.ms设为 5~10 毫秒。对于日请求量几千万的系统这 5 毫秒延迟换来的是更少的网络包、更低的 Broker 负载。前提是你的业务能接受几毫秒的额外延迟如果链路本身要求毫秒级极致响应那保持默认即可。2.3 ACK 机制与可靠性权衡acks参数是 Producer 和 Broker 之间约定什么程度算写入成功的开关有三个取值acks 取值含义风险0发出即认为成功不等 Broker 确认吞吐最高但消息可能直接丢失1Leader 落盘成功即返回确认分区 Leader 异常时可能丢消息all-1所有 ISR 副本都写入成功才返回最可靠但吞吐略降生产环境里金融、订单、支付类数据我会强约束使用acksall配合min.insync.replicas一起使用。min.insync.replicas的意思是如果 ISR 中的在线副本数少于这个值Broker 就直接拒绝写入宁可让业务报错也不要让数据在副本不足的极端情况下看似成功。常见搭配是acksallmin.insync.replicas2这样 Topic 有 3 个副本时即使 1 个 Broker 宕机消息依然能安全写入。有一个坑我在排查线上问题时遇到过只把acks设为 all但 Topic 副本数是 1min.insync.replicas也没设置。这种情况下所有副本都写入成功其实就一个副本真出事时数据照样丢。acksall只有在副本数足够时才有实际意义。2.4 幂等与事务不重复到底靠什么很多人以为enable.idempotencetrue能完全解决不重不丢其实这个机制解决的是Producer 重试导致的重复。幂等原理是Producer 每次初始化会申请一个 PIDProducer ID每条消息带上一个单调递增的 sequence number。Broker 端对同一个 PID 的分区消息做去重如果收到的 sequence number 比已写入的最大值小就丢弃。这样 Producer 因网络超时重试时消息不会在 Broker 端重复落盘。但注意PID 改变之后比如 Producer 重启幂等区间就断了。事务机制transactional.id在这基础上又加了一层跨分区原子性与状态管理让多条消息要么全部对 Consumer 可见要么全部不可见。架构上我建议这样选普通日志采集开幂等够了多表写入、订单状态流转这类需要多分区一致性的场景再上事务。3. Broker 存储层日志分段、偏移量与顺序写盘的真相3.1 分区日志在磁盘上的真实结构每个 Topic 的分区在 Broker 上对应一个目录命名规则是topic-分区号。这个目录里是一个个日志分段文件每个分段由一对文件组成.log存消息数据.index存稀疏偏移量索引。分段文件不是无限增长的。log.segment.bytes默认是 1GB当一个分段写满后Broker 会创建一个新的分段文件并把这个分段设为只读。这样做的好处在与清理——Kafka 的日志删除retention和压缩compaction都以分段为单位处理而不是一行一行删。分段足够小时过期数据的清理成本很低分段太大时清理延迟会很明显。日志文件还有一个重要特性顺序写。机械硬盘的顺序写性能可以跑到百兆每秒以上Kafka 利用的就是这一点。我们经常听说Kafka 快是因为顺序写但这只解释了一半。另一半是Kafka 写入时先在内存中做页缓存Page Cache然后异步刷盘。也就是说消息对 Consumer 可见的速度取决于写入页缓存而不是物理磁盘落盘时间。这是 Kafka 能维持极高吞吐的核心原因之一。3.2 消费者如何定位消息索引文件的作用假设 Consumer 要消费 offset 为 10000 的消息Broker 不可能把整个日志文件遍历一遍去找这条消息。它会先查构建好的偏移量索引文件.index这个索引是稀疏的每隔一定字节数记录一条offset物理位置对应关系。查的时候先找到小于等于目标 offset 最近的索引项再顺着物理位置往下扫描直到找到目标消息。这里的实际性能非常好因为一次查找最多多读几百 KB 数据而且这部分数据大概率已经在页缓存里。所以 Kafka 支持随便跳到任意 offset 消费代价很小。折中一点说之所以用稀疏索引而不是每条消息都做索引是为了在索引文件自身可以放内存和读取时定位快速之间找平衡。索引太稀疏定位要扫描更多数据索引太密集索引文件本身又太大占用页缓存空间。默认每写入约 4KB 数据记一条索引实测是合适的折中点。3.3 页缓存与刷盘策略的取舍Kafka 依赖操作系统页缓存而不是自己做一套缓存这个设计非常聪明。它带来的好处是只要内存足够读写速度都能接近内存。但副作用是如果进程崩溃Broker JVM 挂了页缓存里的数据尚未落盘消息就会丢失。针对这一点Kafka 提供了log.flush.interval.messages和log.flush.interval.ms两个参数但生产环境中一般不建议频繁刷盘。频繁刷盘等于把顺序写退化成随机写吞吐瞬间掉一个量级。实际做法是依赖副本机制兜底——如果一个 Broker 进程崩溃了它没来得及落盘的数据可能丢失但只要数据还在其他副本上消息就不会丢。这也是为什么 Kafka 高性能和数据安全并不矛盾它靠的是副本而不是刷盘保证可靠性。4. 副本与 ISR高可用架构里最容易理解偏的一环4.1 Leader 如何把消息同步给 Follower每个分区有多个副本其中一个被选为 Leader其余是 Follower。所有读写请求都走 LeaderFollower 只负责从 Leader 拉取数据、保持追赶。同步过程和 Consumer 拉取数据几乎一样每个 Follower 会主动向 Leader 发起FetchRequest告诉 Leader我已经消费到哪个 offset 了把后面的数据给我。Leader 收到请求后把对应的消息返回给 Follower。这里没有专门的主推通道也没有复杂的二阶段提交协议就是一个普通的拉取模型。副本同步涉及两个关键概念LEOLog End Offset当前分区日志里最后一条消息的下一个偏移量也就是已经写到哪里了。HWHigh Watermark已经被成功复制到所有 ISR 副本里的最新偏移量。HW 有一个重要作用它决定了哪些消息对 Consumer 可见。消费者只能消费 offset 小于 HW 的消息。这是为了防止 Leader 把单副本的数据直接给人消费结果副本还没同步完Leader 挂了消息跟着丢Consumer 读到的东西在故障后消失。4.2 ISR 机制什么样的副本才有资格参与同步如果所有副本都要确认写入一个失联的副本会把整个集群拖垮。Kafka 的解决办法是引入了 ISRIn-Sync Replicas也就是和 Leader 保持同步的副本集合。副本默认会被纳入 ISR 的条件是在replica.lag.time.max.ms默认 30 秒内Follower 一直在正常拉取数据。只要 Follower 持续跟上 Leader 的进度它就在 ISR 里。一旦某个副本超过 30 秒没有跟上网络故障、Broker 假死、Full GC它就会被踢出 ISR。acksall实际等待的是ISR 里的所有副本都写入成功而不是所有副本都写入成功。这里要明白两个容易混淆的概念ISR 收缩同步慢的副本被移出集合这是保护机制。ISR 扩张副本追上了 Leader 的进度重新被加入集合。在 ISR 缩到只剩 Leader 一个副本时如果min.insync.replicas配置小于当前 ISR 大小写入依然可以继续但此时的可靠性已经降到最低。如果这个 Topic 是重要的业务数据我强烈建议把min.insync.replicas设为 2宁可让写入报错也不能让消息悄无声息地丢。4.3 副本数到底配多少复盘过不少生产事故后我对副本数配置的结论很明确日志、监控类数据副本数 2 就够了甚至 1 也行丢了可以从源头重新采集。业务核心数据副本数 3min.insync.replicas设为 2。不建议超过 5副本数太多Leader 的同步压力会明显增大写放大严重反而拖慢吞吐。另外有个很容易被忽视的坑unclean.leader.election.enable这个参数。它默认是 false但这恰恰是关键。如果 ISR 为空比如所有副本都挂了Kafka 不会从 ISR 之外的副本选 Leader分区保持不可用而不是把可能落后很多的数据副本提上来。这样做的代价是可用性降低但避免了选出一个消息严重缺失的新 Leader导致大量数据丢失的情况。我的原则是核心业务一律保持unclean.leader.election.enablefalse。有些团队为了追求分区永远可用把它打开结果故障恢复后发现一个分区的数据落后了几个小时整个链路的数据都对不上这种事故比短暂不可用可怕得多。4.4 副本同步与生产写入的协同写入时请求到达 LeaderLeader 追加日志后要等 ISR 中的副本完成同步、更新 HW才对 Producer 返回成功。换句话说acksall 时Producer 感受到的延迟本质上是ISR 集合里最慢那个副本的同步延迟。如果某个 Follower 网络抖动同步延迟变大整个分区的写入延迟都会变大。这也是为什么副本数量不是越多越好——每加一个副本都要等一个同步节点。做过压测的读者应该能看到明显对比副本从 1 加到 3TPS 可能有 30% 的下降从 3 加到 5下降会更明显。5. 消费组与 Rebalance消费者侧的协调架构5.1 消费组到底由谁协调Consumer 不是直接连到分区读写数据而是要经过一个组协调者GroupCoordinator。每个 Broker 上都运行着协调者角色负责管理一部分消费组。协调者的职责包括管理消费组的状态初始、准备重平衡、稳定等。管理组成员的心跳。触发并完成分区分配。维护消费组的 offset 元数据。Consumer 启动时会请求 Broker 找到自己所属消费组的协调者然后向协调者注册。协调者和 Broker 的对应关系老版本中由 Zookeeper 协调新版本也同样是先查元数据然后再建立连接。5.2 Rebalance 的完整过程与触发条件所谓 Rebalance直白说就是消费组成员变化时把分区的所有权重新分配一遍。整个过程分三步第一步任何一个消费者加入或离开组都会向协调者发送请求。协调者检测到成员变化后把组状态置为 PreparingRebalance。第二步协调者向组内所有消费者发送通知要求它们重新加入JoinGroup。所有消费者停止消费、提交 offset然后重新提交自己的订阅信息。第三步协调者从组内选择一个消费者作为分配者让它根据订阅信息算出分配方案SyncGroup再把方案广播给所有成员。不难看出整个 Rebalance 是一个全体成员参与、全体暂停消费的过程。这是消费侧架构里最影响稳定性的部分。一个消费组几百个消费者一旦某台机器失联触发 Rebalance可能出现消费暂停几十秒、分区在成员间转移、原本本地缓存的数据全部作废重拉。触发 Rebalance 的常见原因有三个触发条件相关参数默认值消费者心跳超时session.timeout.ms10000ms消费者处理消息超时max.poll.interval.ms300000ms新消费者加入或主动退出无无实际排障中rebalance 频率最高的原因是max.poll.interval.ms。消费者单条消息处理太慢或者批量拉取到太多消息导致一轮处理超过 5 分钟协调者就认为它死了强制把它踢出组触发重平衡。5.3 三种分区分配策略的差异协调者选出一个消费者当分配者后这个消费者按当前组里的分配策略生成方案。常见的有三种RangeAssignor按主题顺序将分区分配给消费者。比如一个主题有 3 个分区、2 个消费者第一个消费者拿 2 个分区第二个拿 1 个。多个主题时每个主题都这样分容易倾斜。RoundRobinAssignor把组内订阅的所有主题分区按环形轮流分配给消费者尽量平均但重平衡时容易变化。StickyAssignor在尽量保持之前分配结果的前提下做平衡rebalance 时不会大量转移分区是目前默认配置。我实际使用中的建议是如果每个消费者订阅的主题相同、数量多Sticky 是首选如果业务上确实需要某个消费者只负责特定分区那就不要依赖自动分配直接手动给消费者指定分区列表。5.4 如何减少 Rebalance 的影响以我多年排障的经验治理 rebalance 主要从三个方向下手调参把session.timeout.ms调大比如 15000msheartbeat.interval.ms保持为session.timeout.ms的三分之一给短时网络抖动留余量。改逻辑Consumer 处理消息和poll()分开把耗时的业务操作放到单独的线程池去做保证主线程能持续 poll避免max.poll.interval.ms超时。升级协议启用增量再平衡协议Cooperative Incremental Rebalance它允许部分配属稳定的消费者不中断消费只在需要调整的消费者间转移分区。Kafka 2.4 之后默认支持开启后重平衡的影响面会小很多。6. Controller 与集群元数据Kafka 的分布式大脑6.1 Controller 是谁干什么活Kafka 集群里有一个逻辑上的主控角色叫 Controller。它实际由某个 Broker 进程承担负责全局元数据管理。Controller 的核心职责有分区 Leader 选举、分区分配与迁移、副本变化处理、集群 Broker 上下线感知、向所有 Broker 广播元数据变更。可以这样说数据读写不经过 Controller但谁当 Leader、哪个分区在哪个 Broker 上、Broker 挂了之后怎么恢复都由 Controller 拍板。如果 Controller 所在的 Broker 宕机其他 Broker 会通过内部的选举机制重新选出一个 Controller。选举过程不用人工干预整个集群会自动恢复。6.2 分区 Leader 的选举逻辑正常情况下的 Leader 选举规则是优先选择 ARAssigned Replicas列表里靠前的、并且存活副本中的第一个作为 Leader。这里有一个配置叫auto.leader.rebalance.enable它保证集群在运行一段时间后会尽量把 Leader 平衡到各个 Broker避免 Leader 都堆在同一个 Broker 上。故障选举和正常选举不同。分区当前 Leader 失联了Controller 会根据自己的元数据从 ISR 里挑一个副本作为新 Leader。如果unclean.leader.election.enablefalse则执行严格的规则ISR 为空时分区不可用等原 Leader 恢复。实践中区分正常与异常选举很重要。正常选举几乎无感知异常选举如果没有打开 unclean 选举就表现为分区 Write/Read 不可用这时候不要急着改配置让分区立刻可用先看看能不能把原 Leader 拉起来或确认 ISR 之外的副本数据是否完整。数据完整性永远排在可用性前面。6.3 新架构Controller 和元数据管理的演进早期版本的 Kafka 重度依赖外部协调组件来管理元数据和 Controller 选举。集群元数据Topic 列表、分区分配、Broker 存活状态都存在这个外部系统里Controller 选举也由它控制。这套机制虽然成熟但多了一套外部依赖运维成本和故障点都变多了。较新的版本逐步引入了自己的内部元数据机制KRaft即 Kafka Raft。这个模式下Kafka 不再依赖外部协调组件而是自己通过 Raft 协议管理元数据。Controller 仍然是核心角色但元数据被记录在专用的内部主题中由 Controller Quorum 共同维护。从架构演进角度看Kafka 是在把协调外部化变成协调内部化。这带来的实际好处是部署组件更少、元数据恢复更快、运维复杂度更低。目前不少新部署已直接采用 KRaft 模式老集群迁移则要评估现有工具链和管理脚本是否兼容。我在带团队做新业务选型时对新集群直接建议使用 KRaft 模式。不是因为新而是因为部署和维护成本低了一个量级也不存在外部协调组件出问题时整个 Kafka 不可用的连锁故障。7. 故障排查实战架构知识怎么用在关键时刻7.1 分区不可用的排查思路线上最常遇到的告警是分区不可用OfflinePartitions。从架构角度看这类故障的根源基本都是 ISR 为空、没有可用的 Leader。排查路径如下查看哪些分区离线登录 Broker 用命令确认分区副本分布情况、确认 ISR 列表。正常状态下 ISR 里应该有多个副本如果 ISR 为空说明所有副本都不健康。找原因分别检查副本所在的 Broker 是否存活、磁盘是否写满、网络是否隔离、Broker 是否处于 Full GC。看监控。如果只是某个 Broker 的副本被踢出 ISR重点查这个 Broker 的 GC 时间、磁盘延迟、CPU 负载。如果是跨机房的网络抖动导致整体 ISR 收缩优先查网络质量。根据原因恢复而不是盲目重启。磁盘满就清理或扩容GC 问题就调 JVM 堆和 GC 策略网络问题就报给网络团队处理后等 ISR 自动恢复。7.2 ISR 频繁收缩的隐蔽原因ISR 收缩是最让运维头疼的问题之一因为它的表现是数据不丢写入延迟偶尔飙高过一会儿又自己恢复。常见原因包括Broker 的页缓存不足Follower 拉取速度跟不上。磁盘 IO 被其他业务挤占比如和其他高 IO 组件部署在一起。副本同步线程数不足默认的num.replica.fetchers是 1多副本时同步能力可能不够。消息体过大单条消息几十 MBFollower 拉取一次要写很久。排查 ISR 收缩时kafka-topics.sh的--describe是最好用的诊断工具。它能看到每个分区的 Leader、ISR、副本分布以及 ISR 里有没有少副本。如果某个 Broker 上的副本频繁不在 ISR 里这个 Broker 大概率有问题。7.3 消费延迟与堆积怎么定位是消费者还是 Broker消费延迟的排查第一步是用kafka-consumer-groups.sh --describe --group 组名看每个分区的当前 offset 与 log-end-offset 的差距。如果所有分区都有延迟且消费组所有成员都在运行那问题在消费者侧性能单条消息处理太慢、处理逻辑里有远程调用或锁竞争、消费者线程数不足。如果只有个别分区有明显延迟问题可能是分区分配不均衡。比如某个消费者被分配了多个消息量大的分区而其他消费者很空闲。这时需要看分配方案和 Sticky 策略是否真的打散了热点。还有一个经常被忽略的原因Consumer 拉取到的消息量太大单次 poll 返回几千条业务处理不过来然后一直循环拉取-处理-拉取max.poll.interval.ms超时被踢出组又触发 rebalance重平衡期间消费停止延迟进一步扩大。形成一个恶性循环。这种情况要调整的不是并发数而是max.poll.records把单次拉取量降到几百条让每次处理都在超时时间以内。7.4 常用工具与参数速查我把排障中用得最多的几个工具和参数整理成表方便大家直接参考工具/参数用途常用命令或配置示例kafka-topics.sh查看分区、副本、ISR 状态--describe --topic order-topickafka-consumer-groups.sh查看消费组状态、位点、延迟--describe --group order-groupkafka-configs.sh修改或查看 Topic 级配置--alter --entity-type topics --entity-name t --add-config min.insync.replicas2num.replica.fetchers控制副本同步线程数Broker 配置建议 2~4min.insync.replicas控制写入可用副本的下限Topic 级或 Broker 级业务核心数据建议 2replica.lag.time.max.ms控制副本被踢出 ISR 的超时默认 30000ms按网络质量调整排障接近尾声的时候还有一个小技巧分享给大家Kafka 的监控指标一般都会暴露UnderReplicatedPartitions和OfflinePartitionsCount。前者是副本同步落后的实时值后者是分区无 Leader的计数。我通常会把这两条指标设为高优先级告警只要它们一抬头就立即开始排查而不是等用户报障。8. 关于架构深入的一点个人体会把 Kafka 架构从头到尾过一遍之后你会发现它没有任何一个环节是为了复杂而复杂。分区模型是为了水平扩展ISR 是为了在性能和可靠之间动态平衡消费组协调是为了让多个消费者安全地分摊数据Controller 是为了让集群具备自治能力。理解这些设计意图远比记住某个参数默认值重要。如果在读这篇文章的你也正在维护 Kafka 集群我建议你下次再遇到问题时不要急着翻参数文档。先问自己三个问题这条链路里哪个环节做了取舍我看到的指标和这个环节有没有直接关系如果我调整参数是在调整哪个取舍的天平想清楚这三个问题大部分故障的原因和解决方案已经清晰了一半。