我们已经用 Node.JS 构建了一个聊天系统。我们有三个 channel 用于传递消息，第一个使用 mqtt 协议(protocol)，第二个使用第三方服务推送 channel ，第三个基于接收到的 gcm 消息获取服务。一旦消息从一个用户发送到第二个用户，它就会存储在 Redis 中，直到传递给第二个用户。
我们面临的问题是我们无法追踪未送达的丢失邮件
知道我们如何跟踪聊天中的消息吗？
我们尝试从客户端确认消息。但有时由于 api 故障等原因，我们也无法获得 ack。因此我们无法跟踪消息。
我还研究了消息系统，其中一些使用基于队列的消息代理。我正在考虑使用rabbit mq来达到这个目的。有人可以解释一下天气消息代理将使消息传递更加清晰吗？
最佳答案
也许(除非特定情况)pub/sub 可能不是您需要的正确工具，在这种情况下，pub/sub (mqtt) 的问题在于这是广播发布，这意味着您只是发布一个给该主题订阅者的消息。 Pub/Sub 有一种称为服务质量 (QoS) 的东西，它有 3 个级别，其中处理此消息的代理的行为将取决于您想要的传递的可靠性:
服务质量是:
- 最多一次 (0)
- 至少一次 (1)
- 恰好一次 (2)
QoS 级别 2 可能是您需要的级别，其中消息将被重试，直到它被传递到接收者，因此如果它(接收者)不可用，代理将继续尝试传递消息，但 QoS 级别的问题2 是并不是所有的 pub/sub 服务都可用(我认为 Redis 没有它，至少我知道)……其次，你需要知道谁是所有接收者才能建立这个 QoS级别。
您可以在此处找到有关 QoS 的更多详细信息: https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/
我认为这个项目所需的最好(也许是最简单)的工具是
- 文档数据存储 (NoSQL)，用于使用 UUID 和 时间戳。
- Web 套接字，用于通知所有连接的客户端有新消息 消息。这也将是提供新传入的 channel 消息(也可以用于获取旧消息，但取决于 需求水平)。
- 本地存储用于在聊天服务器不可用时保留消息。
就是这样。
也许使用发布/订阅服务看起来更简单，因为它处理接收、管理和传递消息的复杂性，但它们更旨在与传入和传出的客户端解耦。时间不知道其他人。
关于javascript - 跟踪聊天系统中的消息，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57951368/