**结束。**此问题不符合堆栈溢出准则。它目前不接受答案。
**想改进这个问题吗？**更新问题，使其成为堆栈溢出的主题。

三个月前关门了。
改进这个问题
我们有一个spring引导后端，它还维护与客户端（浏览器选项卡）的双向（stomp-over）websocket连接。我们已经使用stompbrokerrelay（服务器端）+activemq（消息代理）实现了这一点。还有一个心跳消息每25秒交换一次，以保持连接。

我们面临的问题

在1k连接之前，这个设置似乎运行良好。一旦超过activemq中的几千个连接，我们就会遇到一些奇怪的问题：浏览器能够通过spring boot成功连接和订阅activemq上的主题，但是它没有成功接收到任何消息，同时能够每25秒交换一次心跳！我们的spring后端提高了cpu利用率，其中一个线程tcp客户机循环消耗1个完整的cpu。
我们也在下面分享了我们的完整调查。

问题

这种带有一些可调参数的体系结构是一个很好的解决方案，可以在明天扩展到大约10万个并发websocket连接吗？如果没有，有哪些行业推荐的向浏览器发送通知的替代方案？我们也一直在研究socket.io+redis pub/sub在互联网上的大量引用，但不确定它是否真的是一个更好的方法。

目前为止的调查

我们的后端日志显示正在发布事件并将其中继到客户端，但是这些事件的负载为空并且包含 stompMessageType 作为 OTHER 而不是假设值 MESSAGE . 我们还使用了终端上的stomp客户机直接与activemq连接，并注意到在这段时间内没有来自订阅主题的消息，因此我们的注意力转向了activemq代理端的一些错误。
在同样的高流量时间段，我们注意到我们的后端被卡在 tcp-client-loop 然而，线程还不能确定这是否与activemq服务器的连接有关。p、 我们决定在高流量时排除tcp连接限制，因为连接已成功建立。我们还将activemq配置为通过stomp接受50k连接，而不是默认的1k连接。
我们从activemq的日志（和web控制台）中几乎找不到任何关于发布或消费的错误，即使是在 DEBUG 以及 TRACE 日志级别。在此期间，cpu利用率仅徘徊在5%左右。