From 21168d728aad4e671096b731ae22fa968e1f049f Mon Sep 17 00:00:00 2001 From: windyboy Date: Sat, 19 Sep 2026 21:49:47 +0800 Subject: [PATCH] =?UTF-8?q?docs(acm2-75):=20Q1=20=E5=AE=9A=E6=A1=88=20schd?= =?UTF-8?q?=20record=20=E7=B2=92=E5=BA=A6=E6=B2=BF=E7=94=A8=E6=97=A7?= =?UTF-8?q?=E7=B3=BB=E7=BB=9F=E6=95=B4=E6=89=B9=E5=8D=95=E6=9D=A1?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/contracts/interface-contract.md | 2 +- docs/specification.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/contracts/interface-contract.md b/docs/contracts/interface-contract.md index f1af31f..bd13bd6 100644 --- a/docs/contracts/interface-contract.md +++ b/docs/contracts/interface-contract.md @@ -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-*）处理」）： diff --git a/docs/specification.md b/docs/specification.md index 7681a6f..b5e9f95 100644 --- a/docs/specification.md +++ b/docs/specification.md @@ -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「消息、身份与决策」） | 改发正文的重发会被判为重复并跳过 |