通过Socket.IO将数据从RabbitMQ发送到Node.JS

我将设计一个系统，其中客户端和web应用程序之间存在双向通信。web应用程序可以从客户机接收数据，以便将其持久化到DB等，同时还可以向客户机发送指令。因此，我将使用Node.JS和Socket.IO

我还需要使用RabbitMQ，因为我希望如果web应用程序向客户机发送指令，而客户机已关闭（因此套接字已断开），我希望它排队，以便在客户机再次连接并创建新套接字时发送它

从客户机到web应用程序应该非常简单，因为客户机使用套接字将数据发送到Node.JS应用程序，然后Node.JS应用程序将数据发送到队列，以便最终将数据转发到web应用程序。从这个方向看，如果套接字关闭，则没有internet连接，因此数据不会首先发送，或者缓存在客户机上

我关心的是另一个方向，在我以这种方式设计它并实际实施它之前，我希望得到一个答案，这样我就可以避免撞到任何砖墙。假设web应用程序尝试向客户端发送指令。如果套接字可用，web应用程序将指令转发给队列，队列又将指令转发给Node.JS应用程序，Node.JS应用程序又使用套接字将指令转发给客户端。到现在为止，一直都还不错。另一方面，如果来自客户端的internet连接已断开，因此套接字当前已关闭，则web应用程序仍将向队列发送指令。我的问题是，当队列将指令转发给Node.JS，并且Node.JS发现套接字不存在，因此无法发送指令时，队列是否会收到Node.JS的回复，即它无法转发数据，因此应该保留在队列中？如果是这样，那就太完美了。当客户端成功连接到internet时，它将再次执行握手，队列将再次尝试发送到Node.JS，只有这一次Node.JS成功地将指令发送到客户端

---

这是关于这些组件如何相互作用的正确推理吗？

这不会按您希望的方式工作

当节点进程从rabbitmq接收到消息并看到套接字消失时，您可以轻松地

nack

将消息返回队列

但是，将立即再次处理该消息。它不会坐在那里无所事事。节点进程将再次拾取它。最终，您的节点/rabbitmq将受到重击，因为它只是一次又一次地发送消息，等待套接字重新联机

如果您有几十条或数百条未连接的客户机消息，您将有几十条或数百条消息在这样的圆圈中来回摆动。它将破坏节点进程和rabbitmq的性能

我的建议是：

当节点应用程序从rabbitmq接收到消息，并且套接字对客户端不可用时，将消息放入数据库表中，并将其标记为正在等待该客户端

当客户端重新连接时，检查数据库中是否有任何挂起的消息，并在该点转发所有消息