标签：数据 连接状态 连接 and 方案 相关 也会 var 根据
让我们来看一下这个场景：
你有一个温度传感器，它每三个小时向一个 Topic 发布当前的温度。那么问题来了，有一个新的订阅者在它刚刚发布了当前温度之后订阅了这个主题，那么这个订阅端什么时候能才能收到温度消息？
对的，它必须等到三个小时以后，温度传感器再次发布消息的时候才能收到。在这之前，这个新的订阅者对传感器的温度数据一无所知。
怎么来解决这个问题呢？
这个时候就轮到 Retained 消息出场解决这个问题了。Retained 消息是指在 PUBLISH 数据包中 Retain 标识设为 1 的消息，Broker 收到这样的 PUBLISH 包以后，将保存这个消息，当有一个新的订阅者订阅相应主题的时候，Broker 会马上将这个消息发送给订阅者。
Retain 消息有以下一些特点：
注意：Retained 消息和持久性会话没有任何关系，Retained 消息是 Broker 为每一个 Topic 单独存储的，而持久性会话是 Broker 为每一个 Client 单独存储的。
如果你想删除一个 Retained 消息也很简单，只要向这个主题发布一个 Payload 长度为 0 的 Retained 消息就可以了（qos=0，retain=1，payload=任意值的消息即可解除 。）。
那么开头我们提到的那个场景的解决方案就很简单了，温度传感器每 3 个小时发布当前的温度的 Retained 消息，那么无论新的订阅者什么时候进行订阅，它都能收到温度传感器上一次发布的数据。
LWT 全称为 Last Will and Testament，也就是我们在连接到 Broker 时提到的遗嘱，包括遗嘱主题、遗嘱 QoS、遗嘱消息等。
顾名思义，当 Broker 检测到 Client 非正常地断开连接的时候，就会向遗嘱主题里面发布一条消息。遗嘱相关的设置是在建立连接的时候，在 CONNECT 数据包里面的 Variable header(可变头与) Payload(有效载荷) 中 指定的。
Broker 在以下情况下认为 Client 是非正常断开连接的：
如果 Client 通过发布 DISCONNECT 数据包断开连接，这个属于正常断开连接，不会触发 LWT 的机制，同时，Broker 还会丢弃掉这个 Client 在连接时指定的 LWT 参数。
根据遗嘱的属性和触发机制，我们不难看出，遗嘱常用于获取设备的连接状态。
注意，设置好遗嘱以后还不够（因为你只要订阅者一启动就会收到遗嘱消息，如果此时发布者已经在线，会导致不准确），
所以，还需要在设备成功连接MQTT的时候主动发个消息,发送的主题必须和遗嘱的主题相同，设置好消息的 retain 属性，让其自动纠正过来。
MQTT中的Retained（保留消息） 与 LWT（最后遗嘱）
标签：数据 连接状态 连接 and 方案 相关 也会 var 根据
原文地址：https://www.cnblogs.com/zhao-yi/p/13367594.html
