我工作的公司评估了 MQTT，并决定将其用作大型系统的核心消息传递平台。主要原因是协议的紧凑程度以及实际实现的容易程度。不过，我对 MQTT 有一个问题，我正在寻找以下问题的答案：
QoS1 和 QoS2 消息需要客户端确认。在接收 PUBACK、PUBREC、PUBREL 和 PUBCOMP 时，我对消息（识别它）的唯一了解是 messageId 和 clientId。消息 id 是一个无符号的 int16，因此最大值是 65535。对于长时间运行的客户端来说，它似乎不够大，比如一年，每小时发送 15 条 QoS2 消息。
我不太确定是否还有其他方法可以识别消息？我希望尽可能符合标准。
可能要明确的第一点是消息 ID 是在每个客户端和每个方向的基础上处理的。也就是说，代理将为每个连接的客户端创建一个 QoS>0 的传出消息的消息 ID，并且这些消息 ID 将完全独立于用于发布到其他客户端的同一消息的任何其他消息 ID。同样，每个客户端都会为其发送的消息生成自己的消息 ID。
消息 ID 不必是唯一的，因此您的客户端每小时发送 15 条 QoS 级别 2 的消息会在某个时候简单地溢出。真正的限制是每个方向一次最多只能有 65535 条消息“在飞行中”（即，在消息握手的过程中）。一旦具有给定 ID 的消息被完全处理，那么该消息 ID 就可以被重用。
另一种看待它的方法是考虑如果您的客户一次只有一条消息在传输中，它将如何工作，无论是因为消息传输的速率还是您处理消息的方式的设计。在这种情况下，您可以将每条消息的消息 ID 设置为 1，因为永远不会有重复的机会。
如果您希望支持同时发送多条消息，则在分配新消息之前检查是否有消息 ID 重复是相对简单的。
因为消息 ID 是每个客户端的，所以如果您向 >65535 个客户端发送单个消息，则不会有消息 ID 冲突的机会。如果您一次向每个客户端发送 >65535 条消息并且消息流不完整，那么就会出现问题。
回答评论“我注意到每个 MQTT 代理倾向于只传递最后一个 QoS1/2 消息”：
代理只会向它知道的客户端发送消息。如果您是第一次连接，则无法获取过去的消息，但有一个例外：保留消息。如果将消息设置为保留，则它是“最后一次正确”的值。当新客户端订阅时，它将立即发送保留消息，这对于不经常更新的内容非常有用。我怀疑这就是你所指的。如果您希望客户端在未连接时将消息排队，那么您必须禁用“干净会话”选项以使客户端持久连接。您还必须使用 QoS>0 订阅和 QoS>0 发布。当您的客户端重新连接时（干净会话仍设置为禁用），排队的消息将被传递。您通常可以在代理中以这种方式配置要排队的消息数量，其中任何进一步的消息都将被丢弃。重要的一点是，设计不支持为先前未连接的客户端排队消息。
为了在 QOS1 或 QOS2 上传递更多消息，您应该使用持久内存的概念。在这种情况下，当订阅者不可用时，消息将存储在持久内存中，并在订阅者连接后传递。您也可以在配置 mosquitto.conf 文件后在 QOS0 上执行此操作。