在聊天系统中跟踪消息

Question

我们已经在 Node.JS 中构建了一个聊天系统。我们有三个用于传递消息的通道，一个使用mqtt 协议，第二个使用第三方服务推送通道，第三个消息获取服务基于接收到的gcm。一旦消息从一个用户发送到第二个用户，它就会存储在 redis 中，直到它传递给第二个用户。 我们面临的问题是我们无法跟踪未投递的丢失消息 知道如何跟踪聊天中的消息吗？

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

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

Answer 1

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

服务质量是：

• 最多一次 (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. 在聊天服务器不可用时保存消息的本地存储。

就是这样。

也许使用 pub/sub 服务看起来更简单，因为它处理接收、管理和传递消息的复杂性，但它们更多地被设计为与进出的客户端解耦时间不知道别人。