一、该问题的重现步骤是什么？
1. 是否应该考虑新增一个定时器，定时扫描所有设备状态并落库。因为考虑到有种情况：设备原先是在线状态，系统宕机或者重启后设备处于“离线”或者“禁用”状态，这时候如果没有定时器定时读取状态并落库，会导致页面上设备一直处于设备原先的状态。如下图，“kSoERsAnc***”开头的设备原先是在线状态，注释掉这个设备的代码并重启后相当于这个设备掉线了，页面依然处于“在线”状态（此时页面上应该显示“未激活”或者“异常”状态？甚至是否应该删除页面上的设备，因为注释的代码模拟的是设备没有了）。
二、你期待的结果是什么？实际看到的又是什么？
期待的结果：应该有定时器定时读取设备状态并落库。
实际看到的：设备的状态处于系统宕机或者重启之前的状态。
三、你正在使用的是什么产品，什么版本？在什么操作系统上？
正在使用的产品：BladeX物联网平台
版本：1.0.0
操作系统：Windows11
四、请提供详细的错误堆栈信息，这很重要。
五、若有更多详细信息，请在下面提供。
考虑到海量设备的场景，设备下线是走批量的，也就会有一个下线的延迟。你链接了设备，设备掉线后断开mqtt，broker服务端就会按顺序下线。
你可以测试一下，在broker服务正常的时候，看他设备断开的日志。设备页你也可以f5刷新看看多久会自动掉线。
另外你如果是重启了broker或者关闭了broker，这个是没法处理设备上下线了。服务端掉线会有一个心跳周期，下一个周期之前重启没问题，超时就不行了。
关于你说的定时任务是不可取的，海量设备的场景，会把系统直接搞崩。针对极端场景，比如broker挂掉很久，这是属于事故了，那设备也就相当于全部掉线了。重启服务后，手动更新所有设备离线就行。
至于这种极端场景如何自动处理，这会放到后续的kafka组件来处理。当然你又会说kafka挂了怎么办，还是那句话，事故级别，手动处理，没有完美的方案。
这个你也可以先了解一下：https://www.bilibili.com/video/BV1wv4y1F7Av/
ok
扫一扫访问 Blade技术社区 移动端
加载中...
苏公网安备 32041102000998号