问题描述
我正在构建一个使用从服务器推送的数据的 Web 应用程序。
每条消息都是 JSON，可能很大，数百 KB，消息每分钟发送几次，顺序无关紧要强>.
服务器应该能够保留尚未传送的消息，可能会为客户端存储几兆字节几天，直到客户端无法上网。未发送消息的存储大小有限制，例如每个客户端 20mb，当超过此限制时，未发送的旧消息将被删除。
服务器应该能够处理大约一千个同时连接。如何简单地实施？
可能的解决方案
我想也许将消息作为文件存储在磁盘上并使用浏览器池 1 秒，以检查新消息并使用 Nginx 或类似的东西提供它？对于此类用例，Nginx 是否有一些配置/模块？
或者使用 MQTT Server 或一些 Message Queue（如 Rabbit MQ）和一些浏览器适配器会更好？
解决方法
实际上，MQTT 支持跨客户端连接持续存在的会话概念，但是客户端必须首先连接并请求“非干净”会话。之后，如果客户端断开连接，代理将保留所有发往该客户端的 QoS=1 或 2 消息，直到它重新连接。
使用 MQTT v3.x，从技术上讲，服务器应该永远保存所有这些断开连接的客户端的所有消息！每条消息的最大负载为 256MB，但服务器应该保存您提供的所有内容。这给 MQTT v5 来修复的服务器带来了一个大问题。大多数现实世界的经纪人都有围绕这一点的可配置设置。
但是，如果连接是通过不可靠的网络（无线、蜂窝调制解调器等）进行的，这些网络可能会意外断开并重新连接。
如果客户端通过相当可靠的网络连接，则带有 RabbitMQ 的 AMQP 更加灵活，因为客户端可以创建和管理各个队列。但有趣的是，您可以使用 RabbitMQ 混合使用这两种协议，因为它有一个 MQTT 插件。因此，不可靠网络上的较小客户端可以通过 MQTT 连接，其他客户端可以通过 AMQP 连接，并且它们都可以相互通信。
,MQTT 很可能不是您正在寻找的。该协议是轻量级的，正如评论指出的那样，该协议规定可能只存在“大小不超过 268,435,455 (256 MB)”的控制包source。显然，这对于您的用例来说太小了。
此外，如果在发布消息时客户端未连接（并订阅该特定主题），则永远不会传递消息。 编辑：正如@Brits 所指出的，这仅适用于 QoS 0 发布/订阅。
就像 JD Allen 提到的那样，您需要像 Rabbit MQ 或 AMQ 这样的排队服务。存在无数其他此类服务/库/包，因此请进行更多调查。
如果您想扮演自己的角色，可能值得考虑使用 AWS SQS 并围绕它包装一些您自己的应用程序逻辑。不过，这可能有点棘手，因此请谨慎对待该建议。