做 Kafka 生产运维这些年，有一个话题永远绕不开，就是 Kafka 的数据丢失与数据重复。每次出事故，群里最先炸开的永远是两句话：“消息是不是丢了？” “下游怎么收到两遍？” 很多团队第一次用 Kafka 都把它当成一根不会出错的“消息水管”，可上了生产跑一阵就会发现，Kafka 的默认配置里其实藏着大量可靠性陷阱，丢数据可以悄无声息，重复数据也未必会立刻报警。先说我处理过的一个典型案子。某电商系统在月底对账的时候，发现订单明细表和支付流水怎么都对不上。上游生产日志一切正常，数据库也查不到删除记录，最后层层排查，才发现消费端的某个消费者在重平衡之后把位移回退了两分钟，后半段消息重新走了一遍。一部分被幂等逻辑过滤跳过了，另一部分被当新消息重复处理。最终数据“多了一截又少了一截”——表面上只是个数字对不上的小问题，实际上把 Kafka 的数据丢失与数据重复两个问题同时暴露了。所以这篇就来专门拆这两件事：Kafka 到底承诺了怎样的投递语义，哪些配置会埋下丢数据的雷，哪些重复是重试和重平衡带来的锅，线上出了问题怎么定位，以及最后用什么工程手段兜底。适合准备把 Kafka 引上线的团队，也适合正在被“数据对不上”折磨的开发者、运维和架构师。1. 投递语义——先搞清楚 Kafka 承诺了什么1.1 三种投递语义，对应不同忍耐场景接触 Kafka 可靠性，首先绕不开的一个基础概念就是投递语义（Delivery Semantics）。它分为三档：最多一次（At Most Once）、至少一次（At Least Once）、精确一次（Exactly Once）。用快递来打比方：“最多一次”像快递员向你保证包裹一定不重复送，但路上弄丢了他就直接说丢了，你永远收不到；“至少一次”是快递员保证一定送到，但路上即使送了两遍他也会再送一遍；“精确一次”是既不丢也不重，只送一次，但实现起来成本最高。Kafka 默认的行为是“至少一次”。也就是说，在合理配置下，消息不会因为服务器端正常流程而丢，但重复消费是可能发生的。很多开发者第一次听到这话都挺意外，因为大家习惯性地认为消息队列就是“必达而且只有一次”。事实上，Kafka 把“不丢”和“不重”拆成了两个不同的工程问题：不丢靠副本、确认和位移提交；不重要靠幂等生产者、事务，以及应用层的去重。理解了这三档语义，很多配置行为就变得可推演了。比如你设置acks=0，生产端发完就算成功，本质就是你选择了“最多一次”——代价是消息可能在网络途中丢失，换来极低的延迟；设置acks=all并配合副本同步，你得到的就是“至少一次”，它是绝大多数核心业务默认选项。至于精确一次，Kafka 在生产者端是用“幂等 + 事务”实现的，它能保证写到同一个分区里的消息不重复，但消费者下游能不能做到精确一次，从来都不是 Kafka 单方面能承诺的。1.2 可靠性机制门槛：ISR、HW 与位点提交在聊具体丢数据场景之前，先把 Kafka 的几个底层机制说清楚，否则后面很多参数讲起来会很绕。每个 Topic 的分区有多个副本：一个是 Leader，负责承接生产者的所有写入；其余是 Follower，不断从 Leader 拉取数据做同步。能跟上 Leader 进度的 Follower 会进入“同步副本集合”，也就是 ISR（In-Sync Replicas）。当你设置acks=all，并不是要求所有副本都确认，而是要求 ISR 中所有的副本都确认。此时，只要 ISR 里至少有一个健康副本存活，消息就不会因为某个 Broker 宕机而丢。HW（High Watermark）是指已经被足够多副本确认、对消费者可见的消息位置。另一个必须理解的概念是“位点提交”。消费者每消费一批消息，需要把当前消费到的 Offset 提交给 Kafka。Kafka 本身并不清楚你这批数据的业务处理成功了没有，它只按照你提交的位点往下继续。这个“提交时机”就是数据丢失与数据重复的分水岭：早提交，可能导致业务处理失败时数据丢；晚提交，可能导致处理成功后推进位点太慢，重平衡时重复消费。后面所有故障案例，本质上都是“提交时机”和“业务处理结果”没有对齐导致的。2. 数据丢失——大多数事故都踩了这几个配置2.1 生产者配置：acks、retries 和幂等的取舍生产者丢数据，九成以上都出在三个参数上：acks、retries、enable.idempotence。先说acks。它有三个取值，分别对应三种可靠性级别：acks 取值行为丢数据风险0不等待任何确认，发完就当成功非常高，任何网络抖动都会丢1Leader 写入本地日志后返回确认中，Leader 宕机且副本没同步时会丢allISR 全部写入后才返回确认低，但需要结合最小 ISR 配置在记账、订单这类不能丢数据的系统里，我几乎不会用 0 或 1。acks=0适合日志采集、监控上报这类允许丢一丢的轻量场景，前提是整个架构要明确知道“丢数据是预期行为”，不能事后去对账。acks=1看似折中，实际上风险最大——Leader 刚写完本地日志，还没来得及同步给 Follower 就宕机了，旧 Leader 上的数据在新 Leader 身上找不到，消费者一读就是缺的。第二个参数是retries。不少人以为这个参数是万能的，其实它是双刃剑。retries=0时，Broker 正在做 Leader 切换、网络瞬时抖动、请求超时，发送就直接失败，消息丢了。retries设得太大，Produce 请求会不断重试，可能把 Broker 压垮。生产环境我通常配合delivery.timeout.ms一起用：总超时时间设 2 分钟，重试次数用一个大数，这样 Kafka 会在时间内尽力重试，超过总超时才宣布失败。第三个是幂等生产者enable.idempotence=true。它通过给每个生产者分配 producerId 和消息序号，让 Broker 端能识别重复消息并拒绝重复写入。这条配置解决了“重试导致同一消息被写了两次”的问题，但它不是银弹——如果生产者进程重启，producerId 变化，幂等边界就断了；如果一条消息已经由业务下游的另一个系统消费并写入了数据库，生产者端的幂等并不能阻止下游重复消费。还有一个容易忽略的生产者丢数据路径：linger.ms和batch.size。生产者为了提高吞吐，会先把消息攒在内存缓冲区，达到条件才批量发送。如果进程被kill -9或发生 OOM，缓冲区内没来得及发出去的消息直接丢失。所以生产环境里，关闭生产者进程尽量走优雅关闭，让 KafkaProducer 把剩余数据 flush 完。2.2 Broker 配置：副本、ISR 判定与刷盘策略Broker 侧的丢数据，通常不是“消息在磁盘上坏了”，而是配置让副本机制失效了。最典型的就是replication.factor=1。分区只有 Leader 没有 Follower，再牛的 Kafka 也保护不了单点磁盘故障。很多小团队刚开始搭 Kafka 图省事，一个 Broker 一台机器，Topic 副本数默认是 1，等机器磁盘坏了才发现数据全没了。生产环境至少应保证副本数 3，且三副本尽量分散在不同机器上。第二个坑是min.insync.replicas与acks=all的配合。假设 Topic 配置三副本，acks=all，但min.insync.replicas=1，那么只要 Leader 自己活着，就认为消息已同步。此时 Follower 挂掉两个，Kafka 依然能正常写入，但 ISR 已经悄悄缩到 1 了，一旦 Leader 再挂，数据直接丢。正确的做法是：acks=all必须配合min.insync.replicas=2，让系统在副本不足时主动拒绝写入，而不是用“可用性”掩盖“数据正在丢”的风险。第三个坑是unclean.leader.election.enable。当 Leader 挂了，ISR 里的副本全不可用，只剩一个落后很多的副本时，Kafka 是否允许它上位当新 Leader？false表示不允许，分区宁可短暂不可用，也要等 ISR 副本恢复；true表示允许，服务是不断了，但新 Leader 会丢掉那些它没来得及同步的消息。我处理过的一起事故就是某个团队把这个参数设成了true，一次机器宕机后系统确实没停，但数据回退了一个多小时——而且发现得晚，回退影响早就扩散到了下游好几个微服务。在金融、订单这类场景里，我强烈建议保持false，并且把监控指标UnderReplicatedPartitions设为长期盯防项。Broker 刷盘参数也要提一嘴。Kafka 默认依赖 OS 页缓存，日志文件不是每写一条就 fsync，如果宿主机断电或内核崩溃，未落盘数据会丢。多副本 +acks=all其实已经能兜住单机断电风险，所以不需要把刷盘阈值调得过于激进，否则性能会很难看。真要在临界场景下更强一致，通常是结合外部存储做数据校验，而不是死磕单机刷盘。最后还有一类特殊“丢失”，是日志被保留策略清理了。log.retention.hours、log.retention.bytes如果设置得比某个消费者的消费速度更短，消费者还没攒到那批消息，数据就被过期清掉。这种现象在日志数据里很容易被误判为丢消息，其实是被自己配的 TTL 删了。排查时第一件事就应该确认，Topic 的保留窗口和消费者 lag 是否有交集。2.3 消费者配置：位移提交和重平衡的连环坑消费者导致的丢失，往往比生产者和 Broker 更隐蔽。最常见的失误就是直接使用默认的自动提交：enable.auto.commit=true，默认每 5 秒提交一次位移。想象一个场景：你拉了一批 1000 条消息，程序处理到第 800 条时，刚好到了 5 秒的自动提交点，位移提交到了 800。接下来继续处理第 801 条时，进程重启。重启后消费者从 800 继续消费，中间那 200 条已经处理但没提交的消息被重新消费——这其实是重复，不是丢。如果是反过来的顺序：程序处理完 800 条，但还没到 5 秒点，进程就崩了，那么位点停在旧位置，重启后这 800 条会重新走一遍。对于有状态处理的业务来说，如果重新处理时没有幂等保护，下游就会看到“重复”。更隐蔽的是自动提交期间，某批消息拉下来后，poll返回，但业务处理还没完成，自动提交线程已经帮它提交了新位点，这时进程崩溃，这批消息实际上没被正确处理，位点却已经提交了——数据从消费者视角看是“消费过”了，但对下游业务来说就是丢了。所以我的第一建议是：核心业务一律enable.auto.commit=false，改用手动提交。手动提交也有讲究，commitSync()会阻塞到提交成功，可靠但吞吐低；commitAsync()不阻塞，性能好，但失败时不重试就可能会丢位移。稳妥做法是commitAsync()成功则罢，失败则进回调重试或兜底。最忌讳的是提交完位移，业务数据还没落库——那才是真正的逻辑丢失，Kafka 再可靠也救不回来。重平衡也是丢数据的高发场景。消费者组里有新消费者加入、消费者心跳超时、max.poll.interval.ms处理超时，都会触发分区重新分配。旧消费者负责的分区被分配给新消费者时，如果旧消费者还没来得及提交位移，新消费者就会从旧位点重新消费。这里既有重复，也可能因为过滤逻辑等问题造成下游数据处理错乱。前面提到的“对不上账”事故，本质就是重平衡把位移回退了两分钟。3. 数据重复——重复消息到底是怎么来的3.1 生产者重试带来的重复与顺序问题数据重复最容易被误判为“下游代码 bug”，其实源头往往在生产者重试。逻辑是这样：生产者发送一条消息到 Leader，Leader 写入成功，正要返回 ACK 时网络抖动，ACK 没送到生产者。生产者判断发送失败，按retries配置重新发送，Broker 上就被写了两遍。这是“至少一次”语义下的天然结果。开了幂等生产者，enable.idempotence=true以后，Broker 端会通过 producerId 和序列号把同一批重复写入挡掉，这个问题在 Kafka 内部算是缓解了。但要注意几个边界：幂等生产者在生产端重启后会生成新的 producerId；事务型场景中如果事务回滚处理不当，消费者还是可能在旧位点反复读；而且幂等只解决单分区内的重复，如果消息跨分区投递且消费端没有任何去重，依然可能出现逻辑上的重复。除了重复，重试还会带来乱序。如果max.in.flight.requests.per.connection大于 1，而同一个连接上有多个请求在途，后发送的消息可能先被 Broker 处理，旧请求失败后重试，新请求先落盘，消息顺序就会颠倒。开幂等后，Kafka 对分区内消息有排序机制，但如果你显式关掉幂等、又追求高吞吐，乱序风险得自己承受。对订单这类对顺序敏感的业务，我通常建议要么单分区单连接，要么接受乱序后用应用层的序列号去重排序。3.2 消费者重复消费的主要路径消费者端重复，基本都围绕“位移提交”和“重平衡”两个词转。第一种路径：处理成功但提交失败。你手动用commitSync()提交位移，网络超时导致提交返回失败，但 Leader 可能已经提交成功了，只是响应丢了。此时消费者重试提交，逻辑上是重复提交，问题不大；但如果没做幂等就继续处理业务，重复消费就可能发生。第二种路径：处理过程中崩溃。poll 出一批消息，处理到一半进程崩溃，位移还没提交。重启后消费者从上次提交的位点重新消费，已处理过的消息再走一遍。这个场景里，“丢”不会发生，但“重”几乎是必然的。第三种路径：重平衡触发。消费者处理耗时太长，超过max.poll.interval.ms，Kafka 认为它已经死掉，踢出消费者组并触发重平衡。分区重新分配后，新消费者会从被踢消费者最后提交的位移开始消费。如果旧消费者在最后并没有及时提交处理到哪，这中间的整段数据都会重来。这里还有一个小坑，新手很容易混淆：新消费者加入时，auto.offset.reset=earliest或latest不是用来解决重复的，而是决定“没有提交过位移”时从哪里开始。如果一位同学把消费者组名写错，新组没有任何历史位移，默认从末尾开始消费，看起来就是少了一大段历史数据，其实那只是从latest开始读而已。3.3 Kafka 的“精确一次”能解决到什么程度Kafka 官方提供了“精确一次”的完整方案：幂等生产者 + 事务。生产者通过transactional.id开启事务，Broker 端会给生产请求打上事务标记，消费者设置isolation.level=read_committed后，只会读取已提交事务内的消息。跨分区、跨 Topic 的写入也有了原子性边界。但要特别说清楚：这个“精确一次”传达的范围，只覆盖“生产端写入 Kafka 到消费者从 Kafka 读取”这一段。消费者拿到消息后去更新数据库、调外部接口、写缓存，如果能和位点提交放进同一个本地事务里，那么可以达到端到端的精确一次；但如果下游是独立的数据库，且没有使用“业务操作和位移提交”共用一个事务，那 Kafka 的精确一次对下游而言依然只是“至少一次”。所以我在实际项目中很少把希望全部押在 Kafka 事务上，而是按“生产者端尽量不重复、消费者端主动去重”的原则设计。Kafka 事务做兜底，应用层幂等做最后防线。不是 Kafka 做不到，而是很多团队的业务系统根本承接不了事务化读写的性能开销。4. 排查与定位——从“消息不对”到“实锤”4.1 监控指标教你锁定故障面线上出了问题，第一步不是去改代码，而是先通过监控指标确认故障面在生产端还是消费端、抽 Broker 还是抽网络。我最常盯的几个 Kafka JMX 指标：指标含义异常时说明什么UnderReplicatedPartitions分区有多少副本没同步上位长期大于 0，副本同步出问题，存在丢数据风险IsrShrinksPerSec / IsrExpandsPerSecISR 集合收缩/扩张频次频繁抖动说明有节点不稳定，会诱发丢数据ActiveControllerCount集群中活跃 Controller 数量应该在集群里恰好为 1，多个或 0 都说明 Controller 选举办砸了RequestHandlerAvgIdlePercentBroker 请求处理器空闲率低于 30% 说明 Broker 繁忙，生产端请求可能超时BytesInPerSec / BytesOutPerSec主题流入流出速率突然归零，往往伴随生产端故障或消费端故障消费者端最容易看的是消费者组的 lag。用管理工具查一下某消费者的CURRENT-OFFSET和生产端的LOG-END-OFFSET，如果 lag 持续增长，说明消费速度跟不上；如果 lag 突然清零或变成 0，反而要警惕是不是重平衡后位移被重置了。4.2 命令行工具：查看位移、分区和副本Kafka 自带的命令行工具是定位问题的基本功。查看主题分区和副本状态：kafka-topics.sh --bootstrap-server <broker_host> --describe --topic order_topic输出里能看到每个分区的 Leader、Replicas、Isr。如果某个分区 Isr 只有 Leader 自己，说明副本同步已经出状况了，后续任何一台机器挂掉都可能丢数据。查看消费者组位点：kafka-consumer-groups.sh --bootstrap-server <broker_host> --group order_consumer --describe输出的CURRENT-OFFSET、LOG-END-OFFSET、LAG三列，能一眼看出是否消费落后。如果某个分区的CURRENT-OFFSET比业务逻辑预期值小很多，再结合消费日志判断是没消费完还是位点被回退了。怀疑数据被清理时，可以用kafka-configs.sh查看 Topic 的保留策略参数，再用kafka-dump-log.sh检查日志片段。很多看起来“丢数据”的案例，实际只是log.retention.hours设置太短，早就把片段删干净了。4.3 结合时间线反推：丢还是重，一看便知工具看的是静态画面，真正把问题钉死，需要靠时间线反推。具体做法是把生产和消费两侧日志拉出来做对比。生产侧重点看三个时间点：某段时间是否有重试、是否有超时、所在 Broker 是否有 Leader 切换或宕机记录。消费侧重点看三个时间点：位移提交是否连续、是否有重平衡、消费者实例是否有重启或超时。我遇到一次诡异的重复消费，从指标上什么都看不出来，最后发现生产者在某 30 秒内经历了一次网络分区，回滚后重试导致大量重复写入；又因为消费者当时也在重平衡，位移回退，两条原因叠加，下游某张表里的金额对不上了。时间线一核对，两边的时间戳都指向同一个 30 秒窗口，问题就立刻清楚了。实际操作里我还会故意做一次小规模验证：在测试 Topic 上生产一批带业务流水号的消息，用同样的消费者配置跑一遍，对比消费到的流水号和发送时是否一致。如果重复一串、缺失一串，那基本能判断是消费端位移提交逻辑的问题；如果发送侧出现重复，但消费者读到的数据量没变多，基本就是幂等生产者没有生效。5. 工程实践——配置、去重、对账的最优组合5.1 业务场景配置清单：从高可靠到高吞吐不同业务的可靠性诉求不一样，配置组合不要太死板。我按两种典型场景给出参考配置。高可靠场景，比如订单、支付、余额变动。生产者端配置：acks=all min.insync.replicas=2 retries=2147483647 max.in.flight.requests.per.connection=5 enable.idempotence=true delivery.timeout.ms=120000 request.timeout.ms=30000消费者端配置：enable.auto.commit=false auto.offset.reset=earliest max.poll.records=500 max.poll.interval.ms=300000 heartbeat.interval.ms=3000 session.timeout.ms=10000高吞吐场景，比如访问日志、行为埋点。生产者端可以适当放宽：acks=0 retries=0 linger.ms=20 batch.size=32768消费者端也可以提高fetch.min.bytes、fetch.max.wait.ms，让批量拉取更爽快，但这套组合要接受偶尔丢数据、偶尔乱序的事实。更细致的场景选择参考这边：场景可靠性要求推荐配置订单支付不丢不重acks=all、min.insync.replicas=2、幂等生产者、手动提交日志采集可丢部分acks=0、retries=0、批量发送缓存刷新可接受重acks=1、消费者自动提交+业务幂等对账系统高度敏感acks=all、事务生产者、read_committed5.2 消费幂等：唯一键、幂等表、状态校验配置层面做到最佳，还是不能根除下游重复消费。所以工程上的重点是把消费幂等做成默认能力。最稳妥的是“数据库唯一索引 + 业务流水号”。每条消息带一个全局唯一 ID，比如订单号+事件类型+随机数。消费时直接往订单表插入一条记录，撞到唯一索引就说明已经处理过，直接跳过。这个方案简单可靠，但如果消息里没有自带 ID，就要在应用层维护一个 ID 生成器。第二个方案是“幂等表”。消费端在同一个数据库事务里，先往msg_process_record表插入一条消费记录（主键就是消息 ID），再执行业务数据更新。如果消息 ID 重复插入，数据库会报主键冲突，事务回滚，业务更新也不会发生。这种做法把“消息去重”和“业务写入”绑进了同一个事务，能挡住大多数重复消费。第三个方案是“状态校验去重”。适合业务本身有状态机的场景，比如订单状态已经是“已支付”，再收到一条支付成功事件就直接忽略。用状态字段做判断比维护一张幂等表更轻量，但要小心状态更新不是原子操作时出现并发问题。RedisSETNX做幂等也可以，但我不建议作为唯一防线。Redis 缓存总有失效时间，万一业务处理超过缓存 TTL，重复消息就会绕过缓存进库。比较稳妥的组合是 Redis 拦截快路径，数据库唯一索引兜底慢路径。5.3 数据校验、补偿与监控预案光有防御还不够，数据可靠性的最后一道防线是“发现异常并补偿”。我建议按天或按小时做离线对账。比如，每天凌晨统计某个 Topic 的 BytesIn 总量，和业务数据库里的实际记录数做对比；消费端每处理一条业务消息，往对账表写一条流水，第二天拿流水数和 Kafka 消费到的消息数对比，差异超过阈值就报警。这类对账任务一开始可能很粗，但一旦发现问题，能帮你把故障范围快速缩小到某一条链路。还要建立“补发机制”。发现丢数据后，人肉去翻原始业务日志是不现实的。正确的方式是单独建一个补偿 Topic，业务系统在写消息时同时记录一份关键数据到外部存储，或者定期扫描未完成状态的任务列表，把遗漏的消息重新生产到补偿 Topic。补偿消息照样走幂等逻辑，重复了也不会对下游造成二次脏写。监控预案方面，至少要把四类告警做起来：消费者 lag 突增、UnderReplicatedPartitions 大于 0、ActiveControllerCount 不等于 1、生产端请求错误率升高。告警之后要有预案，比如 lag 突增时是扩容消费者还是先暂停消费，Broker 宕机时是先扩容副本还是降级消费，这些最好提前演练过，免得故障来了现场开脑洞。最后分享一点个人感受。我见过太多团队把“Kafka 不丢不重”当成理所当然，出了问题第一反应是怪框架、怪网络。但真正深入排查下来，绝大多数事故都出在配置组合、位移提交时机、以及下游没有幂等这三个层面。Kafka 其实已经给了足够多的机制，问题是我们有没有认真理解它、正确地使用它。生产环境里，配置保守一点、幂等扎实一点、对账勤快一点，比追求任何“最先进方案”都更重要。
做 Kafka 生产运维这些年，有一个话题永远绕不开，就是 Kafka 的数据丢失与数据重复。每次出事故，群里最先炸开的永远是两句话：“消息是不是丢了？” “下游怎么收到两遍？” 很多团队第一次用 Kafka 都把它当成一根不会出错的“消息水管”，可上了生产跑一阵就会发现，Kafka 的默认配置里其实藏着大量可靠性陷阱，丢数据可以悄无声息，重复数据也未必会立刻报警。先说我处理过的一个典型案子。某电商系统在月底对账的时候，发现订单明细表和支付流水怎么都对不上。上游生产日志一切正常，数据库也查不到删除记录，最后层层排查，才发现消费端的某个消费者在重平衡之后把位移回退了两分钟，后半段消息重新走了一遍。一部分被幂等逻辑过滤跳过了，另一部分被当新消息重复处理。最终数据“多了一截又少了一截”——表面上只是个数字对不上的小问题，实际上把 Kafka 的数据丢失与数据重复两个问题同时暴露了。所以这篇就来专门拆这两件事：Kafka 到底承诺了怎样的投递语义，哪些配置会埋下丢数据的雷，哪些重复是重试和重平衡带来的锅，线上出了问题怎么定位，以及最后用什么工程手段兜底。适合准备把 Kafka 引上线的团队，也适合正在被“数据对不上”折磨的开发者、运维和架构师。1. 投递语义——先搞清楚 Kafka 承诺了什么1.1 三种投递语义，对应不同忍耐场景接触 Kafka 可靠性，首先绕不开的一个基础概念就是投递语义（Delivery Semantics）。它分为三档：最多一次（At Most Once）、至少一次（At Least Once）、精确一次（Exactly Once）。用快递来打比方：“最多一次”像快递员向你保证包裹一定不重复送，但路上弄丢了他就直接说丢了，你永远收不到；“至少一次”是快递员保证一定送到，但路上即使送了两遍他也会再送一遍；“精确一次”是既不丢也不重，只送一次，但实现起来成本最高。Kafka 默认的行为是“至少一次”。也就是说，在合理配置下，消息不会因为服务器端正常流程而丢，但重复消费是可能发生的。很多开发者第一次听到这话都挺意外，因为大家习惯性地认为消息队列就是“必达而且只有一次”。事实上，Kafka 把“不丢”和“不重”拆成了两个不同的工程问题：不丢靠副本、确认和位移提交；不重要靠幂等生产者、事务，以及应用层的去重。理解了这三档语义，很多配置行为就变得可推演了。比如你设置acks=0，生产端发完就算成功，本质就是你选择了“最多一次”——代价是消息可能在网络途中丢失，换来极低的延迟；设置acks=all并配合副本同步，你得到的就是“至少一次”，它是绝大多数核心业务默认选项。至于精确一次，Kafka 在生产者端是用“幂等 + 事务”实现的，它能保证写到同一个分区里的消息不重复，但消费者下游能不能做到精确一次，从来都不是 Kafka 单方面能承诺的。1.2 可靠性机制门槛：ISR、HW 与位点提交在聊具体丢数据场景之前，先把 Kafka 的几个底层机制说清楚，否则后面很多参数讲起来会很绕。每个 Topic 的分区有多个副本：一个是 Leader，负责承接生产者的所有写入；其余是 Follower，不断从 Leader 拉取数据做同步。能跟上 Leader 进度的 Follower 会进入“同步副本集合”，也就是 ISR（In-Sync Replicas）。当你设置acks=all，并不是要求所有副本都确认，而是要求 ISR 中所有的副本都确认。此时，只要 ISR 里至少有一个健康副本存活，消息就不会因为某个 Broker 宕机而丢。HW（High Watermark）是指已经被足够多副本确认、对消费者可见的消息位置。另一个必须理解的概念是“位点提交”。消费者每消费一批消息，需要把当前消费到的 Offset 提交给 Kafka。Kafka 本身并不清楚你这批数据的业务处理成功了没有，它只按照你提交的位点往下继续。这个“提交时机”就是数据丢失与数据重复的分水岭：早提交，可能导致业务处理失败时数据丢；晚提交，可能导致处理成功后推进位点太慢，重平衡时重复消费。后面所有故障案例，本质上都是“提交时机”和“业务处理结果”没有对齐导致的。2. 数据丢失——大多数事故都踩了这几个配置2.1 生产者配置：acks、retries 和幂等的取舍生产者丢数据，九成以上都出在三个参数上：acks、retries、enable.idempotence。先说acks。它有三个取值，分别对应三种可靠性级别：acks 取值行为丢数据风险0不等待任何确认，发完就当成功非常高，任何网络抖动都会丢1Leader 写入本地日志后返回确认中，Leader 宕机且副本没同步时会丢allISR 全部写入后才返回确认低，但需要结合最小 ISR 配置在记账、订单这类不能丢数据的系统里，我几乎不会用 0 或 1。acks=0适合日志采集、监控上报这类允许丢一丢的轻量场景，前提是整个架构要明确知道“丢数据是预期行为”，不能事后去对账。acks=1看似折中，实际上风险最大——Leader 刚写完本地日志，还没来得及同步给 Follower 就宕机了，旧 Leader 上的数据在新 Leader 身上找不到，消费者一读就是缺的。第二个参数是retries。不少人以为这个参数是万能的，其实它是双刃剑。retries=0时，Broker 正在做 Leader 切换、网络瞬时抖动、请求超时，发送就直接失败，消息丢了。retries设得太大，Produce 请求会不断重试，可能把 Broker 压垮。生产环境我通常配合delivery.timeout.ms一起用：总超时时间设 2 分钟，重试次数用一个大数，这样 Kafka 会在时间内尽力重试，超过总超时才宣布失败。第三个是幂等生产者enable.idempotence=true。它通过给每个生产者分配 producerId 和消息序号，让 Broker 端能识别重复消息并拒绝重复写入。这条配置解决了“重试导致同一消息被写了两次”的问题，但它不是银弹——如果生产者进程重启，producerId 变化，幂等边界就断了；如果一条消息已经由业务下游的另一个系统消费并写入了数据库，生产者端的幂等并不能阻止下游重复消费。还有一个容易忽略的生产者丢数据路径：linger.ms和batch.size。生产者为了提高吞吐，会先把消息攒在内存缓冲区，达到条件才批量发送。如果进程被kill -9或发生 OOM，缓冲区内没来得及发出去的消息直接丢失。所以生产环境里，关闭生产者进程尽量走优雅关闭，让 KafkaProducer 把剩余数据 flush 完。2.2 Broker 配置：副本、ISR 判定与刷盘策略Broker 侧的丢数据，通常不是“消息在磁盘上坏了”，而是配置让副本机制失效了。最典型的就是replication.factor=1。分区只有 Leader 没有 Follower，再牛的 Kafka 也保护不了单点磁盘故障。很多小团队刚开始搭 Kafka 图省事，一个 Broker 一台机器，Topic 副本数默认是 1，等机器磁盘坏了才发现数据全没了。生产环境至少应保证副本数 3，且三副本尽量分散在不同机器上。第二个坑是min.insync.replicas与acks=all的配合。假设 Topic 配置三副本，acks=all，但min.insync.replicas=1，那么只要 Leader 自己活着，就认为消息已同步。此时 Follower 挂掉两个，Kafka 依然能正常写入，但 ISR 已经悄悄缩到 1 了，一旦 Leader 再挂，数据直接丢。正确的做法是：acks=all必须配合min.insync.replicas=2，让系统在副本不足时主动拒绝写入，而不是用“可用性”掩盖“数据正在丢”的风险。第三个坑是unclean.leader.election.enable。当 Leader 挂了，ISR 里的副本全不可用，只剩一个落后很多的副本时，Kafka 是否允许它上位当新 Leader？false表示不允许，分区宁可短暂不可用，也要等 ISR 副本恢复；true表示允许，服务是不断了，但新 Leader 会丢掉那些它没来得及同步的消息。我处理过的一起事故就是某个团队把这个参数设成了true，一次机器宕机后系统确实没停，但数据回退了一个多小时——而且发现得晚，回退影响早就扩散到了下游好几个微服务。在金融、订单这类场景里，我强烈建议保持false，并且把监控指标UnderReplicatedPartitions设为长期盯防项。Broker 刷盘参数也要提一嘴。Kafka 默认依赖 OS 页缓存，日志文件不是每写一条就 fsync，如果宿主机断电或内核崩溃，未落盘数据会丢。多副本 +acks=all其实已经能兜住单机断电风险，所以不需要把刷盘阈值调得过于激进，否则性能会很难看。真要在临界场景下更强一致，通常是结合外部存储做数据校验，而不是死磕单机刷盘。最后还有一类特殊“丢失”，是日志被保留策略清理了。log.retention.hours、log.retention.bytes如果设置得比某个消费者的消费速度更短，消费者还没攒到那批消息，数据就被过期清掉。这种现象在日志数据里很容易被误判为丢消息，其实是被自己配的 TTL 删了。排查时第一件事就应该确认，Topic 的保留窗口和消费者 lag 是否有交集。2.3 消费者配置：位移提交和重平衡的连环坑消费者导致的丢失，往往比生产者和 Broker 更隐蔽。最常见的失误就是直接使用默认的自动提交：enable.auto.commit=true，默认每 5 秒提交一次位移。想象一个场景：你拉了一批 1000 条消息，程序处理到第 800 条时，刚好到了 5 秒的自动提交点，位移提交到了 800。接下来继续处理第 801 条时，进程重启。重启后消费者从 800 继续消费，中间那 200 条已经处理但没提交的消息被重新消费——这其实是重复，不是丢。如果是反过来的顺序：程序处理完 800 条，但还没到 5 秒点，进程就崩了，那么位点停在旧位置，重启后这 800 条会重新走一遍。对于有状态处理的业务来说，如果重新处理时没有幂等保护，下游就会看到“重复”。更隐蔽的是自动提交期间，某批消息拉下来后，poll返回，但业务处理还没完成，自动提交线程已经帮它提交了新位点，这时进程崩溃，这批消息实际上没被正确处理，位点却已经提交了——数据从消费者视角看是“消费过”了，但对下游业务来说就是丢了。所以我的第一建议是：核心业务一律enable.auto.commit=false，改用手动提交。手动提交也有讲究，commitSync()会阻塞到提交成功，可靠但吞吐低；commitAsync()不阻塞，性能好，但失败时不重试就可能会丢位移。稳妥做法是commitAsync()成功则罢，失败则进回调重试或兜底。最忌讳的是提交完位移，业务数据还没落库——那才是真正的逻辑丢失，Kafka 再可靠也救不回来。重平衡也是丢数据的高发场景。消费者组里有新消费者加入、消费者心跳超时、max.poll.interval.ms处理超时，都会触发分区重新分配。旧消费者负责的分区被分配给新消费者时，如果旧消费者还没来得及提交位移，新消费者就会从旧位点重新消费。这里既有重复，也可能因为过滤逻辑等问题造成下游数据处理错乱。前面提到的“对不上账”事故，本质就是重平衡把位移回退了两分钟。3. 数据重复——重复消息到底是怎么来的3.1 生产者重试带来的重复与顺序问题数据重复最容易被误判为“下游代码 bug”，其实源头往往在生产者重试。逻辑是这样：生产者发送一条消息到 Leader，Leader 写入成功，正要返回 ACK 时网络抖动，ACK 没送到生产者。生产者判断发送失败，按retries配置重新发送，Broker 上就被写了两遍。这是“至少一次”语义下的天然结果。开了幂等生产者，enable.idempotence=true以后，Broker 端会通过 producerId 和序列号把同一批重复写入挡掉，这个问题在 Kafka 内部算是缓解了。但要注意几个边界：幂等生产者在生产端重启后会生成新的 producerId；事务型场景中如果事务回滚处理不当，消费者还是可能在旧位点反复读；而且幂等只解决单分区内的重复，如果消息跨分区投递且消费端没有任何去重，依然可能出现逻辑上的重复。除了重复，重试还会带来乱序。如果max.in.flight.requests.per.connection大于 1，而同一个连接上有多个请求在途，后发送的消息可能先被 Broker 处理，旧请求失败后重试，新请求先落盘，消息顺序就会颠倒。开幂等后，Kafka 对分区内消息有排序机制，但如果你显式关掉幂等、又追求高吞吐，乱序风险得自己承受。对订单这类对顺序敏感的业务，我通常建议要么单分区单连接，要么接受乱序后用应用层的序列号去重排序。3.2 消费者重复消费的主要路径消费者端重复，基本都围绕“位移提交”和“重平衡”两个词转。第一种路径：处理成功但提交失败。你手动用commitSync()提交位移，网络超时导致提交返回失败，但 Leader 可能已经提交成功了，只是响应丢了。此时消费者重试提交，逻辑上是重复提交，问题不大；但如果没做幂等就继续处理业务，重复消费就可能发生。第二种路径：处理过程中崩溃。poll 出一批消息，处理到一半进程崩溃，位移还没提交。重启后消费者从上次提交的位点重新消费，已处理过的消息再走一遍。这个场景里，“丢”不会发生，但“重”几乎是必然的。第三种路径：重平衡触发。消费者处理耗时太长，超过max.poll.interval.ms，Kafka 认为它已经死掉，踢出消费者组并触发重平衡。分区重新分配后，新消费者会从被踢消费者最后提交的位移开始消费。如果旧消费者在最后并没有及时提交处理到哪，这中间的整段数据都会重来。这里还有一个小坑，新手很容易混淆：新消费者加入时，auto.offset.reset=earliest或latest不是用来解决重复的，而是决定“没有提交过位移”时从哪里开始。如果一位同学把消费者组名写错，新组没有任何历史位移，默认从末尾开始消费，看起来就是少了一大段历史数据，其实那只是从latest开始读而已。3.3 Kafka 的“精确一次”能解决到什么程度Kafka 官方提供了“精确一次”的完整方案：幂等生产者 + 事务。生产者通过transactional.id开启事务，Broker 端会给生产请求打上事务标记，消费者设置isolation.level=read_committed后，只会读取已提交事务内的消息。跨分区、跨 Topic 的写入也有了原子性边界。但要特别说清楚：这个“精确一次”传达的范围，只覆盖“生产端写入 Kafka 到消费者从 Kafka 读取”这一段。消费者拿到消息后去更新数据库、调外部接口、写缓存，如果能和位点提交放进同一个本地事务里，那么可以达到端到端的精确一次；但如果下游是独立的数据库，且没有使用“业务操作和位移提交”共用一个事务，那 Kafka 的精确一次对下游而言依然只是“至少一次”。所以我在实际项目中很少把希望全部押在 Kafka 事务上，而是按“生产者端尽量不重复、消费者端主动去重”的原则设计。Kafka 事务做兜底，应用层幂等做最后防线。不是 Kafka 做不到，而是很多团队的业务系统根本承接不了事务化读写的性能开销。4. 排查与定位——从“消息不对”到“实锤”4.1 监控指标教你锁定故障面线上出了问题，第一步不是去改代码，而是先通过监控指标确认故障面在生产端还是消费端、抽 Broker 还是抽网络。我最常盯的几个 Kafka JMX 指标：指标含义异常时说明什么UnderReplicatedPartitions分区有多少副本没同步上位长期大于 0，副本同步出问题，存在丢数据风险IsrShrinksPerSec / IsrExpandsPerSecISR 集合收缩/扩张频次频繁抖动说明有节点不稳定，会诱发丢数据ActiveControllerCount集群中活跃 Controller 数量应该在集群里恰好为 1，多个或 0 都说明 Controller 选举办砸了RequestHandlerAvgIdlePercentBroker 请求处理器空闲率低于 30% 说明 Broker 繁忙，生产端请求可能超时BytesInPerSec / BytesOutPerSec主题流入流出速率突然归零，往往伴随生产端故障或消费端故障消费者端最容易看的是消费者组的 lag。用管理工具查一下某消费者的CURRENT-OFFSET和生产端的LOG-END-OFFSET，如果 lag 持续增长，说明消费速度跟不上；如果 lag 突然清零或变成 0，反而要警惕是不是重平衡后位移被重置了。4.2 命令行工具：查看位移、分区和副本Kafka 自带的命令行工具是定位问题的基本功。查看主题分区和副本状态：kafka-topics.sh --bootstrap-server <broker_host> --describe --topic order_topic输出里能看到每个分区的 Leader、Replicas、Isr。如果某个分区 Isr 只有 Leader 自己，说明副本同步已经出状况了，后续任何一台机器挂掉都可能丢数据。查看消费者组位点：kafka-consumer-groups.sh --bootstrap-server <broker_host> --group order_consumer --describe输出的CURRENT-OFFSET、LOG-END-OFFSET、LAG三列，能一眼看出是否消费落后。如果某个分区的CURRENT-OFFSET比业务逻辑预期值小很多，再结合消费日志判断是没消费完还是位点被回退了。怀疑数据被清理时，可以用kafka-configs.sh查看 Topic 的保留策略参数，再用kafka-dump-log.sh检查日志片段。很多看起来“丢数据”的案例，实际只是log.retention.hours设置太短，早就把片段删干净了。4.3 结合时间线反推：丢还是重，一看便知工具看的是静态画面，真正把问题钉死，需要靠时间线反推。具体做法是把生产和消费两侧日志拉出来做对比。生产侧重点看三个时间点：某段时间是否有重试、是否有超时、所在 Broker 是否有 Leader 切换或宕机记录。消费侧重点看三个时间点：位移提交是否连续、是否有重平衡、消费者实例是否有重启或超时。我遇到一次诡异的重复消费，从指标上什么都看不出来，最后发现生产者在某 30 秒内经历了一次网络分区，回滚后重试导致大量重复写入；又因为消费者当时也在重平衡，位移回退，两条原因叠加，下游某张表里的金额对不上了。时间线一核对，两边的时间戳都指向同一个 30 秒窗口，问题就立刻清楚了。实际操作里我还会故意做一次小规模验证：在测试 Topic 上生产一批带业务流水号的消息，用同样的消费者配置跑一遍，对比消费到的流水号和发送时是否一致。如果重复一串、缺失一串，那基本能判断是消费端位移提交逻辑的问题；如果发送侧出现重复，但消费者读到的数据量没变多，基本就是幂等生产者没有生效。5. 工程实践——配置、去重、对账的最优组合5.1 业务场景配置清单：从高可靠到高吞吐不同业务的可靠性诉求不一样，配置组合不要太死板。我按两种典型场景给出参考配置。高可靠场景，比如订单、支付、余额变动。生产者端配置：acks=all min.insync.replicas=2 retries=2147483647 max.in.flight.requests.per.connection=5 enable.idempotence=true delivery.timeout.ms=120000 request.timeout.ms=30000消费者端配置：enable.auto.commit=false auto.offset.reset=earliest max.poll.records=500 max.poll.interval.ms=300000 heartbeat.interval.ms=3000 session.timeout.ms=10000高吞吐场景，比如访问日志、行为埋点。生产者端可以适当放宽：acks=0 retries=0 linger.ms=20 batch.size=32768消费者端也可以提高fetch.min.bytes、fetch.max.wait.ms，让批量拉取更爽快，但这套组合要接受偶尔丢数据、偶尔乱序的事实。更细致的场景选择参考这边：场景可靠性要求推荐配置订单支付不丢不重acks=all、min.insync.replicas=2、幂等生产者、手动提交日志采集可丢部分acks=0、retries=0、批量发送缓存刷新可接受重acks=1、消费者自动提交+业务幂等对账系统高度敏感acks=all、事务生产者、read_committed5.2 消费幂等：唯一键、幂等表、状态校验配置层面做到最佳，还是不能根除下游重复消费。所以工程上的重点是把消费幂等做成默认能力。最稳妥的是“数据库唯一索引 + 业务流水号”。每条消息带一个全局唯一 ID，比如订单号+事件类型+随机数。消费时直接往订单表插入一条记录，撞到唯一索引就说明已经处理过，直接跳过。这个方案简单可靠，但如果消息里没有自带 ID，就要在应用层维护一个 ID 生成器。第二个方案是“幂等表”。消费端在同一个数据库事务里，先往msg_process_record表插入一条消费记录（主键就是消息 ID），再执行业务数据更新。如果消息 ID 重复插入，数据库会报主键冲突，事务回滚，业务更新也不会发生。这种做法把“消息去重”和“业务写入”绑进了同一个事务，能挡住大多数重复消费。第三个方案是“状态校验去重”。适合业务本身有状态机的场景，比如订单状态已经是“已支付”，再收到一条支付成功事件就直接忽略。用状态字段做判断比维护一张幂等表更轻量，但要小心状态更新不是原子操作时出现并发问题。RedisSETNX做幂等也可以，但我不建议作为唯一防线。Redis 缓存总有失效时间，万一业务处理超过缓存 TTL，重复消息就会绕过缓存进库。比较稳妥的组合是 Redis 拦截快路径，数据库唯一索引兜底慢路径。5.3 数据校验、补偿与监控预案光有防御还不够，数据可靠性的最后一道防线是“发现异常并补偿”。我建议按天或按小时做离线对账。比如，每天凌晨统计某个 Topic 的 BytesIn 总量，和业务数据库里的实际记录数做对比；消费端每处理一条业务消息，往对账表写一条流水，第二天拿流水数和 Kafka 消费到的消息数对比，差异超过阈值就报警。这类对账任务一开始可能很粗，但一旦发现问题，能帮你把故障范围快速缩小到某一条链路。还要建立“补发机制”。发现丢数据后，人肉去翻原始业务日志是不现实的。正确的方式是单独建一个补偿 Topic，业务系统在写消息时同时记录一份关键数据到外部存储，或者定期扫描未完成状态的任务列表，把遗漏的消息重新生产到补偿 Topic。补偿消息照样走幂等逻辑，重复了也不会对下游造成二次脏写。监控预案方面，至少要把四类告警做起来：消费者 lag 突增、UnderReplicatedPartitions 大于 0、ActiveControllerCount 不等于 1、生产端请求错误率升高。告警之后要有预案，比如 lag 突增时是扩容消费者还是先暂停消费，Broker 宕机时是先扩容副本还是降级消费，这些最好提前演练过，免得故障来了现场开脑洞。最后分享一点个人感受。我见过太多团队把“Kafka 不丢不重”当成理所当然，出了问题第一反应是怪框架、怪网络。但真正深入排查下来，绝大多数事故都出在配置组合、位移提交时机、以及下游没有幂等这三个层面。Kafka 其实已经给了足够多的机制，问题是我们有没有认真理解它、正确地使用它。生产环境里，配置保守一点、幂等扎实一点、对账勤快一点，比追求任何“最先进方案”都更重要。