Kafka read_uncommitted 与 read_committed 混跑：一次 offset 错位导致的 40 分钟数据丢失复盘

作者江望舒-235

Kafkaexactly-onceread_committedoffset消息中间件分布式一致性

一、现象与背景：消费端没报错，但下游对不上账

先给结论：在同一个 topic 上，read_uncommitted 和 read_committed 两个消费组"看到的 offset 根本不是同一把尺子"，一旦你在两者之间做迁移、重放或 offset 对齐，就会踩到 offset 错位——而 Kafka 不会给你任何显式报错。

事故背景：

Kafka 3.5，3 节点 KRaft，order-state topic 16 分区，峰值约 4.8 万 msg/s；
上游有 2 个生产者应用，都开了 enable.idempotence=true 且部分请求走了 transactional.id（为了跨 topic 原子写）；
老消费组 A：isolation.level=read_uncommitted，8 实例，跑了两年；
新消费组 B：isolation.level=read_committed，2 实例，上周刚上线做灰度核对。

周五晚上 23:40 开始，核对服务报「B 组比 A 组少 11,342 条」。值班同学第一反应是 B 组消费慢，kafka-consumer-groups --describe 看 lag，发现 B 组的 lag 只有 200 多条，A 组反而是 0——于是怀疑 B 组"吞消息"。实际排查到 00:20，根因才定位：A 组在 23:12 读到了一批「已写入 log、但所属生产者事务还没 commit」的消息（offset 108,441–108,553 区间），B 组在同样的时间点读到的是 LSO=108,440 之前。同一条逻辑消息，在两组里的 offset 语义不同，两边各自都"消费成功"，但账对不上。

影响：下游对账窗口 40 分钟无法闭合，人工补数 11,342 条，耗时约 35 分钟。

二、原理：LEO、LSO 与「事务未决」区间

Kafka 每个分区维护两个 offset：

LEO（Log End Offset）：log 末尾下一条消息的 offset，read_uncommitted 消费者最多读到 LEO-1；
LSO（Last Stable Offset）：所有已 commit 或已 abort 的最后一个 offset，read_committed 消费者最多读到 LSO-1。

关键机制是 abort txn marker：当一个带 transactional.id 的生产者崩溃、其事务没 commit，事务协调器（__transaction_state 里记录的 coordinator epoch）会在过期后（transaction.timeout.ms，默认 60s）把该事务标记为 aborted，并在 log 末尾追加一条 ABORT 标记。这条标记本身占一个 offset——它不是普通消息，但它会推进 LSO。

这意味着三件事：

LSO 的推进依赖协调器活性。coordinator 抖动 / leader 切换期间，LSO 可能长时间不前进，read_committed 消费端就会"卡住"，而 read_uncommitted 端完全无感。这是两组 offset 出现分叉的最大来源。
abort marker 会"占坑"：假设事务 T 写了 offset 100–105，之后被 abort，则 log 里会有 100..105 + ABORT@106，LSO=106。read_uncommitted 端在 abort 前读到的是 100–105（脏读），abort 后读到 106 也只是"跳过"——它不会主动回滚已经投递给业务的消息。这是"混跑"最危险的一点：A 组可能已经把 100–105 落库了，B 组永远看不到。
offset 不可跨 isolation 对齐：--from-beginning / --reset-offsets 都是基于 LEO 的 offset 空间，你无法"把 B 组的 offset 对齐到 A 组"，因为两边指向的物理位置不同。

三、具体做法：如何安全地切换 / 共存

1. 切换前先「冻结事务窗口」

如果计划从 read_uncommitted 切到 read_committed，先让上游生产者关闭事务写（或把 transaction.timeout.ms 从默认 60s 调小到 5s），观察 kafka-metadata-shell 里 __transaction_state 的 pending 事务数降到 0 后再切：

# 查看当前 pending 事务
kafka-metadata-shell --bootstrap-server prod-kafka:9092
> get --entity-type transaction --entity-name order-state-0
# 关注 coordinatorEpoch 与 lastProducerEpoch 是否稳定

2. 灰度期两组并行，用「业务主键对账」而非「offset 对账」

-- 核对 A 组落库 vs B 组落库，按业务主键（order_id + event_type）
SELECT a.order_id, a.event_type, a.offset AS off_a, b.offset AS off_b
FROM consumer_a_log a
LEFT JOIN consumer_b_log b
  ON a.order_id = b.order_id AND a.event_type = b.event_type
WHERE a.created_at BETWEEN '2026-10-12 23:00:00' AND '2026-10-13 00:30:00'
  AND b.order_id IS NULL;

不要用 kafka-consumer-groups --describe 的 CURRENT-OFFSET 去比，那个数字在两个 isolation 下不可比。

3. 切换时 reset 的坑：必须用 `--to-datetime` 而非 `--to-offset`

# 正确：按时间戳定位，让 broker 自己算 LSO
kafka-consumer-groups --bootstrap-server prod-kafka:9092 \
  --group consumer-b --reset-offsets --to-datetime 2026-10-12T23:00:00 --execute

# 错误：直接给 offset 108,441——这个 offset 在 read_committed 语义下
# 可能指向一条 ABORT marker，消费端会跳过后续 N 条已 commit 消息
kafka-consumer-groups --bootstrap-server prod-kafka:9092 \
  --group consumer-b --reset-offsets --to-offset 108441 --execute   # ← 会丢数据

4. 监控加两个指标

LSO 滞后量：LEO - LSO，超过 5000 就告警（说明有事务在悬挂）；
coordinator 切换次数：__transaction_state 的 coordinatorEpoch 变化频率，一次切换通常意味着 LSO 会卡 5–60 秒。

四、踩过的坑（反直觉之处）

read_uncommitted 不是"更快的 read_committed"，它是"能读到脏数据的 read_committed"。我们团队之前把 uncommitted 当作"低延迟档位"来用，这个认知是错的——它不是延迟问题，是正确性问题。
ABORT marker 不占"消息位"但占 offset。kafka-console-consumer 用 --from-beginning 跑 read_uncommitted 时，你会看到 offset 连续递增，但中间混着 abort marker——它被透明跳过，你的 offset 计数器已经把它算进去了。
两个消费组 lag 都是 0，不代表数据一致。这是最反直觉的：lag 是相对 LEO 算的，A 组 lag=0 只说明它读到了 LEO-1，不说明它读到的都是 committed。
transaction.timeout.ms=60s 默认值在 KRaft 模式下偏大。我们后来把它调到 5s，LSO 卡顿时间从平均 42s 降到 3s，但代价是上游事务窗口变短，有一次批量写 800 条的事务被 abort 了——这个 trade-off 没有银弹，取决于你的事务大小分布。

五、结论与可复用清单

结论：read_uncommitted 和 read_committed 不是"快/慢"两档，是两把不同的 offset 尺子。混跑可以，但必须用业务主键对账，不能用 offset 对齐；切换时必须冻结事务窗口；reset 必须用时间戳而非 offset。

可复用清单：

[ ] 上线新消费组前，确认 isolation.level 与上游生产者的事务模式匹配；
[ ] 监控 LEO - LSO 差值，>5000 告警；
[ ] 切换 isolation 前，等 __transaction_state pending 事务 = 0；
[ ] 灰度期用业务主键 JOIN 对账，禁用 offset 比对；
[ ] --reset-offsets 只用 --to-datetime，禁用 --to-offset（read_committed 场景）；
[ ] transaction.timeout.ms 按业务事务 P99 时长设定，不要盲用 60s 默认值。

一个开放问题抛给大家：Kafka 目前只有 read_uncommitted / read_committed 两档，没有"已 commit 但允许一定窗口内的 LSO 滞后"的中间态。如果让你设计一个 isolation.level=read_committed_bounded(n)——允许消费端读 LSO-n 以内的数据以换取吞吐，你会怎么定义 n 的语义？n 是 offset 差值还是时间窗口？abort marker 在这个语义下怎么"部分回滚"？我觉得这可能是 Kafka 4.x 值得讨论的方向，欢迎拍砖。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。