perf(cmpp): decouple supplier result callbacks

2026-08-20 14:19:42 +08:00
parent 485af688d2
commit 67b760a599
27 changed files with 1000 additions and 66 deletions
@@ -1153,5 +1153,6 @@ global，不能错误归入client。`client-signature-*`、发送页、企业认
 - CMPP性能分段沿用上述边界：业务模块只在原调用边界提交固定阶段名、成功标志和单调时钟耗时；指标模块拒绝未知阶段。`supplier_rtt`在供应商连接调用结束时立即停止，API结果回写另计`api_callback`，防止后续优化依据混杂总耗时。
 - V2提交工作池只归`gateway/internal/submitworker/`治理：Redis领取、全局槽位、在途消息ID和逐条ACK不能渗入上游连接池；`gateway/internal/upstream/`继续只负责通道连接、窗口和供应商协议往返。这样Worker吞吐调优不会改写CMPP连接状态机，连接池也不能自行确认Redis消息。
 - V3客户入站窗口只归`gateway/internal/inbound/`与项目内受控的`third_party/gocmpp`服务循环治理：API认证只返回应用窗口，inbound会话负责收紧窗口，协议服务循环负责受限派发和断线等待；不得把客户入站槽位与`submitworker`供应商槽位或`upstream`供应商窗口合并成同一并发计数。
+- V4供应商结果异步边界只归`gateway/internal/resultoutbox/`治理：`upstream`在每个真实分片SubmitResp后只调用持久化接口，`submitworker`只负责聚合结果入Outbox与命令ACK的原子边界，Outbox回调Worker独立控制API并发和PEL恢复。API的`SmsSubmitRecord.resultEventId`是跨重启持久幂等事实；不得把HTTP回调重新放回供应商连接池或Submit工作槽，也不得让Outbox承担业务计费、补发或状态机判断。
 - `api/src/infrastructure-monitoring/`是运营端监控聚合与固定阈值应用边界：只消费代码白名单 PromQL，并通过版本化 PostgreSQL 单例、promtool 校验和原子规则热加载管理数值阈值；Exporter安装、端口隔离、固定规则模板和权限仍归`tools/monitoring/`治理。
 - 活动告警已读也归该边界：Prometheus保留告警事实，Prisma仅持久化逐管理员、逐触发周期的阅读状态；全局布局只消费轻量未读汇总，不复制指纹、activeAt或用户隔离逻辑。
@@ -0,0 +1,24 @@
+{
+  "schemaVersion": "v1",
+  "eventId": "submit:submit-20260820-0001:aggregate",
+  "eventType": "submit_result",
+  "path": "/gateway/events/submit-result",
+  "traceId": "trace-20260820-0001",
+  "messageId": "message-20260820-0001",
+  "channelId": "channel-test-1",
+  "submitId": "submit-20260820-0001",
+  "payload": {
+    "eventId": "submit:submit-20260820-0001:aggregate",
+    "schemaVersion": "v1",
+    "messageType": "SubmitResult",
+    "traceId": "trace-20260820-0001",
+    "messageId": "message-20260820-0001",
+    "channelId": "channel-test-1",
+    "createdAt": "2026-08-20T05:00:00Z",
+    "sequenceId": 1,
+    "gatewayMessageId": "1000000000000001",
+    "submitStatus": "accepted",
+    "submittedAt": "2026-08-20T05:00:00Z"
+  },
+  "createdAt": "2026-08-20T05:00:00Z"
+}
@@ -6,7 +6,8 @@
    { "$ref": "#/$defs/SubmitCommand" },
    { "$ref": "#/$defs/SubmitResult" },
    { "$ref": "#/$defs/ReceiptEvent" },
-    { "$ref": "#/$defs/UplinkEvent" }
+    { "$ref": "#/$defs/UplinkEvent" },
+    { "$ref": "#/$defs/SubmitResultOutboxEvent" }
  ],
  "$defs": {
    "Envelope": {
@@ -139,6 +140,26 @@
        }
      ]
    },
+    "SubmitResultOutboxEvent": {
+      "type": "object",
+      "required": ["schemaVersion", "eventId", "eventType", "path", "messageId", "channelId", "submitId", "payload", "createdAt"],
+      "properties": {
+        "schemaVersion": { "const": "v1" },
+        "eventId": { "type": "string", "pattern": "^submit:.+:(aggregate|segment:[1-9][0-9]*)$" },
+        "eventType": { "enum": ["submit_result", "submit_segment_result"] },
+        "path": { "enum": ["/gateway/events/submit-result", "/gateway/events/submit-segment-result"] },
+        "traceId": { "type": "string" },
+        "messageId": { "type": "string", "minLength": 1 },
+        "channelId": { "type": "string", "minLength": 1 },
+        "submitId": { "type": "string", "minLength": 1 },
+        "payload": {
+          "type": "object",
+          "required": ["eventId"],
+          "properties": { "eventId": { "type": "string", "minLength": 1 } }
+        },
+        "createdAt": { "type": "string", "format": "date-time" }
+      }
+    },
    "ReceiptEvent": {
      "allOf": [
        { "$ref": "#/$defs/Envelope" },
@@ -17,7 +17,7 @@
    {
      "name": "handleSubmitResult",
      "file": "send-gateway-result.service.ts",
-      "bodySha256": "6184170748eb3934496b060ea3b6704f1d1a831e7ffde7e7f8b73a7c223a869c"
+      "bodySha256": "9414f8d4e5e1c3cf6d0747e47ce01e101e142772af4f56900932bc6d4ac11ec7"
    },
    {
      "name": "resolveSubmitRecordForGatewayResult",
@@ -173,7 +173,7 @@
      "name": "Manager",
      "kind": "type",
      "file": "manager.go",
-      "sha256": "c7ead8b037bc87ad9800650ce191f5fcee9648b8805a133b9506743c762ea608"
+      "sha256": "b08726201c34da87ae735abd7fc56d2b904104d4b7f6a6a6365263ec5b0a43bc"
    },
    {
      "name": "defaultChannelConnectionID",
@@ -389,7 +389,7 @@
      "kind": "func",
      "receiver": "Manager",
      "file": "submit.go",
-        "sha256": "a25d30aeb87c1fe123929330fdabc99261e63d5b51e1cb6207197c43a15de07d"
+        "sha256": "9be92b0d32626ce93d0b2d721bf008305c4b9e5919e287d49b91c6f2474ddeb1"
    },
    {
      "name": "submitPart",
@@ -410,7 +410,7 @@
      "kind": "func",
      "receiver": "connectionPool",
      "file": "submit.go",
-        "sha256": "e3dbf2d433ef4ff95b2fe7a8494b17c6a8e185bdace017cce9c7d2e8c785bfb3"
+        "sha256": "577b7f942f4b95ea3868d7cf9aadae800df8edda0e7ca94a205b4124be58e9e3"
    },
    {
      "name": "defaultInt",
@@ -240,6 +240,7 @@
 9. Gateway 必须按通道连接和窗口容量控制并发，处理窗口满、SMSC 慢响应、sequence 回绕、连接断开时的在途消息状态。
 10. Gateway 必须对每个物理通道执行 Redis 分布式 TPS 限速。`SmsChannel.rateLimitPerSecond` 是单通道上限，不是平台总上限；同一通道被多个通道组或多个 Gateway 实例使用时共享同一额度，不同通道独立计数。通道连接命令下发的配置值是最终上限，提交命令携带的值只能进一步降低、不能放大该上限。超流速消息必须继续保留在 Redis Stream pending 中等待可用时隙，不能因等待直接标记发送失败；Gateway 重启后仍可由 consumer group 恢复。worker 必须使用持续补位的全局有界工作池，任一任务完成后立即领取后续消息，不得以“读取10条、等待整批结束”形成批次屏障；每条消息只在自身提交结果已持久回传或完成死信处理后独立`XACK`。全局并发默认64、可由`GATEWAY_SUBMIT_WORKER_CONCURRENCY`配置且上限1024；单通道实际并发仍由 Redis 限速、连接数和 CMPP 窗口共同约束。恢复pending时必须防止超过`MinIdle`的在途消息被同一进程重复提交。
 11. Gateway 不承担业务审核、计费、签名报备、通道组路由、黑名单或敏感词判断；这些由 NestJS 完成，Gateway 只执行已授权通道提交与协议事件回传。
+12. 供应商SubmitResp及长短信分片结果必须先进入共享Redis的幂等Outbox，再由独立有界回调Worker异步上报API；供应商Submit工作槽只等待连接窗口、限速和真实供应商往返，不得等待API结果回写。每个分片结果必须在继续发送下一分片前写入Outbox；聚合结果入Outbox与原`gateway.submit.commands`消息`XACK`必须原子完成。事件ID按submitId和分片序号确定生成，重复发布不得产生第二个事件；API必须按事件ID持久幂等，重复回调不得重复扣费、释放余额、补发或推进状态。回调失败保留在Outbox PEL并可在进程重启后恢复，成功后逐条ACK并删除；去重键和并发必须有界配置，不得形成无限内存或Stream归档。

 #### 4.8.2 下游客户 CMPP 接入能力

@@ -2100,6 +2101,7 @@
 - Gateway供应商下发必须分别记录`stream_wait/rate_limit_wait/connection_wait/supplier_rtt/api_callback`；其中`supplier_rtt`只覆盖供应商连接上的Submit请求与SubmitResp往返，不得包含结果回写API的耗时。阶段名和结果值必须使用代码固定白名单，不得添加手机号、企业、应用、通道、消息、任务或连接ID标签。
 - V2有界工作池必须暴露配置槽位数和当前在途槽位数，使用固定`state=configured|in_flight`标签；该指标用于区分Worker容量耗尽与供应商窗口/限速等待，不得增加通道或消息标签。
 - V3入站并发必须只并发Submit业务处理，连接认证保持串行先完成，心跳和Deliver ACK不得被长耗时Submit阻塞；每个SubmitResp继续使用原请求Sequence_Id关联，允许按实际完成顺序返回。同一连接关闭时必须先等待已接受的在途处理收尾，再清理会话和回执映射，避免迟到处理重新注册已断开的连接。`cmpp_gateway_inbound_submit_slots{state=configured|in_flight}`只暴露全部在线连接的聚合窗口与在途数量，不得增加账号、应用、连接或消息标签。
+- V4结果Outbox必须暴露独立回调Worker的configured/in_flight槽位和Outbox pending/lag，仍只使用固定状态标签。`api_callback`从V4起只在Outbox回调Worker计时，不再混入供应商Submit工作槽；压测结束必须同时核对命令Stream和结果Outbox均`pending=0/lag=0`，并证明API回调故障时供应商槽继续释放、结果不丢失且恢复后只处理一次。
 - 系统监控标题说明必须明确标注数据来自 Prometheus；“服务关键指标”位于趋势/核心服务区域之后、活动告警之前，并提供统一的“告警阈值设置”入口。安全检测页不重复渲染大号标题，说明文字必须明确标注使用 Fail2ban。
 - 告警阈值仅开放固定指标的警告/严重数值，不允许前端提交 PromQL、标签、文件路径或持续时间；必须满足警告值小于严重值。配置以 PostgreSQL 保存版本、期望值、生效值和应用状态，经 `promtool check rules` 校验、同目录原子替换和 Prometheus 热加载成功后才标记生效，失败保留上一生效规则并展示原因。
 - 右上角预警中心增加“系统监控告警”，通过独立轻量接口统计 Prometheus 当前 firing/pending 告警及严重数，跳转系统监控活动告警区；任一预警域失败不得清空其他域。
@@ -61,6 +61,10 @@ CMPP_PUBLIC_HOST=8.160.169.106
 CMPP_PUBLIC_PORT=17890
 GATEWAY_STARTUP_RECONNECT_DELAY_MS=1000
 GATEWAY_SUBMIT_WORKER_CONCURRENCY=64
+GATEWAY_SUBMIT_RESULT_STREAM=gateway.submit.results
+GATEWAY_SUBMIT_RESULT_GROUP=cmpp-api-callback
+GATEWAY_SUBMIT_RESULT_CONSUMER=gateway-1
+GATEWAY_SUBMIT_RESULT_WORKER_CONCURRENCY=8
 GATEWAY_CMPP_INBOUND_MAX_CONCURRENCY=64
 OBJECT_STORAGE_DRIVER=minio
 OBJECT_STORAGE_LOCAL_ROOT=/var/lib/cmpp-platform/object-storage
@@ -85,6 +89,8 @@ Gateway 的最终 TPS 防线依赖与 API 相同的 Redis。通道连接时会

 V3起客户CMPP入站Submit按应用`cmppWindowSize`在单连接内受限并发，全局上限`GATEWAY_CMPP_INBOUND_MAX_CONCURRENCY`缺省64、最大1024。发布后必须先以已认证测试连接确认`cmpp_gateway_inbound_submit_slots{state="configured"}`等于应用有效窗口，再执行阶梯压测；不得通过调高全局值绕过应用窗口，也不得在未验证Sequence_Id关联、心跳/ACK活性和断线清理时直接提高生产并发。

+V4起供应商分片和聚合结果写入`gateway.submit.results`幂等Outbox，由默认8槽、最大1024的独立回调Worker上报API。聚合结果XADD与原命令XACK由Redis Lua原子执行；回调成功后结果事件XACK+XDEL，失败事件留在PEL。发布时必须保留同一Redis数据和AOF，不得清理`gateway.submit.results`、其consumer group或`gateway.submit.results:dedupe:*`；调整`GATEWAY_SUBMIT_RESULT_WORKER_CONCURRENCY`前须核对API/PostgreSQL承载能力。第91条向前兼容migration增加`SmsSubmitRecord.resultEventId/resultProcessedAt`，用于回调跨重启幂等，不删除历史字段或数据。
+
 服务重启顺序必须是 Gateway 在前、API 在后。API 启动后等待 `GATEWAY_STARTUP_RECONNECT_DELAY_MS`（默认 1 秒），从 PostgreSQL 读取全部 active 通道并重新下发真实连接命令，同时恢复 Gateway 内存连接池和 Redis 权威 TPS key；禁止沿用数据库中重启前的 connected 状态冒充当前连接。

 日报任务默认启用，并由 `REPORT_REFRESH_INTERVAL_MS` 每小时检查一次北京时间业务日是否变化；每个业务日只执行一次 T-4 至 T-1 重算。服务重启后也会自动补跑最近四个完整自然日，确保 72 小时回执更新反映到对账和利润报表。
@@ -145,9 +151,10 @@ curl http://127.0.0.1:8090/health
 curl http://127.0.0.1:12026/
 redis-cli -h 127.0.0.1 -p 6379 ping
 pg_isready -d "$(grep '^DATABASE_URL=' /etc/cmpp-platform/cmpp-platform.env | cut -d= -f2-)"
-grep -E '^(API_ENABLE_SEND_WORKER|API_SEND_WORKER_CONCURRENCY|GATEWAY_SUBMIT_WORKER_CONCURRENCY|GATEWAY_CMPP_INBOUND_MAX_CONCURRENCY)=' /etc/cmpp-platform/cmpp-platform.env
+grep -E '^(API_ENABLE_SEND_WORKER|API_SEND_WORKER_CONCURRENCY|GATEWAY_SUBMIT_WORKER_CONCURRENCY|GATEWAY_SUBMIT_RESULT_WORKER_CONCURRENCY|GATEWAY_CMPP_INBOUND_MAX_CONCURRENCY)=' /etc/cmpp-platform/cmpp-platform.env
 redis-cli --scan --pattern 'rate:gateway:channel:*'
 redis-cli XINFO GROUPS gateway.submit.commands
+redis-cli XINFO GROUPS gateway.submit.results
 ```

 ## 回滚
@@ -4682,6 +4682,14 @@ npm run verify:phase8
 | TC-CMPP-PERF-V3-004 | 断线在途清理 | Submit进入API后由客户端断开TCP，随后让API处理完成 | Gateway等待已接受处理收尾后再执行连接关闭回调；会话、Submit barrier和消息映射最终清理，不重新出现幽灵连接，不发生panic |
 | TC-CMPP-PERF-V3-005 | 入站槽位聚合指标 | 建立不同窗口的测试连接并制造部分在途Submit后抓取metrics | `cmpp_gateway_inbound_submit_slots`的configured等于在线连接有效窗口合计、in_flight等于当前业务处理数；只有固定state标签 |
 | TC-CMPP-PERF-V3-006 | V3阶梯容量复测 | 在与V2相同的隔离真实后端/数据库/Redis/供应商模拟器中执行10、20、30、40、50条/秒各60秒 | 与V2按同口径比较SubmitResp P50/P95/P99、API阶段、Stream pending/lag、供应商吞吐和资源；遇P95超过5秒、持续积压或服务异常立即停止，未执行档位不记为通过 |
+| TC-CMPP-PERF-V4-001 | 分片结果幂等入Outbox | 对同一submitId和segmentIndex重复发布两次分片结果 | `gateway.submit.results`只新增一个确定性eventId事件；下一分片仅在前一分片Outbox写入成功后发送 |
+| TC-CMPP-PERF-V4-002 | 聚合结果与命令ACK原子性 | 让供应商返回成功，在聚合结果写入与命令ACK边界注入Redis失败并重启Gateway | 不存在“命令已ACK但结果Outbox缺失”状态；重试同一发布脚本不会产生重复聚合事件 |
+| TC-CMPP-PERF-V4-003 | API回调不占供应商槽 | API submit-result接口延迟10秒，同时持续让供应商快速返回SubmitResp | 供应商Worker槽在结果写入Outbox后立即释放；API延迟只增加独立回调Worker和Outbox积压，不降低供应商Submit槽可继续补位的能力 |
+| TC-CMPP-PERF-V4-004 | 回调失败恢复与逐条ACK | 结果回调第一次返回503，随后恢复201并重启回调Worker | 失败事件保留PEL且未删除；恢复后重新投递，成功时单事件原子ACK+删除，其他事件不受整批等待 |
+| TC-CMPP-PERF-V4-005 | API持久幂等 | 对同一聚合eventId重复回调两次，并检查提交记录、计费、余额、重试和任务进度 | `SmsSubmitRecord.resultEventId`只记录一次；第二次直接返回当前结果，不重复扣费、释放、补发或推进状态；不同eventId占用同一submit尝试时拒绝 |
+| TC-CMPP-PERF-V4-006 | Outbox有界指标 | 制造回调在途和积压后抓取Gateway metrics | 回调Worker configured/in_flight与真实槽位一致，Outbox pending/lag与Redis consumer group一致，指标不含手机号、消息、submit、企业、应用或通道标签 |
+| TC-CMPP-PERF-V4-007 | 双Stream发布后排空 | 完成一档隔离压测并等待异步处理结束 | `gateway.submit.commands`和`gateway.submit.results`均为`pending=0/lag=0`，结果Outbox成功事件已删除，无Gateway Submit死信；数据库业务数与客户端完全一致 |
+| TC-CMPP-PERF-V4-008 | V4阶梯容量复测 | 在V3相同隔离供应商模拟器与真实API/PostgreSQL/Redis/Gateway中依次执行10、20、30、40、50条/秒各60秒 | 对比V3的SubmitResp分位、供应商RTT、命令Stream、结果Outbox、API阶段和资源；任一档出现拒绝、连接错误、P95超过5秒、双Stream持续增长或服务异常立即停止升档 |
 | TC-GLOBAL-ALERT-001 | 铃铛分域预警菜单 | 准备签名清退未读消息和安全待处置告警后点击右上角铃铛 | 弹层分开显示“签名清退预警”和“安全检测与封禁”，分别展示真实数量和摘要，角标等于两项之和 |
 | TC-GLOBAL-ALERT-002 | 预警菜单跳转 | 分别点击铃铛中的两个菜单项 | 签名项跳转`/admin/signature-retirement`，安全项跳转`/admin/security-detection`，弹层关闭且对应页面读取真实后端数据 |
 | TC-GLOBAL-ALERT-003 | 域间故障隔离与轻量轮询 | 分别让一个汇总接口失败并观察30秒轮询请求 | 失败域显示0且另一域数据保留；安全预警使用专用汇总接口，不调用完整overview、规则、代理状态或告警大列表 |
@@ -3747,3 +3747,17 @@ git diff --check
 - 优先级隔离仍未通过：40条/秒priority P95约3912ms、normal P95约3911ms，且两次SubmitResp拒绝都发生在priority连接；全部5996条均为mobile，联通/电信及六通道容量仍待号段识别修复后测试。原始目录名继续沿用既有`lg-v2-*`脚本标签，但被测运行标识和代码均为V3修复版，正式结论以运行标识为准。
 - V3回归已通过Gateway全量`go test ./... -count=1`、`go vet ./...`、项目内gocmpp测试/vet、API TypeScript正式编译、真实隔离Redis上的SendChain 113/113、4份Stream契约、R6 102声明/14项关键测试、R7、SendChain R10及`git diff --check`。Linux测试机补跑`-race`时因网络无法下载仅供测试的`miniredis`和`golang.org/x/text`依赖而阻塞，未伪报通过，也未伪造外部依赖。
 - 本轮只使用隔离供应商模拟器，没有发送、补发或重投真实短信，没有修改通道账号、密码、启停状态、企业余额或客户连接。`api/tsconfig.build.tsbuildinfo`、`tsconfig.tsbuildinfo`、`outputs/`、`pnpm-lock.yaml`和空文件`=`继续作为受保护项排除提交。
+
+# 2026-08-20 CMPP压测优化V4：供应商结果幂等Outbox、测试环境发布与阶梯复测
+
+- V4将供应商分片结果和聚合结果先写入Redis Stream `gateway.submit.results`，API回调由独立持续有界工作池执行，供应商Submit工作槽不再等待API往返。分片事件ID为`submit:<submitId>:segment:<index>`，聚合事件ID为`submit:<submitId>:aggregate`；Lua脚本保证分片去重键与XADD原子、聚合XADD与原命令XACK原子、成功回调XACK与XDEL原子。失败事件保留在PEL并由`XAUTOCLAIM`恢复，回收阈值30秒高于10秒HTTP超时，避免多Gateway实例在回调仍执行时并发重领。
+- 第91条向前兼容migration `20260820130000_add_submit_result_idempotency`为`SmsSubmitRecord`增加唯一可空`resultEventId`和`resultProcessedAt`。API重复收到同一已完成事件直接返回当前消息，冲突事件ID拒绝；测试覆盖重复回调不重复计费、重试或下游业务副作用。新增第5类Gateway队列契约示例，Outbox指标覆盖回调Worker槽位和结果Stream pending/lag。
+- 本地验证通过：Gateway全量`go test ./... -count=1`及`go vet ./...`，API 42套/483项断言全部通过，API与前端TypeScript正式编译、Vite生产构建、5份队列契约、R0/R6/R7及SendChain R10结构门禁、`git diff --check`均通过。全量Jest在断言完成后仍因仓库既有异步句柄不自行退出，本轮未把人工终止后的进程伪报为完整退出码0；使用本机真实Redis补跑，不伪造外部依赖。
+- 仅发布到`100.93.204.60`虚拟机测试环境；预生产`8.160.169.106`只读复核标识保持`433b2ee56f6016ad8afff1bac73f510b8fd53083+gateway-v2.cd7bb8d05e7b`，未发布、未回退、未压测。测试环境发布前恢复资产位于`/opt/cmpp-platform-backups/v4-20260820T052241Z`，包含PostgreSQL自定义格式备份、运行源码、环境和systemd配置；`pg_restore --list`、源码tar可读性及`SHA256SUMS`全部通过。
+- 最终运行包`outputs/cmpp-v4-runtime-final-20260820-141323.tar.gz`共827项、1641927字节，本地与测试机SHA-256均为`a63885439ed53d53a3a012048d5fd1a9aa67772503fd778ec510ec6a38a9944f`，排除依赖、构建产物、`outputs`、`*.tsbuildinfo`、`pnpm-lock.yaml`和空文件`=`。测试环境运行标识为`485af688d21ee0bdb98281f4c20d151d69f7889f+workspace.v4.a63885439ed5`；第91条migration仅应用一次，API、Gateway、安全代理、MinIO、PostgreSQL和Redis健康，最终供应商连接6/6，两条Stream均`pending=0/lag=0`。
+- 首轮默认32槽10条/秒恰逢重启积压回执回放，599/599受理但回执2536、P95=3294ms；积压排空后再测仍为P95=671ms。把测试配置收敛为8槽后，10条/秒599/599、P50/P95/P99=`39/146/304ms`、回执603。基于该对照，代码、示例环境和发布文档的默认值同步改为8；32槽不作为推荐配置。
+- 8槽正式阶梯结果：20条/秒1199/1199受理、P50/P95/P99=`45/1129/1259ms`；30条/秒1799/1799受理、`1081/1626/1885ms`；40条/秒2399/2399受理、`2049/2330/2386ms`。三档均无连接错误；相对V3，20/30/40条/秒P95分别由1427/2033/3912ms降至1129/1626/2330ms，且40条/秒从2条10秒超时改进为零拒绝，确认安全档位由30提升到40条/秒。
+- 解耦证据：20条/秒命令Stream未投递lag峰值0，结果Outbox峰值`pending=8/lag=242`后归零；30条/秒峰值约`pending=8/lag=1076`；40条/秒峰值约`pending=9/lag=1639`，压测结束后约36秒归零并连续保持0/0。40条/秒时供应商命令与结果回调已分开排队，结果回调积压不再占用供应商Submit槽；但Outbox回落时间已成为容量判定的一部分，不能只看客户SubmitResp。
+- 50条/秒触发停止线：因客户端背压只生成2790条而非约2999条，2787条成功、3条等待API满10秒后返回result=9，P50/P95/P99=`6765/7236/7789ms`，throttled ticks=3184。结束后命令Stream一度`pending=64/lag=489`、结果Outbox`pending=8/lag=1690`；命令约1分钟内、结果随后约20秒内归零。日志显示API饱和时协议遥测和连接状态回调超时，并暴露既有`CmppDownstreamConnection`创建/更新的P2002/P2025竞态；未出现`resultEventId`唯一键冲突或Outbox事件失败。停止后未继续上探。
+- 整个窗口客户侧共9984条业务提交，真实PostgreSQL按`queuedAt`精确新增9984条；窗口内7922条实际供应商提交记录全部具有非空且互不重复的`resultEventId`，重复事件组0、Gateway Submit死信0。提交结果为accepted 7392、rejected 147、timeout 383；客户有限回执收集窗口和重连积压回执不替代数据库/Stream对账。最终确认40条/秒为当前测试环境安全档，50条/秒瓶颈转为API/数据库同步入站及遥测争用，后续应继续V1的重复查询/零散写入合并和P1分阶段指标分析。
+- 本轮只连接隔离供应商模拟器`100.91.249.119:17900`，没有发送、补发或重投真实短信，没有修改真实通道账号、密码、启停状态、企业余额或客户连接。压测原始目录沿用既有`lg-v2-*`名称，但被测运行标识与结论均为V4；完整V4报告保存在短信平台测试项目。受保护的`api/tsconfig.build.tsbuildinfo`、`tsconfig.tsbuildinfo`、`outputs/`、`pnpm-lock.yaml`和空文件`=`继续排除提交、不删除、不归因。