docs: record CMPP phase three pressure results

This commit is contained in:
hectorzhao
2026-08-21 09:56:31 +08:00
parent 52028b9bbd
commit 0176aa6952
2 changed files with 11 additions and 0 deletions
+2
View File
@@ -4713,6 +4713,8 @@ npm run verify:phase8
| TC-CMPP-PERF-P3-005 | 三表与队列崩溃恢复 | 在三表提交后、BullMQ发布前注入失败并重领 | 任务/API请求/消息不重复,稳定MessageId对应唯一消息;以MessageId Job ID补入队后Inbox独立完成 | | TC-CMPP-PERF-P3-005 | 三表与队列崩溃恢复 | 在三表提交后、BullMQ发布前注入失败并重领 | 任务/API请求/消息不重复,稳定MessageId对应唯一消息;以MessageId Job ID补入队后Inbox独立完成 |
| TC-CMPP-PERF-P3-006 | 异常与付费回退 | 覆盖正单价、黑名单、非法号、人工审核、引流歧义和已有消息 | 全部走原逐条状态机,余额冻结和回执语义不变;不得进入零计费批量快路径 | | TC-CMPP-PERF-P3-006 | 异常与付费回退 | 覆盖正单价、黑名单、非法号、人工审核、引流歧义和已有消息 | 全部走原逐条状态机,余额冻结和回执语义不变;不得进入零计费批量快路径 |
| TC-CMPP-PERF-P3-007 | 500条/秒阶梯 | 在100.93.204.60依次执行smoke、100/200/300/500并逐级检查数据库、Redis和日志 | 任一级拒绝、缺响应、持续积压、锁等待或对账不一致立即停止;分别报告入口、Inbox完成和完整供应商链速率,不用积压冒充吞吐 | | TC-CMPP-PERF-P3-007 | 500条/秒阶梯 | 在100.93.204.60依次执行smoke、100/200/300/500并逐级检查数据库、Redis和日志 | 任一级拒绝、缺响应、持续积压、锁等待或对账不一致立即停止;分别报告入口、Inbox完成和完整供应商链速率,不用积压冒充吞吐 |
执行记录(2026-08-21):`TC-CMPP-PERF-P3-001/002/003/004/005`已通过本地专项和测试机正常批次对账;`006`保留既有逐条回归通过,正单价吞吐未外推;`007`的smoke通过,100条/秒入口及Inbox对账通过,但命令Stream在注入结束时`pending=128/lag=922`且完整下游排空约87秒,按停止线判完整链失败并停止200/300/500档。
## Fail2ban 安全检测与人工封禁测试矩阵(2026-08-14) ## Fail2ban 安全检测与人工封禁测试矩阵(2026-08-14)
- 本模块必须执行 `docs/fail2ban-assisted-blocking-test-cases-20260814.md` 中 TC-F2B 全量用例,专项用例是本平台功能测试的组成部分,不是可选附录。 - 本模块必须执行 `docs/fail2ban-assisted-blocking-test-cases-20260814.md` 中 TC-F2B 全量用例,专项用例是本平台功能测试的组成部分,不是可选附录。
+9
View File
@@ -3824,3 +3824,12 @@ git diff --check
- 当前实现把Worker按默认64条组成有界业务批次:批次共享应用、模板、签名、黑名单、风控规则和敏感词只读快照;日限额按applicationId固定顺序锁定并为每条请求写独立预留;唯一号码频控按应用在短事务批量更新并逐条持久化决定;正常零计费单号码的任务、API请求和消息三表在一个短事务批量创建,再以MessageId作为BullMQ Job ID批量入队和逐条结算Inbox。 - 当前实现把Worker按默认64条组成有界业务批次:批次共享应用、模板、签名、黑名单、风控规则和敏感词只读快照;日限额按applicationId固定顺序锁定并为每条请求写独立预留;唯一号码频控按应用在短事务批量更新并逐条持久化决定;正常零计费单号码的任务、API请求和消息三表在一个短事务批量创建,再以MessageId作为BullMQ Job ID批量入队和逐条结算Inbox。
- 正单价、同号重复、业务拒绝、人工审核、歧义匹配、既有消息和其他异常保留原逐条状态机。批量路径任一步失败会使用稳定日限/频控键、确定性任务号/请求号、MessageId和队列Job ID逐条恢复;Redis发布不包在数据库事务中。新增固定阶段`worker_claim/reference_preload/daily_quota`并保留`risk_frequency/message_persist/queue_publish` - 正单价、同号重复、业务拒绝、人工审核、歧义匹配、既有消息和其他异常保留原逐条状态机。批量路径任一步失败会使用稳定日限/频控键、确定性任务号/请求号、MessageId和队列Job ID逐条恢复;Redis发布不包在数据库事务中。新增固定阶段`worker_claim/reference_preload/daily_quota`并保留`risk_frequency/message_persist/queue_publish`
- 当前本地API正式TypeScript编译通过;RiskReview、PhoneFrequency、SendChain专项3套145项通过。尚未提交、建立本次恢复资产、部署或压测;后续结果必须按smoke→100→200→300→500停止线补记,且零计费批量结果不得外推为付费链路吞吐。 - 当前本地API正式TypeScript编译通过;RiskReview、PhoneFrequency、SendChain专项3套145项通过。尚未提交、建立本次恢复资产、部署或压测;后续结果必须按smoke→100→200→300→500停止线补记,且零计费批量结果不得外推为付费链路吞吐。
- 第三阶段代码提交`52028b9bbdea20f0cd02efe792e91b558ba50be9`,未推送。API全量42套495项、Prisma validate/generate、API与前端正式构建、Gateway全量test/vet、5份Stream契约、安全/部署门禁、R0/R6/R7/R10、Bash语法和`git diff --check`通过;R8/R9分别被HEAD既有且本轮未修改的`GatewayInboundSubmitDto``dispatchDueScheduledTasks`契约漂移阻断,没有为通过门禁吸收无关历史。
- 本次测试环境恢复资产位于`/opt/cmpp-platform-backups/p3-20260821T014531Z-before-batch-worker`PostgreSQL custom dump 96897546字节、运行源码189193980字节、环境/systemd/Nginx/Prometheus配置包23127字节,全部0600`pg_restore --list`、两份tar读取和`SHA256SUMS`全部通过,恢复说明明确Gateway→API→Worker启动顺序。精确发布包2441194字节,本地/服务器SHA-256均为`7c14cd5f197a0fa049748bea44b9a99b28f2ca1b5a23c4d6bce4ec8f22f1f9eb`
- 首次发布在Prisma输出Unicode勾号时,本地Windows GBK日志转发进程异常关闭SSH通道,远端失败保护自动恢复原运行目录、环境和服务;恢复后标记仍为`f456047...p2fix`且三服务/健康检查正常,失败目录保留为`/opt/cmpp-platform.failed-p3-20260821T014701Z`。改用UTF-8二进制日志后复用同一已校验包成功发布;当前标记`52028b9b...+workspace.p3.7c14cd5f197a`,上一运行目录`/opt/cmpp-platform.previous-p3-20260821T014803Z`92条migration无待应用项。
- 发布后API/Worker/Gateway/PostgreSQL/Redis/Nginx/Prometheus全部active,批处理显式启用、批次64、Worker槽96、API/Worker池48/32;数据库7连接、无未授予锁/idle in transactionInbox和双Stream初始排空。隔离供应商模拟器健康且6条连接在线,未连接或修改预生产。
- smoke使用新前缀`1380010`:1条/秒10秒生成9条,9/9受理、零拒绝/节流/连接错误,P50/P95/P99=`30/71/71ms`;数据库9条消息、9个唯一MessageId,最终9条deliveredBullMQ与双Stream排空,Worker无warning,数据库无锁等待或idle in transaction。
- 100条/秒30秒使用新前缀`1380011`:生成2998条,2998/2998受理,零拒绝、零节流、零连接错误,P50/P95/P99=`28/71/181ms`。2998条Inbox全部completed,消息/唯一MessageId/任务/API请求/日限预留/频控预留均2998且任务号、请求号无重复;创建窗口29.954秒,最后一条创建后1.418秒完成,完成分布32个秒桶、平均93.69条/秒、P50/P95=`96.5/121`、最大124条/秒。批量阶段累计180次reference preload/日限批次、216次三表持久化/批量入队,证明不是逐条伪装。
- 100档注入结束时命令Stream`pending=128/lag=922`、结果Stream`pending=32/lag=31`,数据库瞬时`idle in transaction=3/waiting active=12/not-granted locks=7`;约25秒后数据库恢复0/0/0、双Stream恢复0/0。自开始至最终排空约87秒,按2998条折算完整下游约34.5条/秒,低于100条/秒;最终消息delivered2770、failed64、submitted164,隔离供应商本档累计提交尝试3281、accepted3226、rejected55、无回执69,错误0。
- 因100档下游队列在负载期持续增长且完整链不足100条/秒,严格按停止线没有执行200/300/500档。第三阶段结论:入口100条/秒和业务Inbox接近实时排空通过、相较第二阶段约57.5条/秒显著改善,但业务Worker500条/秒与完整链500条/秒均未证明;第四阶段仍需供应商六通道真实并行、发送链/回调独立工作池后再升档。测试应用单价为0,本结果不得外推正单价批量计费吞吐;正单价继续走已回归的逐条原子账务路径。
- 全程仅使用`100.93.204.60`测试环境和`100.91.249.119:17900`隔离供应商模拟器,没有发送、补发或重投真实短信,没有修改通道账号、密码、启停状态、企业余额或客户连接。预生产只读标记保持`433b2ee5...+gateway-v2.cd7bb8d05e7b`,未发布、未回退、未压测;受保护的`tsbuildinfo``outputs/``pnpm-lock.yaml`和空文件`=`继续排除提交、不删除、不归因。