docs(acm2-75): Q1 定案 schd record 粒度沿用旧系统整批单条

2026-09-19 21:49:47 +08:00
parent 25cc967bd2
commit 21168d728a
2 changed files with 3 additions and 3 deletions
@@ -44,7 +44,7 @@ AODB 经 CIIMS adapter 把 XML 报文写入 `CMINMSGS`，格式以架构指定
 | 主题 | 已确定的消息语义 | 尚需确定 |
 |---|---|---|
 | `msg` | 单条航班变更通知；航班动态与删除处理完成后投递；发送失败自动重试，一直失败的记录保留可查并告警（`US-08`）；同一 `FLID` 的变更保序，对外按至少一次投递。删除通知的来源有三处：`FDEL` 删除（`US-06`）、日计划快照缺席删除（`US-07`）、历史清理在物理删除前必要时登记（架构 `D1`）。 | Kafka value 的字段与类型、变更和删除的区分方式（`Q5`）、编码方式、分区规则。 |
-| `schd` | 定时批量发送最新航班状态；内容是 `SCHD.FLTR` 序列化出的 JSON，空字段不输出，字段与类型见 [XSD](../legacy/unisysaodbsis.xsd) 的 `FLTR`；边界是定时任务的一次 tick，两次 tick 之间积累的变化整批发一次，没有变化就不发；删除航班不进入本主题，由 `msg` 发一条删除通知；发送失败自动重试，对外按至少一次投递（`US-08`）。 | “批量”对应的 Kafka record 粒度（`Q1`）。 |
+| `schd` | 定时批量发送最新航班状态；两次 tick 之间积累的航班组成 `SCHD.FLTR` 数组 JSON，整批作为单条 record 发出（沿用旧系统，`Q1`）；空字段不输出，字段与类型见 [XSD](../legacy/unisysaodbsis.xsd) 的 `FLTR`；没有变化不发；删除航班不进入本主题，由 `msg` 发一条删除通知；发送失败自动重试，对外按至少一次投递（`US-08`）。 | 消费方按数组格式解析的确认（`Q1`）。 |

 旧系统线索（来源：旧项目用户故事「前端通知」「动态类（FLOP-*）处理」）：

@@ -54,7 +54,7 @@

 ### 2.4 下游（admin-api、网页客户端与运营航班显示界面）

- **C-9** 航班变更发到 Kafka 主题 `msg`（单条）和 `schd`（批量）；`schd` 的内容是 `SCHD.FLTR` 序列化出的 JSON，空字段不输出，边界是定时任务的一次 tick——两次 tick 之间积累的变化整批发一次，没有变化就不发；删除航班不进 `schd`，只由 `msg` 发一条删除通知；不设消息键。同一条可能发多次。
+- **C-9** 航班变更发到 Kafka 主题 `msg`（单条）和 `schd`（批量）；`schd` 沿用旧系统粒度：两次 tick 之间积累的变化序列化成一个 `SCHD.FLTR` 数组 JSON，整批作为单条 record 发出（`Q1`），空字段不输出，没有变化就不发；删除航班不进 `schd`，只由 `msg` 发一条删除通知；不设消息键。同一条可能发多次。
 - **C-10** 静态参考数据写入本系统数据库，供 admin-api 只读；本系统不调用 admin-api。
 - **C-11** 航班投影写入 Redis，供读取全体动态航班；`GET /all/flights` 与网页客户端读同一份；返回 JSON 由消息文档中的 XML 结构转换而来（`Q6`、`Q21`）。

@@ -106,7 +106,7 @@

 | 编号 | 事项 | 当前假定 | 影响 |
 |---|---|---|---|
-| Q1 | `schd` 的 Kafka record 粒度 | 按 `C-9` 是每条 record 一条运营航班 JSON；旧系统相反，把两次定时 tick 之间积累的整批序列化成一个 JSON 数组作为单条 record 发出 | 消费方的解析方式与 `C-9` 二者只能取一 |
+| Q1 | `schd` 的 Kafka record 粒度 | 已定原则：按旧系统，两次 tick 之间积累的整批序列化成一个 JSON 数组作为单条 record 发出（`C-9`） | 消费方未确认按此格式解析 |
 | Q2 | 请求与应答按时间匹配时的时钟偏斜容忍判据 | 比较前统一时区与单位（implementation.md「上游请求与静态数据」） | 容忍判据未定前，降级匹配不得描述为精确关联 |
 | Q3 | 现场会发但 SIS 未定义的子类型（靠桥、延误等）的报文形态与逐类终态 | 按现有处理逻辑延续，不得因 SIS 未记载就丢掉（`US-05` AC1） | 逐类终态与幂等规则未定（`G-FLOP-SEMANTICS`） |
 | Q4 | 上游重发时是否可能改发正文 | 报文不可变，绑定身份后不比对内容（implementation.md「消息、身份与决策」） | 改发正文的重发会被判为重复并跳过 |