不能用定时轮询判断设备在线状态，因其存在最大30秒延迟，且批量更新会导致并发不一致、全表扫描和锁表问题；应改用内存映射集合+变更流实现低延迟、最终一致的状态同步。
为什么不能用定时任务轮询设备状态做在线判断
轮询有固有延迟窗口，比如每 30 秒扫一次，设备在第 29 秒断连，要等整整 30 秒才被标为离线——这对安防、门锁类场景不可接受。真正的问题不在“要不要轮询”，而在于「状态判定不该依赖读操作」。
常见错误是写一个后台 job 跑 find({ lastSeen: { $lt: ... } }) 批量更新 online: false，这会导致：
- 并发读可能看到过期状态（因为写还没发生）
- 全表扫描压垮慢查询，尤其设备数超 10 万后
- 磁盘 I/O 暴涨，
updateMany锁住集合时间变长
用内存映射集合（in-memory collection）替代轮询
MongoDB 4.2+ 支持 inMemory 存储引擎，专为高频读写、低持久性要求的状态缓存设计。它不落盘，所有数据驻留 RAM，写入吞吐可达普通 WiredTiger 集合的 3–5 倍。
适用场景明确：只存临时状态，如 lastSeen、online、心跳时间戳，且可容忍实例重启后重连恢复。
- 创建方式：
db.createCollection("device_status_cache", { storageEngine: { wiredTiger: { configString: "in_memory=true" } } }) - 必须显式指定
storageEngine，不能靠配置文件全局开启 - 该集合不支持副本集同步、不参与 oplog，只用于单节点本地状态快照
- 别往里塞
state这种业务字段——它该存主集合，这里只放轻量元数据
状态同步怎么做到最终一致又不丢数据
内存集合只是加速层，真实状态仍以主集合（如 devices）为准。关键在「写路径收敛」：所有设备心跳必须同时更新内存集合 + 主集合，且顺序可控。
推荐做法是用事务包装双写，但注意限制：
- 事务不能跨存储引擎——
inMemory集合不支持事务，所以不能把内存集合放进事务 - 正确顺序是：先
updateOne主集合（带$currentDate），再异步或同步写内存集合 - 更稳的方式：用变更流（
change stream）监听主集合更新，触发内存集合刷新，避免应用层双写失败导致不一致 - 内存集合设 TTL 索引（如
expireAfterSeconds: 90）自动清理陈旧条目，防止 OOM
查询时如何避免查错集合或漏判离线
客户端查在线状态时，不能只查内存集合——它可能还没刷入，也不能只查主集合——它可能因写延迟暂未更新。必须组合使用：
- 优先查
device_status_cache，命中则直接返回online和lastSeen - 未命中或
lastSeen超过 60 秒，立刻 fallback 到主集合查devices，并用$expr计算是否离线：{ $lt: [{ $subtract: ["$$NOW", "$lastSeen"] }, 60000] } - 禁止在应用层拼接两个查询结果做“或逻辑”——网络分区时可能返回矛盾值
- 所有读请求加
readPreference: primary，避免从延迟副本读到 stale 状态
最易被忽略的一点：内存集合的 _id 必须和主集合严格对齐，用设备 ID（如 "dev_abc123"）作 _id，否则关联查询会失效；也别在内存集合里建额外索引——它本就不走 B-tree，全内存哈希查找已足够快。
