我有一个相对高层次的体系结构问题。我的应用程序运行在集群中多个物理节点上的多个jvm上。如果我定义了一个websocket端点，使它可以由任何JVM提供服务，我如何启动服务器发起的"发送"消息，以便跨任何JVM的所有适当连接都可以发送消息?
我的意思是，如果用户A连接到JVM-A，用户B连接到JVM-B，然后JVM-C上发生了一个事件，需要通知用户A和B，这将如何工作?起初我在考虑共享连接/会话对象在分布式内存，但我不认为有该对象将是足够的，因为物理连接是在某个服务器上?
有没有更标准的方法来处理这个问题?
建议创建一个ApplicationScoped(如果是JSF)或Singleton(如果使用订阅多播套接字的CDI)的bean(最好是在只有LAN可访问的网络接口上)。当一个websocket发起发送时，它也会向多播组发送一个局域网消息(可能包括要重新发送的websocket消息)。接收bean应该检查它们是否发送了发送的消息(取决于多播环回是否活动)，并丢弃它们自己发起的任何消息，但是一旦局域网消息在多播组上收到，它们将使用自己的活动websockets重新发送相关消息。
借鉴于Phoenix框架的一个想法:
你可以引入某种发布/订阅(例如Redis)。每当在集群中的某个服务器上发生有趣的事情时，向pub/sub发布通知。所有服务器都订阅该pub/sub。当服务器从pub/sub接收到通知时，它检查自己的websockets，决定哪些应该接收消息，将通知转换为消息，并将其发送给客户端。
难点在于pub/sub服务器的单点故障。你必须复制它
您可以创建一个队列，并让节点从该队列中读取数据。接下来的挑战是知道何时从队列中删除消息。建议:每个节点读取消息并为自己连接的套接字组播，然后为消息设置超时时间，这样每个节点都应该知道它已经发送了该消息，如果消息超时，任何节点都可以将其从队列中删除。这对你来说可能吗?