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://help.aliyun.com/document_detail/42420.html?spm=a2c4g.59914.0.0.27a386f62x80M9#concept-42420-zh
此回答整理至钉群“阿里云 微消息队列 MQTT产品咨询群”。"2023-08-09 11:27:36赞同 展开评论
涵盖 RocketMQ、Kafka、RabbitMQ、MQTT、轻量消息队列(原MNS) 的消息队列产品体系，全系产品 Serverless 化。RocketMQ 一站式学习：https://rocketmq.io/