物联网后端面试MQTT 与设备接入层高频 10 问附项目答法这篇不是八股文背诵版。下面 10 个问题都是我搭设备接入平台时真踩过的每个都配了面试怎么答——把答案绑到项目上比背概念强十倍。为什么单独准备设备接入层普通 Java 后端面试问的是 CRUD、索引、并发、JVM。物联网后端会多出一层设备怎么连进来、怎么证明它是它自己、消息丢了怎么办、一万台设备同时在线怎么扛。这一层答得好面试官立刻知道你是真做过而不是背了八股。下面 10 问按重要度排。1. MQTT 为什么要用 Topic 而不是点对点调用答MQTT 是发布/订阅模型设备只管往 Topic 发消息不需要知道谁在消费。这样设备和后端在时间上和数量上都解耦了——设备上线时后端可能没启动后端重启时设备也不用重连业务逻辑。项目答法我们 Topic 按up/{产品}/{设备ID}、st/{产品}/{设备ID}、down/{产品}/{设备ID}三层设计服务端用通配符up//一次订阅全部上行数据。加新设备无需改后端代码。2. QoS 0/1/2 到底怎么选答QoS 0最多一次可能丢。适合高频、丢了无所谓的周期性遥测比如 5 秒一次的温度QoS 1至少一次可能重复。绝大多数业务用这个QoS 2恰好一次四次握手开销大物联网里很少用项目答法全链路用 QoS 1重复靠 payload 里的时间戳 设备 ID 做幂等去重。因为丢数据比重复数据更难补救——重复可以过滤丢了就是真没了。3. QoS 1 会重复你怎么保证数据不重复入库答幂等设计。最直接的是唯一索引兜底入库前按业务键去重。项目答法入 data_point 表前先查同设备 同时间戳是否已存在存在就跳过数据量上来后加(device_id, ts)唯一索引插入冲突直接忽略。再加一层每台设备只允许时间戳单调递增旧数据直接丢弃。4. 遗嘱消息Last Will有什么用答设备连接时向 Broker 注册一条遗嘱一旦异常断线没发 DISCONNECT 就掉线Broker 自动替它发布这条消息——通常是设备离线状态。项目答法设备上线发st/{pk}/{id} online遗嘱里注册 offline。后端订阅st//设备掉线后端立刻知道不用轮询心跳表。这是设备状态机最省事的实现。5. 保留消息Retained用在哪有什么坑答保留消息让 Broker 把最后一条消息存下来新订阅者一订阅立刻收到——适合当前状态这类数据。坑它会一直留着设备状态过时了还会推给新订阅者。所以保留消息必须带时间戳消费端判断过期就丢弃。项目答法只对状态类 Topic 开保留遥测数据不开数据量大且不需要历史回放。6. 一机一密怎么实现为什么不能所有设备共用一个密钥答每台设备注册时分配唯一 secret设备用username 产品:设备ID、password secret连接Broker 通过认证回调校验。项目答法EMQX 配 HTTP 认证回调设备连接时 EMQX 调我们的/api/mqtt/auth服务端用 SHA-256 校验密钥哈希库里只存哈希明文只在注册那一刻返回一次。共用一个密钥的话一台设备被破解全部设备沦陷。这里踩过一个坑EMQX 要求响应体必须是{result: allow}或{result: deny}我们一开始返回了项目统一的{code, data}格式结果所有设备都连不上排查半天才发现是两边约定不一致。7. 设备连上来就能发任何 Topic 吗答不能要做 ACL访问控制最小权限。每台设备只允许发布自己的上行 Topic、只允许订阅自己的下行 Topic。项目答法ACL 规则按up/{pk}/{deviceId}精确匹配设备 A 发不了设备 B 的数据。这是防伪造的第二道防线——第一道是连接认证第二道是 ACL第三道是入库前校验设备是否存在。8. 保活时间Keep Alive设多少合适答取决于功耗和实时性。Wi-Fi 常电设备 60 秒够用电池设备要放大到几分钟否则心跳比数据还耗电。项目答法模拟设备和消费端都用 60 秒。要提醒的是 Keep Alive 是客户端承诺的最长静默时间Broker 超过 1.5 倍没收到心跳就判定掉线——所以别设得比业务上报周期还小否则网络抖动就误判离线。9. 一万台设备同时在线怎么扛答分两层看。Broker 层用 EMQX 集群横向扩它单节点就能承几万连接后端层的关键是别让消费端成为瓶颈项目答法消费端不直接在 MQTT 回调里做数据库写而是回调里解析 入队异步批量入库。批量写比单条写吞吐高一个数量级。再往后是 Kafka 削峰MQTT 只负责接Kafka 负责缓这是生产环境的常规分层。10. 后端启动时 Broker 还没起来服务就起不来了怎么办答不能因为依赖不可用就启动失败。连接动作要和业务启动解耦。项目答法应用启动时连 Broker 失败只打告警日志由定时任务兜底重连同时开setAutomaticReconnect(true)让客户端自己退避重连。重连成功后必须在connectComplete回调里重新订阅——这是最容易漏的一步不重新订阅会出现连着但收不到消息的诡异现象。面试现场的加分话术被问到你项目里怎么保证消息可靠别只答技术点这样说“可靠分三段看入站用 QoS 1 保证不丢重复用时间戳幂等过滤进程内用单条 try-catch 隔离脏数据不让一条坏消息拖垮整个连接入库用批量写抗吞吐原始 JSON 原样落库解析逻辑升级后历史数据还在。三层各管一段哪段出问题都不会全盘崩。”这种分层回答比背概念值钱得多——面试官要的不是你记得 QoS 有三个等级而是你知道在什么场景下用哪个、以及出问题怎么兜底。我是软件工程在读正在从零搭一个物联网设备接入平台Spring Boot EMQX MySQL所有代码和踩坑记录都会发出来欢迎关注一起卷物联网后端。
# 物联网后端面试：MQTT 与设备接入层高频 10 问（附项目答法） ＞ 这篇不是八股文背诵版。下面 10 个问题都是我搭设备接入平台时真踩过的，每个都配了“面试怎么答“——把答案绑到项目上，比背
物联网后端面试MQTT 与设备接入层高频 10 问附项目答法这篇不是八股文背诵版。下面 10 个问题都是我搭设备接入平台时真踩过的每个都配了面试怎么答——把答案绑到项目上比背概念强十倍。为什么单独准备设备接入层普通 Java 后端面试问的是 CRUD、索引、并发、JVM。物联网后端会多出一层设备怎么连进来、怎么证明它是它自己、消息丢了怎么办、一万台设备同时在线怎么扛。这一层答得好面试官立刻知道你是真做过而不是背了八股。下面 10 问按重要度排。1. MQTT 为什么要用 Topic 而不是点对点调用答MQTT 是发布/订阅模型设备只管往 Topic 发消息不需要知道谁在消费。这样设备和后端在时间上和数量上都解耦了——设备上线时后端可能没启动后端重启时设备也不用重连业务逻辑。项目答法我们 Topic 按up/{产品}/{设备ID}、st/{产品}/{设备ID}、down/{产品}/{设备ID}三层设计服务端用通配符up//一次订阅全部上行数据。加新设备无需改后端代码。2. QoS 0/1/2 到底怎么选答QoS 0最多一次可能丢。适合高频、丢了无所谓的周期性遥测比如 5 秒一次的温度QoS 1至少一次可能重复。绝大多数业务用这个QoS 2恰好一次四次握手开销大物联网里很少用项目答法全链路用 QoS 1重复靠 payload 里的时间戳 设备 ID 做幂等去重。因为丢数据比重复数据更难补救——重复可以过滤丢了就是真没了。3. QoS 1 会重复你怎么保证数据不重复入库答幂等设计。最直接的是唯一索引兜底入库前按业务键去重。项目答法入 data_point 表前先查同设备 同时间戳是否已存在存在就跳过数据量上来后加(device_id, ts)唯一索引插入冲突直接忽略。再加一层每台设备只允许时间戳单调递增旧数据直接丢弃。4. 遗嘱消息Last Will有什么用答设备连接时向 Broker 注册一条遗嘱一旦异常断线没发 DISCONNECT 就掉线Broker 自动替它发布这条消息——通常是设备离线状态。项目答法设备上线发st/{pk}/{id} online遗嘱里注册 offline。后端订阅st//设备掉线后端立刻知道不用轮询心跳表。这是设备状态机最省事的实现。5. 保留消息Retained用在哪有什么坑答保留消息让 Broker 把最后一条消息存下来新订阅者一订阅立刻收到——适合当前状态这类数据。坑它会一直留着设备状态过时了还会推给新订阅者。所以保留消息必须带时间戳消费端判断过期就丢弃。项目答法只对状态类 Topic 开保留遥测数据不开数据量大且不需要历史回放。6. 一机一密怎么实现为什么不能所有设备共用一个密钥答每台设备注册时分配唯一 secret设备用username 产品:设备ID、password secret连接Broker 通过认证回调校验。项目答法EMQX 配 HTTP 认证回调设备连接时 EMQX 调我们的/api/mqtt/auth服务端用 SHA-256 校验密钥哈希库里只存哈希明文只在注册那一刻返回一次。共用一个密钥的话一台设备被破解全部设备沦陷。这里踩过一个坑EMQX 要求响应体必须是{result: allow}或{result: deny}我们一开始返回了项目统一的{code, data}格式结果所有设备都连不上排查半天才发现是两边约定不一致。7. 设备连上来就能发任何 Topic 吗答不能要做 ACL访问控制最小权限。每台设备只允许发布自己的上行 Topic、只允许订阅自己的下行 Topic。项目答法ACL 规则按up/{pk}/{deviceId}精确匹配设备 A 发不了设备 B 的数据。这是防伪造的第二道防线——第一道是连接认证第二道是 ACL第三道是入库前校验设备是否存在。8. 保活时间Keep Alive设多少合适答取决于功耗和实时性。Wi-Fi 常电设备 60 秒够用电池设备要放大到几分钟否则心跳比数据还耗电。项目答法模拟设备和消费端都用 60 秒。要提醒的是 Keep Alive 是客户端承诺的最长静默时间Broker 超过 1.5 倍没收到心跳就判定掉线——所以别设得比业务上报周期还小否则网络抖动就误判离线。9. 一万台设备同时在线怎么扛答分两层看。Broker 层用 EMQX 集群横向扩它单节点就能承几万连接后端层的关键是别让消费端成为瓶颈项目答法消费端不直接在 MQTT 回调里做数据库写而是回调里解析 入队异步批量入库。批量写比单条写吞吐高一个数量级。再往后是 Kafka 削峰MQTT 只负责接Kafka 负责缓这是生产环境的常规分层。10. 后端启动时 Broker 还没起来服务就起不来了怎么办答不能因为依赖不可用就启动失败。连接动作要和业务启动解耦。项目答法应用启动时连 Broker 失败只打告警日志由定时任务兜底重连同时开setAutomaticReconnect(true)让客户端自己退避重连。重连成功后必须在connectComplete回调里重新订阅——这是最容易漏的一步不重新订阅会出现连着但收不到消息的诡异现象。面试现场的加分话术被问到你项目里怎么保证消息可靠别只答技术点这样说“可靠分三段看入站用 QoS 1 保证不丢重复用时间戳幂等过滤进程内用单条 try-catch 隔离脏数据不让一条坏消息拖垮整个连接入库用批量写抗吞吐原始 JSON 原样落库解析逻辑升级后历史数据还在。三层各管一段哪段出问题都不会全盘崩。”这种分层回答比背概念值钱得多——面试官要的不是你记得 QoS 有三个等级而是你知道在什么场景下用哪个、以及出问题怎么兜底。我是软件工程在读正在从零搭一个物联网设备接入平台Spring Boot EMQX MySQL所有代码和踩坑记录都会发出来欢迎关注一起卷物联网后端。
