192 lines
28 KiB
Markdown
192 lines
28 KiB
Markdown
# 签名退网检测与签名质量四页查询优化方案
|
||
|
||
维护日期：2026-09-17。状态：**本地实现及隔离验收完成，待发布**。用户于本轮授权修改并本地提交；没有授权本轮推送、部署、历史上行认领或真实短信/通知发送。第1节保留实施前取证；本轮实现与验收以第8节为准。
|
||
|
||
本文是本次三项需求的统一实施设计，补充[签名清退设计](signature-retirement-alert-design.md)。实施后替代该设计第6节、第7节第15步中“热力图直接读检测快照、按当前报备维度展示、前端筛选分页”的实现方式，以及[运营修复设计](operations-fixes-20260908.md)第4项中的客户端热力图分页；保留四TAB独立状态、默认25条、10/25/50/100档、D-1至D-30列序和原业务统计单位。现阶段旧代码仍在运行，不能把本方案描述为已上线功能。
|
||
|
||
本方案仅针对“签名质量检测”四TAB与签名退网检测，不改变“报表对账/发送质量报表”的既有T-4～T-1刷新任务，不改变短信门禁、补发、计费、余额或报备状态。
|
||
|
||
## 1. 核查结论与证据
|
||
|
||
### 1.1 基线
|
||
|
||
- 本地main与实际远端main均为`4eb7b16d122da14f921093716d4ca1ed390d9e4c`，暂存区空；已有版本、metrics、发布工具、部署脚本及文档草稿保留。
|
||
- 2026-09-17 09:37北京时间只读核验预生产运行`010ba3216889032a6160cdb14d8536b616ae7102`。上述两个提交间本方案涉及的页面、质量查询和退网检测源码没有差异。
|
||
- 证据：`src/apps/admin/AdminAnalyticsPage.tsx`、`src/api/admin/signature-retirement.api.ts`、`api/src/operations/queries/quality.queries.ts`、`api/src/signature-retirement/signature-retirement.service.ts`、对应controller及`api/prisma/schema.prisma`。
|
||
- 本机原始取证在忽略目录`.local-data/cpu-20260917/`：`prom.json`、`detail.jsonl`、`design-audit.json`及只读脚本。线上DB使用只读事务与8秒语句超时，未启动应用调度器。此次未执行登录后的四TAB真实浏览器/HTTP复测；以下交互结论来自当前源码，不冒称已复现浏览器串数据。
|
||
|
||
### 1.2 凌晨CPU与检测成本
|
||
|
||
今天检测日2026-09-17的结果从04:00:01.620写到04:04:07.792，共5,831条（企业1,431、通道4,400）。前一天4,280条。Prometheus五分钟CPU均值峰值58.79%，04:06:45为32.81%；04:06最近一分钟忙碌率约2.54%，趋势包含此前负载。日报刷新日志完成于00:33:09。
|
||
|
||
同窗口`SmsMessageRecord`与`SmsSubmitRecord`顺序扫描行速率峰值分别约362万、536万行/秒；这是数据库重复访问行的计数，不是短信量或TPS。IO等待较低。检测时段、真实快照与数据库扫描高度吻合，是主要负载线索；缺少历史业务进程CPU与SQL耗时采样，不能量化各进程占比或断言唯一原因。
|
||
|
||
现有`runDetection`逐个维度调用`activityCounts`：至少一次单日查询，完成观察期后再查一次规则窗口；每次关联消息、提交、分段/回执。已有检测是否存在的判断在这些计算之后的`persistDetection`中，重启补偿仍可能先重复计算再退出；周期、抑制、检测记录还存在逐行读写。现有唯一键保证部分去重，不等于任务已具备全程原子认领和完整事务恢复。
|
||
|
||
### 1.3 四TAB是否关联
|
||
|
||
| TAB | 当前请求与数据来源 | 当前关联/独立性 | 与目标的差距 |
|
||
|---|---|---|---|
|
||
| 签名通道发送质量 | `GET /admin/operations/signature-quality`；所有日期实时聚合消息、提交、分段与回执 | 独立日期、关键字、分页、请求序号；详情使用本TAB结果 | 历史也查明细，无近三天报表/冻结分支 |
|
||
| 企业签名活跃度 | `GET /admin/signature-retirement/heatmap?date=D` | 独立组件状态，但接口返回企业和通道全部数据，再在前端选企业、过滤、排序分页 | 使用次日检测快照而非可刷新的活动日报；行集合依赖当前通过任务 |
|
||
| 通道签名活跃度 | 同上 | 独立发起请求，但再次拉取相同两类数据，再在前端选通道 | 同上，整月全量传输和处理重复 |
|
||
| 未报备签名 | `GET /admin/signature-retirement/unreported-signatures`；所有日期查消息正文及当前有效签名库 | 独立日期、关键字、分页与结果 | 历史实时重算；补登记/删除签名会改变旧日期结果 |
|
||
|
||
结论：没有发现四TAB共用筛选状态或一个TAB直接改写另一个结果的实现；存在两个活跃度TAB共用全量接口与数据源，且活跃度展示依赖退网检测任务。底层业务事实本来有关联，不能为“页面独立”复制出四套互相矛盾的短信事实；应解除请求、状态、失败和生成触发之间的耦合。
|
||
|
||
另需同步修复的本TAB日期歧义：未报备TAB编辑顶部日期后，卡片内“查询”仍按`appliedDate`请求，须先点顶部“查询统计”才能应用新日期。这不是跨TAB串数据，但会造成查询条件似乎未生效。
|
||
|
||
### 1.4 三档取数规则当前未实现
|
||
|
||
质量与未报备页面全部日期实时查库；活跃度使用`SignatureRetirementDetection`快照，`persistDetection`已存在即返回，不会连续刷新最近三天。历史展示又拼接当前签名名称和当前报备维度，因此既不是完整的实时统计，也不是稳定冻结日报。
|
||
|
||
已有`DailyQualityReport`服务另一个报表模块，按计费单位统计，维度缺少本页完整的运营商、通道、引流拆分、去重业务数与到达耗时分子分母，不能直接拿来替代本页。既有财务/质量报表T-4～T-1策略也不自动等同本次要求。
|
||
|
||
## 2. 已确认业务规则
|
||
|
||
### 2.1 日期定义和数据来源
|
||
|
||
T始终指服务器按`Asia/Shanghai`确定的真实今天；D指页面所选日期；d指实际统计自然日，均不依赖浏览器所在时区。用户已确认：**每天凌晨同时刷新T-1、T-2、T-3；热力图保留所选日之前30天。**
|
||
|
||
| 实际统计日d | 查询行为 | 后台生成/更新 |
|
||
|---|---|---|
|
||
| d=T | 本次查询访问真实业务库，在一致性读视图中聚合 | 不将昨日缓存冒充当天数据，不写退网检测或通知 |
|
||
| T-3≤d≤T-1 | 只读已完整发布的日报 | 每天凌晨刷新最近三个完整自然日，吸收迟到回执 |
|
||
| d≤T-4 | 只读冻结日报 | 普通调度、页面查询、进程重启均不得自动重算或覆盖 |
|
||
|
||
例：今天9月17日，9月17日实时，9月14～16日报表可刷新，9月13日及以前冻结。9月18日可刷新范围成为9月15～17日；9月14日报表保留9月17日最后成功发布的版本，不在成为T-4后再额外重算。刷新判断相对真实今天，不能相对用户选择的历史日期重新开放冻结区。
|
||
|
||
热力图选D=9月17日仍展示9月16日至8月18日（D-1至D-30），没有当天列；每一列按该格子的d判断可刷新/冻结。单日质量与未报备TAB选今天时采用实时路径。禁止选择未来D来变相让热力图出现今天列。
|
||
|
||
冻结意味着“固定统计截面”，不意味着所有短信此时都已有最终回执。冻结后迟到回执继续正常更新短信业务事实，不改已冻结报表，不把未知自动改成失败；报表与当前详单存在截面差异时明确显示截止时间。跨日补发也不得使已冻结日的历史报表被普通任务改写。
|
||
|
||
### 2.2 独立查询的边界
|
||
|
||
- 四TAB各有日期草稿/已应用日期、过滤草稿/已应用过滤、排序、分页、pageSize、请求取消/序号、loading/error和结果，任何查询只更新本TAB。
|
||
- 首次打开TAB只请求该TAB；切回保留自己的条件及已取得结果，用户查询/刷新只重查当前TAB。隐藏TAB不自动重查，不用另一TAB成功响应填补失败。
|
||
- 企业、通道活跃度请求明确携带不同`dimensionType`，服务端只处理所选维度，按过滤后的完整30日合计排序再分页，只返回当页维度及其30格。
|
||
- 日期与搜索“查询”统一应用本TAB当前全部草稿条件并回到第一页；翻页只使用已应用条件。特别修正未报备卡片查询沿用旧日期的问题。
|
||
- 底层只读聚合器、数据库连接池和已发布日报可以复用；页面查询不触发其他TAB请求、不触发报表重建、不运行退网检测、不创建预警。
|
||
|
||
### 2.3 指标和历史维度
|
||
|
||
- 质量列表/运营商概览以业务短信为单位；通道矩阵以真实发送尝试为单位；保留现有不同成功率分母并在契约逐字段登记，不把计费片数换成业务条数。
|
||
- 业务统计按`SmsMessageRecord.queuedAt`归日；通道尝试及活跃度按现有`COALESCE(submittedAt,createdAt)`归日。跨日补发可能使列表与矩阵日期归属不同，应分别生成，不能先用当天业务列表裁掉当天实际提交、但原消息属于其他日期的事实。
|
||
- 企业活跃度在统计范围内按messageRecordId去重，通道按messageRecordId+channelId去重；不直接累加通道值得到企业值。规则窗口跨日也须重新去重，不能把每日distinct数简单相加。热力图“30日合计”保持每日展示值之和并标注为日活跃量合计，区别于预警窗口去重人数/条数。
|
||
- 成功必须按发送尝试完整分段事实判断，缺片/缺回执仍为未知；长短信不能因已到的几个分段都成功而提前成功。旧记录无分段事实时才按既有明确回执兼容；不把上游接受当送达。
|
||
- 平均到达时长持久化成功耗时总和与样本数，展示时相除；不能平均各组平均值。列表、抽屉、运营商概览及引流三类拆分使用相同generation版本。
|
||
- 日报保存当次统计维度名称、企业应用归属、运营商、报备适用状态/通过时间与统计规则版本。历史筛选使用报表快照字段，不能inner join当前通过任务导致历史行消失。活动日报逐日记录适用性；尚未通过、不适用、已通过且零发送、未生成必须区分。
|
||
- 未报备仍指规范正文签名在该企业应用有效签名库中不存在，且原消息无signatureId，不等于缺少通道报备。实时用查询时签名库；近三日用本轮生成时签名库；冻结日保留最后发布判定及名称。此后补登记不得追溯抹除冻结历史。
|
||
|
||
## 3. 性能优化方案
|
||
|
||
### 3.1 优先消除重复计算
|
||
|
||
1. 将逐个签名×通道×运营商反复扫描，改为按统计日有界批次聚合；先限定日期与候选消息/提交，再对这些submitId批量归集分段/回执，避免每个维度重新读取相同事实。
|
||
2. 一次读取参与检测的规则、通过任务、既有检测键与抑制摘要。已经完成的检测批次直接退出；部分完成只恢复缺失维度，避免昂贵计算后才查存在性。
|
||
3. 单日活动日报与质量日报复用经核验的尝试分类逻辑，按各自归日维度生成结果。退网“是否活跃”的窗口只需要accepted去重，不为判断阈值重复关联所有回执；送达率由日报单独计算。
|
||
4. 预警窗口最长支持现有365天，按实际生效规则的最大窗口限制扫描，批量JOIN规则维度后按message/channel去重。企业跨通道、跨日不能直接SUM日报；在测试库比较批量COUNT DISTINCT与适量窗口分组方案后选定。禁止以改成30天窗口偷换规则。超大窗口必要时分阶段物化紧凑去重键，但须先盘点容量，不能本轮默认复制全量短信正文或全部历史明细。
|
||
5. 批次发布后退网任务引用已完成单日活动版本，并独立保存当时窗口判断及规则版本。刷新日报不更新既有检测决策、不推进旧周期、不重新生成通知。
|
||
|
||
### 3.2 索引和SQL计划
|
||
|
||
预生产真实索引已有message.queuedAt、submit.messageRecordId，但未见消息的signatureId+carrier组合索引，也未见submit的`COALESCE(submittedAt,createdAt)`表达式时间索引。不能仅因没有索引就断言某一SQL必然全表扫描。
|
||
|
||
候选包括消息(signatureId,carrier,id)、提交(COALESCE(submittedAt,createdAt),messageRecordId)、按实际计划需要的通道+有效提交时间，以及日报日期/维度/排序组合。保留表达式原语义，不能直接用createdAt替代submittedAt。候选须通过有代表性数据的`EXPLAIN (ANALYZE, BUFFERS)`验证选择性、loops、临时文件和写入成本后决定，不盲目全部加索引；本轮未执行重查询或建索引。
|
||
|
||
大表索引上线采用平台支持的在线建索引流程，明确非事务DDL、失败无效索引检查及重试；具体迁移方式在实施时结合Prisma发布门禁验证，禁止把不允许在事务中的DDL塞进普通事务而绕过错误。不全局扩大work_mem，不默认增加SQL/worker并发。
|
||
|
||
### 3.3 页面成本
|
||
|
||
- 活跃度改服务端过滤、排序、分页，只传单类维度的当页30格；四TAB仍各自独立，不将两个活跃度结果捆绑返回。
|
||
- 查询快照元数据和维度使用Map/数据库JOIN，不逐条Array.find造成大集合反复查找；保留已有模块级日期格式化器。
|
||
- 首屏与列表查询仅取所需字段；若详情改独立请求，必须携带列表generationId以保证详情一致，不能点击详情又扫原始历史短信。
|
||
- 当天实时查询采用有界日期、分页和超时；失败保留当前TAB最后真实结果并标注其日期/时间，不能把旧值作为新查询成功。跨午夜请求由服务端固定T并回传，前端不自行混合两个自然日结果。
|
||
|
||
## 4. 日报生成、冻结和恢复
|
||
|
||
建议签名日报任务北京时间03:00启动，依次处理T-3、T-2、T-1，与已存在财务日报错峰；04:00退网检测、08:00通知时点保留。固定时间是拟实施配置，尚未上线；也必须检查与其他后台任务是否重叠。
|
||
|
||
生成任务具备耐久状态`pending/running/succeeded/retry_wait/failed`、租约、递增fence和有限重试；按scope+businessDate唯一认领，旧worker过期后不能发布。每个日期在一致性数据库快照下生成候选版本，完成四类校验后短事务切换publishedGenerationId。部分失败保留完整旧版；其他日期可继续，但整轮不得虚报全成功。发布必须再次验证fence、日期是否已冻结和候选水位。
|
||
|
||
页面只读published版本；生成中有旧版则显示旧版及刷新中/上次成功时间，没有旧版显示“报表尚未生成”，失败显示失败，不能返回空数组冒充零数据或回退扫描明细。合法零数据日期也必须生成完成清单与0行标记。
|
||
|
||
日界线进入T-4后自动禁止覆盖；跨午夜仍在运行的旧任务在发布校验时被拒绝。若T-3最后刷新失败，冻结上一成功版本并显示未达到预期截止时间；若从未成功则保留缺口，不伪造冻结完整。错过整个三日窗口的缺口只能进入显式历史补建流程，不能借“启动补偿”无限回算。
|
||
|
||
04:00所需日报未完成时，检测等待该日完成且告警；08:00只发送已完整完成检测的结果，不把半批维度当完整预警。后续恢复沿用当日补偿与幂等，不补发旧日期通知。周期变更、检测行、通知意图在维度事务中一致提交；全批完成标记必须在全部维度校验后置位。通知仍按日期+企业应用聚合及现有抑制规则，重试不能重复创建消息/Webhook。
|
||
|
||
日报刷新三天不等于重新做三天的预警判断。`SignatureRetirementDetection`保留历史判断审计，页面活动日报是另一投影，两者截止时间可能不同，页面标明统计口径而不是互相覆盖。
|
||
|
||
## 5. 拟新增模型与接口
|
||
|
||
以下名称仅为设计，不表示Prisma已有模型：
|
||
|
||
| 模型 | 主键/唯一维度与作用 |
|
||
|---|---|
|
||
| SignatureAnalyticsDay | businessDate唯一；publishedGenerationId、state、generatedAt、sourceAsOf、frozenAt、schemaVersion、coverage/provenance、rowCounts/checksum；成功零行也记录 |
|
||
| SignatureAnalyticsRun | scope+businessDate+generationId唯一；owner、leaseUntil、fence、attempt、checkpoint、startedAt/finishedAt、error摘要；每scope/date最多一个有效运行者 |
|
||
| SignatureQualityDaily | generationId+metricKind+tenant/application/signature+carrier/channel/drainage规范化维度键唯一；区分business与attempt，计数、耗时分子分母、名称快照 |
|
||
| SignatureActivityDaily | generationId+dimensionType+tenant/application/signature/channelKey/carrier唯一；单日提交、accepted业务数、送达数、适用性及报备快照 |
|
||
| UnreportedSignatureDaily | generationId+tenantId+applicationId+规范正文签名键唯一；业务数、生成时判定及名称快照 |
|
||
|
||
空channel/application使用无碰撞规范键，不能依赖可空字段唯一约束防重复。行均有真实businessDate和generationId外键；普通查询仅取发布版本。预警任务可复用耐久Run机制但scope独立，不与日报共用完成状态。旧版本保留期限和空间预算须在实施/发布阶段核验，不自动清理现有业务记录。
|
||
|
||
API建议：
|
||
|
||
- 质量与未报备保留现有GET路径和date/keyword/page/pageSize，增加`dataSource=live|report`、`reportState=ready|refreshing|failed|missing`、`mutable/frozen`、businessDate、serverBusinessDate、generatedAt/sourceAsOf、generationId和schemaVersion。数据源由服务器决定，客户端不能要求重算冻结日。
|
||
- 热力图提供独立版本路径`GET /admin/signature-retirement/activity`，必填dimensionType=enterprise|channel，date为D；企业/应用/签名/通道过滤分别传入，pageSize只接受10/25/50/100。返回单类当页维度、total和D-1至D-30；逐日期带版本/完整性元数据。保留旧heatmap GET只作兼容，最新页面不再调用；记录旧调用后再决定移除，不让旧前端接收截断结果冒充完整数据。
|
||
- 活跃度筛选、30日排序、总数与当页结果在同一个一致性读事务获取；先在过滤全集排序再LIMIT。缺失日期不可当成0参与已完整合计，须展示“部分日期缺失”。冻日前名称和维度只来自报表。
|
||
- 日期严格验证真实日历、拒绝未来日；页码为正整数、pageSize有上限，排序白名单。请求取消和旧响应隔离按TAB独立实现。
|
||
- 沿用运营端鉴权及数据可见范围，在数据库查询前约束tenant/application；不新增匿名查询/生成接口，不以报表缓存绕过权限。真实HTTP401/403、越权筛选和缓存键隔离须专项验收。
|
||
|
||
## 6. 历史切换、发布和恢复
|
||
|
||
1. 在真实数据规模的隔离测试库建立旧口径对照，包括长短信、补发、跨日和未报备；冻结字段契约，修正差异而非迎合旧错误。
|
||
2. 增量新增模型/索引与后台生成器，旧接口继续运行；候选生成器先影子计算，不产生通知，完成准确性与负载对照后切换。
|
||
3. 盘点可支持历史日期的源数据覆盖、报备轨迹、消息/回执保留和磁盘空间。一次性按明确日期清单补建历史日报，先满足热力图至少30日与用户常用查询区间；预警规则窗口另覆盖实际最大365日需求。没有可信历史事实就标记缺口，不把当前报备状态当作过去状态。
|
||
4. 旧检测快照可作为活动量迁移证据，但不能冒充补齐迟到回执后的完整日报。用原始事实重建的历史报表须记录backfilledAt/sourceAsOf/provenance，不能伪造为当年T+3冻结结果。完整性不足的日期不宣称已完成，历史可查询范围明确展示。
|
||
5. 迁移期不复制历史周期、不重发历史消息。生成和读取按schemaVersion切换；切换后禁用旧逐维度检测调度入口，防止双跑。先测试环境验收，再另按授权发布预生产。
|
||
6. 应用回退保留新增表和已发布冻结版本；异常优先暂停新任务、保留只读已发布日报。旧应用会恢复历史实时查询行为，不能称之为满足新冻结规则的等价回退，须在恢复说明中明确影响。不自动恢复数据库或删除候选/旧报表。
|
||
|
||
## 7. 验收、观察指标与实施顺序
|
||
|
||
详见[功能用例](system-functional-test-cases.md)中`TC-SQA-20260917-01～16`，本地执行覆盖及环境未执行项见第8节。
|
||
|
||
- 准确性：真实PostgreSQL逐字段对账；短/长短信、缺片、重复乱序、失败补发、跨通道/跨日去重、未知和迟到回执；旧历史无分段兼容；成功率分母及耗时加权正确。
|
||
- 冻结：T、T-1、T-3、T-4、跨午夜/跨月/闰日；刷新原子性、版本一致、补登记不改变冻结未报备、名称/通过状态变更不让历史行消失；失败与零数据可区分。
|
||
- 独立性：四TAB首次/切换/查询/分页/详情；一个TAB失败、慢响应或修改日期不影响另一个；企业请求不含通道维度；真实HTTP与三尺寸浏览器核验，不仅用mock证明功能。
|
||
- 可靠性：双worker抢占、租约超时接管、旧fence发布被拒、批次部分失败、任务重启、错过冻结窗口、08:00依赖未完成、重复通知去重。报表刷新不写短信/余额/报备/通知状态。
|
||
- 性能记录：整机及PG/API进程CPU、数据库扫描行/块、SQL耗时/p95、任务耗时、锁等待/临时文件、响应字节、API内存、短信队列延迟；分别标注冷/热缓存和相同业务规模，不把一次结果当容量承诺。
|
||
- 拟验收目标：相同数据规模，退网原始明细扫描行数下降至少80%，任务耗时下降至少50%；单类热力图每页最多100×30个格，响应规模不随未选维度总数增长。此为测试目标而非已实测收益；不能单凭CPU目标判定成功。若准确性/业务队列恶化立即停止候选压测，不在预生产重新跑整套重任务验证猜测。
|
||
|
||
实施分三批：①独立接口/页面查询及精确统计契约；②日报三日刷新/冻结/历史补建与版本化读取；③退网批量聚合/原子任务/依赖编排及性能对照。批次①不宣称已完成报表化，③完成前不宣称CPU问题已解决。
|
||
|
||
这是前端、查询后端、数据库模型和后台调度的跨模块改造，主要成本在历史回填、口径对账和故障恢复验收，不能按简单索引补丁处理。实施需API/前端定向与全量回归、类型/构建/质量门禁、真实PG/接口/浏览器；若不修改Gateway无需冒充重做Gateway发布。真实短信、外部通知及压测只在后续明确授权的环境和范围执行。
|
||
|
||
## 8. 2026-09-17 本地实现与验收
|
||
|
||
### 8.1 实现及设计落地
|
||
|
||
- `api/src/signature-analytics/`提供北京时间日期校验、日报聚合、版本读取、后台调度和独立退网批次。03:00后依次刷新T-3/T-2/T-1，60秒补偿检查；04:00检测与08:00通知保留。日报失败不降级实时查询，未生成与合法零结果分开；热力图继续D-1～D-30。
|
||
- 新增六表：Day发布清单、Generation不可变版本、Run耐久任务、QualityDaily、ActivityDaily、UnreportedDaily。日报行和发布指针以generationId+businessDate复合外键保证日期/版本一致。质量嵌套矩阵和概览保存在同一JSON快照，检索字段独立列化；引流分组保存耗时总和/有效样本数并加权合并，不平均组均值。
|
||
- 与原建议“候选后短事务切指针”相比，本期采用**每个自然日一个RepeatableRead事务**，聚合、分批250行写入、发布与fence验证一起提交。理由是保证同日各口径取自同一源快照，避免未持久化源水位的断点续算混入不同截面。单SQL90秒、事务120秒、租约300秒；失败重算该日，成功日期不重算，最多5次指数退避。事务上限短于租约，不需要保持长事务跨租约续期。超过此规模应先扩展分阶段水位设计，不能直接无限增大超时。
|
||
- 退网窗口只扫描accepted提交，批量按实际规则窗口（最长365天）去重，单日送达数复用活动日报。规则与所引用日报版本在首次认领后持久化为checkpoint，重试不改变；检测、周期及冻结通知正文同事务。完成检查前移；日报刷新不修改已有检测/消息。缺昨日当日刷新版本时等待，不消耗检测重试次数。通知沿用原耐久消息/Webhook去重，同进程完成后不每分钟重扫全部消息；重启可补偿，禁止自动补发历史检测。
|
||
- 两个活动TAB改用`/admin/signature-retirement/activity`，明确dimensionType；服务器过滤、排序、分页和完整性读取处于一致性事务。每页只返回所选维度，最多100×30格；空的越界页仍返回正确总数。旧heatmap接口保留兼容旧页面，当前页面不调用。四TAB查询/取消/错误/日期/筛选各自独立，未报备卡片查询应用新日期。
|
||
- 普通历史读取只访问日报快照，无当前报备/名称JOIN。报备轨迹可还原时取历史状态与通过时间，旧数据仅有明确approvedAt时保留兼容证据；缺完整历史轨迹不宣称重建了过去所有状态。无报备资格的格子N/A，缺日报的格子显示缺口。旧记录完全无分段审计时保留明确回执兼容；存在分段时按预期总片数判断，缺片不提前成功。
|
||
- 迁移`20260917030000_signature_analytics`新增表；`20260917031000_signature_submit_effective_at`单独以非事务`CREATE INDEX CONCURRENTLY`建立有效提交时间表达式索引，避免将所有历史源扫描混进三日任务。108项完整迁移已在独立PostgreSQL库执行。线上失败须检查`pg_index.indisvalid`及迁移状态，按发布恢复流程处理；不自动DROP/resolve失败迁移，不绕过门禁。
|
||
|
||
### 8.2 历史补建与发布边界
|
||
|
||
离线入口`tools/testing/backfill-signature-analytics.mjs`使用已构建API，要求环境变量DATABASE_URL和匹配目标主机的`--host`，逐个明确`--dates=YYYY-MM-DD,...`；默认只检查，明确`--execute=yes`才生成。禁止未来/当天、隐式范围和覆盖已有发布版本。最多366个显式日期，逐日顺序生成；不初始化应用调度、不运行检测/通知，结果标记`backfill-current-source`与实际sourceAsOf，页面标明“事后补建”。本轮只在隔离库验证，线上补建未执行。
|
||
|
||
发布时需先核对源数据覆盖、实际报备历史与存储空间，生成影子日报并对账，至少为常用D准备此前30日，再切换页面；缺失日期保持可见缺口。新版本/旧版本表行均保留，不自动清理。回退应用保留新增表与冻结版本，但旧应用将恢复旧历史查询行为，不是业务等价回退。本轮没有推送或部署，也没有声称线上CPU已下降。
|
||
|
||
### 8.3 已执行证据及限度
|
||
|
||
- 真实PostgreSQL16隔离集群127.0.0.1:16435，空库完整迁移；`verify-signature-analytics.mjs`覆盖日报三日、冻结、跨日去重、2/3/4片、缺片、旧无分段回执、耗时加权、超出页码、重复认领、旧fence拒绝、失败回滚/重试及规则快照。验收数据只在本机专用`cmpp_qa_signature_*`库，脚本拒绝其他主机/库名。
|
||
- `verify-uplink-matching.mjs`真实事务验证重复事件、应用归属、供应商MO ID保留、并发人工认领和通知存储故障回滚。故障注入仅模拟存储错误；实际数据/事务/通知意图均为PostgreSQL，未调用外部Gateway发送。
|
||
- 真实完整Nest应用、PostgreSQL和隔离Redis，生产构建页面在1600×1000、1366×768、390×844打开/切TAB/查询/刷新，页面异常0；HTTP正常查询200、匿名401、非法维度/分页400。浏览器认证会话仅内存传递，不保存密码、令牌或storageState。Redis本机为5.0.14.1，有BullMQ建议6.2警告；本轮未将其视为生产队列能力验收。
|
||
- 前端全量35文件/163项、API全量78套/842项；类型检查、构建、代码结构、格式、ESLint、CSS治理、样式和Bundle门禁记录在testing-progress。Gateway代码未改，不重复冒称实发/协议验收。
|
||
- `benchmark-signature-analytics.mjs`对照4eb7b16原活动聚合：30000条消息、600维度，本地热缓存旧逐维度10343.912ms，新批量624.940ms，减少93.96%，accepted计数逐维度相等。EXPLAIN原单维度实际源表访问30113行，按600维度估算约1806.78万；新批量60039行。旧总行数是样本外推，不是全批逐SQL实测；均为热缓存，未产生临时磁盘块。这里只证明活动聚合环节，整个日报+365日检测批次的CPU、p95、内存、线上队列影响、真实高密度回执规模仍须部署前/后专项验收，不能宣称全部性能目标已达标。
|
||
- 本机原始日志、截图和故障证据在忽略目录`.local-data/signature-optimization-20260917/`。初次迁移目录未生成SQL、测试通道缺carriers、断言漏计样本、临时账号缺email等失败已修正并保留原日志，不用最后成功覆盖失败历史。
|