如果订阅客户端在他们订阅的主题模式中包含通配符，即使保留消息的主题不完全匹配，它也会收到保留消息。下面是一个示例：客户端 A 将保留的消息发布到 myhome/livingroom/temperature。稍后，客户端 B 订阅 myhome/#。客户端 B 订阅myhome/#后直接收到myhome/livingroom/temperature保留消息。客户端 B（订阅客户端）可以看到该消息侍氏是保留消息，因为代理发送保留标记为 true 的保留消息。客户端可以决定如何处理保留的消息。
保留消息可帮助新订阅的客户端在订阅主题后立即获得状态更新。保留的消息消除了等待发布客户端发送下一个更新的时间。
换句话说，关于一个主题的保留消息是最后一个已知的好值。保留消息不一定是最后一个值，但它必须是保留标志设置为真的最后一条消息。
重要的是要了解保留的消息与持久会话（我们上周讨论的主题）无关。一旦代理存储了保留的消息，就只有一种方法可以将其删除。继稿谈肢续阅读以了解如何 *** 作。
从开发人员的角度来看，发送保留消息非常简单直接。你刚才设置的 保留了标志 的的 MQTT发布消息 为真。通常，您的客户端库提供了一种设置此标志的简单方法。
还有一种非常简单的方法可以删除主题的保留消息：在要删除之前保留消息的主题上发送带有零字节负载的保留消息。代理删除保留的消息，新订阅者不再获得该主题的保留消息。通常，甚至不需要删除，因为每条新保留的消息都会覆盖前一条消息。
(补充：
发布消息的时候，有一个专门控制保留消息的字段retain
当retain = true，发布不为空的消息，则订阅端连接代理后会自动订阅到发布端发布的最后一条消息
当reatin = false，发布不为空的消息，则订阅端连接代理后不会自动订阅到发布端发布的最后一条消息
当reatin = true，发布空的消息，可以消除代理端保留的发布端发生的最后一条消息，这样订阅端连接代理后不会自动订阅到发布端发布的最后一条消息)
当你希望新连接的订阅者立即接受到消息(无需等到发布客户端发送下一条消息)时，保留消息是有意义的。这对于单个主题的组件或者设备的状态更新非常有用。例如：device1的状态在主题myhome/devices/device1/status上。当使用保留消息时，主题的新订阅者在订阅后立即获得设备的状态(在线/离线)。对于按时间间隔、温度、GPS坐标和其他数据发送数据的客户端也是如此。如果没有保留消息，新的订阅者在发布间隔之间将处于黑暗中。使用保留的消息有助立即为连接的客户端提供最后的良好价值。
名词释义：
MQTT——Message Queuing Telemetry Transport消息队列遥测传输
PUB——Publish发布
QoS——Quality of Service服务质量
LWT——Last Will &Testament最后遗嘱
MQTT简介
3.2 通配符
MQTT 中有两个可用的通配符，分别是+和#，+表示匹配单一层级中的任意主题，#表示匹配任意数量的层次。
3.3 服务质量（QoS）
MQTT 的设计初衷是为了在不可靠的网络中运作良好，为不同的场景提供了三个级别的歼贺服务质量，允许客户端指定自己想要的可靠性级别。
3.3.1 QoS Level 0：至多一次
这是最简单的级别，无需客户端确认，其可靠性与基础网络层 TCP/IP 一致。
3.3.2 QoS Level 1：至少冲岁一次，有可能重复
确保至少向客户端发送一次信息，不过也可发送多次；在接收数据包时，需要客户端返回确认消息（ACK 包）。这种方式常用于传递确保交付的信息，但开发人员必须确保其系统可以处理重复的数据包。
3.3.3 QoS Level 2：只有一次，确保消息只散改睁到达一次
这是最不常见的服务质量级别，确保消息发送且仅发送一次。这种方法需要交换4个数据包，同时也会降低消息代理的性能。由于相对比较复杂，在 MQTT 实现中通常会忽略这个级别，请确保在选择数据库或消息代理前检查这个问题。
3.4 “临终遗嘱”信息
MQTT提供了检测方式，利用KeepAlive机制在客户端异常断开时发现问题。因此当客户端电量耗尽、崩溃或者网络断开时，消息代理会采取相应措施。
客户端会向任意点的消息代理发送“临终遗嘱”（LWT）信息，当消息代理检测到客户端离线（连接并未关闭），就会发送保存在特定主题上的 LWT 信息，让其它客户端知道该节点已经意外离线。
3.5保留消息 Retained Messages
1个Topic只有唯一的retain消息，Broker会保存每个Topic的最后一条retain消息。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）