我正在研究使用Jersey SSE来替换目前成千上万REST资源的轮询机制。随着注册节点数量的增加,轮询方法的伸缩性不是很好。
我有一个客户端,可以管理很多服务器,使用该客户端可以注册多达10000个节点/服务器,而每个节点都有一组REST资源。 可以说,其中一些资源当前以30秒为间隔进行轮询,以使客户端使用从REST资源获得的信息保持最新。该信息通常以可用内存,磁盘空间,CPU使用率等形式出现。 考虑通过HTTP / REST对在不同主机上运行的某些JVM进程(带有servlet容器和Jersey)的监视。 尽管由于它主要是监视数据,所以与客户机的状态保持一致直到第二秒(当前轮询使用30秒间隔)对于客户端来说并不重要,但是另一方面,某些非常重要的功能客户端的数量取决于特定的REST服务器是否在线以及它处于什么状态。
被轮询的数据本身不应该经常更改,因此我开始研究SSE,其思想是客户端/服务器使用某种智能NIO方法,以便在没有数据的情况下不让进程繁忙当前正在通过网络传输的数据/事件。
因此,我已经下载了最新的球衣发行版并开始进行查看。我很快就运行了基本的SSE示例。
SSE资源与示例完全相同,而客户端是这样的。 COUNT_EVENT_SOURCE可以高达10000:
public static void main(String[] args) {
Client client = ClientBuilder.newBuilder().register(SseFeature.class)
.build();
for (int i = 0; i < COUNT_EVENT_SOURCE; i++) {
WebTarget target = client.target(Constants.ENDPOINT);
EventSource eventSource = EventSource.target(target).build();
final int count = i;
EventListener listener = new EventListener() {
@Override
public void onEvent(InboundEvent inboundEvent) {
System.out.println("listener no. " + count + " event name: " + inboundEvent.getName()
+ "; " + inboundEvent.readData(String.class));
}
};
eventSource.register(listener, "message-to-client");
eventSource.open();
}
}
我启动了一个jvisualvm,并观察到为每个客户端创建了一个新线程,只要与SSE资源的连接良好,该线程就会保持活动状态。
因此,如果我有一个客户端希望使用SSE与位于不同主机/端口上的多达10000个SSE资源进行通信,这意味着我将为每个SSE资源持续使用10 000个长生存线程CPU时间和10000个使用寿命长的客户端套接字对吗?
这似乎又不是一种非常可扩展的方法...
可以使用具有适当大小的线程池代替吗? 总的来说,您认为SSE对于这种用例来说是一个很好的解决方案吗?