工厂可视化电子看板多屏数据不同步：根因排查与同步机制设计

车间里挂着八块电子看板计划员、班长、质检各看各的最怕的就是两块屏幕上同一工序的产量数字对不上。去年我在客户现场调一个可视化电子看板项目前后折腾了大半个月问题恰恰就出在“多块大屏数据不同步”上。这类项目的技术链路其实不复杂底层是PLC、传感器或MES数据库中间经过采集服务、后端接口最后通过HTTP或WebSocket推送到前端大屏渲染。可一旦牵扯到多块屏同步问题就像打地鼠一样按下葫芦浮起瓢。这篇文章我把自己在工厂可视化电子看板调试中踩过的坑、验证过的排查方法和同步机制设计思路完整梳理一遍给正在搞大屏项目的朋友一个直接能抄的作业。1. 数据不同步的根因先从数据链路说起1.1 一个大屏可视化项目的典型数据链路工厂电子看板的数据链路和互联网公司的BI报表有本质区别。互联网报表晚几分钟无人在意车间看板上产量、合格率、设备状态少一个数班组长当场就能拍桌子。一条典型的看板链路长这样设备层PLC、传感器、DCS → 采集层串口/Modbus/OPC UA网关 → 存储层MySQL、Redis → 服务层接口服务、消息推送 → 前端大屏浏览器渲染。数据每经过一层就多一分偏差的可能。我接手那个项目时客户现场有四块车间屏、两块办公区屏、一块展示屏一共七块。展示屏和车间屏显示的是同一套产量数据车间屏正常刷新办公区屏却慢了五分钟。第一反应是办公区网络差但排查后发现网速正常。最后定位到根因办公区大屏访问的是一个历史遗留接口而车间屏用的是新版聚合接口两个接口的数据源和统计口径根本不一样。多块大屏不同步第一步永远是画数据链路图搞清楚每一块屏到底从哪取数。不要看IP和端口要看到接口层和数据表层级。1.2 六种典型“不同步”现象与根因速查同一个“数据不同步”现场表现五花八门。我把高频症状梳理成一张速查表排查时先对号入座再动手现场症状典型根因排查方向一块屏5秒刷新另一块1分钟刷新各屏定时器/刷新频率不统一统一前端刷新策略同一时刻两块屏产量相差几件取数接口或缓存不一致对比接口返回与缓存Key某块屏卡在几小时前的数据不动WebSocket断链未重连或页面被节流查心跳、重连和浏览器节能机制前后两块屏时间戳差几分钟系统时间未统一全网NTP校时服务重启后屏反而显示旧数据缓存未失效、前端未重置清理Redis并通知前端重置状态某块屏重启浏览器后恢复过几小时又乱前端内存泄漏或消息堆积检查浏览器任务管理器内存占用这些现象我在不同项目里都见过有时候一次出现两三种叠加看起来很复杂但只要按“源头→传输→展示”的顺序逐层排除半小时内基本能定位。2. 想根治不能只靠现场“救火”2.1 统一时钟、统一取数源先把“时间差”干掉很多数据不同步问题根源是时间基准不统一。车间屏显示“当前产量 1234 件”办公区屏显示“1233 件”操作工说不对但你看数据库里其实两个数都是对的——因为两块屏分别在5秒前和3秒前拉过一次数据数据本身没有错只是时间截点不同。解决思路分三层第一层是全网校时。看板主机、后端服务器、数据库服务器全部配置NTP同步确保“同一时刻”在各设备上是同一个时间。很多老项目服务器和看板主机时间差了十几分钟排查问题时日志对不上连定位都困难。第二层是统一取数源。所有大屏只允许调用统一的聚合接口禁止各屏自行拼装数据库查询或直连第三方接口。我在项目里定的规矩是前端不直接访问采集表所有指标由后端聚合服务统一输出。同一指标在七块屏上必须走同一个服务同一个方法。第三层是引入时间戳或版本号。后端接口返回数据时带上lastUpdated字段前端记录上一次渲染的版本号只有新版本号大于当前版本号才更新画面。这样即使网络乱序或重复推送旧数据也永远不会覆盖新数据。这个设计看起来多写了几行代码但它把“数据不同步”问题从“靠运气”变成了“靠机制”。2.2 数据推送链路改造轮询、WebSocket与双通道大屏可视化项目常见两种数据推送方式HTTP轮询和WebSocket长连接。轮询实现简单但问题很多。七块屏各拉各的接口如果接口没做缓存数据库直接被轮询请求打爆如果做了缓存各屏取到的缓存时间点又不一样。轮询还会产生“边缘情况”你刚好在数据变更前一秒拉了数据下一次拉取要等整整一个周期。WebSocket是解决实时同步的主流方案但只建连接不维护照样出问题。我见过一个项目WebSocket连上后没有任何心跳机制路由器空闲超时把连接断了大屏画面从此定格只有重启浏览器才恢复。实操中我建议做两件事一是必选心跳与自动重连。前端每30秒发一次ping后端回pong连续三次无响应则主动断开并重连。重连成功后立刻拉一次全量数据把断线期间漏掉的数据补回来。二是做“双通道兜底”。即使WebSocket正常前端也要开启一个低频轮询比如每5分钟一次作为数据最终一致性的兜底。任何一个通道出问题另一通道都能把画面拉回正确状态。后端推送也要注意聚合和节流。曾经有个设备状态数据每秒变化后端每秒都推送一次前端渲染队列堆满页面越来越卡。后来后端改成“2秒内多条变化合并为一条最新状态推送”渲染压力立刻降下来。批量聚合、串行推送、必要时做消息队列削峰是后端推送设计的三条铁律。2.3 后端缓存与接口一致性的隐藏坑多块大屏不同步很多坑埋在Redis缓存里。最常见的是缓存Key不一致。同一个产量指标车间屏走output:line1这个Key办公区屏走output_line1两个Key对应两个值数据自然对不上。查这种问题直接用Redis可视化客户端工具连上去看Key列表一目了然。另一种坑是缓存过期策略不统一。同一个指标一个接口设置了60秒过期另一个设置了300秒两块屏拉到的数据截点就差了好几分钟。我的习惯是所有看板数据接口的缓存过期时间由后端统一配置禁止各接口自行设定。第三种坑是缓存与数据库的一致性。看板数据通常读Redis写入时先更新数据库再失效缓存。但如果更新数据库成功、删除缓存失败接口还会继续返回旧数据。我处理这类问题喜欢在接口里加一个“数据版本号”每次业务数据变更版本号加一前端把版本号显示在页面角落。现场验收时操作工看到版本号变化就知道数据确实更新了这个设计后来成了我所有看板项目的标配。3. 现场调试别靠肉眼猜3.1 逐段排查法从接口Response开始逐层定位现场调试最忌讳一上来就开抓包工具分析TCP包。正确姿势是“先看两头再查中间”。第一步对比各屏的接口返回。在两块不同步的大屏上同时打开浏览器开发者工具刷新接口对比Response。如果两个Response的内容一致说明问题出在前端渲染或传输环节如果不一致问题出在后端取数或缓存环节。第二步验证数据来源的时效性。直接查数据库里最新一条记录的时间戳再对比接口返回的时间戳。如果数据库有数据而接口返回旧值大概率是缓存问题。此时用Redis可视化客户端查看对应Key的TTL和值基本能当场定位。第三步验证推送链路。WebSocket场景下在开发者工具Network面板里过滤ws查看最近几秒是否有消息帧进来。有消息没渲染问题在前端没消息但有连接问题在后端推送或路由层。断线重连机制是否生效也可以在这里直接观察。这套方法我用了很多年平均能把定位时间压缩到20分钟以内。它的核心逻辑是不猜、不赌把链路切成段每一段用客观日志和响应包说话。3.2 常用调试工具网口调试、串口调试、抓包各有各的用法看板项目调试工具按用场分三类接口层调试我用网口调试助手比Postman多。网口调试助手的界面更直接可以配置多个常用请求现场改个IP、换个参数就能立刻发请求比在命令行敲curl直观得多。对比两块屏的接口差异时开两个网口调试助手窗口同时请求Response差异一眼可见。涉及底层设备采集比如STM32、PLC通过Modbus协议走串口或网口上报数据串口调试助手是绕不开的工具。它能直接看到设备上发的原始报文排查“设备数据有没有上来”“协议解析是否正常”这类问题非常高效。但我提醒一句串口调试助手打开串口后会独占端口如果采集服务正连着同一个串口你这边一打开就会把服务顶掉操作前一定要和生产确认。底层的链路问题比如WebSocket连接被无故断开、TCP重传严重、路由器空闲超时这些用Wireshark抓包最靠谱。抓包文件里的TCP Keep-Alive间隔、FIN包来源能直接告诉你连接是被谁断的、断在哪里。工具不在多在于用对层级。接口层用网口调试助手设备层用串口调试助手链路层用Wireshark缓存层用Redis可视化工具这一套下来覆盖了全部可疑环节。3.3 把日志做成“现场探头”工厂现场不像办公室问题不会等你在电脑前慢慢复现。所以日志必须做成“探头”问题什么时候发生日志什么时候告诉我。我推行了一套三级日志规范前端大屏日志每次收到推送或轮询数据console打印一条记录包含数据版本号、时间戳、渲染耗时。页面出错时直接打印错误堆栈。现场人员按F12打开控制台把截图发到群里问题定位就有了第一手线索。后端接口日志记录每个接口的调用来源、参数、耗时、返回状态。两块屏的接口日志放在一起对比谁调了旧Key、谁走了慢查询、谁触发了缓存重建一清二楚。采集服务日志记录设备数据上来的原始值、转换后的数值、写入时间。这个环节最容易产生“隐性不同步”——设备数据本身没变但采集服务因串口被占用或网络抖动漏采了几条导致两块屏取到不同的数据区间。这套日志体系搭建起来之后我接到现场电话的频率直线下降。因为大多数问题看日志已经能定位七七八八。4. 高频踩坑点与避坑清单4.1 现场高频坑位对照表我把这几年在现场踩过的、帮别人排过的坑整理成一张对照表。每一条都是真实发生过的场景工具和方案也都是验证过有效的坑位现象根因处理方法系统时间未统一各屏时间基准差几分钟未部署NTP校时所有服务器和看板机统一NTPWebSocket无心跳大屏隔一段时间就定格路由器空闲超时断开连接增加心跳与自动重连页面休眠被节流次日上班屏数据空白浏览器标签页后台节能监听visibilitychange恢复时拉全量前端取数接口不统一同一指标两块屏数值不同各屏各自调接口统一后端聚合接口缓存Key不统一同指标走两个RedisKey不同服务各自定义Key统一缓存规范并巡检缓存过期策略差异屏幕更新频率不一致各接口TTL自行设定后端统一配置缓存策略服务重启未清缓存重启后屏幕显示旧数缓存未失效前端未重置重启流程串行清缓存和重置消息推送无聚合页面越用越卡高频消息堆满渲染队列后端按时间窗口聚合推送数据格式各自处理合格率小数位对不上前端四舍五入规则不一致后端统一格式化规则串口被多个进程占用采集上报时断时续调试工具和服务抢端口用前确认用完关闭前端字段无兜底页面偶发显示undefined某字段空值未处理前端统一默认值兜底浏览器版本过旧WebSocket连接异常大屏主机系统老旧换新内核浏览器或工控机看板硬件残影画面重影/花屏显示器老化或主机带不动硬件排查、重启浏览器接口超时无重试偶发整屏空白后端慢查询拖垮超时加超时重试和降级方案这张表基本覆盖了我遇到过的90%的“多块大屏数据不同步”案例。它是排查清单也是验收清单——项目上线前逐条过一遍能少踩很多坑。4.2 项目落地阶段的几条硬核经验最后聊几条项目落地阶段才体会得到的经验这些不是网上文档里能查到的全是一次次熬夜换来的。第一改动后别只看一眼。看板数据是否同步要观察至少十分钟。很多问题在短时间内看不出来比如缓存过期边界、WebSocket断线周期、浏览器节流触发都与时间相关。我习惯修改后让两块屏并排运行一两个小时中间多次切换画面验证。第二大屏和业务系统的数据校验必须留“日志口”。项目上线后现场反馈“数据不对”时第一个动作永远是让他们打开控制台截图日志。如果日志口在交付时没留好远程排查的成本会高好几倍。第三永远不要相信“应该不会有人动配置”。大屏主机的IP、浏览器缩放比例、系统自动更新、屏保和休眠设置都可能在某个深夜被改动然后第二天整个数据展示全乱。我在交付清单里明确写了大屏主机的标准化设置项包括关闭系统自动更新、关闭休眠、设置浏览器开机自启动并锁定缩放比例。第四部署时把“数据版本号”做进页面角落。这个设计我前面提过但值得再说一遍。版本号可见现场人员汇报问题时能直接报出“数据版本停在多少”你在后台看一眼当前版本就知道是前端没更新还是后端没推送省去大量扯皮。这个项目最终上线后虽然陆陆续续还有一些小问题但“多块大屏数据严重不同步”的大故障再也没有发生过。回头总结真正起作用的不是某一招而是把“统一时钟、统一取数源、统一推送通道、统一格式化规则、留足可观测日志”这一整套机制建起来。搞工厂可视化电子看板没有捷径链路里的每一环都值得较真。