万人级赛事指挥调度平台怎么设计？从哈尔滨马拉松说起

一、3 万人的现场，调度平台要扛什么

新华网报道，9 月 13 日哈尔滨马拉松开跑，3 万人沿松花江跑 42 公里。现场警察、医生、志愿者、裁判、环卫、媒体全在一个场地里，各喊各的肯定乱套。

这种一次性活动的调度平台，跟公司日常用的办公软件不是一回事。人集中在几天内、角色互相隔离、指令得马上传到。具体拆一下需求：

一是人多，起终点几千人挤一块，语音信道不能堵。二是角色杂，公安、医疗、志愿者、后勤，各干各的，不能互相串台。三是线路长，42 公里赛道沿着松花江铺，中间还要过阳明滩大桥，信号不是哪儿都好。四是时间紧，赛前一周才进场准备，没条件慢慢调。这四条凑一块，方案就得往 "够用、快上、别瞎花钱" 的方向走。

二、平台放云端，别现场架机器

一开始考虑过现场拉服务器，找个机房机柜把设备摆上。后来算了笔账：就用 6 个小时，搬设备、布线、调试、撤场，人工加设备租赁不便宜，而且真出了硬件故障现场还不好修。直接上云端平台，按需部署，活动完了就缩容释放资源，前期配置一两个小时就能起来。

云端部署选的是几台云主机，操作系统 Linux，跑容器化服务。为什么不上 K8s 那一套？因为就跑 6 个小时，K8s 集群初始化时间比直接起容器还长，不值当。几台云主机上直接跑 Docker，前面挂个负载均衡，一台挂了另一台顶上，简单粗暴但够用。真要扩节点，镜像早就打包好了，加台主机几分钟就能接上。

数据库分了两类：群组配置、权限表这种不怎么变的数据，放 MySQL；终端位置上报频率高、数据量大，放时序数据库，按天滚动存储，赛后一删就完。告警记录单独存一份关系库，方便事后倒查。媒体素材、赛后回放视频这些冷数据扔对象存储，不用占数据库空间。

公网链路本身不靠谱，得做冗余。主链路接固定宽带，备用挂 4G 网卡，主链路断了自动切。专门测过一次：拔了主网线，2.8 秒平台恢复，正在通话的终端一部分自动重连，另一部分没感觉。这种程度在赛事场景下够用了 —— 真要是光纤被挖断，4G 顶上至少关键指令还能喊出去。

平台本身拆成几个独立服务跑：终端注册、权限、群组、位置、告警，哪个挂了不影响其他。值守的时候盯着一块大屏，看终端在线率和人员位置，这是 6 小时里盯得最久的界面。大屏数据不是终端直接推给大屏的，终端先推到消息网关，网关分发给大屏和调度坐席，避免所有终端都连着大屏造成连接数爆炸。

这次用的是 LONPTT 公专融合调度平台，终端和平台的对接是现成的，省了从零开发的时间。公网信号好的地方直接走公网，个别弱覆盖点位加便携中继补盲，不用为了几处盲区全线铺专网。

三、终端和平台怎么通信

这部分是工程细节，也是最容易踩坑的地方。

终端和平台之间长连接，走的 MQTT。选 MQTT 不是因为多高级，是因为终端资源有限，MQTT 协议头小、心跳轻，几百台设备长连接不会把服务器压垮。为什么不用 WebSocket？终端上跑 WebSocket 也不是不行，但 MQTT 在弱网环境下重连机制更成熟，而且支持 QoS 分级，这个后面讲。

语音不走 MQTT—— 语音是实时流，走的 RTP，和控制信令分开。这么做的好处是，就算信令通道卡了或者 MQTT 连接断了，已经建立的语音通话不会断，只是挂电话和重新呼叫受影响。PTT 对讲是半双工，按下说话、松开听，比全双工省带宽，codec 选的是窄带，语音够清晰就行，没必要上宽带占带宽。

消息按重要性分三档：语音包走独立 RTP 通道，和信令完全分开；告警消息走 MQTT 最高 QoS，平台必须确认收到，丢了重传；位置上报和状态心跳走最低 QoS，丢一两条无所谓，下一条马上来。这么分是因为位置数据本来就是 30 秒一报，丢一条不影响整体判断；但告警要是丢了，就是真事故。

心跳间隔也调过。默认 60 秒心跳，几千台终端同时离线重连的时候，服务器会被一波连接打挂。改成 30 秒心跳加随机抖动，让终端不是在同一秒同时发心跳，连接分布就平滑了。断线重连用指数退避，1 秒、2 秒、4 秒、8 秒封顶，避免终端疯狂重连把服务器冲垮。这些参数赛前都压测过，真到比赛当天不用临时调。

四、群组怎么分才不吵

7 个岗位全塞一个群里，安保喊一声，医疗也跟着听，全乱。最后定的结构是：

顶上加一个指挥组，能跨组听、能全频道广播；下面 7 个业务组各喊各的；志愿者组人最多，按赛段拆成 3 个小组。普通组员听不到别的组说话，指挥中心想切哪个组听就切哪个。

权限这块做了细分。普通组员只能在自己组里说话，不能呼别人；组长能组内呼叫，不能跨组；指挥组的人全权限，能监听、能插播、能全域广播。媒体组特殊，只能听不能说，防止现场媒体误操作把指挥频道占了。

群组呼叫的信令流程也说一下：有人按下 PTT 键，终端先发个 "申请说话" 的信令到平台，平台看这个组现在有没有人在说，如果没有就把说话权给它，组内其他终端收到 "开始收听" 的信令，就开始收 RTP 语音流。松开 PTT 再发个 "说话结束"。这个流程保证了一个组同一时间只有一个人在说，不会两个人抢话叠在一起。

组的数量得试。这次 7 个业务组加 1 个指挥组，几百台终端跑下来正好。组少了组内互相吵，组多了指挥中心切不过来，这个数是试出来的，不是拍脑袋定的。志愿者按赛段拆子组也是现场需要 —— 一个志愿者组两百人，全在一个组里，谁在哪段都不知道，拆成三段就清楚了。

五、位置上报别一直高频

终端一直 2 秒报一次位置，平台扛不住，电池也掉得快。做了个简单的分级：

平时 30 秒报一次，够看个大概路线。有人按告警键，或者终端进到预设的电子围栏区域，自动切到 2 秒一次，能跟着人走。终端用户感觉不到切换，就是告警了之后指挥中心看到位置一直在动。

定位用的是 GPS 加北斗双模，比单北斗或单 GPS 在城市楼宇区靠谱。电子围栏提前在地图上画好 —— 医疗站、补给点、关键路口，终端一进去就触发高频上报。围栏坐标是提前勘测时标的，存数据库里，终端进了范围平台自动改上报策略，不用人工干预。

大屏上看几百个终端的位置，不是每个终端位置变了就刷一次屏 —— 那样 60 帧都扛不住。网关把位置数据做了节流，每 2 秒批量推一次给大屏，大屏上的点慢慢移动，看着也流畅。真告警的那个点，单独高亮闪烁，不用节流。

算过账：全程 2 秒上报，平台消息量是原来的 15 倍，电池续航掉四成，没必要。分级就是省资源的办法。位置数据存时序库，按天滚动，赛后调出来看保障人员轨迹，哪个点出了问题倒查起来方便。

六、告警联动：按键之后发生什么

一键告警是用得最多的功能。流程其实不长：

有人按了告警，平台 1 秒内弹出来 —— 谁、哪个组、在哪。下面列周边 500 米在线的终端，点谁就直接呼谁，不用翻通讯录。

告警分了三级：普通求助是黄色弹窗，只要组长和指挥中心看到；选手受伤是红色弹窗，指挥中心强制弹窗加声音提醒；紧急情况是最高级，直接打断正在进行的其他通话。这个分级避免了鸡毛蒜皮的事把指挥中心刷屏，真出事的时候又能跳出来。

周边终端列表是实时算的，根据位置上报数据，把告警人周围 500 米内在线的终端列出来。这个计算不复杂 —— 拿告警点经纬度和终端经纬度做球面距离公式，500 米内的筛出来就行，性能不是问题。点哪个就直接建立单呼，语音走 RTP 通道，不经过群组。

32 公里处出过一次事：选手不舒服，旁边志愿者按了告警。指挥中心看到附近 1.2 公里有辆救护车，直接点了救护车终端的名字，车就过去了。从按键到救护车到现场，数分钟。要是搁以前，打电话问医疗站、再问救护车在哪，来回沟通就慢了。

七、和基站、无线电监测怎么配合

调度平台跑在公网上，基站堵了平台也卡。网络真堵的时候，位置上报会自动降频到 10 秒一次，语音和告警不受影响 —— 这个策略在起点广场人最多那半小时试过，语音没卡，位置数据确实慢了点，但能接受。

央广网报道里提了两套保障在同时跑：运营商那边 198 个基站分级守着，50 个守起终点，148 个沿赛道，5 台应急通信车补位；无线电管理那边 3 台监测车、11 个人，全程扫频率，比赛没出一起干扰事件。调度平台是站在这两层肩膀上的 —— 基站和频率稳了，平台才稳。

八、赛前压测怎么做的

方案配完，赛前 3 天做了两轮压测加一轮故障演练。

压测就是把所有终端集中到一个区域，模拟起点高峰。每台终端平均每 2 分钟发起一次 30 秒组呼，同时按周期上报位置，持续半小时。看几个数：终端在线率、峰值并发路数、语音时延、丢包率、位置上报成功率。时延均值大概 380ms，P95 在 520ms 上下，800ms 以内都能接受；丢包均值 0.3% 左右，峰值不到 1%。这些是我们自己测的，不是实验室数据，但是现场够用。

故障演练就演主链路断了 —— 人为拔了主网线，看 4G 备用多久能切。2.8 秒切完，正在通话的一部分重连，一部分没感觉。又演了盲区切换：在提前标的几个弱覆盖点，终端从公网切到便携中继，语音卡 1 秒多，不断线。

测试过了才敢往现场发设备。赛前一天所有终端充电、校验按键、预加载群组，按岗位分装。培训就三件事：开关机、换群组、告警键在哪。

九、几个现场踩过的坑

培训别搞复杂。用设备的是警察、医护、志愿者，不是搞通信的。告警键上贴个红标，比讲十分钟管用 —— 现场还是有人找不到，红标一贴就多了。

安保组的电不够用。他们全程在喊，后半程有人设备低电。下次直接给这组配充电宝，别等换电池。我们这次准备了备用电池，但换电池得人跑到现场，耽误事。

阳明滩大桥上语音偶尔延迟偏高。P95 在合格线内，但偶尔冒头。下次桥上多加一台中继压一压。这个问题赛前压测没测出来，真跑起来人流上桥和测试的时候两码事。

还有个连接层面的坑：赛前第一次上线的时候，几百台终端同时开机，MQTT broker 一瞬间被连接冲满，一批终端没注册上。后来改成终端开机时间随机错开，有的开机等 5 秒、有的等 30 秒，连接就平滑了。这种问题压测的时候没想过，真到现场几百人同时开机才暴露。

十、几句实话

这次能跑完 6 小时没出大事，一半靠方案，一半靠两个人现场轮班盯了全程。方案设计得再漂亮，没现场踩过坑、没人盯着大屏实时处置，照样出问题。

赛后复盘也总结了下次要改的：桥上中继加一台、高呼叫岗位配充电宝、告警键贴红标、开机时间错开。这些都是现场踩出来的，不是坐在办公室能想全的。

信源：新华网《2026 哈马鸣枪开跑》、央广网《黑龙江移动护航 2026 哈尔滨马拉松》、央广网《黑龙江省无线电管理机构圆满完成 "哈马" 安全保障工作》