我会先确认影响范围，同时控制故障继续放大。从生产者确认、副本同步、消费位点和故障演练建立端到端消息可靠性。Kafka 消息不丢失不是一个参数可以保证的，需要同时保证生产者发送成功、Broker 副本可靠保存、消费者业务成功后再提交位点，并对最终失败建立重试、补偿、告警和故障演练。

止损之后，我会按请求链路建立证据，而不是凭经验猜。沿着「业务事务形成待发送事件 → 生产者带幂等与确认发送 → Broker 在 ISR 内复制 → 消费者处理业务副作用 → 提交位点并通过对账闭环」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 业务事务形成待发送事件 数据库状态与发送动作之间用 Outbox 或 CDC 形成可恢复证据，避免提交后进程崩溃丢消息。 Outbox 表/binlog：业务提交到事件证据。 Producer/Replica/Consumer 指标：端到端确认。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

定位时我最关注这些参数、指标和容量关系。在数据库提交、发送、Broker 确认、业务提交各窗口 kill 进程并按 eventid 对账。

找到根因后先做最小修复，再用同样的流量验证。服务在事务提交后同步 send，进程在两步间崩溃。Kafka 配置再可靠也看不到未发送事件。把事件写入同库 Outbox，由独立发布器重试并记录 broker offset 后消除窗口。 生产者超时后换业务 ID 重发造成重复：Outbox 未投递数：事务 Outbox/CDC。 ISR 不足仍允许不干净选主：生产确认与错误率：生产端 all+幂等。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「Outbox 未投递」为主基线，记录值应满足「记录分区基线」；同时保存 Outbox 未投递数、生产确认与错误率，使后续变化能够回到同一时间轴比较。

恢复阶段要逐步放量，最后把监控和边界补齐。方案：更适合的场景：主要收益：代价与边界。 同步 send + 回调：低频且业务可接受明确失败：链路简单：数据库提交与发送仍有双写窗口。 事务 Outbox：数据库状态必须对应事件：本地事务原子、可重试对账：投递延迟与表治理。 CDC 读取 binlog：多服务统一捕获数据库变更：业务侵入低、顺序证据强：运维、Schema 演进和回放复杂。