Websocket可伸缩性，广播问题

Question

如果你有一个复杂的需求集，有很多用户(和服务器)，你的websocket基础设施(服务器)将如何扩展，特别是在广播方面？

当然，广播不是任何websocket规范的一部分，但它甚至存在于基本的聊天示例中(也称为。websocket的hello world )。

客户端(请求新数据)解决方案似乎仍然比服务器端(广播)解决方案更具扩展性，websockets的低延迟和相对便宜(http headerless)特性。

编辑：

好的，假设你想用websocket实现替换所有的ajax代码，这可能意味着在这么多不同的上下文中有这么多的连接。如果您想要跟踪广播的每个可能的场景，这会给您的系统增加巨大的复杂性。

低(网络/线程等)级别的实现建议也是问题的一部分，而不是解决方案，因为这意味着你必须编写一个特殊的服务器，而不是一般的http服务器。

此外，广播给表带来了某种状态性质，这不容易扩展。考虑添加更多的服务器和负载均衡。

Answer 1

扩展实时web解决方案可能是一个复杂的问题，但像Pusher (我为其工作)这样的服务已经解决了这个问题，并且有最明确的解决方案为self hosted realtime web solutions定义- PubSub paradigm是很好理解的，并且已经被解决了很多次，为了解决这个问题，需要有一些状态(谁订阅了什么)。此范例用于广播您正在讨论的场景类型。

​

​

实时web技术在构建时就考虑到了大量的同步连接--许多是从头开始的。如果你想创建一个可扩展的解决方案，你很可能会使用现有的支持WebSockets的实时web服务器，就像你不太可能决定实现你自己的HTTP server一样，你也不太可能想从头开始实现你自己的支持WebSockets的服务器。

专用的实时web服务器还可以让您将应用程序逻辑与实时通信机制(关注点分离)分开。您的应用程序可能需要维护一些状态，但实时技术处理的是管理订阅和连接。如何在应用程序和实时web技术之间实现通信取决于您，但是经常使用消息队列，特别是redis在这个领域非常流行。

HTTP轮询在概念上可能更容易理解-您可以保持无状态，并且对于每个HTTP轮询请求，您可以准确地指定您正在寻找的内容。但这绝对意味着你将需要更早地开始扩展(添加更多的资源来处理负载)。

WebSocket轮询是我以前没有考虑过的事情，我想我以前也没有在任何地方看到过它的建议；客户应该说“我已经准备好接受我的下一组数据，这是我想要的”，这是一个有趣的想法。WebSockets通常已经脱离了请求/响应范例，但在某些情况下，WebSockets的效率和使用它们的请求/响应的提高可能会带来一些好处。SocketStream应用程序框架可能值得一看，因为它可能是相关的；在初始应用程序加载之后，所有通信都通过WebSockets执行，这意味着事件基本请求/响应功能使用WebSockets。

​

​

然而，由于我们讨论的是广播数据，我们需要回到PubSub范例，在这种范例中，拥有活跃的订阅更有意义，并且当新数据可用时，新数据被分发到那些活跃的订阅(推送)。为了决定是否发布数据，您的应用程序需要知道是否有任何活动的订阅。这个问题已经解决了。

Answer 2

websockets的思想是保持与每个客户端的持久连接。当有新数据要发送给每个客户端时，您已经知道所有客户端是谁，所以您应该直接发送它。

这听起来像是您希望每个客户端不断地向服务器发送请求以获取新数据。为什么？这似乎会浪费每个人的带宽，我不知道为什么你会认为它会更具可扩展性。也许你可以在你的问题中添加更多细节，比如你正在广播什么类型的信息，多长时间一次，多少字节，多少个客户端，等等。

为什么不把开放的websocket连接看作是客户端对更多数据的长期请求？