患者 AI 消息预警平台 — 技术方案

· v1.0 · 2026-06-30
把「采集库里的患者体征 → 丢给 AI 研判 → 把风险预警实时推给医护」这条链路，做成一个独立、可靠、可追溯的后台平台。支持多条产品线，一期接入**重症（ICU）和麻醉（ANES）**两条产品线。
文中关键参数（查库周期、AI 并发/超时、容量等）附默认值和测算过程。

一、为什么单独建一个项目

体征数据已经由采集系统写进了数据库。我们要做的是中间这段：定时取数 → 调 AI → 拿结果 → 推送前端，并保证全程不丢、可查、可统计。

平台不做两件事：不做体征采集入库（采集系统已有），不做 AI 模型（AI 团队提供 HTTP 接口）。

采集库由其他部门维护，我们只有只读权限，不能建表、写数据。研判时读采集库取体征；推送时只读本地业务库——Worker 写 alert_record 时把姓名、床号、room/ward 等字段快照进去，WebSocket/REST 不再查采集库。患者主数据不做全量同步。

为什么单独建项目，而不是塞进现有系统：

二、整体架构：平台在链路里的角色

整个平台夹在采集域和 AI/前端之间，只负责中间的编排和推送。

   采集域（别人的）              本平台（我们做的）                 外部能力（别人的）
 ┌──────────────┐   ①只读查库    ┌──────────────────────────┐
 │ 采集系统      │ ───────────▶  │  ②查库 → ③编排 → ④调AI    │  ④HTTP   ┌──────────┐
 │ 写入体征      │              │  → ⑤落库 → ⑥推送          │ ───────▶ │ AI 服务   │
 └──────┬───────┘              │                          │ ◀─────── │ (重症/麻醉)│
        │ 写入                 │  全程写库：pipeline/日志/  │   返回    └──────────┘
        ▼                      │  预警/通知 → 可追溯        │
 ┌──────────────┐  平台主动查    │                          │  ⑥WS+REST ┌──────────┐
 │ MySQL 采集库  │ ◀──────────  │                          │ ───────▶ │ 业务前端  │
 │ (ICU/ANES)   │              └──────────────────────────┘          │ 弹窗/列表 │
 └──────────────┘                                                     └──────────┘

前端通过 WebSocket（实时）+ REST（兜底拉取）拿预警。

平台内部分五个环节，状态都落库，便于排查和补数据：

三、一条预警是怎么跑完的

1. 采集系统把体征写进采集库                                （平台不参与）
2. XXL-Job 定时触发（默认每 3 分钟，可配）
3. 查库：窗口 = [last_watermark, now]（上限 window_minutes），只查新增体征
   —— 若该患者 AI 正在跑（running 锁）→ 跳过入队，标记 pending_reanalysis
   —— 否则同一事务写 pipeline + 日志 + outbox 并提交（❌ 不更新水位）
4. 投递：Outbox 把任务发到 RabbitMQ（ICU / ANES 各自的队列）
5. 研判：Worker 取任务，汇总体征，HTTP 调 AI（带 requestId=pipelineId，5~30 秒）
6. 落库：AI 成功 → 同事务写 record + notice + 更新水位 + pipeline 完成
7. 推送：WebSocket 按 push_route_key（room/ward）广播；REST + wsToken 兜底
8. 兜底：AI 失败水位不变自动重试 → 仍失败进死信 → 对账/人工补偿补跑
   —— running 锁释放后若 pending_reanalysis=true → 立即补一次分析

整条链路里，唯一的"慢"在 AI（5~30 秒），查库和推送都是毫秒~秒级。

四、技术选型（为什么用它们）

为什么是 RabbitMQ（带容量测算）

一条消息对应一个患者、一个时间窗、一次 AI 研判，属于任务队列，不是日志流。量级如下：

活跃患者          ICU 100 + ANES 100        = 200 人
查库周期          poll_interval = 180s       → 每天 480 轮
每轮有新数据占比  经验取 30%                 → 每轮入队 200 × 30% = 60 条
─────────────────────────────────────────────────────────
平均入队速率      60 条 / 180s              ≈ 0.33 条/秒
日峰（×3 突发）   ≈ 1 条/秒
日任务总量        60 × 480                  ≈ 2.88 万条/天
真正瓶颈          AI 单次 5~30s，并发 5      → 单线约 10~60 条/分钟

瓶颈在 AI 吞吐（每分钟几十条），不在 MQ。日入队约 1 条/秒，主流 MQ 都够用；选型主要看任务语义、重试死信、分线路由和运维成本。

为什么不是 Kafka：我们用不上 Kafka 的百万 TPS 和回放能力，却要维护 ZK/KRaft；任务队列所需的「一条一消费 + 死信重试」在 Kafka 上要自己实现。
为什么不是 Redis Streams：缺原生 DLQ 和 Publisher Confirm，可靠投递要补较多逻辑。
选 RabbitMQ：任务语义清晰，重试/死信/分线路由现成，Spring AMQP 集成成熟，单节点能撑一期。

为什么不用线程池代替 MQ：日任务约 2.8 万条，线程池也能跑。选 MQ 主要是因为失败重试、死信、多 Worker 扩缩和任务持久化，而不是 TPS：

Redis 用途（缓存 / 防抖 / 锁）

Redis 在平台做四件事，（任务队列是 RabbitMQ）：

解锁用 Lua 比对 value 后 DEL；DB 上 idempotency_key 唯一索引再挡一层重复。

五、核心机制详解

5.0 防 AI 重复分析：运行态锁 + 延迟补跑

AI 分析进行中（如 10:00 开始，耗时 30s），若 10:06 查库又来新体征，会再入队，导致同一患者被两个 Worker 同时跑。处理办法：

10:00  Worker 开始分析 P001 → SET alert:running:ICU:P001 = 1 (TTL 300s)
10:05  采集库又来新体征
10:06  查库 Job 扫描到 P001 有新数据
       → 检查 alert:running:ICU:P001 存在 → 跳过入队，不写 outbox
       → 标记 alert_patient_watermark.pending_reanalysis = true（有新数据待补）
10:00:30  AI1 完成 → EVAL Lua（DEL running + 读 pending）→ 若 pending 则发延迟补跑（TTL 45s，is_reanalysis=true）
10:01:15  补跑 Worker 消费 → 新建 pipeline + outbox → 清除 pending

多实例并发（查库 Job + Worker 同时跑）

部署多实例时，查库 Job 和 Worker 可能同时改 alert_patient_watermark 和 Redis，需要额外约束：

-- fetch 阶段（持 alert:fetch 锁）
IF running 存在 THEN
  UPDATE watermark SET pending_reanalysis=1
  跳过 outbox
ELSE
  IF 该患者 45s 内已有 is_reanalysis pipeline 在处理/刚完成 THEN 跳过
  写 pipeline + outbox
END

-- AI 完成（Redis EVAL Lua，见下）

Lua 完成脚本与 fallback

Lua 通过 EVAL 执行，脚本内不抛 Java 异常；返回固定字符串供 Worker 判断：

-- KEYS[1]=running  KEYS[2]=pending  ARGV[1]=pipelineId
local v = redis.call('GET', KEYS[1])
if v then redis.call('DEL', KEYS[1]) end
local p = redis.call('GET', KEYS[2])
if p == '1' then
  redis.call('DEL', KEYS[2])
  return 'pending_cleared'   -- Worker 侧发 MQ 延迟消息
end
return v and 'success' or 'no_pending'

Worker 侧对 Lua 调用设超时（如 500ms）。失败或超时时 fallback：按 pipelineId 校验 value 后 GET + DEL running；再读 DB pending_reanalysis，为 true 则同样发延迟补跑消息。running 锁 TTL 300s 可自愈，但 fallback 避免等满 TTL 才补跑。

监控：alert_running_lock_count（alert:running:* 键数量）、Lua 失败/超时次数。

补跑与查库去重

延迟补跑走 alert.reanalysis.delay（默认 TTL 45s，可配；比查库周期 180s 短、比 5s 更能错开查库 Job）。消息体带 is_reanalysis=true，pipeline 表同步写 is_reanalysis=1。

5.0.1 水位（Watermark）什么时候更新？

查到了 10:01、10:02、10:03 的数据后 AI 失败，水位该不该动？更新了可能丢数，不更新下轮又重复查。规则如下：

水位只在 AI 成功且 alert_record 落库之后，与 record 同一事务内更新。

查库阶段（事务1）：
  读采集库 record_time > watermark
  写 pipeline + log + outbox
  ❌ 不更新 watermark

AI 成功阶段（事务2）：
  BEGIN
    写 alert_record + alert_notice
    更新 pipeline → DONE
    UPDATE alert_patient_watermark SET last_data_time = window_end  ← 只在这里更新
  COMMIT

AI 失败：
  watermark 不变 → 下轮对账/重试仍覆盖同一段数据 → 不丢

5.0.2 数据窗口怎么算？

不是固定「最近 30 分钟」，而是动态区间：

window_start = last_data_time（水位，上次成功处理到的时刻）
window_end   = 当前查库时刻（或该患者采集库 MAX(record_time)）

• 配置项 window_minutes 是上限：若 window_end - window_start > 30min，只取最近 30min（防 AI 输入过大）。
• 正常情况窗口是 [last_watermark, now]，不重叠、不重复——上次成功到哪，这次就从哪开始。

示例：10:00 成功分析到 10:00 → 10:06 查库 window = [10:00, 10:06]，不会重复分析 10:00 之前的数据。

5.0.3 事务边界（两阶段本地事务）

┌─ 事务1（查库 Job 线程）─────────────────────────────┐
│  BEGIN                                               │
│    INSERT alert_pipeline (CREATED)                   │
│    INSERT alert_pipeline_log (DATA_FETCH)            │
│    INSERT alert_outbox (PENDING)                     │
│  COMMIT                                              │
└──────────────────────────────────────────────────────┘
         ↓ Outbox Relay（事务外，~1s 轮询）
         ↓ RabbitMQ Confirm
┌─ Worker 消费（无事务，调 AI 5~30s）──────────────────┐
│  HTTP 调 AI（带 requestId = pipelineId，AI 端幂等）  │
└──────────────────────────────────────────────────────┘
         ↓ AI 返回成功
┌─ 事务2（Worker 线程）─────────────────────────────────┐
│  BEGIN                                               │
│    INSERT alert_record + alert_notice                │
│    UPDATE alert_pipeline → DONE                      │
│    UPDATE alert_patient_watermark.last_data_time     │
│  COMMIT                                              │
│  basicAck(MQ)                                        │
└──────────────────────────────────────────────────────┘
         ↓ 异步
         WebSocket 广播推送 / REST 兜底

事务失败与回滚

• 事务1、事务2均使用 @Transactional(rollbackFor = Exception.class)，任一步异常整笔回滚。
• 事务2失败时：alert_record / 水位均不提交；alert_pipeline 标 FAILED，alert_pipeline_log 记异常；MQ 消息 nack 进重试。
• idempotency_key 或 record 唯一索引冲突：视为重复消费，记日志后直接 ACK，不重复落库。
• 事务2成功后才 basicAck；AI 调通但落库失败时不确认 MQ，保证可重试。

5.0.4 AI 超时与幂等

AI 侧其实已成功，但网络超时未收到响应时，平台若直接重试会导致重复分析。处理如下：

5.0.5 AI 限流与降级

并发上限由 MQ 排队 + Worker prefetch + Resilience4j Bulkhead（每线默认 5）控制。任务突增时先进队列，不会同时打满 AI。

AI 不可用时的行为：
  查库 Job     → 正常跑（不受影响）
  Outbox/MQ    → 正常入队（任务积压队列）
  Worker       → 熔断打开，暂停调 AI，消息留在队列
  AI 恢复      → 熔断关闭，Worker 逐步消费积压
  对账 Job     → 继续跑，发现漏判补跑

5.0.6 Outbox 轮询与投递确认

一期用 Polling Publisher（约 1s 轮询 alert_outbox WHERE status=PENDING）：

状态变更顺序（避免「标记已发但 MQ 未持久化」）：

Relay 取 PENDING 行
  → 发 RabbitMQ（persistent + mandatory）
  → 阻塞等待 Publisher Confirm（broker ack）
  → Confirm 成功后才 UPDATE outbox SET status=PUBLISHED
  → Confirm 失败或超时：保持 PENDING，下轮重发

补偿 Job（XXL-Job，每 1~5 分钟）：扫描 status=PENDING AND create_time < now()-30s 的记录，强制重发并打告警。单条 outbox 累计重试 不超过 10 次（retry_count 字段），超限标 FAILED 并告警，避免对 MQ 死循环打。

禁止在收到 Confirm 之前把 outbox 标为 PUBLISHED。

5.0.7 WebSocket 推送策略（一期 License / 二期 SSO）

现有客户端没有用户登录，用 AiLicense（license + mac） 做设备级鉴权，与麻醉/重症 AI 客户端一致。一期按终端 / 房间 / 病区推送，不按个人——和 License 绑 room 的模型一致。

License → wsToken → WebSocket 建连（一期）

客户端启动
  ① POST /anesthesia/aiLicense/verify（或 ICU 对应接口）
     参数：license + clientMac          ← 现有客户端已有
  ② POST /alert/ws/token
     参数：license + mac + productLine  ← 预警平台新增，复用同一套 License 校验逻辑
     返回：wsToken（JWT，有效期 24h，含 license、mac、productLine、roomId）
  ③ WebSocket 建连
     wss://alert-host/alert/ws?token={wsToken}
     ❌ URL 中禁止裸传 license（安全）
  ④ 服务端
     校验 wsToken → 解析 roomId
     Session 注册到订阅组：{productLine}:room:{roomId} 或 {productLine}:ward:{wardCode}
  ⑤ 有预警时
     读 alert_record / alert_notice 中的 push_route_key
     向对应订阅组广播（带 seq）

REST 兜底接口同样携带 Authorization: Bearer {wsToken}（或 Header 传 license+mac），与 WS 共用鉴权。

roomId / deptCode / ward_code 映射（路由键对齐）

License 表（ai_license）有 roomId、category；采集库患者有 room_id、dept_code、ward_code。推送路由以采集库患者位置为准，License 的 roomId 须与订阅维度对齐：

规则：

• 落库时（写 alert_record / alert_notice）：从采集库快照患者 room_id / ward_code / dept_code，计算并写入 push_route_key。
• 建连时：终端 License 绑定的 roomId 决定它订阅哪个组；须与上表约定一致（绑 OR03 的终端只收 OR03 的预警）。
• dept_code 作为 REST 查询的辅助维度保留；WS 广播以 push_route_key 为准。

License roomId 与患者 room 对齐

License 的 roomId 必须和采集库患者 room_id / ward_code 同一套编码，否则终端订阅了却收不到，或收到别的 room 的预警。

推送路由与注意事项

患者转科/转床：push_route_key 业务规则

一期约定：历史预警以产生时刻的位置为准，push_route_key 落库后不再修改。

落库时除 push_route_key 外，额外写入（一期就存，二期改路由时用）：

新预警始终按当时采集库快照写路由；REST 未读按 push_route_key 过滤。

一期 alert_notice 落库字段：product_line、room_id、ward_code、dept_code、push_route_key、is_read、read_client_id；REST 未读按 push_route_key 或 product_line + room_id/ward_code 过滤。alert_record 同时快照 patient_name、bed_no、体征 JSON 等展示字段——推送 payload 全部来自本地表，不回查采集库（终端读不了采集库；采集库抖动不影响已生成预警的推送；患者转科后历史预警以产生时快照为准）。

5.0.8 线程池与连接池规划

5.0.9 监控体系

5.0.10 患者数据与采集库只读：推送为何不查采集库

研判阶段读采集库，推送阶段只读本地业务库——不做患者主数据全量同步。

为什么推送不能依赖采集库？

两阶段数据用法

┌─ 阶段 A：研判（Worker）────────────────────────────────────┐
│  读采集库（只读）→ 取体征 + 患者路由信息 → HTTP 调 AI        │
│  ❌ 此阶段不写采集库；watermark 在本地维护                   │
└────────────────────────────────────────────────────────────┘
                          ↓ AI 成功，事务2提交
┌─ 阶段 B：落库 + 推送（本地 alert_platform）─────────────────┐
│  alert_record 写入展示快照 + push_route_key                 │
│  alert_notice 写入 → WebSocket 广播 / REST 兜底             │
│  ✅ 此阶段不再查采集库；payload 全部来自本地表               │
└────────────────────────────────────────────────────────────┘

Worker 写 alert_record 时，把当时从采集库查到的展示字段一次性快照进去；之后 WS/REST 只读本地库。WS 按 push_route_key（如 ANES:room:OR03）向对应订阅组广播；客户端用 license+mac 换 wsToken 后建连，终端 License 绑定的 roomId 决定订阅哪个组。

本地存什么？（不是全量同步）

患者主数据不做全量同步到预警平台；只在产生预警时把当时需要的字段快照进 alert_record。

采集库只读对「查数研判 / 推送」的影响

什么时候才需要考虑「同步」？

一期通常不需要。仅以下情况才值得加本地表或 CDC：

当前约束是可只读查询采集库，走「定时增量查 + 快照落库 + 本地推送」即可。

六、四个硬问题怎么解决

6.1 轮询的性能和延迟

活跃患者怎么查

「只查在科/术中患者」如果每轮对采集库做 WHERE status='在科' 全表扫描，容易成为热点。做法：

刷新 Job 不宜每轮全表扫。 SQL 示例：

SELECT patient_key, room_id, ward_code, bed_no, dept_code
FROM   ... 
WHERE  status IN ('在科','术中')
  AND  last_update_time > :lastRefreshTime   -- 增量；首轮或定时全量

有入科/出科时间字段时，用「当前在科」视图或 admit_time / discharge_time 过滤。刷新失败：告警 + 继续用上一版 Redis 缓存（TTL 未到前查库 Job 照常跑）；连续失败 N 次升级告警。

性能手段

轮询查库的性能和延迟，主要靠增量水位、活跃列表缓存、分批查询和独立连接池：

单轮查库耗时：4 批 ×（约 10~50ms）≈ 1 秒内，小于 180s 周期。

端到端延迟（约 1.5~5 分钟）：

瓶颈在查库周期和 AI 耗时。要缩短等待时间可调 poll_interval_seconds（需评估采集库压力）；AI 慢则靠队列排队，查库线程不被拖住。

6.2 数据可靠性

常见故障（MQ 抖动、WS 断线、AI 超时、进程重启）下，研判任务和预警记录应能恢复、不静默丢失；通知最终到达终端，允许秒到分钟级延迟。

以下依赖基础设施或运维，不在本期应用层单独解决：

各段分开容错，MQ 允许重复投递（幂等去重），按最终一致设计。

（1）查库 → 入队：Outbox（本地事务 + 异步投递）

最容易丢的地方：业务库事务提交了，但发往 MQ 的消息没发出去（或反过来）。我们不用 Seata/XA 这种重量级跨库事务，用 Outbox（发件箱）模式，本质是把"要发的消息"和"业务数据"放进同一个本地事务：

① 写库阶段（一个本地事务，要么全成功要么全回滚）
   BEGIN
     写 alert_pipeline      (流水线)
     写 alert_pipeline_log  (日志)
     写 alert_outbox        (待发消息, 状态=PENDING)
   COMMIT

② 发送阶段（独立线程，约 1s 轮询）
   取 PENDING → 发 RabbitMQ → **等 Publisher Confirm**
   Confirm 成功 → 标 PUBLISHED
   Confirm 失败/超时 → 保持 PENDING，下轮重发
   补偿 Job：PENDING 超过 30s 重发；retry_count ≥ 10 标 FAILED

③ 消费阶段（幂等）
   Worker 用 idempotency_key 去重 → 调 AI、落库 → 成功才确认(ACK)
   失败 basicNack → TTL 重试队列（退避）→ 超 3~5 次进死信

这样即使 MQ 临时挂了，待发任务仍留在 alert_outbox，恢复后补发。Outbox 发完标记 PUBLISHED，可定时清理，不会无限膨胀。

不用 XA/Seata：业务库内本地事务 + Outbox 最终一致，够用且更简单。

幂等：MQ 可能重复投递，idempotency_key 唯一索引保证同一研判作业只处理一次。

（2）RabbitMQ：生产 / 存储 / 消费三段

生产者 ──▶ Broker ──▶ 消费者
  ①         ②          ③

生产侧 Outbox + Confirm，Broker 持久化，消费侧手动 ACK、重试和死信，一段失败由下一段承接。

（3）推送到终端：先落库，再推送，断了也能捞

WebSocket 管实时，可靠性靠先写 alert_notice、再 WS 推送、seq 补发和 REST 未读拉取。连接会断，设计上按断线常态处理。

心跳 30s；重连退避 1s→…→30s；服务端 60s 无心跳回收连接。

REST 未读（最后一层）：

已读 / 确认：前端回调落库；一期 clientId=license/mac（终端级），二期 SSO 后改 userId。HIGH 级可要求必须 ack（二期）。

（4）对账与人工补偿

XXL-Job 每 15~30 分钟：采集库某患者最新数据时间 vs 本地水位，有漏判则自动补跑。仍搞不定的进死信，由人工补偿处理台介入。

6.3 出问题能查：全程可追溯

每条预警就是一条**流水线（Pipeline）**记录，配一张阶段日志表，把"查数→调 AI→推送"每一步都记下来。

• alert_pipeline：每条预警一行，记当前状态、风险级别、重试次数、错误。
• alert_pipeline_log：每个阶段一行，记阶段、耗时、请求/响应摘要、错误原因。

状态是细粒度的（不是只有"成功/失败"）：

已创建 → 已查库 → 已入队 → 消费中 → 已提交AI → AI完成
      → 预警已生成 → 推送中 → 已推送 → 完成
任意一步失败 → 等待重试 →（超次）→ 死信，等对账或人工补跑

排查示例——P001 未收到预警：查 alert_pipeline 状态为 AI_TIMEOUT → 查 alert_pipeline_log 见 AI 阶段 30s 读超时 → 任务在重试队列，等待或人工补跑。

6.4 实时看 + 能统计

实时监控大盘（管理端，Micrometer + Prometheus + Grafana）：

统计报表：按时间、风险级别、产品线、病区等维度统计预警量、AI 成功率等。实时查询走预警表聚合，历史报表用每日汇总表，避免大范围实时聚合压库。

6.5 人工补偿处理台

自动重试、对账仍无法处理的异常任务（死信、长期 AI 超时、对账漏判），由运维/管理员在人工补偿处理台介入：

死信 / 对账告警
      ↓
管理端「补偿处理台」列出异常 Pipeline
      ↓
操作员查看 pipeline_log → 确认原因
      ↓
┌─ 补跑 AI ─────────┐  ┌─ 跳过并标记 ────┐  ┌─ 强制关闭 ─────┐
│ 重新入队（新       │  │ 人工确认无需     │  │ 记录原因，      │
│ idempotency_key）  │  │ 预警，更新水位   │  │ 不再自动重试    │
└───────────────────┘  └─────────────────┘  └────────────────┘
      ↓
操作记入 alert_pipeline_log（操作人、时间、原因）

人工补偿用于自动重试和对账仍无法恢复的任务；一期先做异常列表和单条补跑，批量与跳过放二期。

七、消息怎么收发（同步/异步、RabbitMQ、多语言订阅）

7.1 哪些是同步、哪些是异步

写本地库走同步，调 AI 和推送走异步：

7.2 RabbitMQ 通讯模型

RabbitMQ 只在平台内部传研判任务：查库写入任务消息，Worker 消费后调 AI，不对前端开放。

注意：RabbitMQ 传内部研判任务，医护端走 WebSocket + REST。

拓扑：

                 ┌──────────────────────────────┐
  Outbox 投递 ─▶ │ Exchange: alert.task (direct) │
                 └───────┬───────────────┬───────┘
              routing=ICU│               │routing=ANES
                         ▼               ▼
              alert.task.icu       alert.task.anes      ← 重症/麻醉分队列，互不影响
                         │               │
                   Worker(ICU)      Worker(ANES)        ← 各自按并发消费，调各自 AI
                         │
              失败 ─▶ alert.retry.*（TTL 延迟重试）─▶ 回主队列
              超次 ─▶ alert.dlq.*（死信，对账/人工补跑）

  AI 完成且 pending=true ─▶ alert.reanalysis.delay（TTL 45s，is_reanalysis=true）─▶ alert.task.*

7.3 前端 / 不同语言怎么订阅预警

医护端不直连 RabbitMQ，统一走 WebSocket 和 REST。

一期（License 鉴权，按 room/ward 广播）：

① 设备鉴权（现有）
   POST /anesthesia/aiLicense/verify?license=xxx&clientMac=yy:yy:...
   （ICU 客户端走 /icu/aiLicense/verify，路径与现有项目一致）

② 换取 WS Token（预警平台新增）
   POST /alert/ws/token
   Body: { "license": "xxx", "mac": "yy:yy:...", "productLine": "ANES" }
   → 校验逻辑复用 AiLicenseService（license 有效 + mac 匹配 + 已绑定）
   → 返回 { "wsToken": "eyJ...", "roomId": "OR03", "expiresIn": 86400 }

③ WebSocket 建连
   wss://alert-host/alert/ws?token={wsToken}
   服务端：校验 token → Session 注册到 ANES:room:OR03（或 ICU:ward:W01）

④ 接收推送
   服务端按 alert_notice.push_route_key 向对应组广播（JSON + seq）
   客户端只处理 productLine 匹配的 message

⑤ 断线重连
   带 lastSeq → 服务端补发 id > lastSeq；token 过期则重新执行 ②

⑥ REST 兜底（Header: Authorization: Bearer {wsToken}）
   GET  /alert/notices/unread?productLine=ANES&roomId=OR03
   POST /alert/notices/{id}/read   Body: { "clientId": "license或mac" }
   POST /alert/records/{id}/ack    Body: { "clientId": "license或mac" }

推送路由示例：

二期（接入 SSO，按用户精准推送）：

1. 登录拿 Token（Sa-Token/JWT）
2. 建 WebSocket：wss://主机/alert/ws?token=...&productLine=ICU
3. 服务端按 用户 + 产品线 推送；REST 按 recipient_id 过滤

任何能发 HTTP / 连 WebSocket 的语言都能接，不用引 MQ 客户端：

消息带 productLine，客户端只处理自己产品线的，重症/麻醉互不串。

二期若有外部系统（如急诊）要订阅"预警已产生"事件，再单独开放 HTTP Webhook 或事件 Exchange，不影响医护端这套。

八、不确定的事，全做成配置

目前几个还没定的点，不写死在代码里，全部做成配置表 alert_config，业务部门讨论定了之后改配置即可，不用改代码、不用重新发版。

每条配置按产品线（ICU/ANES）独立。AI 处理能力不确定也不怕：任务先进队列排队，AI 多慢都只是排队，不会丢、不会压垮 AI；能力摸清后调并发即可。

九、核心数据表与索引

业务库 alert_platform，核心就这几张。采集库（只读）存体征与患者主数据；业务库存预警、通知、水位与快照——研判读前者，推送只读后者，不做患者主数据全量同步。

主要字段（快照与推送）

alert_record — Worker 在 AI 成功时一次性写入，后续 WS/REST 只读此表组装 payload：

alert_notice — 推送前先落库，保证「不丢」：

alert_patient_watermark — 仅用于增量查采集库，与推送无关：

Redis（非表，建议） — alert:active:{productLine}、patient_key→room/ward/bed，TTL 1~2min，减少采集库压力；不落库、不同步。

索引设计

索引按实际查询路径设计，避免全表扫：

建表 SQL 联调时再定，这里只列职责和字段意图。

十、部署与容量

部署：独立 jar / Docker 一个服务（REST + WebSocket + 内嵌调度），加 MySQL、Redis、RabbitMQ。采集库用只读账号、独立数据源。

alert-platform.jar  (8080: REST + WebSocket)
MySQL alert_platform  业务库
MySQL icu-read / anes-read  采集库(只读)
Redis / RabbitMQ / XXL-Job

容量推算（200 患者、180s 周期、每轮 30% 有新数据）：

按上面推算：

• AI 处理（~15 条/分钟/线）高于平均入队（双线约 20 条/分钟），队列可吸收突发；
• 日增约 2.88 万行业务数据 + 14 万行日志，三年内单表可不分，日志按月归档；
• 一期 1~2 个实例即可。

1000 患者时的扩展：

1000 患者 × 30% × 480 轮/天 ≈ 14.4 万条/天（5 倍于 200 人）
平均入队 ~1.7 条/秒，日峰 ~5 条/秒 —— 仍远低于 RabbitMQ 能力
瓶颈仍在 AI：单线并发 5、单次 20s → ~15 条/分钟/线

患者从 200 扩到 1000：加 Worker 实例、调 ai_max_concurrency 即可，RabbitMQ 竞争消费分摊负载，业务代码不用改。

AI 熔断期间 Worker 暂停调 AI，查库和入队照常，任务留在 MQ；AI 恢复后继续消费。期间无法产生新预警，已写入 alert_notice 的仍可推送。

十一、实施计划

需要各方确认的：