perf: batch gateway submits and isolate callbacks

2026-08-25 11:39:59 +08:00
parent c6f11014d6
commit 761c123b65
29 changed files with 1912 additions and 193 deletions
@@ -4669,6 +4669,11 @@ npm run verify:phase8
 | TC-CMPP-PERF-OBS-003 | Gateway供应商下发分段耗时 | 在隔离测试环境构造Stream等待、限速等待、连接窗口等待、供应商慢响应和API慢回调 | `stream_wait/rate_limit_wait/connection_wait/supplier_rtt/api_callback`可独立区分；`supplier_rtt`在API回调变慢时不等量增长 |
 | TC-CMPP-PERF-OBS-004 | 观测标签边界 | 检查API/Gateway新增指标文本和Prometheus时序标签 | 只出现固定`stage/result/le`；不得出现手机号、企业/应用/通道/连接/消息/Submit/任务ID、短信正文或凭据，未知阶段不生成时序 |
 | TC-CMPP-PERF-OBS-005 | 纯观测语义回归 | 对比启用埋点前后的同一组CMPP Submit结果、数据库记录、扣费冻结、队列命令及回执 | SubmitResp状态、Msg_Id、多号码独立记录、同步拒绝、异步回执、幂等键和业务调用顺序均不改变；埋点不写PostgreSQL/Redis |
+| TC-CMPP-PERF-OBS-006 | 发送Worker分段耗时 | 在隔离测试环境完成正价短信发送并抓取Worker回环metrics | 11个固定阶段按实际路径增长，结果仅为`success/error/skipped`；各阶段count与Worker结果可对账，直方图不含业务实体标签 |
+| TC-CMPP-PERF-OBS-007 | BullMQ与Worker槽位 | 在空闲、入压、排空三个时点抓取Worker metrics并交叉核对BullMQ | waiting/active/completed/failed/delayed/prioritized、configured/in_flight和completed/failed/skipped均为真实值，排空后waiting/active归零 |
+| TC-CMPP-PERF-OBS-008 | Worker数据库连接池等待 | 让发送并发超过Worker数据库池，在压测窗口逐秒抓取metrics | `cmpp_worker_database_pool_connections{state=max|total|idle|waiting}`反映客户端池；waiting峰值可被采到，结束后归零，不通过提高连接上限掩盖等待 |
+| TC-CMPP-PERF-OBS-009 | PostgreSQL归一化热SQL | 测试环境启用并重置`pg_stat_statements`后执行正价六通道压力，再按total执行时间排序 | 可得到归一化SQL的calls/total/mean/rows且不含实参；开放会话累计、账户锁、提交记录和状态写入可分别归因 |
+| TC-CMPP-PERF-OBS-010 | 正价六通道诊断档 | 快照后设置0.0325元单价、三运营商规则和六通道主动双活，执行smoke及100条/秒30秒并监控至排空 | 入口、三运营商、六账号、供应商首次提交、计费、Stream、数据库和恢复配置均可对账；未达到完整100条/秒时停止升档，不以SubmitResp冒充全链吞吐 |
 | TC-CMPP-PERF-V2-001 | 持续补位无批次屏障 | 工作池并发设为2，先投递一个阻塞任务和一个快速任务，再投递第三个任务 | 快速任务结束后第三个任务立即开始，不等待第一个慢任务结束；读取批次不形成整批`Wait`屏障 |
 | TC-CMPP-PERF-V2-002 | 单消息独立ACK | 同一批次投递一快一慢两条消息，慢任务保持在供应商等待 | 快任务完成后Redis PEL立即只剩慢任务；不得等慢任务结束后整批ACK，也不得在供应商结果回传前提前ACK |
 | TC-CMPP-PERF-V2-003 | 全局并发边界 | 分别配置并发1、64、1024和大于1024的值，持续投递超过槽位数的消息 | 同时处理数不超过有效配置；缺省为64，大于1024按1024执行，空闲槽位持续补充 |
@@ -4810,3 +4815,52 @@ npm run verify:phase8
 | TC-CMPP-GUARD-012 | 配置恢复审计 | 每项测试后回读企业、应用、余额、签名、报备、通道、连接和临时规则 | 所有临时配置恢复原值，服务健康、队列无异常状态，操作和测试证据可追溯 |

 执行记录（2026-08-21，测试环境）：`TC-CMPP-GUARD-001`至`012`全部通过。入口采用耐久异步受理，因此业务拦截用例的SubmitResp仍可为0；最终结论以本次MessageId对应的消息错误码、供应商提交数及客户失败回执为准。通道组补发实测主通道结果码8、备通道accepted、消息最终delivered；全部临时配置已恢复。
+
+## TC-CMPP-500-P4-P1 发送Worker低风险数据库往返收敛（2026-08-24）
+
+| 用例ID | 场景 | 预期 |
+| --- | --- | --- |
+| TC-CMPP-500-P4-P1-001 | CMPP单号码任务在提交、结果、回执和超时阶段刷新进度 | 使用直接状态更新；压力窗口不产生按batchTaskId的消息状态`GROUP BY`；多号码任务仍走聚合 |
+| TC-CMPP-500-P4-P1-002 | 路由、在线通道与签名报备候选 | 一次数据库候选查询只返回active/connected/approved通道；无最终通道二次报备查询；报备或通道撤销能实时拦截 |
+| TC-CMPP-500-P4-P1-003 | 开放会话与提交统计 | 每通道首次读取开放会话ID并复用；提交事务不更新`CmppSubmitSession.submitTotal`热点行；提交记录保持独立外键 |
+| TC-CMPP-500-P4-P1-004 | Gateway双发布职责 | Go Gateway只消费Redis Stream；发送Worker不再写无消费者BullMQ副本；Stream PEL/ACK/结果Outbox/死信行为不变 |
+| TC-CMPP-500-P4-P1-005 | 正价六通道100档 | 入口、消息、提交、回执、计费、唯一性和六账号分布一致；双Stream最终排空、Bull遗留值不增长、数据库无持续锁或idle事务 |
+
+执行记录：本地API全量42套500项和TypeScript构建通过；正价smoke 9/9通过。最终100档2999/2999受理，P50/P95/P99=`33/77/179ms`，三运营商=`998/996/1005`，六供应商账号均有提交；2999个唯一号码首次供应商提交覆盖99.940秒、约30.00条/秒，未达到完整100条/秒，按停止线未升200/300/500。应用任务进度`GROUP BY`为0、开放会话热点累计更新为0、Bull遗留wait始终84119；两条Stream最终0/0。计费冻结/释放各2999笔974675，正式扣费2990笔971750、退款25笔8125，SmsBillingRecord当前charged2965笔963625/refunded25笔8125，账务恒等。剩余主瓶颈是同企业计费`pg_advisory_xact_lock`累计373.373秒/841次；P1降低单条Worker总耗时但未提高完整供应商吞吐。临时单价和三条号段规则已恢复。
+
+## TC-CMPP-500-P4-P2 正价计费并发锁治理（2026-08-24）
+
+| 用例ID | 场景 | 预期 |
+| --- | --- | --- |
+| TC-CMPP-500-P4-P2-001 | 同企业多应用正价并发冻结 | 任务、消息、冻结流水和账户余额仍同事务；账户锁仅覆盖事务末尾账务段，等待时间显著低于P1对照 |
+| TC-CMPP-500-P4-P2-002 | 单价325的冻结、释放、扣费、退费并发幂等 | MessageId/号码唯一，账户流水与`SmsBillingRecord`净扣一致，无重复扣费或负余额 |
+| TC-CMPP-500-P4-P2-003 | Worker微批候选的性能比较 | 只有完整供应商吞吐不退化才保留；退化时回退候选代码并重新部署验证 |
+| TC-CMPP-500-P4-P2-004 | 六通道正价50档停止线 | 核对入口、唯一供应商首提交、通道分布、账务和队列；完整吞吐不到50时不升100 |
+| TC-CMPP-500-P4-P2-005 | 禁止0计费压测代替正价证据 | smoke及所有压力档`unitPrice` min/max均325；单价0只在测试结束后做环境恢复，恢复后不再压测 |
+
+执行记录：最经六通道正价50档1499/1499受理，入口P50/P95/P99=`31/77/227ms`，完整供应商首提交约21.69条/秒，因低于50未升100。计费锁598次累计3.241秒/均值5.420ms，较P1累计下降约99.1%、均值下降约98.8%。冻结/释放各1499笔487175，charged1496笔486200，退费21笔6825，账单净扣一致。Worker微批候选因吞吐退化已回退；所有压力运行均为325正价，无0计费压测。
+
+## TC-CMPP-RELEASE-CLOSEOUT 发布前主流程与拦截复核（2026-08-24）
+
+| 用例ID | 场景 | 当前版本结果 |
+| --- | --- | --- |
+| TC-CMPP-RELEASE-001 | 正价CMPP接收、发送、SubmitResp、回执、计费 | 单价325的消息`MSG-6b537761-9a1c-47eb-88d3-fe5e1d7d33f9`为accepted/DELIVRD/delivered，计费记录325、账户charged -325；通过 |
+| TC-CMPP-RELEASE-002 | 上行匹配与客户Deliver/ACK | 上行`cmt75bszh0qjy6vletv06f4pc`按MessageId精确匹配，下游投递最终delivered；通过 |
+| TC-CMPP-RELEASE-003 | 签名、模板、余额、号码频次 | 分别为SIGNATURE/TEMPLATE/BALANCE/RISK，供应商提交均0；通过 |
+| TC-CMPP-RELEASE-004 | 应用接口、应用状态、企业状态 | 接口关闭、应用inactive/deleted、企业inactive/deleted均bind状态3；通过 |
+| TC-CMPP-RELEASE-005 | 报备与通道启停 | 报备缺失和主备全停为ROUTE且提交0；仅主停自动选择备通道并delivered；通过 |
+| TC-CMPP-RELEASE-006 | 主通道拒绝后组内补发 | 主通道结果码8/rejected，备通道关联retryOf后accepted，消息delivered；通过 |
+| TC-CMPP-RELEASE-007 | 配置、队列和服务恢复 | 应用/企业/签名/报备/通道全部恢复；Inbox、BullMQ、双Stream排空；无锁等待/idle事务；六服务和六连接健康；通过 |
+
+说明：异步耐久入口的业务拦截仍可先返回成功SubmitResp，必须按精确MessageId核对最终错误码、供应商提交数和客户失败回执。供应商模拟器重启后必须同时等待模拟器连接数和数据库通道连接状态恢复，不能只看TCP连接数。
+
+| TC-CMPP-OUTBOX-001 | Submit事实与Outbox原子持久化 | 提交记录、消息状态和Outbox同事务，payload submitId一致且唯一 |
+| TC-CMPP-OUTBOX-002 | 影子到正式单路径切换 | 影子只对账；正式启用后旧直投关闭，无双发布 |
+| TC-CMPP-OUTBOX-003 | 租约恢复与批量发布 | SKIP LOCKED领取、Redis pipeline、批量回写和有界失败重试 |
+| TC-CMPP-OUTBOX-004 | 正价阶梯与计费恒等式 | 账单数等于消息数、金额等于消息数乘325，补发有retryOf |
+| TC-CMPP-OUTBOX-005 | 首提容量停止线 | 仅首次Submit计算速率；50 TPS不达标即停止更高档 |
+| TC-CMPP-BATCH-001 | 批量路由规划 | 同一聚合批次只执行一次消息/号段/候选路由预载，仍逐消息执行实时状态、报备及限速判断 |
+| TC-CMPP-BATCH-002 | Submit与Outbox批量原子持久化 | Submit批量插入、消息集合式更新、Outbox批量插入同属一个短事务；MessageId/submitId唯一 |
+| TC-CMPP-CALLBACK-001 | Gateway事件进程隔离 | Submit结果、回执、上行、协议日志和死信只进入回环回调进程及独立12槽池；连接状态仍进入主API |
+| TC-CMPP-CALLBACK-002 | 回调安全边界 | 回调进程仅监听127.0.0.1，不加载计费管理Controller；健康与指标端点只在回环可见 |
+| TC-CMPP-BATCH-003 | 正价50 TPS完整提交 | 单价325，499条首次Submit在9.930秒完成（50.25/s）；499笔账单162175，无丢重，队列最终排空 |