机器人一多服务器就崩？从轮询到事件驱动的架构改造实践

做机器人后端这些年，我见过太多“一多就崩”的项目了。所谓的“一多”，往往不是算法算力问题，而是通信方式本身扛不住。具身机器人这东西，一旦数量超过某个临界点，服务器会以一种非常朴素的方式教做人：先 CPU 报警，然后连接数打满，最后接口超时，谁调用谁怀疑人生。我之前排查过几套调度系统，最后定位到的核心原因几乎都是同一个：状态轮询还在当主角，事件驱动迟迟没上位。

这篇文章想完整记录一下我在这类问题上的排查思路和改造方案：为什么机器人一多服务器就崩，轮询到底怎么把服务拖垮的，以及从状态轮询切到事件驱动时真正落地要做哪些事。适合正在做机器人调度、IoT 平台、设备接入服务，或者纯粹被“设备一多就卡死”折磨过的后端开发同学参考。

1. 先从根子上说：为什么机器人一多，服务器先扛不住

1.1 你以为是硬件问题，其实是通信模型问题

先说个很典型的现场。某条产线上有十几台移动底盘加几台机械臂，后端跑在一台 4 核 8G 的云服务器上。早期跑得还行，因为设备少，每台机器人每隔 2 秒上报一次位置和任务状态，服务器每秒收到的请求量也就个位数。后来机器人数量增加到三四十台，机械臂工位也接进来，服务器开始频繁告警。

很多人第一反应是加配置：内存不够加内存，CPU 不够升核数。但加完配置以后只是“缓一口气”，过一阵子又被打满。原因很简单：请求量并没有因为硬件变强而减少，通信模型里充斥着大量无效请求。更麻烦的是，这些请求每一次都会带回数据库查询、鉴权、序列化、日志记录甚至慢 SQL，等于服务器一直在做无用功，却以为自己很忙。

我习惯把这个现象讲成一个办公室类比。一个人坐在工位上，每隔两分钟挨个问同事“你现在有没有事？现在进度怎么样？需不需要我帮忙？”问十个人还能接受，问一百个人的时候，他根本没法做自己的本职工作。具身机器人集群也是这个道理。每台机器人周期性地向服务器发起状态查询，即使它的状态完全没变化，流量也一样产生，数据库也一样被查一遍。

这不是硬件问题，是通信模型该换了。

1.2 轮询的“舒适区”是怎么一步步变成瓶颈的

轮询在早期项目里几乎是必然选择。它写起来太简单了：机器人端开一个定时器，每隔几秒发一次 HTTP 请求，告诉服务器自己在哪、任务进行到哪一步。服务端只需要定义一个接口，接收数据、更新数据库、返回结果。出问题的时候也特别好排查，打印日志，一眼就能看到这个接口有没有被调用。

问题是它有个隐藏的“舒适区”。当机器人只有几台、十几台时，轮询频率低，每次请求返回的数据量也不大，服务器的线程池和数据库连接池都绰绰有余。代码里没有人会觉得现状有问题，甚至会形成一个默认认知：机器人通信就该是这种一问一答的模式。

等规模上来以后，舒适区就变成泥潭。我见过最夸张的一种写法是：一台机器人上，底盘模块、机械臂控制模块、视觉识别模块、业务调度模块分别独立轮询服务器，一台机器人等于四五个“客户端”在同时跑。更糟的是，有些前端页面也用setInterval定时刷新状态，前端每刷一次，后端接口就被打一次。所有流量堆在一起，服务器根本不像是被某个高并发业务打崩的，而是被无数个低频率轮询叠加起来压垮的。

还有一层隐藏成本是数据库。状态轮询通常意味着每次请求都会把“当前状态”写一遍。机器人一多，写入频率线性上升，数据库的insert和update频繁排队，慢查询开始出现，连接池很快被占满。这种问题如果只靠优化 SQL 或者加缓存，只能暂时缓解，因为源头并没有被处理掉。

1.3 用数字估算一下，轮询压力到底翻了多少倍

我一直建议团队在动工之前先把账算清楚。轮询的压力不是“每台机器人发一个请求”这么简单，它等于：

总请求负载 = 机器人数量 × 每台机器人轮询频率 × 每次轮询触发的接口数量

如果每台机器人上还分多个模块独立轮询，这个数值会进一步放大。举个例子，假设每台机器人每秒轮询一次，每次轮询会请求 3 个接口，那么不同规模的负载如下：

这里的 450 只是理论请求量，还不包括 TLS 握手、鉴权、日志、数据库查询带来的放大。真实系统里，每次查询可能还会带上历史任务、告警信息、配置参数，一个请求背后可能连着好几个数据库查询。负载一旦接近处理上限，请求排队又会反过来拖慢单个请求，形成雪崩效应。

对比之下，事件驱动的请求量只和“真实状态变化次数”有关。一小时内没有状态变化，就不产生业务请求，服务器保持安静。这也是为什么我后来做机器人通信架构时，优先考虑事件驱动，而不是继续优化轮询的性能。

2. 事件驱动和轮询的本质差别到底在哪

2.1 核心思想对比：主动问还是被动等

轮询和事件驱动的差别，用一句话概括就是：轮询是“我定期来问”，事件驱动是“你有变化了再告诉我”。

听起来简单，但这两者在系统设计上的影响完全不同。轮询是一套“主动拉取”模型，客户端按照固定周期请求服务端，服务端只能被动响应。事件驱动是一套“发布订阅”模型，状态变化的源头主动把事件推送出去，关心这件事的服务自己去订阅。

我用一个表格把关键差异列出来，大家做选择题的时候可以直接对着看：

轮询其实也不是没有优点。它天然带有心跳能力，服务器可以通过“多久没收到请求”来判断设备是否离线。而且它足够简单，任何语言都能实现，排障时思路也直白。事件驱动真正的价值在于，它把“周期性占用”变成了“按需占用”，服务器不再为没有意义的变化买单。

2.2 机器人场景下哪些事件适合“被驱动”

在具身机器人系统里，并不是所有数据都适合用事件驱动。我一般会把状态分为三类。

第一类是“低频关键事件”，直接用事件驱动最划算。比如任务状态从执行中变成已完成、机器人触发急停、电量低于阈值、机械臂抓取到位、视觉识别返回异常结果。这类事件虽然很重要，但一天里发生的次数有限，不适合用高频轮询去盯。

第二类是“中频业务状态”，可以做成带节流的事件。比如机器人的位置变化，工位任务进度，地图更新状态。位置如果每 10 毫秒变一次，硬套事件驱动也不合适，容易把系统变成高频消息流。我更倾向于把它改成“位置变化超过一定阈值后才上报”，或者定时汇总一包位置数据再发出去。

第三类是“高频连续数据”，比如电机电流、关节角度、高频里程计、实时视频流。这些数据天然是流式数据，不适合用普通事件去表示。通常应该走独立的数据通道，比如 gRPC 双向流、RTSP、内部共享内存，而不是硬塞进事件总线里。

所以，更准确的说法不是“彻底扔掉轮询”，而是“把轮询只留给必要的心跳和兜底查询，把业务状态迁移到事件驱动的轨道上”。这样做既能享受事件驱动的低负载，又不会被高频传感器的数据流绑架。

2.3 长连接、消息推送和队列之间的关系

事件驱动不是凭空冒出来的概念，落地的时候一定会涉及三样东西：长连接、消息推送、消息队列。

长连接解决的是“连接成本”问题。HTTP 轮询每次请求几乎都要重新建立连接、请求、响应、断开，一个请求的握手开销甚至比业务处理还大。长连接建立后一直保持，服务端随时能把事件推送下去，客户端也随时能上报。常见的载体有 WebSocket、MQTT over TCP、gRPC 流，本质都是为了省掉频繁握手。

消息推送解决的是“主动性”问题。服务器不再等着客户端来问，而是在事件发生的一瞬间，把状态变化直接推给需要的人。对机器人调度页面来说，前端不再需要用setInterval去刷状态接口，WebSocket 一推，页面立刻更新。对机器人本身来说，服务端下发新任务时，也不再等机器人下一轮来“问”任务，而是通过 MQTT 消息直接把指令发给指定的机器人。

消息队列解决的是“缓冲”问题。事件可能瞬间爆发，比如 100 台机器人同时上报“任务完成”，后端如果直接同步处理，很容易瞬间打满线程池。事件先进队列，消费者按自己的能力一批一批处理，就相当于在入口和业务处理之间加了一个水库。这样既不会丢掉事件，也不会因为某一瞬间的峰值把服务压垮。

三者配合起来，才是完整的事件驱动链路：机器人端产生事件 -> 通过长连接推送到网关 -> 事件进入消息队列 -> 后端消费者处理并更新状态 -> 通过长连接推送给订阅方。

3. 具身机器人场景的落地改造方案

3.1 从状态上报到事件订阅的整体流程

改造第一步，先把整个通信链路的图画出来，别急着改代码。我当时面对的方案是这样：

机器人端业务模块 ↓ 产生状态事件 机器人端事件采集层（节流、聚合、本地缓存） ↓ MQTT/WebSocket 上报 接入网关/Broker（长连接管理、鉴权、Topic 隔离） ↓ 原始事件 消息队列（Redis Stream / Kafka / RabbitMQ） ↓ 去重、排序、业务过滤 状态聚合服务 → 更新 Redis / MySQL ↓ 事件广播 调度台 WebSocket 推送 → 前端界面实时刷新

这条链路里，机器人端的事件采集层特别容易被忽视。很多人以为事件驱动就是在代码里把“定时上报”改成“状态变化就上报”，然后就直接发消息。结果上线第一天，前端收到几千条细粒度事件，所有人都在刷屏，服务器照样波动。正确的做法是在端侧先做一次“信息浓缩”：哪些事件值得上传，哪些事件合并后上传，哪些事件根本不需要上传。

我常用的一个原则是：单个事件如果对“后端决策”和“前端展示”没有直接帮助，就不上传。举个例子，底盘导航模块每秒钟都在重新规划路径，这个事件本身并不重要，重要的是“机器人进入目标区域”“机器人完成避障”“机器人停车”这些动作性事件。把连续的过程抽象成有限的动作点，事件量自然就降下来了。

3.2 消息协议选型：MQTT、WebSocket、gRPC 怎么挑

事件驱动的落地，绕不开协议选型。我自己在机器人项目里接触最多的是三种：MQTT、WebSocket、gRPC 双向流。它们的侧重点完全不同，不能一概而论。

MQTT 是物联网场景的标准选手。它基于主题订阅，天然支持一对多广播，还有 QoS 0/1/2 三个级别的投递保障。在弱网和移动机器人场景下，MQTT 的断线重连、遗嘱消息都比较成熟。机器人端只要用轻量级 SDK，就能很方便地把事件发布到robot/{robot_id}/event这个主题上，服务端订阅后统一处理。它的缺点是必须额外部署一个 Broker，比如 EMQX、Mosquitto，系统多一个组件，也就多一个需要运维的点。

WebSocket 最大的优势是浏览器友好。调度台和前端页面可以直接建立 WebSocket 连接，让页面实时接收状态变化，替代掉前端那套定时器轮询。但它的语义比 MQTT 简单得多，没有 QoS，消息确认需要自己实现。我通常的做法是：机器人和服务端之间用 MQTT，服务端向前端推送用 WebSocket，两边各干各最擅长的事。

gRPC 双向流适合服务端到服务端的高吞吐通信，也适合机器人端是 Linux 工控机、且团队有能力自己掌控整套链路的情况。它强类型、二进制序列化、性能高，天然支持多路流式消息。缺点是对嵌入式设备的支持不如 MQTT 成熟，如果机器人端的 MCU 资源很紧张，上 gRPC 就得慎重考虑。

如果是新项目，我给的选型建议很简单：机器人端能力强、网络环境可控，优先选 MQTT；机器人端是 Linux 工控机，且后端已经有 gRPC 基础设施，可以选 gRPC 双向流；前端展示一律走 WebSocket。至于自研 TCP 私有协议，除非团队有长期维护能力，否则不建议在普通业务里自己造轮子。

3.3 服务端的事件分发与连接管理怎么做

服务端作为整个事件驱动架构的中枢，只做好三件事基本就够了：接住连接、转发事件、管理状态。

接住连接的意思是，服务端要知道现在有哪些机器人在线，每个机器人用的是哪一个连接通道，它的认证信息是什么。我用 Redis 维护一张连接表，robot_id -> connection_id，机器人上线时写入，心跳超时后移除，断线重连时更新。这张表同时也能让指令下发服务知道：要给某台机器人发任务，应该发到哪个通道。

转发事件要处理好主题。MQTT 天然把事件按主题隔离，比如robot/001/status、robot/001/alarm、robot/001/task。服务端订阅这些主题后，不需要把事件原样塞进同一个管道，而是要按照业务类型分流。告警事件直接进告警中心，任务事件进任务调度器，状态事件进状态更新服务。这样各条业务线互不干扰，一个模块挂了也不会拖累所有事件。

管理状态需要处理“最终一致性”。机器人可能离线一段时间再上线，服务端不能只靠事件增量来恢复全貌。我通常会在机器人上线或者重连时，先让它做一次全量状态同步，把当前位置、当前任务、当前故障码一次性拉上来，然后再切换到事件增量模式。也就是说，事件驱动不等于没有“兜底同步”，而是把全量同步的频率压到最低，只在建连和异常恢复时才发生。

3.4 机器人端侧的事件采集、节流与补偿

机器人端是整个改造里最容易出事的一环，因为嵌入式环境里的资源有限，而且实时性要求高。我总结下来，端侧要做四件事：检测变化、节流、批量上报、本地补偿。

检测变化不能靠定时器扫描，最好用回调或者中断机制。状态变化时触发事件，而不是每隔几十毫秒去比对一下状态有没有变化。比如机械臂运动到位，轨迹规划器会主动抛出一个“到达目标点”事件；免碰撞系统触发急停，控制模块立刻产生“emergency_stop”事件。这样事件的产生本身就不是靠轮询推动的。

节流是为了防止事件风暴。举个例子，机器人位置每 10 毫秒变化一次，如果每 10 毫秒发一条事件，服务端根本吃不消。我给位置事件加了一个“最小变化阈值”：只有移动超过 5 厘米或者航向角变化超过 2 度才上报；同时加上时间窗口，保证一秒钟最多上报几次。对于一些带抖动的传感器信号，还需要做消抖，比如 IO 信号持续稳定 50 毫秒后才认为状态真的变了。

批量上报的意义在于减少网络包数量。端侧把 50 毫秒内收集到的事件缓存到一个队列里，凑够一包再发，或者每隔 200 毫秒刷一次。这样事件并没有丢失，只是被延迟了一点点，但网络 IO 和 Broker 的压力会小很多。

本地补偿解决的是离线问题。机器人网络不稳定，事件发到一半就断线，这时候事件不能直接丢。我会在端侧维护一个小容量的环形缓存，断线期间事件缓存到本地，重连成功后再按顺序补发。关键事件必须标记为“可靠事件”，服务端收到后返回确认；没确认的事件，客户端会有超时重发逻辑。

4. 实操过程：一次机器人规模扩大引发的重构实录

4.1 现象描述与排查入手点

之前处理过一个很典型的项目。现场有 30 台移动机器人，每台机器人的调度模块、导航模块、充电模块分别向服务器轮询。轮询频率是 1 秒一次，每台机器人大概有 3 个接口在持续被调用。服务器很快就出现了“早上刚重启，下午又告警”的循环。

我接手时看到的直接现象是：CPU 使用率长时间保持在 80% 以上，HTTP 线程池打满，接口平均响应时间从几十毫秒飙到两三秒，前端页面一直在转圈。服务器日志里密密麻麻全是线程池拒绝和等待超时的记录。数据库那边也不乐观，状态表里每秒钟有几十条插入请求，慢查询日志刷得飞快。

排查的时候我并没有急着改架构，而是先花了半天时间把流量来源梳理清楚。具体的排查步骤大致是：

1. 先在 Nginx 或者网关层面按接口维度统计 QPS，找出哪个接口被调得最多。结果毫无悬念，/status和/task/poll占了差不多九成的流量。
2. 用top和jstack看服务器 CPU 和线程栈。线程池里大量线程都卡在数据库查询和网络读写上，处理业务逻辑的时间反而很少。
3. 从机器人端抓日志，确认这些请求的响应内容绝大部分都是“状态没变化”或者“没有新任务”。

其实到这一步，问题已经很清楚了：不是机器人的业务逻辑复杂，也不是服务器配置太低，而是整个系统把大量资源花在了“不停确认对方没有变化”这件事上。这时候再不做架构调整，加多少台服务器都只是临时止痛。

4.2 机器人端改造步骤

机器人端的改造目标很简单：把“高频主动上报”改成“事件触发上报 + 低频心跳”。

我先在机器人端加了一个事件采集模块。原来各业务模块各自发 HTTP 请求，现在改成把事件写入一个统一的事件总线。事件类型包括任务状态变化、导航到达目标点、机械臂动作完成、急停触发、电量告警、充电完成等，每类事件都有固定的结构，统一带robot_id、event_id、timestamp、type和data字段。

然后做了节流和聚合。位置类事件只有在移动距离超过阈值时才上报，并且每 200 毫秒聚合一次；任务类事件不做聚合，但用消抖逻辑避免重复触发。所有事件在端侧先进一个队列，SDK 负责把队列里的若干条事件打包，通过 MQTT 发布到robot/{robot_id}/event主题上。

心跳没有完全去掉。机器人每 10 秒发一次心跳包，里面携带当前电量、当前任务 ID、当前运行状态等少量关键信息。这样服务端能识别设备在线状态，机器人端也能定期把一些没有变化但很重要的状态“压个点”，避免服务端长时间收不到任何消息就误判机器人为离线。

我还在端侧加了一个本地事件缓存。MQTT 断线时，事件不会直接丢弃，而是先缓存到本地文件里，最多保留最近 500 条。重新连上 Broker 后，按照事件序号顺序补发。对于任务完成、急停这类关键事件，还会额外做一次确认机制，收到服务端确认回复后才认为事件真正送达。

4.3 服务端改造步骤

服务端这边，我引入了一个 MQTT Broker 作为设备接入层，然后用自研的事件消费服务去订阅 Broker 上的所有机器人事件。

接入层做的事情很纯粹：机器人长连到这里，发布事件、订阅指令、维持心跳。我在 Broker 层面把每个机器人的事件主题隔离，不允许跨机器人订阅，避免设备间串数据。设备鉴权也放在接入层，只有注册过的robot_id和密钥才能建立连接。

事件消费服务是改造的核心。它订阅所有robot/+/event主题，收到原始事件后先做一遍规范化和去重，然后把事件写入 Redis Stream。按robot_id做哈希分片，确保同一台机器人的事件被同一个消费者线程处理，这样就不会出现“后产生的事件反而先被处理完”的顺序问题。

状态聚合服务从 Redis Stream 里消费事件，更新每台机器人的实时状态。这个状态不是直接写 MySQL 的。我先写 Redis，用HSET robot:{robot_id} status "executing"这种方式把所有实时状态放在内存里，供查询接口快速返回。MySQL 那边只做持久化，由批量任务每隔 5 到 10 秒把一段时间内的事件汇总写入一次，写量就降下来了。

调度大屏和前端页面也不再轮询。服务端新增了一个 WebSocket 网关，前端连接上来后，通过消息队列订阅相关机器人的状态变更事件。状态一变，前端立刻收到推送，页面直接刷新。原来前端那个定时器轮询代码，直接整段删掉。

4.4 压测数据与效果对比

改造完之后，我们做了一轮对比压测。压测条件是在同一套服务器配置下，用模拟程序接入 500 台机器人，分别对比改造前的 HTTP 轮询模型和改造后的事件驱动模型。

轮询模型的数据让人心里有数：接入到 100 台时 CPU 已经接近 60%，响应时延开始波动；到 300 台时服务器出现大量请求排队，整体处于不可用边缘。事件驱动模型这边，500 台机器人同时接入，事件频率按平均每台每 5 秒产生 1 条事件计算，每秒事件总量只有 100 条左右，服务器 CPU 稳定在 20% 上下，调度页面的状态延迟从秒级降到百毫秒以内。

当时的参考数据大概是这样的：

这组数据最能说明问题：不是我们给服务器省了多少资源，而是把通信模型换成事件驱动以后，服务器的压力变成了“跟随真实事件变化”，而不再是恒定不管不顾的负担。

5. 迁移过程中常见的坑，以及我的排查习惯

5.1 事件驱动不是“银弹”

把切换事件驱动想成“改完就万事大吉”，这可能是最大的坑。事件驱动解决的是无效请求和周期性负载问题，但同时也把复杂性转移到了另一个层面。

首先是消息可靠性。HTTP 轮询天然是“调用一次，成功一次”，失败了可以立刻看到状态码。事件驱动不一样，它走的是异步链路，消息可能在网络中丢失，可能重复投递，可能乱序到达。服务端必须为重复消息做幂等处理。比如同一个任务状态事件重复收到两次，不能用第二次去覆盖第一次已经更新的新状态，否则会出现状态倒退。我一般会给每个事件分配一个全局唯一的event_id，服务端用 Redis 做去重，同一个事件的重复投递直接丢弃。

其次是消息顺序。同一台机器人的事件，如果被不同消费者线程并发处理，顺序很容易乱。我这边强制按robot_id哈希分片，保证同一台机器人的事件永远进入同一个分区，由同一个消费者串行处理。这样虽然牺牲了一点吞吐，但换来的是状态一致性。

第三是连接管理。服务端重启以后，所有机器人会同时尝试重连，出现“断连风暴”。如果不处理，Broker 反而会在服务刚启动时被连接请求打爆。解决办法是在客户端加随机退避，重连前等待一段随机时间，比如 1 秒到 5 秒之间随机，而不是所有设备同时秒连。

5.2 常见故障速查表

做事件驱动改造时，遇到的多数问题其实是有套路可查的。我把自己踩过的坑整理成一个速查表，方便大家对照排查：

这些问题不是事件驱动独有的，但确实是异步化之后更容易暴露出来的点。我的排查原则是：先怀疑网络层，再怀疑协议层，最后才怀疑业务逻辑。因为事件驱动的故障通常不像轮询那样直接“报错”，而是表现为“状态一直没更新”“数据偶尔不对”，需要从链路的不同环节逐层验证。

5.3 我的自检清单

最后分享一套我在做类似改造时都会跑一遍的自检清单。每次切换到事件驱动之前，我都会把这些问题写在项目文档最前面，大家也可以拿去对照：

• 这个状态变化频率是多少？一天有多少条真实有效的事件？如果事件总量本身很大，是不是要做更粗粒度的聚合。
• 端到端延迟目标是多少？从机器人产生事件到前端看到更新，中间的链路能承受几秒的延迟？延迟要求越严，链路设计越要精简。
• 事件丢失是否可接受？如果不可接受，客户端和服务端都要有确认和补偿机制。
• 事件重复是否会造成严重后果？处理重复事件是要直接幂等，还是要在业务层做版本号判断。
• 机器人离线一段时间再上线，服务端怎么补齐缺失状态？一般需要设计一次全量同步，不能只依赖增量事件。
• 是否保留了必要的轮询？心跳是一个兜底方案，关键状态的一次性查询接口也可以保留，但要明确停止周期性的setInterval式调用。
• 有没有监控事件链路？Broker 连接数、事件消费积压数、端到端延迟曲线，这三个指标必须进监控系统。

这套清单帮我避掉了不少问题。实际上我在做第一次事件驱动改造时，就因为没设计机器人离线重连后的全量同步，导致有几台机器人在断网恢复后始终状态异常，排查了很久才发现是“事件增量补不齐全量信息”的问题。后来把全量同步放到重连流程里，整个世界就清净了。

最后再分享一个我自己一直在用的判断标准：设计机器人状态上报方案时，先问自己一句——这个状态如果整整一分