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/窗口和回调承载证据。