在聊天系统中跟踪消息

Question

我们已经在Node.JS中构建了一个聊天系统。在这里，我们有三个用于传递消息的渠道，一个是使用mqtt协议来传递消息，第二是使用第三方服务推送器通道和基于收到的gcm的第三条消息获取服务。消息从一个用户发送到第二个用户后，其存储在redis中，直到将其传递给第二个用户为止。 我们面临的问题是我们无法追踪未送达的缺失邮件 知道如何跟踪聊天中的消息吗？

我们尝试了ack来自客户端的消息。但是有时由于api失败等原因，我们也无法获得acks。由于这一原因，我们无法跟踪消息。

我还研究了消息传递系统，其中一些系统使用基于队列的消息代理。我正在考虑将Rabbit mq用于此目的。有人可以解释一下天气消息代理将使消息传递更加清晰吗？

Answer 1

也许（除非特殊情况）pub / sub可能不是您需要的正确工具，在这种情况下pub / sub（mqtt）的问题是这是广播发布，这意味着您只是发布了主题中订阅者的消息。发布/订阅有一个称为服务质量（QoS）的东西，它具有3个级别，其中，代理处理此消息的行为将取决于您想要的传递的可靠性：

QoS为：

• 最多一次（0）
• 至少一次（1）
• 恰好一次（2）

QoS级别2可能是您需要的级别，在该级别将重试该消息，直到将其传递给接收方为止，因此，如果（接收方）不可用，则代理将继续尝试传递该消息，但是QoS lvl的问题2并非在所有发布/订阅服务上都可用（我认为Redis至少没有，所以我知道）...其次，您需要知道谁是所有接收者才能建立此QoS级别。

在这里您可以找到有关QoS的更多详细信息： https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/

我认为该项目所需的最好的（也许是最简单的）工具是

1. 文档数据存储（NoSQL），用于使用UUID和 时间戳。
2. Web套接字，用于将所有新客户端通知给所有已连接的客户端 消息。这将是传递新的传入内容的渠道 邮件（也可以获取旧邮件，但取决于 需求水平）。
3. 本地存储，可在聊天服务器不可用时保留消息。

就是这样。

也许使用发布/订阅服务可能看起来更简单，因为它处理接收，管理和传递消息的复杂性，但是它们的设计目的是与传入和传出的客户端分离时间不认识别人。