kafka-go消费者需设isolationlevel为readcommitted且groupid非空，才能读取已提交事务消息；漏配isolationlevel将导致脏读。
Exactly-Once 不是单靠消费者能实现的，它必须由生产者、Broker 和消费者三方协同完成。Go 生态中没有“开箱即用”的 ExactlyOnceConsumer 类型，强行只在消费端做去重或状态检查，大概率会漏掉边界场景，比如事务回滚后重发、消费者重启时 offset 提交失败等。
kafka-go 里怎么配消费者才能读到真正已提交的事务消息
消费者默认读取的是所有消息（包括未提交的），这会导致脏读 —— 比如生产者事务中途 abort，但消费者已经处理了那些本该丢弃的消息。
关键配置只有两个：
-
IsolationLevel必须设为ReadCommitted（不是默认的ReadUncommitted） -
GroupID必须非空，且与生产者事务 ID 无直接关系，但需确保 group 级别 offset 管理启用
示例：
reader := kafka.NewReader(kafka.ReaderConfig{
Brokers: []string{"localhost:9092"},
Topic: "orders",
GroupID: "order-processor-v1",
IsolationLevel: kafka.ReadCommitted, // ← 这行不能少
})
漏掉 IsolationLevel 配置，哪怕生产者开了事务、写了 TransactionalID，消费者照样可能拿到 abort 掉的消息。
Sarama 的消费者如何避免重复消费 offset 提交失败
Sarama 默认不自动提交 offset，这点比 kafka-go 更可控，但也更易出错：如果业务 panic 后没 recover，又没手动调用 MarkOffset，下次启动就会重复消费。
必须满足三个条件才算安全：
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 使用
ConsumerGroup而非低阶Consumer，否则 offset 管理要自己全包 - 在
ConsumeClaim循环内，每成功处理一条消息，就立即调用message.MarkOffset() -
session.Close()前显式调用group.CommitOffsets()，不能依赖 defer（defer 可能在 panic 后不执行）
常见错误写法：
// ❌ 错误：panic 后 MarkOffset 没执行，offset 没更新
for msg := range claim.Messages() {
process(msg.Value)
msg.MarkOffset() // 这行可能根本没走到
}
正确做法是加 recover + 显式 commit：
for msg := range claim.Messages() {
func() {
defer func() {
if r := recover(); r != nil {
// 记日志、告警，但不要在这里 MarkOffset
}
}()
process(msg.Value)
msg.MarkOffset()
}()
}
franz-go 中 ReadCommitted 的真实行为和坑点
franz-go 的 FetchIsolationLevel 设为 ReadCommitted 后，看似安全，但它有个隐藏前提：Broker 必须开启 transactional.id 相关配置，且客户端连接时用了支持事务的 SASL/SSL 认证方式。
最容易被忽略的是这个组合问题：
- Broker 的
transaction.state.log.min.isr设置过小（比如 1），而集群 ISR 数不足，会导致事务元数据写入失败，消费者卡在等待稳定 offset - 客户端没配
RequireStableFetchOffsets: true，即使 isolation level 是 committed，也可能返回 pending 状态的 offset（表现为消费停滞）
所以初始化 client 时，建议这样写：
client := kgo.NewClient(
kgo.SeedBrokers("localhost:9092"),
kgo.FetchIsolationLevel(kgo.ReadCommitted),
kgo.RequireStableFetchOffsets(true), // ← 关键兜底
)
不加 RequireStableFetchOffsets，在高负载或 ISR 波动时，ReadCommitted 就形同虚设。
Exactly-Once 的复杂性不在代码行数，而在对事务生命周期边界的判断 —— 比如消费者处理完消息、提交 offset、生产者事务 commit 这三件事的时间差，任何一环滞后或失败，都会打破语义。实际项目里，与其强求 Exactly-Once，不如先确保 At-Least-Once 下的幂等处理（比如用唯一业务 ID 做数据库 upsert），再配合事务性生产者把重复概率压到最低。
