问题一：MQTT中主动失败的消息多了后，会影响正常的消息消费吗？
MQTT中主动失败的消息多了后，会影响正常的消息消费吗？主动失败 - 首次收到后处理业务，但是抛异常给mqtt sdk。让它重试。
参考答案：
大量重投不排除会有延迟升高等情况。
关于本问题的更多回答可点击进行查看：
https://developer.aliyun.com/ask/541220?spm=a2c6h.12873639.article-detail.52.4c7d4378ROBC8A
问题二：MQTT有可以根据MsgId查询消息,并获取消息内容的接口吗?这怎么查轨迹啊？
MQTT有可以根据MsgId查询消息,并获取消息内容的接口吗?这怎么查轨迹啊？
参考答案：
"暂时不支持。
关于本问题的更多回答可点击进行查看：
https://developer.aliyun.com/ask/541219?spm=a2c6h.12873639.article-detail.53.4c7d4378ROBC8A
问题三：MQTT中这个重投次数是默认的吗？没在文档中找到相关的描述。
MQTT中这个重投次数是默认的吗？没在文档中找到相关的描述。post-cn-2r42nrmzf09
参考答案：
15次， 3-10s左右的重试时间，间隔时间不一定固定，看网络情况和堆积情况。
关于本问题的更多回答可点击进行查看：
https://developer.aliyun.com/ask/541218?spm=a2c6h.12873639.article-detail.54.4c7d4378ROBC8A
问题四：MQTT中这种情况是什么原因导致的？
MQTT中这种情况是什么原因导致的？
参考答案：
MQTT 中，这种情况可能是由以下原因导致的：
客户端没有连接到 MQTT 服务器。
客户端订阅的主题不存在。
客户端发送的消息过大。
客户端发送的消息格式错误。
客户端发送的消息被 MQTT 服务器拒绝。
你可以通过以下方式排查问题：
检查客户端是否已经连接到 MQTT 服务器。
检查客户端订阅的主题是否存在。
检查客户端发送的消息大小是否超过 MQTT 服务器的限制。
检查客户端发送的消息格式是否正确。
检查客户端发送的消息是否被 MQTT 服务器拒绝。
如果不能通过上述方式排查问题，你可以联系 MQTT 服务器的提供商寻求帮助。
关于本问题的更多回答可点击进行查看：
https://developer.aliyun.com/ask/541217?spm=a2c6h.12873639.article-detail.55.4c7d4378ROBC8A
问题五：MQTT中我们现在有以下场景，我们这样处理有啥问题没有呢？
MQTT中我们现在有这样的场景：
服务端通过 p2p 方式发送消息到客户端。客户端A是通过进程通信方式，需要另一个进程B真正处理消息，是异步交互的，B处理后再异步通知客户端进程。没法通过
正常处理消息这种方式自动ack.
没法主动ack的话；我们想的是第一次通知B处理，但是A抛异常，不自动ack；等离线消息来的时候A检查处理完成没有，再自动ack, 如果还没收到B的回执，可能会再抛异常，直到确认结果。
请问这样处理有啥问题没有呢？离线消息来的时候指的是第二次或者后续的重投。
参考答案：
这样处理有点奇怪，重投只是为了保证消息到达，业务强依赖这个有点奇怪，应该是A中设置异步调用B，B处做幂等，B做完了就调用A回调通知完成。A等待异步结果最终返回ack或者超时。你的方案理论上没有问题，做充分测试符合你们业务预期即可。不过注意重投有次数限制，超出一定次数就不会重投了，这个值目前最低是10. 离线消息的概念是针对客户端订阅的，clean session为true的话，消费者客户端再次上线时，将不再关心之前所有的订阅关系以及离线消息。clean session为false时，消费者客户端再次上线时，还需要处理之前的离线消息，而之前的订阅关系也会持续生效。所以重投和离线的概念无关。
可以看下相关概念
https://help.aliyun.com/document_detail/59914.html?spm=a2c4g.42419.0.i1
关于本问题的更多回答可点击进行查看：
https://developer.aliyun.com/ask/541216?spm=a2c6h.12873639.article-detail.56.4c7d4378ROBC8A
