perf: batch inbound workflows by tenant

2026-08-25 17:11:55 +08:00
parent d3ceeb1e16
commit 76e7c8c401
9 changed files with 184 additions and 25 deletions
@@ -2159,3 +2159,11 @@
 - Gateway拉取待投递回执必须按账号进程内单飞，API必须用FOR UPDATE SKIP LOCKED将pending原子领取为带租约的dispatching；未实际发送的领取必须无损释放，租约过期可恢复。SubmitResp后只能合并调度账号级刷新，不得每条并发扫描同一批pending记录。
 - API新建回执后的直推与Gateway恢复拉取必须共享同一dispatching + claimId所有权；直推未抢到记录时必须退出，不得与恢复路径各发一次。ACK超时定时器必须在ACK注册锁内完成指针赋值，避免极短截止时间下的竞态。
 - 2026-08-25修复后正价阶梯客户入口20/30/50/70/100/150/200 TPS均零拒绝、零节流、零连接错误；完整供应商首提在150/200冲击档分别约94.86/92.24 TPS，显示端到端容量天花板约95 TPS。二次直推领取修复后100 TPS正价复验为999/999、P95/P99=102/179ms、999次999个唯一首提在12.488秒完成（80.00 TPS），972条已形成终态回执的下游投递生命周期尝试次数恰为972、重复0、最大1。生产建议仍保留容量余量，建议限速70 TPS，不将客户SubmitResp受理200 TPS误作完整供应商TPS。
+
+## 单 Gateway 单企业工作流微批治理（2026-08-25）
+
+- 入站工作流按企业分组领取和执行：不同企业可以并行使用工作流槽位，同一企业的多个批次必须串行，保持账户冻结、日限额和频控的一致性边界；当前阶段不得通过增加Gateway实例规避该边界。
+- Worker领取前允许最多`API_INBOUND_WORKFLOW_BATCH_WAIT_MS`毫秒的有界聚合等待，默认40、合法范围0～250；目标批量由`API_INBOUND_WORKFLOW_TARGET_BATCH_SIZE`控制，默认32且不得超过`API_INBOUND_WORKFLOW_BATCH_SIZE`。等待仅在已有少量就绪记录时发生，空队列不得固定休眠。
+- 正在处理的企业必须从下一次领取候选中排除，避免同企业并发事务重新争抢账户锁；租约过期恢复、优先级/FIFO、`FOR UPDATE SKIP LOCKED`和逐请求幂等语义保持不变。
+- 原生SQL对Prisma的无时区时间列统一使用`NOW() AT TIME ZONE 'UTC'`，覆盖Submit Outbox领取、租约、发布、重试及关联消息更新时间，禁止用数据库会话时区污染时延审计。
+- 验收必须保持正价，分别执行单企业100/150 TPS和至少两个独立企业合计200 TPS，按非补发首次供应商Submit、回执、上行、计费、主备补发、业务拦截及全队列排空对账；触发拒绝、连接错误、持续积压、数据库异常或账务不一致立即停止。多Gateway P2不在本阶段范围。
@@ -507,3 +507,9 @@ API 必须返回逐事件结果，而不是只有整批成功或失败：
 5. 只有单Gateway资源被实测打满后才启动多Gateway P2。

 诊断还发现Outbox原生SQL使用`CURRENT_TIMESTAMP`，与Prisma UTC时间混用时会产生8小时审计偏差。该问题不影响本次吞吐和队列排空结论，但必须在下一次代码改造中统一为UTC并回归租约、重试和发布时延。
+
+## 15. 单企业工作流微批治理实施范围
+
+本轮只在单Gateway架构内处理95 TPS定向诊断暴露的工作流问题，不实施多Gateway P2。具体改造为：领取前最多等待40ms把小批合并到目标32条；按企业分组，不同企业并行、同企业各批串行；领取SQL排除正在执行的企业；Submit Outbox及关联消息的原生SQL时间统一为UTC。环境参数必须显式配置并由发布脚本校验，目标批量不得超过实际批次上限。
+
+发布验收保持应用单价325以及现有临时号段规则和白名单。先做单企业100/150 TPS，以确认原约95 TPS边界是否改善；再使用至少两个独立企业做聚合200 TPS，用于区分单企业账户一致性边界和平台总吞吐。所有档位都按非补发首次供应商Submit计算，并对账Submit、回执、上行、账务、主备补发、拦截规则与队列排空；停止条件沿用第五阶段，不以入口SubmitResp替代完整链路结论。
@@ -4881,3 +4881,7 @@ npm run verify:phase8
 | TC-CMPP-PHASE5-010 | API直推与Gateway恢复同时命中同一回执 | 仅抢到dispatching + claimId的路径发送；100 TPS正价实测972条终态回执对应972次下游ACK，重复0，最大尝试1 |
 | TC-CMPP-PHASE5-011 | claim未发送、租约过期和ACK定时器竞态 | SubmitResp屏障或客户离线时释放claim且不增加重试次数；过期dispatching可恢复；Linux go test -race ./internal/inbound通过 |
 | TC-CMPP-PHASE5-012 | 修复后正价容量与口径分离 | 20至200 TPS入口均无拒绝、节流或连接错误；999条100 TPS复验入口P95/P99 102/179ms，供应商首提80.00 TPS；150/200冲击档首提约95 TPS天花板，两种口径分开报告 |
+| TC-CMPP-PHASE5-013 | 同企业工作流串行与有界微批 | 同企业领取期间不再领取第二批；已有少量记录最多等待40ms聚合，目标32、上限64；优先级/FIFO、租约恢复和幂等不变 |
+| TC-CMPP-PHASE5-014 | 不同企业正价并行 | 至少两个独立企业合计200 TPS；各企业账户冻结串行且企业间并行，单价均为325，分别对账消息、账单、首提和最终状态 |
+| TC-CMPP-PHASE5-015 | Outbox UTC时间语义 | Asia/Shanghai数据库会话下领取、租约、发布、重试均写UTC无时区值；publishedAt-createdAt不再出现约8小时偏差 |
+| TC-CMPP-PHASE5-016 | 微批发布边界与停止线 | 仅单Gateway；分别验证单企业100/150与多企业200，发生拒绝、连接错误、持续积压、数据库异常或账务不一致立即停止 |