我想我理解MOM 或Message Queues 背后的想法，但我不确定下面的实现细节。
由于有一个元素充当调度程序，因此它必须与所有客户端具有持久的 TCP 连接（因为可靠性是一项要求）。
因此，对于N 客户端，即使当前没有通信，我们也始终打开N（N 任意高）连接。
这是正确的吗？
流行框架的健壮实现如何处理这个问题？
【问题讨论】：
标签： java jakarta-ee tcp jms message-queue
如果您有 n 个客户端，则您有 n 个连接。
可能还有其他的：如果您使用 JNDI 查找了队列/连接工厂等，那么还有另一个到 JNDI 端口和 RMI 注册表的连接（使用 JBoss 6 观察到）。
另一方面，如果消息传递服务器在 TCP 套接字上使用select()，则仅使用一个线程处理大量连接非常有效。至于连接数/socket数，看看这个问题：How many socket connections are possible。
我不知道使用 UDP（包括可靠性）的 JMS 实现。所以 你无法真正解决这个问题，因为 JMS 使用 TCP 特性来实现可靠且“有序”的分组传递。
如果延迟不是问题，例如，客户端始终可以每分钟“连接、读取、断开连接”。
对于 ActiveMQ，它提供 UDP 传输，请参阅here。在这种情况下，由您来处理可靠性问题。
如果您担心连接/客户端的数量，您可以考虑使用带有自己的协议的“原始 UDP”作为替代方案。
【讨论】：
if the messaging server uses select() on the TCP sockets, that's pretty efficient。我不明白这一点。这个（select与服务器的资源有关，而不是连接数）。那你为什么要提到这个？
假设客户端想要实时接收消息，那么是的，需要与 JMS 服务器的有效且持续的连接。
独立 JMS 客户端使用专用连接，因此 1 个客户端=1 个连接。另一方面，在应用服务器内部运行的消息驱动 bean 重用池中的连接和会话对象，通常可在应用服务器中配置以限制这些对象的数量，但是，连接是“持续”连接的到 JMS 服务器；在应用服务器中的实现方式因产品而异。所以在一个应用服务器中，如果你有 20 条 MDB 的消费消息，但是将池配置为最多使用 10 个连接，你可以确定只会打开 10 个连接。
非活动连接
队列客户端不必连接到服务器，但消息会累积在队列中，当客户端连接时，所有消息将按顺序传递。
连接断开
如果连接断开，客户端（或容器；而不是 JMS 服务器）必须在再次使用消息之前重新连接。
您是否关心与 JMS 服务器的连接数？ 您是指独立的 JMS 客户端还是 MDB？
【讨论】：
the app server typically uses a pool of JMS connections for efficiency and to minimize connections您的意思是通常客户端连接到应用服务器，应用服务器连接到消息队列调度程序？否则我无法理解如何重用连接？此外，这种设计在所有实现中都相同吗？例如。 ActiveMQ、RabbitMQ 等？
X 客户端意味着X 连接，并且随着客户端上升，连接上升。这通常是如何解决的。我认为客户端数量的增加，即连接数量必须以某种方式解决，对吗？