风险概述

• 风险特征
  • 客户端在弱网/离线场景使用“队列重放 + 最后写入覆盖（LWW）”策略；缺少请求幂等键与服务端版本号校验。
  • 离线转在线时，请求乱序（历史创建/取消先后无保障），服务端以时间戳判定，导致状态回退或覆盖。
  • 支付相关接口在超时/失败后客户端自动重试，可能触发重复扣款；支付回调存在重放风险；对账服务可能无法及时发现异常。
• 影响范围
  • 模块：离线缓存、同步引擎、订单服务、支付网关对接、支付回调处理、对账服务。
  • 业务：订单状态正确性、资金扣款一致性、退款/对账异常、用户投诉。
• 发生概率
  • 高：地铁/电梯/跨网切换等弱网；杀进程/系统回收；App重启自动重放；第三方支付回调重试。
• 结果严重性
  • 高：重复扣费、已取消订单被扣款、账实不符。

测试目标

1. 验证在弱网/离线/乱序/重试条件下，订单状态不被旧请求覆盖，且不会产生重复扣费。
2. 验证客户端队列重放机制的去重、有序性和重试策略的安全性（不造成副作用重复执行）。
3. 验证服务端在乱序、重复请求、回调重放、超时等情况下的幂等与一致性保障能力。
4. 验证对账服务能否及时识别重复扣费/状态不一致，并输出可追踪的异常项。
5. 为后续整改（如幂等键与版本校验）提供基线复现证据与回归测试用例。

测试策略

• 方法与覆盖维度
  • 故障注入/网络混沌：延迟、丢包、抖动、限速、断网/恢复、瞬时断开与频繁切换；验证乱序、超时与重试行为。
  • 请求层操控：重复发送、乱序重放、部分成功/部分失败、批量提交中断后重放。
  • 时间维度：客户端与服务端时钟偏移（±1/3/5/10分钟），验证仅靠时间戳判定的风险。
  • 进程/会话：杀死进程、App重启、后台到前台、系统回收后队列重放。
  • 回调幂等：第三方支付回调的重复/延迟/乱序到达对订单状态与资金流的影响。
  • 多终端并发：同一账号多设备离线/在线交错操作，验证全局一致性。
• 环境与前置
  • 使用沙箱支付环境与可回放的网关模拟器；独立商户/用户/订单前缀，便于对账追踪。
  • 接入网络代理/链路整形工具以进行延迟、限速、丢包与重放；具备请求/响应抓取与重放能力。
  • 开启服务端/客户端日志与追踪ID（例如orderId、requestId、traceId），便于端到端关联。
  • 可触发/观察对账任务，导出对账差异报表与异常明细。
• 数据与观测
  • 每个用例使用唯一订单ID；记录请求序列、到达顺序、服务端状态变更日志、资金凭证（预授权/扣款/退款）与对账结果。
  • 断言点：订单最终状态、资金扣款次数、回调处理幂等性、服务端冲突/幂等响应、对账异常捕获。

测试场景

说明：每个场景包含两类期望，用于覆盖“复现实风险（当前基线）”与“修复后目标”。当系统尚未整改时，可按“复现实风险”作为实际观察；整改后以“修复后目标”作为通过标准。

1. 场景S1：离线创建→离线取消→上线乱序重放

• 目的：验证乱序导致状态覆盖风险与重复扣费可能性。
• 前置：关闭网络；新用户U1；余额/支付工具可用。
• 步骤
  1. 离线发起创建订单C1（入本地队列，不发出）。
  2. 离线发起取消C1（再次入队）。
  3. 上线时通过代理将“创建”延迟发送，“取消”优先发送；确认服务端先收到取消后再收到创建。
• 复现实风险观察：最终订单可能被创建或进入支付流程；存在扣款或预授权产生。
• 修复后目标：最终状态为“已取消”；无任何扣款/预授权；创建请求被拒绝（因版本冲突或幂等/时序保护）。

2. 场景S2：离线取消→离线上传时“创建”先到达

• 目的：验证LWW与时间戳判定导致取消失效。
• 步骤：与S1相似，但确保创建先到达。
• 复现实风险：创建成功、取消被覆盖，可能产生扣费。
• 修复后目标：最终“已取消”；创建被判冲突或被丢弃；无扣费。

3. 场景S3：创建请求重复重试（UI多次点击+网络超时）

• 目的：验证缺少幂等键导致重复订单/扣费。
• 前置：限速/高延迟网络；同一商品G1。
• 步骤
  1. 提交创建C2，制造超时（客户端未收到成功）。
  2. 用户再次点击提交（或自动重试触发2~3次）。
• 复现实风险：出现多个订单、或对同一订单多次扣款尝试。
• 修复后目标：仅生成一个订单ID；多次请求返回相同结果；无重复扣款。

4. 场景S4：支付确认接口超时后的客户端重试

• 目的：验证支付确认的幂等性与扣款重复风险。
• 步骤
  1. 创建并进入支付；对“支付确认/扣款”接口注入超时。
  2. 客户端自动重试2~3次。
• 复现实风险：产生重复扣款或重复发起扣款请求。
• 修复后目标：仅一次扣款；重试返回相同交易结果。

5. 场景S5：支付回调重放与乱序

• 目的：验证回调处理幂等性。
• 步骤
  1. 正常完成一次支付，记录回调内容。
  2. 重放相同回调2~3次；调整次序为“成功→失败→成功”。
• 复现实风险：订单状态被回退或重复记录资金流水。
• 修复后目标：回调幂等处理，仅保留一次生效变更；状态不回退；无重复流水。

6. 场景S6：对账发现与隔离能力

• 目的：验证对账能否识别“取消订单发生扣款”的异常。
• 步骤
  1. 通过S1/S2/S4制造至少一笔“取消但扣款”的异常。
  2. 触发对账任务，导出差异清单。
• 复现实风险：对账未能捕获或延迟较长。
• 修复后目标：在可配置时限内（如T+0或T+1）标记异常，生成可追溯记录与告警。

7. 场景S7：客户端与服务端时钟偏移

• 目的：验证仅用时间戳判定的安全性。
• 步骤
  1. 将客户端时间快/慢5分钟，重复S1/S2流程。
• 复现实风险：时间戳误判导致状态错误或扣费。
• 修复后目标：服务端基于版本/乐观锁/服务器时间排序，不受客户端时间影响。

8. 场景S8：最后写入覆盖导致旧状态覆盖新状态

• 目的：验证LWW对订单状态的破坏性。
• 步骤
  1. 在线创建C3并支付成功。
  2. 离线对C3发起取消（入队），随后上线发送。
• 复现实风险：已支付订单被错误标记取消或触发退款异常流。
• 修复后目标：服务端拒绝旧版本更新（返回冲突），不改变既成资金事实；如需退款，走明确的退款接口与流程。

9. 场景S9：杀进程后自动重放

• 目的：验证队列持久化与重放去重。
• 步骤
  1. 离线创建并触发2次重试排队。
  2. 杀进程→重启→上线自动重放。
• 复现实风险：多次创建或重复扣款。
• 修复后目标：去重有效；最终仅一次有效请求。

10. 场景S10：多设备并发与离线交错

• 目的：验证跨设备一致性。
• 步骤
  1. 设备A在线创建C4并进入待支付。
  2. 设备B离线取消C4；A继续支付；随后B上线。
• 复现实风险：状态抖动、重复扣费或错误退款。
• 修复后目标：遵循版本/意图冲突策略：若已支付成功，取消转为退款流程且幂等；无重复扣款。

11. 场景S11：批量重放的部分成功/失败

• 目的：验证部分成功后的再次重放不会产生副作用。
• 步骤
  1. 离线积累创建与取消各3条；上线时注入50%失败。
  2. 自动重放剩余队列。
• 复现实风险：已成功的请求被重复执行。
• 修复后目标：重放对已成功项无副作用；最终状态与金额正确。

12. 场景S12：网络抖动快速切换

• 目的：验证在抖动中重试与乱序的综合影响。
• 步骤：在“创建→取消→支付”过程中每3~5秒切换在线/离线/限速。
• 复现实风险：状态错乱与重复扣费。
• 修复后目标：无重复扣费；最终状态与用户最后意图一致。

13. 场景S13：已发起支付时用户取消

• 目的：验证竞态条件下的资金与状态协同。
• 步骤
  1. 创建并发起支付请求，注入高延迟。
  2. 用户立即取消订单；随后支付结果返回成功。
• 复现实风险：支付成功但订单为取消，导致账务不一致。
• 修复后目标：订单状态进入“需退款/已支付待退款”明确中间态；自动或人工退款流程可追踪；不出现第二次扣款。

14. 场景S14：服务端5xx/429导致的退避重试

• 目的：验证客户端退避策略安全性与服务端幂等。
• 步骤：对创建/支付确认注入5xx/429，观察重试节奏与副作用。
• 复现实风险：高频重试放大重复扣费概率。
• 修复后目标：指数退避与上限生效；服务端幂等保障不产生多次扣款。

15. 场景S15：本地队列重复/损坏

• 目的：验证异常存储导致的重复请求。
• 步骤：制造队列重复项（同一请求两条）后上线重放。
• 复现实风险：重复创建/扣款。
• 修复后目标：客户端/服务端去重均有效；仅一次生效。

验证标准

• 订单状态一致性
  • 最终状态与用户最后意图一致；不存在旧请求覆盖新状态。
  • 禁止状态回退（例如已支付→已取消，除非通过明确退款流程且有资金凭证对应）。
• 资金与交易幂等
  • 同一业务意图仅产生一次有效扣款/预授权；支付回调重复不产生额外变更。
  • 重试/重放/乱序不增加资金流水笔数；若产生退款，需有一一对应凭证。
• 请求与版本控制
  • 修复后目标：对重复/过期/旧版本请求返回幂等命中或版本冲突（如409）；相同幂等键返回相同业务结果。
  • 仅服务器时间参与排序/版本冲突判定，客户端时间偏移不影响结果。
• 回归与对账
  • 对账任务在约定时限内识别异常（重复扣费、取消后扣款、状态不一致），输出明细并可追溯到请求链路（traceId）。
• 重试策略
  • 客户端退避策略生效（指数退避、最大重试次数、抖动）；不会造成风暴式重试。
• 日志与可观测性
  • 端到端可通过orderId/requestId/traceId串联，所有关键操作有审计记录。

优先级建议

• P0（立即执行，直接关联重复扣费风险）
  • S1 离线创建→取消乱序
  • S3 创建请求重复重试
  • S4 支付确认超时后的重试
  • S5 支付回调重放与乱序
  • S13 已发起支付时用户取消
• P1（高优先级，巩固一致性与检测能力）
  • S2 乱序（创建先到）变体
  • S7 客户端/服务端时钟偏移
  • S9 杀进程后自动重放
  • S6 对账发现与隔离能力
• P2（补充场景，完善边界与稳定性）
  • S10 多设备并发
  • S11 部分成功/失败后的重放
  • S12 网络抖动快速切换
  • S14 5xx/429退避重试
  • S15 本地队列重复/损坏

备注与执行要求

• 每个场景需在相同数据构造下重复执行3次以上，确认稳定复现或稳定通过。
• 记录端到端证据：请求序列、服务端状态变更、交易流水、回调明细、对账报表。
• 基于P0/P1结果沉淀自动化回归脚本（接口层+端到端），纳入发布前质量门禁。

风险概述

• 风险特征
  • 事件链“订单创建→记账→发货”缺少最终一致性与补偿（Saga/补偿策略未落地）。
  • MQ未配置唯一键去重且消费侧无幂等控制（无幂等键/去重表/去重缓存），在重放/重试时可能重复记账。
  • 订阅顺序不一致与跨区时延导致发货先于记账，出现“发货成功但资金未冻结”的业务不变式破坏。
• 触发因素
  • MQ抖动（延迟、暂时不可用、消息堆积）、分区重平衡（消费者组变更/再均衡）、跨可用区/跨地域网络延迟。
• 影响范围
  • 订单、账务（资金冻结/扣减）、库存（扣减/回滚）、消息中间件、补偿任务/对账任务、审计。
• 发生概率（在云服务环境，至少一次投递+分区订阅+跨区部署）
  • 中到高（在峰值负载、扩缩容、跨区流量切换时概率上升）。
• 后果严重性
  • 资金与库存不一致、审计困难、对账差异扩大、用户纠纷风险、中台结算风险。
• 现状假设
  • 无消息去重键；消费侧无幂等表；补偿任务缺失或未覆盖；各服务独立订阅，无跨服务序列约束。

测试目标

1. 验证在抖动、重平衡、跨区时延下是否出现“发货先于资金冻结”的不一致。
2. 验证在消费超时/重试/重放条件下，账务是否出现重复记账或重复冻结。
3. 验证无唯一键去重、无幂等机制时的重复处理风险与范围。
4. 验证补偿/对账任务的可用性、覆盖率与SLA（如无补偿则验证差错可观测性与告警）。
5. 评估事件链的最终一致性窗口、失败恢复路径与审计可追溯性（链路可观测性）。

测试策略

• 环境与观测
  • 预备环境：准生产/灰度环境，跨可用区部署，MQ配置与生产一致（至少一次投递、分区订阅、消费者组）。
  • 可观测性：开启分布式追踪（相关ID贯穿订单、记账、发货）、结构化日志、消息头部携带幂等键/消息ID（用于观测即使未用于去重）。
  • 计数与不变式度量：
    • 资金冻结/扣减计数与金额一致性（账务总额变化与订单状态一致）。
    • 库存扣减计数与订单发货状态一致。
    • 账务流水“恰好一次”与消息处理次数对比。
  • 数据基线：构造测试账户与库存（余额充足/不足两类，库存充足/不足两类），固定商品与订单模板。
• 故障注入与触发手段
  • MQ抖动：在消费者端注入随机处理延迟与超时；生产端注入发送延迟；队列限速。
  • 分区重平衡：动态增加/减少消费者实例或调整分区数，触发再均衡。
  • 跨区延迟：使用网络控制（如tc/netem）在账务或发货服务所在节点增加RTT与抖动。
  • 重试与重放：关闭幂等保护后，手动重放消息或配置较短超时+自动重试。
  • 顺序扰动：暂停账务消费者、优先生启发货消费者，或改变并发度与预取以制造先后差异。
• 测试方法
  • 风险属性测试：针对“无序、重复、延迟、丢失”四类事件驱动风险分别设计场景。
  • 不变式验证：定义领域不变式并在每次操作后校验（例如“发货状态=已发货 ⇒ 资金冻结=已完成”）。
  • 混沌/回归：在有负载的情况下持续注入，观察稳定性与一致性窗口。
  • 批量对账：场景完成后进行账务与库存的离线比对，验证差异检测与审计可追溯性。

测试场景

说明：以下场景使用统一前置条件，随后给出执行步骤与预期结果（验证点）。如系统当前未实现补偿/幂等，则预期表现为“发现风险”，并记录不一致与重复范围；如已实现，则按“验证标准”判断通过与否。

通用前置条件

• 环境：云服务准生产环境，订单、账务、库存、发货服务与MQ正常运行，至少一次投递模式，分区数≥3，消费者组各≥2实例。
• 观测：启用追踪ID（例如 trace_id、order_id、message_id），接入日志/指标采集。
• 数据：创建测试用户U1（余额充足）、U2（余额紧张），商品S1（库存充足）、S2（库存紧张）。配置订单模板O（含金额与库存占用）。

场景1：发货先于记账（顺序不一致）

• 步骤
  1. 暂停账务消费者5分钟（或将其处理延迟提高至P99>3s），发货消费者保持正常。
  2. 创建订单O1（U1,S1），订单服务提交事务后发布消息到MQ。
  3. 观察发货服务先消费并成功发货；账务仍未冻结或延迟。
• 预期与验证
  • 发货状态=已发货；账务冻结状态=未冻结或延迟。
  • 不变式被破坏：已发货但资金未冻结。
  • 补偿任务若存在，应在SLA窗口内纠正（例如发货回滚或补记账）；若不存在，记录差异并触发告警。

场景2：记账消费超时+自动重试（重复处理风险）

• 步骤
  1. 将账务消费者的处理超时阈值设置为低值（如1s），在处理时注入随机延迟2-3s导致超时。
  2. 发送订单O2（U1,S1）消息，触发账务消费超时与重试。
  3. 记录账务服务对同一message_id的处理次数与账务流水入账条数。
• 预期与验证
  • 在无幂等保护时，可能出现重复记账/重复冻结。
  • 若有幂等保护，重复处理次数>1但账务入账条数=1，金额正确。

场景3：消息重放（人工重投/死信重试）

• 步骤
  1. 完成一次正常订单O3流程后，手动重放同一message_id或同一业务键消息。
  2. 观察账务与库存的二次处理行为。
• 预期与验证
  • 无去重/幂等：账务流水出现重复，库存可能重复扣减。
  • 有幂等/去重：无重复入账；处理日志记录“已处理”。

场景4：分区重平衡过程中顺序扰动

• 步骤
  1. 在持续下单压测（QPS≥100）的同时，将消费者组实例数从2扩容到6，再缩回2。
  2. 记录同一订单事件在账务与发货消费者的到达与处理时间顺序。
• 预期与验证
  • 观察到处理顺序波动；验证是否出现发货先于记账。
  • 对重复处理进行统计；有幂等时重复处理不会生成重复业务效果。

场景5：MQ抖动与延迟（队列堆积）

• 步骤
  1. 限速生产端或引入MQ端到端延迟（例如延迟队列/网络抖动）。
  2. 发送订单O5，记录消息在不同订阅的延迟差异。
• 预期与验证
  • 当发货通道等待较短而账务通道堆积，出现先发货后记账。
  • 验证是否有告警与补偿介入。

场景6：跨区延迟（账务跨区部署）

• 步骤
  1. 使用网络控制在账务服务节点注入RTT 200-500ms，发货保持本区低延迟。
  2. 发送订单O6，观察处理顺序。
• 预期与验证
  • 高概率出现发货先于记账。
  • 验证最终一致性窗口与是否在窗口内完成资金冻结或回滚发货。

场景7：补偿任务不可用或滞后

• 步骤
  1. 暂停或延后补偿/对账任务（例如周期从5min改为60min）。
  2. 执行场景1/5/6引入不一致。
• 预期与验证
  • 不一致持续存在超过定义的SLA阈值；审计差异累积。
  • 验证是否有自动告警、人工干预流程与手工对账入口。

场景8：无消费幂等表/缓存

• 步骤
  1. 明确账务服务无幂等记录（表/缓存）后，重复投递同一订单O8消息3次。
  2. 记录账务流水与资金状态。
• 预期与验证
  • 出现多条相同流水或多次冻结/扣减；金额累计错误。
  • 记录重复发生率与影响金额。

场景9：唯一键去重缺失（生产端无去重键）

• 步骤
  1. 发送两条业务内容相同但message_id不同的订单O9消息（模拟上游重复发送）。
  2. 观察账务与库存效果。
• 预期与验证
  • 无去重：产生两次处理；有消费幂等但无业务幂等键时可能仍重复。
  • 有业务幂等键：只处理一次。

场景10：审计与批量对账

• 步骤
  1. 汇总场景1-9产生的订单事件与账务流水、库存变更，进行离线对账。
  2. 校验审计线索（trace_id、操作人、事件时间线）完整性。
• 预期与验证
  • 不一致项被准确识别；差异来源可追溯；输出修复清单。
  • 若有补偿机制，验证补偿后对账为一致。

验证标准

• 领域不变式
  • 已发货 ⇒ 资金冻结已完成（或先冻结后发货）。不满足则判定为一致性失败。
  • 每个订单在账务与库存侧的处理“恰好一次”（无重复流水/无重复扣减）。
• 幂等与去重
  • 对同一业务幂等键/消息ID的重复投递，账务流水最多一条，库存扣减最多一次。
• 最终一致性窗口
  • 在定义窗口T（例如≤5分钟）内，通过补偿实现账务与库存一致。超出T判定为失败。
• 重试与重放
  • 消费超时或重试不会导致金额或库存的重复变更；日志记录显示“重复处理但无副作用”。
• 审计与对账
  • 对账差异=0（或≤可接受阈值）；审计线索完整，能够重建事件序列。
• 告警与可观测性
  • 当出现不一致或重复，触发告警并包含必要上下文（order_id、message_id、服务名、时间戳）。

优先级建议

• P0（立即执行）
  • 场景1 发货先于记账（顺序不一致）：直接导致资金风险与用户纠纷，覆盖面广。
  • 场景2 记账超时重试导致重复处理：高影响金额风险，直接破坏“恰好一次”。
  • 场景8/9 幂等与去重缺失：基础控制缺失，需尽快量化重复发生率。
• P1（高优先级）
  • 场景4 分区重平衡：在扩缩容与峰值期常见，易触发顺序扰动与重复。
  • 场景5 MQ抖动与延迟：与云环境运行特性高度相关，验证告警与缓解策略。
  • 场景6 跨区延迟：跨区部署下的系统性风险，需要明确一致性窗口。
• P2（中优先级）
  • 场景7 补偿任务不可用或滞后：在P0/P1暴露后评估恢复能力与SLA。
  • 场景10 审计与批量对账：用于阶段性收敛与评估风险余量。

附：风险缓解建议（供测试后评估与设计参考）

• 事件链控制：采用Saga编排或本地事务+Outbox确保消息与业务变更原子性；发货前校验资金冻结状态。
• 幂等与去重：在生产端携带业务幂等键（order_id+event_type），消费侧维护幂等表/缓存；重复投递只记轨迹不重复入账。
• 顺序与隔离：按业务键分区以增强局部顺序；将“发货”订阅依赖于“记账完成”事件。
• 补偿与对账：实施准实时补偿任务与对账任务，设定明确SLA与告警阈值。 上述为行业通用做法，需结合系统架构与合规要求进行验证与落地评审。