为了账号安全,请及时绑定邮箱和手机立即绑定

Shifu教你轻松理解MQTT ——(4)服务质量QoS

标签:
Go Docker API

在阅读了***Shifu*** 此前发布的系列MQTT文章后,相信你已经对MQTT的QoS(Quality of Service,服务质量)有了个大概印象——用于指示如何传递消息;共有3个QoS级别和2种类型的消息。

Shifu是由边无际Edgenesis自主研发的物联网开源开发和管理平台,开发者通过Shifu可以轻松实现连接、监控和控制任何物联网设备。


快速回顾

3个QoS级别:

  • 0-最多一次

  • 1-至少一次

  • 2-正好一次

2种交付方式:

  • 发布者对中间人

  • 中间人对订阅者

此外,在上一篇文章中,我们已经讨论了从订阅者发送至中间人的订阅消息;它定义了用户可以接受的最大QoS级别,任何具有更高级别的消息都将被降低至订阅该级别用户能承受的最大级别。

0-最多一次

我们常能通过事物的名字来判断它是做什么的。因此,如果你的QoS级别为0,则消息要么被传递一次,要么不传递——只尝试一次,并且不重试。发了就算完。哇,非常异步。

1-至少一次

假设我要传递某条信息,则会疯狂地进行重试。发送消息的人将继续重复发送消息,直到它从接收者那里收到PUBACK(由packetId组成,仅此而已)。

还记得我们在发布消息中的dupFlag字段吗?下面就来看看如何使用——在初次尝试后的每次重试中,这个dupFlag都会被设置为true,以此来通知收件人这可能是一条重复消息。

2-刚好一次

确保消息被传递,并且确保只传递一次。这是最慢也是最复杂的QoS级别。以下为QoS 2消息发送的整个生命周期:

首先,发送方(发布者或中间人)将发布消息发送给接收方(中间人或订阅者)。“咚咚!”

第二,一旦接收者收到发布消息,它就向发送者发送PUBREC消息,表示“我认出了这个消息,是QoS 2,以此句话为证,不要再发了!”在接收PUBREC之前,发送方仍然会不断重试向接收方发送带有dupFlag==true的发布消息。

第三,在收到PUBREC后,发送方便得知消息已经被传递。因为它知道QoS消息是正好一次,所以它将丢弃该消息并停止疯狂重试行为,然后将PUBREL发送给接收者,说“我保证我不会再发这条信息了。”

第四,当PUBREL到达时,接收方将PUBCOMP发送回发送方,生命周期结束。

这与我们在TCP中的握手方式非常相似——使用一些额外的步骤来确保所有利益相关者都知道当前状态。

如果无法访问接收方,发送方会将消息保存在本地队列中,以便在接收方在线时发送消息。


点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消