perf: batch CMPP inbound workflow processing

2026-08-21 09:44:51 +08:00
parent 57192b7586
commit 52028b9bbd
15 changed files with 662 additions and 7 deletions
@@ -1161,4 +1161,6 @@ global，不能错误归入client。`client-signature-*`、发送页、企业认
 - `api/src/infrastructure-monitoring/`是运营端监控聚合与固定阈值应用边界：只消费代码白名单 PromQL，并通过版本化 PostgreSQL 单例、promtool 校验和原子规则热加载管理数值阈值；Exporter安装、端口隔离、固定规则模板和权限仍归`tools/monitoring/`治理。
 - 活动告警已读也归该边界：Prometheus保留告警事实，Prisma仅持久化逐管理员、逐触发周期的阅读状态；全局布局只消费轻量未读汇总，不复制指纹、activeAt或用户隔离逻辑。
 - 500条/秒第二阶段仍限制在`send-inbound-entry`和既有进程容量边界：短短信用一个PostgreSQL CTE完成当前应用校验和Inbox写入；长短信继续走既有分片域。Worker可按一次领取批次预取应用快照，但不得引入跨批应用状态缓存，也不得把模板、风控、计费、路由状态塞回Gateway同步入口。
+- 500条/秒第三阶段继续留在`send-inbound-entry`编排边界，但将批次只读风控快照下沉到`RiskReviewService.evaluateTasksBatch`，将频控原子批量预留下沉到`PhoneFrequencyService.reserveBatch`。Inbox编排层只负责批次分组、日限额锁顺序、正常三表批量持久化、幂等入队与逐条租约结算；付费及异常状态机仍委托原单条路径，避免形成第二套计费/审核领域模型。
+- 批次锁顺序固定为：领取事务只锁Inbox后立即提交；日限额事务按applicationId排序锁`SmsApplicationDailyUsage`；频控按tenant/application分组且规则优先级顺序更新号码状态；三表事务不持有前两类锁，Redis/BullMQ发布永不位于数据库事务内。该顺序用于限制死锁面并允许单批失败后按每条稳定幂等键恢复。
 - 容量参数继续归进程组装层：Inbox业务槽、BullMQ发送槽、Gateway供应商槽和结果Outbox槽分别有界、分别观测。代码模块不得假定测试环境参数就是生产默认值；生产调优必须重新基于PostgreSQL连接预算、六通道TPS/窗口和回调承载证据。
@@ -2122,3 +2122,10 @@
 - 长短信仍在完整重组并完成既有校验后写Inbox，不为追求吞吐改写分片状态机。Inbox Worker每次领取后应按本批应用ID一次读取当前应用/企业/白名单快照，不能对同一批每条消息重复查应用；领取、实际业务处理和逐条完成仍保持原短事务与租约边界。
 - 测试环境可在PostgreSQL连接总预算内分别提高Worker业务槽、BullMQ发送槽、Gateway供应商槽及结果Outbox槽，但每个池必须显式有界，且总数据库连接须为运维保留余量。供应商真实TPS、连接数和窗口仍是硬上限，禁止用并发参数绕过单通道限速。
 - 第二阶段仍以“完整处理”验收：除500条/秒SubmitResp零拒绝、零缺失和延迟停止线外，还必须等待Inbox、BullMQ、命令Stream、结果Outbox与回执链排空，并按数据库业务记录、唯一MessageId、供应商尝试/接受和最终状态对账。入口达到500而全链排空速率不足500条/秒时必须明确判失败。
+
+## 完整处理500条/秒第三阶段：Inbox业务批处理与数据库竞争治理（2026-08-21）
+
+- Worker以`API_INBOUND_WORKFLOW_BATCH_SIZE`控制单次有界批次，仍用优先级/FIFO和`FOR UPDATE SKIP LOCKED`短事务领取；批次只共享当次读取的应用、模板、签名、黑名单、风控规则和敏感词快照，不得跨批缓存应用状态、余额、频控计数或日限额。
+- 正常单号码、零计费短短信允许走批量快路径：日限额按应用锁定并为每个Inbox请求写独立幂等预留，风控只共享只读输入，号码频控在同一事务批量更新状态并逐请求保存决定，任务/API请求/消息三表在一个短事务批量创建，BullMQ使用消息ID作为幂等Job ID批量入队。
+- 付费短信、重复号码、黑名单/格式拒绝、模板人工审核、引流匹配歧义、既有消息恢复及其他异常分支必须回到原逐条状态机；不得为压测降低计费、风控、频控、模板、签名或失败回执规则。批量路径在数据库提交后、队列发布前崩溃时，逐条恢复必须利用稳定任务号、请求号、MessageId和预留键补齐，不得重复计量或创建消息。
+- 批量Worker指标增加`worker_claim/reference_preload/daily_quota`固定低基数阶段，并继续记录`risk_frequency/message_persist/queue_publish`；配置必须显式启用批处理并使用正整数批次大小。验收仍以真实PostgreSQL、Redis、BullMQ和隔离供应商证据为准，不能用零计费压测结果外推付费链路吞吐。
@@ -154,7 +154,7 @@ 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_SUBMIT_RESULT_WORKER_CONCURRENCY|GATEWAY_CMPP_INBOUND_MAX_CONCURRENCY)=' /etc/cmpp-platform/cmpp-platform.env
-grep -E '^(CMPP_INBOUND_FAST_PATH_ENABLED|CMPP_INBOUND_WORKFLOW_WORKER_ENABLED|API_INBOUND_WORKFLOW_CONCURRENCY|API_INBOUND_WORKFLOW_POLL_INTERVAL_MS|API_INBOUND_WORKFLOW_STALE_SECONDS|API_DB_POOL_MAX|API_WORKER_DB_POOL_MAX|API_WORKER_METRICS_PORT)=' /etc/cmpp-platform/cmpp-platform.env
+grep -E '^(CMPP_INBOUND_FAST_PATH_ENABLED|CMPP_INBOUND_WORKFLOW_WORKER_ENABLED|API_INBOUND_WORKFLOW_CONCURRENCY|API_INBOUND_WORKFLOW_BATCH_ENABLED|API_INBOUND_WORKFLOW_BATCH_SIZE|API_INBOUND_WORKFLOW_POLL_INTERVAL_MS|API_INBOUND_WORKFLOW_STALE_SECONDS|API_DB_POOL_MAX|API_WORKER_DB_POOL_MAX|API_WORKER_METRICS_PORT)=' /etc/cmpp-platform/cmpp-platform.env
 systemctl is-active cmpp-api cmpp-send-worker cmpp-gateway
 curl -fsS http://127.0.0.1:9465/metrics | grep '^cmpp_worker_inbound_workflow_'
 redis-cli --scan --pattern 'rate:gateway:channel:*'
@@ -186,3 +186,4 @@ bash tools/deploy/production-deploy.sh
 - 环境必须显式启用`CMPP_INBOUND_FAST_PATH_ENABLED=true`、`CMPP_INBOUND_WORKFLOW_WORKER_ENABLED=true`，并给出正整数`API_INBOUND_WORKFLOW_CONCURRENCY`、`API_DB_POOL_MAX`和`API_WORKER_DB_POOL_MAX`；推荐初始值分别为32槽、API池32、Worker池8、轮询100ms、租约300秒。API systemd角色必须是`api`，Worker角色必须是`worker`；Worker可通过`API_WORKER_DATABASE_URL`使用独立地址，未配置时仍使用同一数据库地址但保持独立进程和有界连接池。发布前必须核对两池之和、其他服务连接与运维余量不超过PostgreSQL`max_connections`。
 - Worker日志目录归`cmpp-api:cmpp-security`且仅服务可写，9465只监听回环并加入Prometheus `cmpp-send-worker` target。发布后必须验证两进程均为非root、API/Gateway health、Worker metrics、PostgreSQL/Redis，以及Inbox pending/processing/最老等待可观测。
 - 回滚前先停止Gateway、API和Worker，保留故障现场Inbox及日志；如恢复旧数据库备份，必须同时恢复对应源码和环境/systemd资产。不得在回滚时删除pending Inbox或重投真实短信。
+- 第三阶段要求环境显式设置`API_INBOUND_WORKFLOW_BATCH_ENABLED=true`和正整数`API_INBOUND_WORKFLOW_BATCH_SIZE`，初始建议64且不得大于Worker业务槽的可解释倍数。批次增大前必须核对PostgreSQL参数数量、单事务持续时间、Worker RSS和租约时长；付费短信仍走逐条账务锁，不能用零计费批量结果替代付费链路验收。
@@ -4701,6 +4701,18 @@ npm run verify:phase8
 | TC-GLOBAL-ALERT-002 | 预警菜单跳转 | 分别点击铃铛中的两个菜单项 | 签名项跳转`/admin/signature-retirement`，安全项跳转`/admin/security-detection`，弹层关闭且对应页面读取真实后端数据 |
 | TC-GLOBAL-ALERT-003 | 域间故障隔离与轻量轮询 | 分别让一个汇总接口失败并观察30秒轮询请求 | 失败域显示0且另一域数据保留；安全预警使用专用汇总接口，不调用完整overview、规则、代理状态或告警大列表 |
 | TC-DEPLOY-NET-001 | API回环监听边界 | 使用标准生产环境启动API，执行`ss -lnt`并从LAN/Tailscale探测3000端口，同时经Nginx业务入口请求健康接口 | API仅监听`127.0.0.1:3000`，外部不能直连3000；Nginx入口仍正常返回真实API健康结果；部署静态门禁校验`API_HOST`默认值与启动参数一致 |
+
+## CMPP第三阶段业务批处理专项（2026-08-21）
+
+| 用例ID | 场景 | 步骤 | 预期 |
+| --- | --- | --- | --- |
+| TC-CMPP-PERF-P3-001 | 有界批次领取 | 制造priority/normal混合Inbox并并发启动两个Worker | 每次领取不超过配置批次/槽位，使用SKIP LOCKED，无重复领取；priority先于normal且类内FIFO |
+| TC-CMPP-PERF-P3-002 | 批次只读预加载 | 同批放入多应用、多内容正常短短信并统计SQL | 应用、模板、签名、黑名单、风控规则和敏感词按批读取，不逐短信重复；下一批重新读取应用状态 |
+| TC-CMPP-PERF-P3-003 | 日限额批量原子性 | 在剩余额度边界并发提交并重放相同请求键 | 使用量不超过上限；每条预留决定独立持久化，重放不重复递增，拒绝项走既有失败回执 |
+| TC-CMPP-PERF-P3-004 | 号码频控批量原子性 | 唯一号码批量提交、同号重复提交并模拟Worker崩溃重领 | 唯一号码批量更新；同号保留顺序语义并逐条处理；重领返回原决定，无穿透、重复计频或重复命中 |
+| TC-CMPP-PERF-P3-005 | 三表与队列崩溃恢复 | 在三表提交后、BullMQ发布前注入失败并重领 | 任务/API请求/消息不重复，稳定MessageId对应唯一消息；以MessageId Job ID补入队后Inbox独立完成 |
+| TC-CMPP-PERF-P3-006 | 异常与付费回退 | 覆盖正单价、黑名单、非法号、人工审核、引流歧义和已有消息 | 全部走原逐条状态机，余额冻结和回执语义不变；不得进入零计费批量快路径 |
+| TC-CMPP-PERF-P3-007 | 500条/秒阶梯 | 在100.93.204.60依次执行smoke、100/200/300/500并逐级检查数据库、Redis和日志 | 任一级拒绝、缺响应、持续积压、锁等待或对账不一致立即停止；分别报告入口、Inbox完成和完整供应商链速率，不用积压冒充吞吐 |
 ## Fail2ban 安全检测与人工封禁测试矩阵（2026-08-14）

 - 本模块必须执行 `docs/fail2ban-assisted-blocking-test-cases-20260814.md` 中 TC-F2B 全量用例，专项用例是本平台功能测试的组成部分，不是可选附录。
@@ -3817,3 +3817,10 @@ git diff --check
 - 仅在测试环境连接总预算内设置API/Worker池48/32、Inbox业务槽96、BullMQ发送槽96、Gateway Submit槽128、结果Outbox槽32和客户入站上限128；代码默认值未改变，PostgreSQL`max_connections=100`仍保留至少20条非业务池余量。修复后1条/秒低负载9/9受理、P95=41ms，Inbox与短信主记录均9条且MessageId唯一，双Stream归零。
 - 正式100条/秒30秒档生成2998条，2998/2998成功，零拒绝、零节流、零连接错误，P50/P95/P99=`34/79/128ms`；相较第一阶段100条/秒P95=147ms，合并SQL在更高Worker竞争下仍降低入口尾延迟。数据库2998条Inbox全部completed、2998条短信主记录及唯一MessageId完全对账，Inbox从首条创建至末条完成约52.1秒，折算约57.5条/秒。
 - 该档未通过“完整处理100条/秒”停止线：全部为移动号码并只走`LGST-M-P`主通道，最终产生3863次供应商尝试，其中accepted3118、rejected78、timeout667；回退通道接受846次。命令Stream和结果Outbox从首条接收至最终0/0约136秒，按2998条业务短信折算约22.0条/秒；最终消息delivered2797、failed70、submitted131。高峰期间API后台协议日志、连接状态和待投递查询出现超时，说明提高Worker/Outbox槽后共享API/数据库回调仍受争用。因100档完整链已经失败，按阶梯停止线没有继续200/500档，不能宣称完整500条/秒达标。
+
+## 2026-08-21 完整处理500条/秒第三阶段：业务Worker批处理与数据库竞争治理（实施中）
+
+- 接管复核：本地`HEAD=57192b7586b1e2c14f2edf0633d2d35936352879`、`origin/main=c4f36fc50d7906dfb2f97c881e9ea43c6a64c370`，ahead 15；测试环境标记`f4560479...+workspace.p2fix.51553e0d5555`，预生产标记`433b2ee5...+gateway-v2.cd7bb8d05e7b`。测试机API/Worker/Gateway/PostgreSQL/Redis/Nginx/Prometheus均active，92条migration、数据库6连接/无idle in transaction/无未授予锁，Inbox和双Stream均排空；预生产仅只读核验，未修改。
+- 当前实现把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`。
+- 当前本地API正式TypeScript编译通过；RiskReview、PhoneFrequency、SendChain专项3套145项通过。尚未提交、建立本次恢复资产、部署或压测；后续结果必须按smoke→100→200→300→500停止线补记，且零计费批量结果不得外推为付费链路吞吐。