资产管理系统平时不出事出事都在关键时刻——年度盘点当天、审计进驻前夜。本文谈RFID系统的可用性工程设备掉了怎么办、MQ挂了怎么办、平台瘫了怎么办。一、先想清楚可用性需求是分层的RFID资产管理系统的可用性设计第一步不是堆架构而是分层定义故障影响层故障业务影响可用性要求标签单个标签损坏单资产失联容忍人工补扫兜底读写设备单台读写器/PDA掉线局部区域无法自动采集分钟级发现可用移动设备顶替网关/边缘网关进程崩溃该区域事件断流自动重启事件补传消息层MQ集群故障事件积压、实时性丧失双集群切换秒级平台应用/数据库宕机全部业务不可用主备切换分钟级RTO关键认知RFID系统的天然优势是边缘有记忆。读写器和网关本地有缓存能力平台短暂不可用不会丢数据——这个特性要充分利用它决定了平台故障的业务代价远小于传统实时交易系统。二、设备层掉线检测与降级兜底掉线检测的正确姿势不要依赖设备主动上报异常——设备掉线时恰恰无法上报。正确做法是平台侧心跳超时检测读写器每30秒上报一次心跳含天线状态、温度、最近事件时间平台连续3个周期90秒未收到心跳标记设备 OFFLINE 并告警告警必须带着影响面下发给管理员“3楼东侧读写器离线影响B区机柜01-12的自动盘点”。/** * 设备健康监测器 * 节选自 首码信息 RFID 中间件 DeviceHealthMonitor 模块 * * 设计要点掉线判定必须平台侧主动超时而非依赖设备自报 * 告警内容必须包含业务影响面否则运维只知设备挂了不知该急不该急。 */publicclassDeviceHealthMonitor{privatestaticfinalintHEARTBEAT_TIMEOUT_MS90_000;// 3个心跳周期publicvoidcheckHealth(){for(ReaderDevicedev:registry.all()){longsilentSystem.currentTimeMillis()-dev.lastHeartbeatAt();if(silentHEARTBEAT_TIMEOUT_MSdev.isOnline()){dev.markOffline();// 告警携带影响面哪些区域/盘点任务会受波及alertService.send(Alert.builder().level(AlertLevel.WARN).device(dev.getId()).impact(dev.affectedZones())// 影响面B区机柜01-12.suggestAction(请检查设备网络与供电期间可派PDA进行移动盘点).build());log.warn([首码信息] 设备离线 detected, id{}, silentMs{},dev.getId(),silent);}}}}降级兜底从自动退到半自动设备故障不是终点业务要有Plan B故障场景降级方案固定读写器离线该区域盘点任务自动降级为PDA人工触发盘点通道门离线出入登记退回人工扫码登记恢复后补录RFID打印机故障预打印一批备用标签应急恢复后补绑定智能管控柜离线柜体本地策略开门本地缓存权限事件暂存补传注意最后一项管控柜这类设备本地必须有权限缓存不能所有开门请求都实时调平台——平台一抖柜门开不了业务直接瘫痪。本地缓存的授权列表按天同步事件先落本地存储恢复后补传这是边缘自治的基本功。三、消息层不丢数据的三个机制MQ是RFID事件流的主动脉围绕它做三件事1. 生产端确认 本地暂存。网关收到事件先写本地日志或SQLite发送MQ成功后才标记完成MQ不可达时本地积压恢复后按序重发。2. 消费端幂等。重发必然带来重复事件消费侧按事件ID去重数据库层加唯一约束兜底——代码写业务去重数据库写物理约束双保险。3. 集群双活。主备两套MQ集群生产端配置双写或故障自动切换。这里不要过度设计读写器事件这种高吞吐但允许秒级延迟的数据切换过程中的少量重复靠幂等消化即可不必追求金融级的零丢失方案。四、平台层故障降级与有损服务平台层的高可用除了常规的应用集群、数据库主从RFID系统还有自己的特殊性——盘点高峰的流量洪峰。一次全楼盘点任务下发后几千台设备同时上报事件洪峰可能是日常流量的50倍。如果直接透传给数据库平台先于故障被自己的业务压垮。所以要有洪峰治理盘点任务分批下发按区域错峰每批间隔30秒网关侧做窗口聚合3秒内同一标签多次读取合并上报消费端线程池隔离盘点事件处理与工单审批用独立的线程池/队列盘点洪峰不应拖垮审批等核心交互。/** * 盘点任务错峰下发器 * 节选自 首码信息 RFID 资产管理系统 InventoryDispatcher 模块 * * 分批间隔可配置默认30秒。批次大小按网关承压能力评估 * 宁可盘点慢2分钟不给平台制造雪崩。 */publicvoiddispatchByBatch(InventoryTasktask){ListZonezoneszoneService.zonesOf(task.getScope());for(ListZonebatch:Lists.partition(zones,task.getBatchSize())){batch.forEach(z-gatewayClient.push(task.id(),z.id()));scheduler.delay(task.getBatchIntervalMs());// 错峰间隔log.info([首码信息] 盘点任务分批下发, taskId{}, batchSize{},task.id(),batch.size());}}有损服务的取舍真正宕机时要有明确的降级预案而不是全线不可用业务正常降级事件采集实时入库网关本地暂存最长支持72小时盘点任务系统下发沿用最近一次任务快照PDA离线盘点审批流转在线审批移动端缓存最近待办恢复后补签报表查询实时报表只读库降级到最近一次同步的副本设计原则就一句话采集永远不停数据永不丢失交互可以延迟。RFID系统的数据是物理世界的事实记录事件断流的损失远大于界面卡顿。五、RTO/RPO怎么定不建议照抄互联网大厂的四个九。资产管理系统的合理目标是RPO 0事件数据靠本地暂存确认机制不允许丢RTO ≤ 15分钟应用集群自动切换 数据库主从切换采集链路永不断边缘自治保底。为达成这个目标日常要做两件事主从切换演练每季度一次不演练的预案等于没有网关本地暂存容量定期验证别等故障时才发现本地缓存只够存2小时的数据。六、故障复盘模板每次故障后按这个模板复盘可用性能力才会持续进化影响面量化故障时长、断流事件数、受影响盘点任务数、人工补救工作量时间线还原从故障发生→检测→决策→恢复各环节耗时检测耗时是否占了50%以上根因归类是探测缺失、预案缺失、还是预案存在但没演练过改进项闭环每个改进项要有owner和deadline进下季度演练验证。写在最后RFID系统的高可用一半在平台集群、主从、切换另一半在边缘本地暂存、自治降级、补传机制。很多团队把预算全花在平台侧忽视了边缘自治结果平台切换的5分钟里事件断流、盘点任务失败最后只能全员返工。把采集永不停、数据永不丢、交互可延迟这三条原则刻进架构设计里系统的可用性才经得起年度盘点那一天的真正考验。