当前位置: 首页 > 知识库问答 >
问题:

MQTT 3.1.1代理QOS=1(“至少一次”)消息重新传递

柳修平
2023-03-14
    null

为了更具体地说明我试图实现的目标:
推迟发送puback,直到成功持久化接收到的消息--有效地扩大QoS级别,直到我的订阅应用程序保证消息得到处理--这是一个好的/有效的想法吗?
以及对于例如持久化错误(数据库超时),是否会发送puback,这将自动导致重新传递此类消息。

最诚挚的问候

共有1个答案

卢子民
2023-03-14

MQTT代理是否从订户重新传递未确认的“QoS 1”消息?

从[规格]:

当客户机将CleanSession设置为0时重新连接,客户机和服务器都必须使用它们的原始数据包标识符[MQTT-4.4.0-1]重新发送任何未确认的发布数据包(其中QoS>0)和PUBREL数据包。这是唯一需要客户端或服务器重新传递消息的情况。

根据上述规定,自动重试不是规范所要求的。一些经纪人可能会在一段时间后重新传输。emqx支持这一点;mosquitto过去有一个选项,但在1.5版本中删除了这个选项,更改日志解释说:。

QoS>1的传出消息在超时后不再重试。当客户端重新连接时,将重试消息。可以通过考虑超时可能发生的时间来证明这种行为的改变是合理的。

  • 如果连接不可靠并已断开,但一端没有注意到,则在重新连接时将重试消息。发送附加的PUBLISH或PUBREL不会更改任何内容。
  • 如果客户端过载/无法响应/连接缓慢,则发送额外的PUBLISH或PUBREL将无助于客户端赶上。一旦待办事项清理完毕,客户机就会响应。如果无法赶上,则发送额外的副本也无济于事

推迟发送PUBACK直到成功持久化接收到的消息是一个好的/有效的主意吗

几个月前,paho-dev集团对此进行了讨论。Go v5客户机正在考虑这个问题(目前该客户机自动确认消息)。

需要注意的一点是,MQTT规范确实有关于发送订单确认的要求。许多客户机忽略了这一要求(只在处理程序返回时发送确认),但有些客户机(例如HiveMQ Java客户机)将ACKs排队,以便能够以正确的顺序发送它们。

 类似资料:
  • 我试图提出一个设计,使用Kafka为多个处理代理并行处理来自Kafka主题的消息。 null 或者还有什么我遗漏的地方可能有助于我对这一点的理解?

  • 我正在读一条来自Solace的信息。我能够成功地阅读信息。假设我正在阅读一条消息,在侦听器线程上读取/处理消息时,应用程序崩溃。那我怎么能在那上面再读一遍那条信息呢。使用下面的代码,我无法再次阅读该消息。下面是我的配置

  • 我们有一个camel路由,在这里我们从输入队列读取消息,处理它,设置一些JMS头(使用exchange.getin().setheader(...)),然后将消息路由到某个输出队列。在MQ故障转移方案期间,将重新传递消息。但是,当重新传递消息时,我前面放置的JMS头丢失了。是否有任何方法可以在重新交付后保留JMS头?

  • 我正在为Kafka工作客户:librdkafka。图书馆在这里https://github.com/edenhill/librdkafka/blob/master/examples/rdkafka_example.cpp.我的程序正在向代理写入2000000条消息。在此过程中,我重新启动了代理。有时,没有消息无法传递到代理。有时,大约100000条消息未能传递到代理。队列缓冲。最大消息数=1000

  • 我已经设置了一个Flink 1.2独立集群,其中包含2个JobManager和3个TaskManager,我正在使用JMeter通过生成Kafka消息/事件对其进行负载测试,然后处理这些消息/事件。处理作业在TaskManager上运行,通常需要大约15K个事件/秒。 作业已设置EXACTLY_ONCE检查点,并将状态和检查点持久化到Amazon S3。如果我关闭运行作业的TaskManager需

  • 我正在使用apacheMQ作为队列管理器。我使用Spring的DefaultMessageListenerContainer来使用消息。我已经对它进行了配置,以便它有一个事务: