验证计划——编码前制定项目专属的证据路径。适用于功能开发、b…

# 支付回调同步→异步改造验证计划

一、验证目标

• 回调经Kafka消费后100%落库（MySQL），0丢失、0重复扣款记录
• 对比同步/异步链路的正确性与性能差异

二、测试环境与准备

• 搭建与生产配置一致的完整链路：模拟支付网关 → 回调接口 → Kafka → 消费者 → MySQL
• 准备压测工具（JMeter/Locust）、Kafka监控（自建或开源工具）、MySQL监控
• 订单表、支付流水表增加唯一约束（如 payment_no 唯一索引）防重复

三、模拟方案设计

1. 数据准备：生成1000笔模拟订单，每笔携带唯一回调ID，落库前先写入“待验证清单”表

2. 发送策略：

• 正常批量：按中等速率分批发送1000笔
• 峰值场景：瞬时并发冲击，验证积压与消费能力
• 异常注入：消费者处理中强制重启、模拟Kafka Broker单节点故障、MySQL短暂不可达

3. 失败重试：消费失败进重试Topic，设置有限次数后入死信队列（DLQ），人工兜底

四、数据不丢失核对方法（核心）

• 对账三方核对：发送清单（1000笔）↔ Kafka消息数 ↔ MySQL落库数
• SQL核对：按唯一回调ID做 LEFT JOIN，输出缺失、重复明细
• 幂等校验：确认重复消息只产生一条支付流水（唯一索引+先查后写/INSERT IGNORE）
• 死信核查：DLQ中的消息需人工确认处理并闭环，最终对账数=1000
• 状态一致性：抽验订单状态与支付流水的终态匹配（成功/失败均有落库）

五、验收标准

| 项目 | 标准 |

|---|---|

| 落库数 | =1000，缺失=0 |

| 重复流水 | =0 |

| 死信消息 | 100%闭环处理 |

| 幂等性 | 重放同消息不产生新记录 |

| 消费延迟 | 记录P95/P99延迟区间，满足业务可接受范围 |

六、回滚预案

• 保留同步开关（功能开关/配置中心），异常时可秒级切回同步
• 对账不平立即冻结后续验证，保留Kafka日志与MySQL binlog排查

提示：Kafka本身不保证“恰好一次”业务语义，不丢数据的关键在于消费端手动提交offset（处理成功后再提交）+ 幂等落库。