目前我们正在构建一个支持SSE的web应用程序。
我们对SSE都比较陌生，所以我们要处理很多(新手)问题:
当客户端关闭浏览器时，我们将以断开连接告终。我想有人叫它鬼影联系。我们如何在服务器端检测这种连接?我们想要从通知列表中删除这些客户端。
限制连接数
我明白每个"SSE-connection"在application server上都是活的。当我关闭开发服务器时，我直接在浏览器调试器上注意到连接消失了。我们不应该设置一些连接的上限吗? The application server连接将耗尽一段时间…
此外，有些服务器为每个请求指定一个线程。所以这可能会导致一些线程耗尽问题…
应用程序或web服务器
整个SSE-broadcasting应该由application server(其中大多数请求与业务相关)管理，还是应该由一些完全专用于处理SSE-event的web server管理?目前，所有业务请求和sse事件都由Jboss application server处理。
如何在集群环境中应用active-active模式管理SSE(=master-master)请求在实例之间随机路由?
如果你有更多有用的信息(和注意事项)，请随时分享!
集群环境
我想你的意思是
- 任意数量的后端
- 来自客户端的查询可以针对任何后端实例(负载均衡)
- 后端实例可以无声地消失(崩溃或pod因资源原因或其他原因而终止)
在这种情况下，我认为你需要区分什么需要从客户端拉，什么需要从后端推。通常需要推送的内容是实时通知或更新。但许多其他调用可以用经典的方式拉出。对于所有从客户端拉出来的东西，只要你的后端是无状态的，那么你就没事了。
对于所有被推送的内容，我将这样做:当打开浏览器应用程序(客户端)时，它会创建到一个后端实例的SSE连接。你不能保证是哪一个。后端应该每隔X秒向客户端发送一次心跳。如果客户端停止接收心跳，那么他可以假定后端已经关闭。然后，它可以重新创建SSE连接。但是你可能丢失了通知……为了避免这种情况，你可以有一个时间戳或通知id，当重新创建连接时，你传递时间戳或id来获取所有后续的通知。
在后端下面，需要某种消息总线或代理的订阅系统。以便每个后端接收到通知并尝试将它们推送到连接的客户端。
限制连接数
使用上面的设计，您可以通过终止创建的第一个连接来限制每个后端连接的数量。然后，客户端将尝试建立到可能的新后端实例的连接。这可能不是"干净"，但可能工作…
<<p> 断开连接/strong>看Audrey回答，这其实是使用heartbeat的经典方式:)
应用程序或web服务器
我认为这个问题会导致固执己见的答案。对我来说，我会说"KISS"(简单点)
集群环境
管理服务器发送的事件应用程序与管理传统的web应用程序没有太大的不同。您可以使用负载平衡器来正确管理集群环境，并实现自动扩展机制，以便在达到实例限制时继续为连接提供服务。你应该注意的最重要的一点是确保你使用的代理可以保持你的连接几乎无限期地打开:HAProxy和NGINX是很好的候选人。
限制连接数
有些服务器回收线程(例如Undertow)，有些则不。一旦知道所选择的服务器如何处理线程，就可以计算每个实例的限制。
应用程序或web服务器
除非管理"经典"业务相关请求的应用服务器已经被大量使用，否则没有必要使用专用服务器来管理sse事件。
<<p> 断开连接/strong>对于断开的连接，您可以通过定期发送通常称为"心跳"的内容来测试它们:如果连接已被客户关闭，则会返回一个空消息。