scalability - Websocket可扩展性，广播问题

Question

如果您对许多用户(和服务器)设置了复杂的要求，那么您的websocket基础架构(服务器)将如何扩展，尤其是在广播方面？

当然，广播不是任何websocket规范的一部分，但即使在基本的聊天示例中(也就是websocket的hello世界)，广播都是存在的。

客户端(寻求新数据)解决方案似乎仍然比服务器端(广播)解决方案更具可扩展性，因为Websockets的延迟低且相对便宜(无HTTP header )。

编辑:

好的，只是认为您想用websocket实现替换所有的ajax代码，这可能意味着在这么多不同的上下文中有那么多的连接。如果要跟踪广播的每种可能情况，这将给您的系统增加极大的复杂性。

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

而且，广播给 table 带来了某种状态性，这很难扩展。考虑添加更多服务器和负载平衡。

Answer 1

扩展实时Web解决方案可能是一个复杂的问题，但Pusher(我为之工作)之类的服务已经解决，并且为self hosted realtime web solutions定义了绝对肯定的解决方案是一个问题-PubSub paradigm已广为人知，并且已经按顺序解决了很多次要解决该问题，需要有某种状态(谁在订阅什么)。此范例用于广播您正在谈论的场景类型。

建立实时网络技术时要牢记大量的同时连接-许多都是从头开始的。如果要创建可伸缩的解决方案，则很可能会使用支持WebSocket的现有实时Web服务器，其方式与您不太可能决定实现自己的HTTP Server一样，不太可能希望实现自己的服务器从头开始支持WebSockets。

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

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

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

但是，由于我们正在谈论广播数据，因此我们需要回到PubSub范例，在该范例中拥有事件订阅更为有意义，并且当有新数据可用时，会将新数据分发给这些事件订阅(推送)。您的应用程序所有需要知道的是是否有任何事件的订阅，以便决定是否发布数据。这个问题已经解决了。