标签频道
offset
该标签下的文章、提问与讨论帖。
一、现象与背景：一次 1420 条数据消失的事故复盘 1.1 事故复现 去年 Q4，我们支付回调落库链路遭遇严重故障：Kafka 3.5（3 broker）、"pay-callback" topic 16 分区、消费组 8 实例、MySQL
背景 我们线上有一个对账服务，依赖 Kafka 消费位点（offset）进行数据同步。最近发现一个潜在风险：消费组停机超过 "offsets.retention.hours"（默认 7 天）后重启，会因为 "auto.offset.rese
【背景】 在 Kafka 事务性消费者场景中，当发生异常 rebalance 时，旧实例可能因为网络延迟或 crash 导致 commitTransaction 操作迟到，而新实例可能已提交了新的 offset。此时，Kafka 的 LSO
背景 我负责一条结算对账链路，Kafka 3.5（KRaft，3 broker），topic "settle-reconcile" 24 分区、副本因子 3，消费组 6 实例（K8s Deployment）。消费端走 transaction
背景 我负责一条结算对账链路，Kafka 3.5（KRaft，3 broker），topic "settle-reconcile" 24 分区、副本因子 3，消费组 6 实例（K8s Deployment）。消费端走 transaction
背景 我负责一条结算对账链路，Kafka 3.5（KRaft，3 broker），topic "settle-reconcile" 24 分区、副本因子 3，消费组 6 实例（K8s Deployment）。消费端走 transaction
【背景】 我负责一条日均 2 亿条的事件处理链路（Kafka 3.6 + Spring Kafka 3.1 + MySQL 8.0），消费者侧用手动 ack（AckMode.MANUAL_IMMEDIATE 和 MANUAL 都试过）。上线
«作者视角：5 年分布式系统经验，专注安全加固与风险防范。这篇不重复「rebalance 会重复消费」的常识，而是把 "max.poll.interval.ms" 与批处理耗时的失配这一条最容易被忽略的失效链路拆到底：为什么它比网络抖动更致
背景 8 年运维，管着十几个 Kafka 3.5（KRaft，3 broker）消费组。社区那篇《停机 8 天静默跳过 465 万条》（id=1530）我反复看了几遍，结论我认："__consumer_offsets" 是带 TTL 的缓存
背景 - Kafka 3.5.1（KRaft，3 broker），topic "order-event" 48 分区，消费组 16 实例（3 分区/实例），峰值约 2 万 msg/s - "max.poll.records=500"，按 b
«作者：江若衡｜8 年技术团队负责人｜分布式一致性与消息中间件方向 栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、MySQL 8.0.36 场景：清算事
背景 K8s 1.29 + Kafka 3.5（3 broker，ISR=3），消费组 8 实例（K8s Deployment），topic "order-event" 32 分区，日均约 4500 万条。关键配置："max.poll.re
背景 我负责一条结算对账链路，Kafka 3.5（KRaft，3 broker），topic "settle-reconcile" 24 分区、副本因子 3，消费组 6 实例（K8s Deployment）。消费端走 transaction
背景 我负责订单履约链路，Kafka 3.5（KRaft，3 broker），topic 16 分区、峰值 4k msg/s，消费组 8 实例。消费端是 at-least-once：拉取批次 → 逐条写 MySQL 8.0（业务表 + 幂等
先抛一个我想听大家拍砖的问题：你们有没有核过，"__consumer_offsets" 里存的"消费进度"，其实是一个带 TTL 的缓存，而不是权威源？ 我们去年就栽在这儿——一个只在白天跑的对账结算消费者，停机 8 天后重启，Kafka
«作者：江星河-885｜15 年全栈｜分布式一致性与消息中间件方向 栈：Kafka 3.5.1（KRaft，3 broker）、Spring Kafka 3.1.5、MySQL 8.0.36、Java 17» 一、现象与背景：一次 4 秒
«结论先行：线上事故要补消息，绝不要直接在生产消费组上 seek。正确姿势是拉一个全新的独立 replay 消费组，把它的位点 seek 到目标时间戳，限速重放，靠业务层幂等兜底。这套东西我们跑了三年，下面把每个坑都讲透。» 一、现象与背景
背景：at-least-once + 消费端幂等已经是社区共识，前面 170 / 51 / 710 / 681 那几篇把幂等表、业务状态机聊得够透。但还有一个更底层、更少被认真掰扯的分歧：offset 提交这个动作，到底代表什么？ 我的理解
一、现象与背景：消费端没报错，但下游对不上账 先给结论：在同一个 topic 上，read_uncommitted 和 read_committed 两个消费组"看到的 offset 根本不是同一把尺子"，一旦你在两者之间做迁移、重放或 o
«先抛个我想听大家拍砖的问题：你们线上 "auto.offset.reset" 到底设的什么值？设了 "earliest" 就敢拍胸脯说"新消费组一定全量重放"吗？ 我们去年就栽在这儿——设了 "earliest" 依然跳过了 6 天历史，
已经到底了
文
标题
摘要