很多刚接触Kafka的朋友第一次听到HWHigh Watermark高水位和LEOLog End Offset日志末端偏移时多少会有点懵。这俩指标是副本同步机制的核心直接决定了消费者到底能读到哪些消息、节点故障后哪些数据还保得住。可以说搞不懂HW和LEO就不算真正理解Kafka的副本机制。这篇文章就从底层原理讲起把副本同步的完整链路、指标更新的细节、以及实际运维中的排查方法都过一遍适合刚入门Kafka的开发者也适合正在维护生产集群的运维同学参考。1. 先把概念盘明白HW、LEO、ISR到底是什么1.1 LEO日志末端偏移数据落盘的真实进度LEO全称Log End Offset指的是某个分区副本上日志最后一条消息的下一条偏移量。注意这里是“下一条”不是“最后一条”。比如某个副本的日志里已经写到偏移量5那么它的LEO就是6。这个值像一个计数器告诉我这个副本目前积攒到多少数据了。每个副本都维护自己的LEOLeader副本有Follower副本也有。LEO的意义在于它代表了副本本地数据的真实写入进度。生产者把消息发给Leader后Leader会先追加到自己的日志里然后Follower通过拉取请求从Leader那里拿到数据追加到各自的日志中。每个Follower的LEO就是它自己的进度可能比Leader慢也可能追上了。有一个很容易忽略的细节LEO是在消息真正写入磁盘或者说写入页缓存之后才递增的。Kafka用顺序写盘和页缓存来提升性能但LEO的推进一定是跟着实际落盘走的。所以如果你看到某个副本的LEO长期不动那大多不是拉取卡住就是写盘出了问题。1.2 HW高水位线消费者可见性的边界HWHigh Watermark是另一个偏移量它标记了一个分区中“可以被消费者读取”的消息边界。消费者只能消费位移小于HW的消息等于或者大于HW的消息即使已经存在消费者也暂时看不到。HW为什么会有这样的限制因为它代表的是“已经被足够多副本确认”的位置。所谓“足够多”通常是指ISRIn-Sync Replicas同步副本集合中全部副本都已经把这条消息落盘了。只有消息被ISR里的所有副本都确认写入它才算是真正安全了这时候才能放心让消费者读到。HW本身也是由Leader计算的。Leader会关注所有ISR副本的LEO取其中最小的LEO作为HW然后把这个HW同步给Follower和消费者。整个机制可以理解为一道闸门闸门之下的数据大家都能读闸门之上属于“正在复制但未被集体确认”的部分暂时不对外开放。1.3 ISR同步副本集合与副本状态的转换ISRIn-Sync Replicas是Kafka副本机制里的另一个关键概念。它并不是固定的而是动态变化的。一个副本能够待在ISR里前提是它能跟上Leader的写入节奏。Kafka怎么判断“跟得上”主要看两条一是副本没有长时间落后于Leader二是副本没有长时间停止向Leader发送拉取请求即没有失联。具体参数包括replica.lag.time.max.ms默认是30秒。只要在30秒内副本与Leader的差距没有超过阈值或者还在持续拉数据它就能留在ISR里。ISR的重要性在于HW的推进只考虑ISR内的副本。非同步副本比如已经落后很多或者掉线的节点不参与HW计算。这样设计的目的很明确宁可让HW不往前推也不能让一个已经落后的副本拉着整个分区的数据可靠性下水。当Follower重新追上来后Leader会把它重新加回ISR。这个状态转换过程是自动的不需要重启任何服务但对我们理解副本指标的意义非常关键。2. 副本同步的完整链路与关键流转2.1 从生产者写入到Leader落盘要理解HW和LEO是怎么变动的最好顺着消息的完整路径走一遍。这里以acksall这种最保守的配置来推演因为它涉及最完整的同步流程。生产者发送消息到某个分区时会先定位到这个分区的Leader副本。Leader收到消息后立即把消息追加到本地日志这时候Leader自己的LEO就递增了。但注意此时HW还没有推进。因为HW要等ISR里所有副本都确认写入之后才能更新。假设分区有3个副本Leader在Broker AFollower在Broker B和Broker C。Leader追加完消息后它的LEO从10变成11但HW还是10。然后B和C各自发起拉取请求把这条消息拉走并写入自己的日志B的LEO和C的LEO都变成11。Leader发现ISR里所有副本的LEO都大于等于11于是把HW推进到11并且这个新HW会随下一次拉取响应一起下发给Follower。消费者在HW推进之后才能读到这条消息。从这个流程可以看出消息的“可见”不是即时的而是延迟于写入的。延迟取决于最快的那个Follower的拉取速度而不是最慢的那个因为只要ISR里有一个Follower还没写入HW就无法推进。2.2 Follower拉取、写入与LEO/HW更新很多资料在讲Follower同步时只说“Follower从Leader拉数据”但没讲Follower拿到数据后除了写日志还做了什么。实际上Follower在每次拉取响应里会拿到两个关键信息从哪个偏移量开始拉取的数据以及当前Leader的HW。Follower的处理顺序是先把拉到的消息写入本地日志更新自己的LEO然后根据Leader下发的HW更新自己本地记录的HW。这里有个容易混淆的点Follower也有HW但它自己平时不计算HWHW是从Leader那里同步过来的。所以在Follower侧LEO是本地真实写入进度HW是“最近一次从Leader那边获知的安全水位”。如果Follower长时间没拉取它的HW会落后一旦恢复正常拉取Leader会把最新HW带过来Follower的HW会跳变追上。我见过不少刚接触Kafka的同事在查看Follower节点指标时发现LEO和HW不一致就以为出问题了。其实只要LEO大于等于HW而且两者都在增长就属于正常状态。真正的异常是HW原地不动或者LEO卡住不涨。2.3 HW的两种更新场景Leader侧与Follower侧HW的更新分成两个场景处理逻辑不一样。Leader侧更新HW是在两种情况下触发的。第一种是Follower拉取消息时Leader会在处理拉取请求的过程中检查ISR中所有副本的LEO取最小值来更新HW。第二种是Leader自己追加了消息后也会检查一次因为此时Leader自己作为副本它的LEO变化会影响最小值。Follower侧更新HW则是在它处理完拉取响应之后把响应里携带的Leader HW更新到本地。这里有一个特别需要注意的历史版本坑在旧版本里HW推进存在“时间窗口”可能导致消费者读到之后又被回滚的消息也就是“消费丢数据”的假象。新版本引入了Leader Epoch机制来解决HW更新顺序带来的数据不一致问题但概念上理解HW依然很重要。用公式表达Leader侧HW更新的核心逻辑就是HW min(所有ISR副本的LEO)注意这个公式的前提是至少有一个ISR副本存在。如果ISR为空那事情严重了HW无法推进消费者读不到新数据。3. 为什么HW与LEO如此重要可见性与数据安全3.1 消费者可见性的“水位线”效应理解了HW的更新逻辑就能明白为什么消费者只能读到HW以下的数据。我在实际排查消费者“明明写入成功但读不到”的问题时十有八九都是HW没跟上。举例来说某分区当前HW是100生产者继续写入了10条消息Leader的LEO变成110。如果Follower同步速度稍慢ISR里某个副本的LEO还停在103那么HW只能推进到103。此时消费者最多读到102那7条已经被Leader确认的消息暂时不可见。这不算故障只要Follower追上HW就会继续推进。但如果这个Follower一直追不上甚至被踢出ISR情况就不一样了。ISR里只剩Leader和其他少数副本时HW会基于新的ISR重新计算可能一下子往前跳一大截消费者会突然看到一批消息涌出来这也就是“消费延迟突然下降”的一个原因。3.2 故障切换时怎么保证不丢消息HW和LEO最核心的价值体现在Leader切换的过程中。假设某个分区的Leader所在机器突然宕机Kafka会从ISR里选出一个新的Leader。新的Leader接管后它把自己本地日志的LEO作为数据恢复的基础。为什么这里强调“ISR里选”因为ISR中的副本数据是和旧Leader保持一致的它们没丢消息选它们当新Leader不会丢数据。那HW在这里起什么作用新Leader启动时会处理一些日志截断逻辑确保所有副本都对齐到统一的安全位置避免有的副本日志比新Leader长导致消费者读到“不存在的消息”或者数据分叉。有一个需要警惕的场景如果unclean.leader.election.enabletrueKafka允许在ISR为空时从非同步副本里选Leader。这种情况下那个副本的LEO可能落后了几千条消息一旦它成为Leader这些消息就相当于丢了。所以我一直建议除非你明确知道自己在做什么否则生产环境里把这个配置保持默认的false。3.3 同步复制与异步复制acks参数如何影响HW推进生产者配置里的acks参数直接决定了消息写入多少个副本后才算成功进而影响HW的推进速度。acks0生产者发了就不管不等待确认。HW和LEO该走就走但消费者可能读到半截消息。acks1只要Leader写入就返回成功。此时Leader的LEO已经推进但HW可能还没更新因为Follower还没跟上。如果Leader宕机ISR里新的Leader可能没有这条消息。acksall要求所有ISR副本都写入后才返回。这等价于HW推进到“至少覆盖这条消息”后才能给生产者回包。这个配置能最大限度保证不丢消息但写延迟会提高特别是跨机房的集群。我在实际生产里对核心交易类Topic一律用acksall加上min.insync.replicas2兜底。min.insync.replicas的意思是当ISR里副本数量少于2时Leader不再接受写入。这样即使某个副本挂掉另一个副本和Leader还能保证数据安全不会傻乎乎地单副本写下去。4. 实操用工具和命令观察HW与LEO4.1 kafka-topics.sh 查看ISR与分区状态拿到一个集群怎么快速看副本同步是否健康最直接的就是用kafka-topics.sh查看分区详情。bin/kafka-topics.sh --describe --bootstrap-server localhost:9092 --topic test-topic输出里每个分区分成一行重点关注这几个字段Leader当前Leader所在Broker IDReplicas该分区所有副本所在的Broker列表Isr当前ISR中的Broker列表正常情况下Replicas里面的Broker应该都出现在Isr里。如果Isr比Replicas少说明有副本掉队或失联了。这时候再叠加观察对应Broker的负载、网络、磁盘基本能定位问题。注意这个命令的Isr是Broker ID的集合它不直接给出LEO和HW的数值。想看具体偏移量需要换工具。4.2 kafka-run-class.sh 查看HW与LEO详情Kafka提供了一个底层工具可以查看分区每个副本的偏移量详情比--describe更细。bin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list localhost:9092 --topic test-topic --time -1--time -1表示获取每个分区最新的偏移量也就是LEO。这里列出的LEO是每个副本的Leader视角准确说是每个分区对应Broker上看到的LEO。如果想看Follower的LEO和HW差异更清晰的办法是直接用Kafka自带的浏览器工具或者JMX指标。还有一条命令可以看HWbin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list localhost:9092 --topic test-topic --time -2--time -2返回每个分区当前可消费的最早偏移量不是HW。所以生产环境里我更推荐用kafka-consumer-groups.sh结合消费组看延迟或者直接通过JMX拿HW指标这样更直观。4.3 监控指标Kafka JMX中的相关指标Kafka内置了丰富的JMX指标线上监控系统比如某开源监控面板配Prometheus通常就是采集这些指标来绘制副本同步状态图。值得盯的主要指标有这么几个kafka.server:nameUnderReplicatedPartitions,typeReplicaManager分区副本数小于Replicas配置值的分区数量。大于0就要注意。kafka.server:nameIsrShrinksPerSec,typeReplicaManagerISR收缩速率。如果这个值持续波动说明副本进出ISR很频繁。kafka.log:typeLogFlushStats和分区级别的LEO/HW指标具体到每个分区的LogEndOffset和HighWatermark可以直接算出“LEO - HW”这个差值代表还有多少消息没被所有ISR副本确认。我习惯把“LEO减HW”的差值做成曲线正常情况它是锯齿状波动的Follower同步一批差值涨一点HW推进后回落到0。如果它持续上涨而不回落那基本可以断定有副本同步卡住。5. 排查实录副本同步常见问题与处理思路5.1 副本长期处于非同步状态最常见的告警之一就是“分区处于非同步副本状态”。我遇到过一次模拟场景某个Broker所在机器磁盘IO被打满Follower处理拉取请求的速度跟不上持续超过30秒后被踢出ISR。此时Isr字段里少了这个Broker。排查顺序是这样先看这个Broker的系统负载磁盘IO、CPU、网络是不是有瓶颈再看它有没有频繁的GC停顿然后看它和Leader之间的网络是否通、延迟是否过高。很多情况下把负载降下来副本自动会追回来并重新加入ISR。如果长期追不上可以临时调整两个参数replica.lag.time.max.ms调大给副本更长的追赶时间或者num.replica.fetchers调大增加拉取线程数。但这些都是缓解治本还得看Broker本身的资源是否够用。5.2 HW不推进或原地踏步HW不推进会表现为生产者写入正常Leader LEO在涨但消费者读不到新数据或者所有ISR副本的LEO都涨了但HW不动。这种情况通常有两个原因。第一某个ISR副本虽然还在ISR里但它的拉取已经卡住比如网络断连但没超时这时候ISR里这个副本的LEO停留在旧位置HW就被它卡住。第二min.insync.replicas配置大于ISR实际数量分区处于不可写状态HW自然不推进。有一次我排查一个“看起来正常但读不到新消息”的Topic最后发现是某个ISR副本所在节点时钟漂移严重导致拉取请求总是超时但它又没被踢出ISR。修复时钟后HW立即开始推进。5.3 消费者延迟飙升但服务正常消费者延迟大不一定就是消费者处理慢也可能是HW推进慢导致消费组拉不到可用数据。这种情况在监控上表现为消费组Lag在涨但消费者CPU很低。这时候不要急着加消费者实例先看Topic的HW曲线。如果HW本身就在低位徘徊那就是副本同步的问题如果HW正常推进才需要分析消费者逻辑。这里补一个实用技巧用kafka-consumer-groups.sh --describe --group 消费组名可以同时看到每个分区的LagLag定义为当前消费偏移量与分区LEO的差值但部分版本的Lag计算用的是HW实际含义要看版本。遇到具体数字对不上时先用工具确认LEO和HW再反推。5.4 常见问题速查表现象可能原因排查命令/思路解决方向ISR少于Replicas副本掉队、断连、GC暂停--describe查看Isr字段检查BrokerCPU/IO/网络必要时调大replica.lag.time.max.msHW不涨但LEO涨ISR内某副本拉取卡住JMX看各副本LEO定位卡住副本检查其磁盘/网络/时钟生产者报“NotEnoughReplicas”min.insync.replicas大于ISR数量查看ISR数量和配置恢复同步副本或调低min.insync.replicas但需评估数据安全消费Lag持续上涨且HW不涨HW推进阻塞消费者等不到数据对比HW与LEO曲线优先修复副本同步问题不要盲目扩容消费者单个分区有时能读有时读不到unclean选举导致数据被截断查看集群配置unclean.leader.election.enable确认配置为false并通过Leader Epoch日志分析5.5 独家避坑技巧看指标别只看单点我在维护多个集群时踩过不少坑有几个经验值得专门提一下。第一HW和LEO本质上都是动态值看它们不能只看某一秒的快照一定要连续观察一段时间。有些问题只在特定流量高峰出现峰值一过指标就恢复正常单点截图很难发现问题。第二不要只看Leader的HW。很多监控面板默认展示的是Leader侧的HW和LEOFollower侧的异常往往会被掩盖。有条件的话为每个Broker单独配置分区级指标采集尤其是跨机房的集群Follower的拉取延迟经常和Leader侧表现完全不同。第三升级Kafka版本或调整参数后一定要重新观察HW的推进行为。旧版本的HW更新逻辑在极端场景下会有“数据可见后再回滚”的窗口新版本虽然修复了但如果版本跨度大中间可能还有行为差异。我自己的习惯是在变更后连续看一个完整流量周期的HW曲线确认没有异常跳变和回退。写在最后如果要让我用一句话总结HW和LEO在Kafka里的分量我觉得它们是理解副本机制的两根柱子LEO告诉你有多少数据“已经写下来了”HW告诉你这些数据“够不够安全、能不能对外可见”。平时调优、排障、评估数据可靠性说到底都是在跟这两个值打交道。上面这些思路是我在维护集群时一点点积累下来的里面提到的排查方法也都经过实际验证希望能帮你少走弯路。如果你在生产环境里遇到副本同步相关的奇怪现象记住先看ISR再看HW和LEO的曲线差值大部分问题都不会藏得太深。