波仔
📹 第十章 GB／T 28181协议原理
📄 一句话概括

报警是「设备主动推」，和查询正好反过来：查询是平台问、设备答；报警是设备说、平台听。 它的带宽小得可以忽略，但处理量可能压垮平台——洪峰时每分钟几万条，每条还要联动。

📝 本节和前面几节的关系

前面几个流程都是「平台发起」。这一节第一次讲「设备发起」。 主动推送带来一个新问题：平台不知道下一秒会来多少条。 所以它必须有「限流」和「分级」。

一、主动推送的三种情况

报警推送有三种触发方式： 设备自己判断（移动侦测、区域入侵）、外部信号（报警输入口被短接）、平台下发（手动触发）。 三种在报文里的区别在 AlarmMethod：同一个 Notify，方法字段不同，含义就不同。 报警报文里的关键字段有四个：优先级、时间、方法、描述。 优先级决定怎么处置，时间决定去重，描述是给人看的。 「时间」这个字段特别要注意：它是设备时间，不是平台时间。 设备没校时的话，这个字段可能差好几天——所以收到报警要先用「平台时间」打上接收时刻。

二、带宽不是问题，处理才是

一条报警报文两百多字节，一千路设备哪怕每秒各报一条，也就两兆。 这个量对任何平台都不算什么。 真正的压力在「每条要做什么」：落库、查预案、联动抓图、联动录像、发通知。 一次报警的成本不是两百字节，可能是一路流。 这就是「报警放大效应」：入口只有几兆，出口可能是几十路视频。 很多平台上线第一天没事，装到一千路就崩，原因就在这儿。 所以限流必须做在「联动」这一层：同一台设备同一类报警，一分钟内只联动一次。 这不是偷懒，是正确—— 同一个区域一分钟内被触发二十次，人只需要知道一次。

三、分级：最怕的不是误报

报警必须分级，因为人的注意力是有限资源。 一级立即联动加弹窗，二级落库加列表提醒，三级只落库不打扰。 不分级的后果很具体：半夜一只猫走过，整个值班室响成一片；第二天所有人都会把报警关掉。 报警系统最怕的不是误报，是「被关掉」——一旦被关掉，真正的入侵也不会有人看。 所以「降低误报」这件事的价值，不在技术指标上，在「系统还活着」上。

四、动手 Demo：报警洪峰来了，平台要接住多少条

造一条真实的报警报文，量它的长度和标签占比。 再按三种场景算千路设备的推送量和平台的处理压力。

body = ('<?xml version="1.0"?>'
        "<Notify><CmdType>Alarm</CmdType><SN>1</SN>"
        "<DeviceID>34020000001320000001</DeviceID>"
        "<AlarmPriority>1</AlarmPriority>"
        "<AlarmTime>2026-10-24T09:15:30</AlarmTime>"
        "<AlarmMethod>5</AlarmMethod>"
        "<AlarmDescription>区域入侵</AlarmDescription></Notify>")
tags = re.findall("<[^>]+>", body)
print(len(body), sum(len(x) for x in tags))

for name, per in (("平时", 60), ("忙时", 10), ("洪峰", 1)):
    pps = 1000.0 / per
    print(name, "%.1f 条/秒" % pps,
          "%.2f Mbps" % (pps * len(body) * 8 / 1e6))

实跑输出：

--------------------------------------------------------------------
报警洪峰来了，平台要接住多少条
--------------------------------------------------------------------
**报警报文是「设备主动推」**：**平台订阅了，设备一有报警就发一条 `Notify`。**
**它和查询是反的**：**查询是平台问、设备答；报警是设备说、平台听。**

  一条报警报文 256 字节
  其中标签占 205 字节、内容占 51 字节

  场景                        千路每秒             带宽              平台每分钟
  ------------------------------------------------------------------------------------------
  **平时（每分钟 1 条）**     **16.7 条/秒**       **0.03 Mbps**     **1000.0 条/分钟**
  **忙时（每分钟 6 条）**     **100.0 条/秒**      **0.20 Mbps**     **6000.0 条/分钟**
  **洪峰（每秒 1 条）**       **1000.0 条/秒**     **2.05 Mbps**     **60000.0 条/分钟**

**带宽那一列全都很小**，最大也就几兆——**所以报警从来不是带宽问题，是「处理不过来」的问题。**
**看第四列**：洪峰时平台每分钟要处理六万条，**每条都要落库、可能还要联动抓图、发通知。**

**真正的放大效应在「联动」上**：
**一条报警如果触发抓图，就是一次对设备的额外请求；触发录像，就是开一路流。**
**一次报警的成本不是三百字节，可能是一路流。**

**所以报警处置必须分级**：
  级别                 处置
  -----------------------------------------------
  **一级（紧急）**     **立即联动抓图＋弹窗**
  **二级（重要）**     **落库＋列表提醒**
  **三级（提示）**     **只落库，不打扰**

**不分级的后果很实际**：**半夜一只猫走过，整个值班室响成一片，第二天所有人都会把报警关掉。**
**报警系统最怕的不是误报，是「被关掉」。**

两百五十六字节的报文里，标签占了两百零五字节——八成是标签，真正的信息只有五十一个字节。 这是所有 XML 协议的通病，也是它「可读」的代价。 三行带宽全在零点零几到两兆之间，所以「报警会不会把网络压垮」这个问题，答案是不会。 看第四列才看清压力在哪：洪峰时平台每分钟要处理六万条。 六万条意味着六万次解析、六万次落库、可能还有几万次联动判断。 那个「一次报警的成本可能是一路流」的说法不是夸张： 一条报警触发录像，就是开一路 RTSP 或国标会话。 一百条同时触发，就是一百路流。

30 秒实验

  1. 算一下：一条 256 字节的报警，标签占了多少？（205 字节）
  2. 想一下：为什么报警的「时间」字段不能直接用？
  3. 想一下：限流为什么应该做在「联动」这一层？

常见误区

  1. 以为「报警流量大会压垮网络」。 带宽很小，压垮平台的是处理量。
  2. 以为「每条报警都该联动」。 联动会放大成倍，必须限流。
  3. 以为「误报只是烦人」。 误报多了会让人把报警关掉，那才是真正的风险。
自测三问（点开对答案） 1. 报警推送和查询的本质区别是什么？ —— **报警是设备主动发起，查询是平台发起**。 2. 报警报文的四个关键字段是什么？ —— **优先级、时间、方法、描述**。 3. 为什么报警必须分级？ —— **人的注意力有限**，**不分级就会「响成一片」，最后被整体关掉。**

下一节讲查询：一万路目录一次查不完，怎么分页、怎么续查。

相关笔记