acks=all和enable.idempotence=true必须同时启用：前者确保消息在ISR全部落盘才确认，防丢失；后者通过PID与序列号实现Broker端去重，防重复；二者协同才能保障单会话单分区下不丢不重。
acks=all 和 enable.idempotence=true 必须同时启用
单独设 acks=all 只防 Broker 丢消息，不防生产者重试导致的重复；单独开 enable.idempotence=true 则无法保证写入成功——它依赖 max.in.flight.requests.per.connection=1 和序列号机制，若 acks=1，Leader 写完就返回，follower 同步失败时消息仍会丢失。
acks=all 要求 ISR 全部落盘才确认，必须配合 Broker 端 min.insync.replicas=2 才真正起效；enable.idempotence=true 会隐式设置 retries 为极大值，并强制 max.in.flight.requests.per.connection=1，避免乱序破坏幂等性。
- 不要手动设
retries=0或很小值——幂等性依赖重试完成去重，禁用重试等于废掉幂等 - 使用
confluent-kafka-go时，enable.idempotence必须在ConfigMap初始化时声明，运行时无法动态开启 - 事务（
TransactionalID）只解决跨分区原子写入，掩盖不了本地业务失败、消费者重复或消息表漏写等更常见的丢消息路径
消费者不能依赖 auto.commit，必须手动同步提交 offset
enable.auto.commit=true 是最大陷阱：它按固定间隔（如 auto.commit.interval.ms=5000）提交 offset，不管业务逻辑是否执行完。HTTP handler 中调用 consumer.Commit() 前 panic，或处理耗时超过间隔，都会导致 offset 提前提交、消息丢失。
- 务必设
enable.auto.commit=false，并在业务逻辑成功后立即调用consumer.CommitMessage(ctx, msg)或consumer.CommitOffsets(ctx, offsets) - 用
commitSync保证提交结果可知（失败可重试），commitAsync仅适用于允许少量重复的场景 - 不要在 goroutine 里异步 commit——若 consumer 关闭或进程退出，该 goroutine 可能被直接终止，offset 永远不提交
- 如果业务处理涉及数据库写入，
commit offset应放在tx.Commit()之后，否则可能造成“消息已确认但 DB 写失败”的不一致
kafka-go.Reader 比 sarama.ConsumerGroup 更适合流式消费
sarama.ConsumerGroup 要求实现 Setup 和 Cleanup 方法，一旦含阻塞操作（比如数据库连接池初始化、HTTP client warmup），整个 rebalance 流程就会卡住——消费者组无法完成重分配，消息停止消费。而 kafka-go.Reader 是无状态、按 partition 自动分片的轻量级结构，不依赖 goroutine 生命周期协调。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
立即学习“go语言免费学习笔记（深入）”；
-
kafka-go.Reader默认每个实例只读一个 partition，配合PartitionWatchInterval可平滑响应 topic 分区变更 -
sarama需手动做 partition-aware worker 调度，否则容易出现单个 consumer 处理多个 partition 导致 CPU 或 I/O 倾斜 -
kafka-go.Reader的ReadMessage返回值直接带Offset和Partition，业务逻辑与位点提交可精确对齐；sarama的ConsumeClaim中 offset 提交需额外调用session.Commit，且易被 panic 中断
本地事务表才是最终一致性兜底，Kafka 事务不是银弹
Kafka 事务本身不解决「业务失败后消息不该被确认」的问题。哪怕开了 TransactionalID，只要业务逻辑失败、服务崩溃、或消费者处消息未落库，就仍可能丢数据或重复。
- 推荐落地模式是：本地事务（如 PostgreSQL）写业务数据 + 写 offset 表，再统一提交；失败则整个事务回滚
- 不要试图在 Go 里手写 2PC 协调器——没有业务价值，只有运维噩梦
- 所有跨服务写操作必须拆解为「本地事务 + 外发事件」两步，本地事务成功后才发消息（推荐用
kafka-go Writer配RequiredAcksAll）
最容易被忽略的是：事务配置只是起点，真正决定消息是否可靠的是业务逻辑与 offset 提交的耦合方式——它必须和你数据库事务的边界完全对齐，而不是和 Kafka 的 transaction 边界对齐。
