Kafka不是事件总线，仅是可靠消息管道，事件语义、顺序、消费者组生命周期等需自行实现；send()成功后丢消息主因是默认配置宽松，须设acks=all、retries=Integer.MAX_VALUE、校验Future并调用flush()/close()。
Kafka 本身不是事件总线，强行当总线用容易出事——它只是可靠的消息管道，事件语义、顺序保证、消费者组生命周期、错误重试策略这些都得自己补。
为什么 send() 成功后事件还是丢了
常见错误现象：生产者调用 producer.send() 返回成功，但下游服务完全没收到消息；或者只收到部分，且顺序错乱。
根本原因在于 Kafka 默认配置极度“宽松”：不等副本确认、不校验发送结果、不阻塞重试。这在高吞吐场景合理，但在事件驱动微服务里等于埋雷。
- 必须显式设置
acks=all（而非默认的acks=1），确保 ISR（同步副本）全部写入才返回成功 - 禁用
retries=0，至少设为retries=Integer.MAX_VALUE，配合retry.backoff.ms=100避免瞬时网络抖动丢事件 - 永远别忽略
send()的Future返回值——哪怕只做get()等待一次（测试/关键事件场景），否则异常直接吞掉 - 示例中常漏掉
flush()或close()，导致缓冲区残留消息未发出
ConsumerGroup 重启后重复消费或跳过事件
典型表现：服务发布后，老事件被重复处理（如扣款两次），或新上线服务直接从最新 offset 消费，跳过积压事件。
这不是 Kafka bug，而是对 auto.offset.reset 和提交时机理解偏差。
-
auto.offset.reset=earliest只在 group 无历史 offset 时生效；已有 offset 会继续从上次位置读——所以删 topic 或重命名 group id 才能真正“重放” - 手动提交（
commitSync()）必须在业务逻辑执行成功后调用，且要捕获CommitFailedException，否则网络抖动会导致 offset 提交失败但业务已执行 - 避免用
commitAsync()处理金融类事件，它不保证提交成功，崩溃时可能丢失已处理 offset - 消费者实例数超过分区数毫无意义，还会造成空闲 consumer，检查
partitionsFor(topic)再规划实例规模
如何让不同微服务对同一事件有不同处理粒度
比如订单创建事件，库存服务要强一致性扣减，通知服务可容忍秒级延迟且允许少量重复——不能靠一个 topic + 一个 group 解决。
核心思路是解耦消费契约，而不是共享消费逻辑。
- 用不同 topic 分发语义不同的事件流：
order-created-strict（带事务 ID、要求 exactly-once）和order-created-notify（带 ttl、允许 at-least-once） - 避免在 consumer 内部做 if-else 分支处理，那会让所有服务绑定同一套序列化协议和错误策略
- 如果必须复用原始事件，用
headers字段标记处理等级（如"qos": "at-least-once"），下游按需解析，不强制所有服务支持全部 header - Kafka Streams 的
KTable适合状态聚合，但微服务间共享 state store 会引入隐式依赖——优先走 topic 交互，state 由各服务自己维护
Spring Kafka 的 @KafkaListener 不是银弹
开发时看着方便，但上线后常遇到线程阻塞、死循环重试、OOM 等问题，尤其在处理慢 SQL 或 HTTP 调用时。
它的默认行为掩盖了太多底层细节。
- 默认
concurrency=1，单线程卡住整个 listener；提高并发前先确认 topic 分区数，否则多线程争抢同一 partition 无效 -
max.poll.interval.ms设太小（如默认 5 分钟），长事务处理直接触发 rebalance，导致重复消费；建议按业务最大耗时 × 2 设置 - 异常抛出后默认立即重试，若下游 DB 正在维护，会雪崩式打满重试队列；用
DefaultErrorHandler配合FixedBackOff控制节奏 - 别在 listener 方法里直接 new ObjectMapper，高频 JSON 序列化会触发大量 GC；复用
ObjectMapper实例并禁用FAIL_ON_UNKNOWN_PROPERTIES
事件的“分布式”不来自 Kafka，而来自你如何定义边界、划分 topic、控制重试、隔离故障——Kafka 只负责把字节流从 A 送到 B，中间那层语义，没人替你写。
