perf: merge CMPP inbox validation and persistence

2026-08-20 18:55:09 +08:00
parent 633e7a7055
commit 99fb346566
6 changed files with 303 additions and 32 deletions
@@ -4745,3 +4745,14 @@ npm run verify:phase8
 | TC-CMPP-500-P1-012 | API/Worker数据库池隔离 | API与Worker分别配置32/8连接并在Worker积压时持续提交 | 两进程使用各自有界连接池，API受理连接不被Worker抢占；总连接数不超过PostgreSQL上限且压后无`idle in transaction`泄漏 |

 执行记录（2026-08-20，测试环境）：P1-001至009已由API/Gateway自动化、真实PostgreSQL迁移和独立Worker恢复验证覆盖；P1-011专用Submit传输隔离后100、200条/秒分别2999/2999、3998/3998成功，零拒绝、零节流、零连接错误。P1-010在500条/秒档失败：测试环境池调优后10秒仅2979条，实际297.9条/秒且节流611次；全部2979条最终完成并排空，但完整链仅约24条/秒。故第一阶段不通过500条/秒总目标，不执行“完整500条/秒已达标”的结论。
+
+### 完整处理500条/秒第二阶段
+
+| 编号 | 场景 | 操作 | 预期 |
+|---|---|---|---|
+| TC-CMPP-500-P2-001 | 合并校验与Inbox写入 | 普通短短信走快路径并检查SQL与阶段指标 | 使用账号唯一索引在同一SQL校验应用/企业/接口/IP/Src_Id并幂等插入；正常请求仅一次DB往返且不再单独记录`application_lookup` |
+| TC-CMPP-500-P2-002 | 合并SQL拒绝安全 | 分别停用应用、停用企业、关闭接口、使用错误IP和Src_Id | 返回对应拒绝且Inbox没有新增；不读取或缓存旧应用快照 |
+| TC-CMPP-500-P2-003 | 幂等与并发唯一键竞争 | 同载荷重试、冲突载荷重试，并并发提交相同请求键 | 同载荷返回原MessageId；冲突载荷拒绝；并发竞争最多执行一次只读恢复，不发生重复Inbox或无意义更新 |
+| TC-CMPP-500-P2-004 | Worker批量应用快照 | 同批领取多个相同及不同应用Inbox | 每个领取批次按唯一应用ID一次查询，逐条继续使用匹配快照；应用不匹配时安全退避，不跨租约持有事务 |
+| TC-CMPP-500-P2-005 | 有界容量配置 | 在测试环境提高Worker、BullMQ、Gateway Submit和Outbox并发并观测连接 | 各池配置值与在途数可观测，PostgreSQL连接低于`max_connections`并无长事务；单通道限速不被绕过 |
+| TC-CMPP-500-P2-006 | 100→200→500完整链阶梯 | 使用全新测试号段、隔离六通道模拟器，逐档注入并等待全部队列排空 | 每档报告入口实际速率/分位、Inbox完成、各队列峰值与排空、供应商阶段和数据库对账；500档只有入口及完整链均达到500条/秒且零丢重才通过 |