Websocket的可扩展性,广播问题

Question

如果您有许多用户(和服务器)的复杂需求集,您的websocket基础架构(服务器[s])将如何扩展,尤其是广播？

当然,广播不是任何websocket规范的一部分,但它甚至在基本的聊天示例中(也就是websocket的hello world).

客户端(请求新数据)解决方案似乎仍然比服务器端(广播)解决方案更具可扩展性,其中websockets的低延迟和相对便宜(http无头)性质.

编辑:

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

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

而且,广播给桌面带来某种状态性,不容易扩展.考虑添加更多服务器和负载平衡.

Answer 1

扩展实时Web解决方案可能是一个复杂的问题,但像Pusher(我为之工作)这样的服务已经解决了问题,并且有一个确定为自托管实时Web解决方案定义的解决方案 - PubSub范例已被很好地理解并且已经解决很多次,为了解决问题,需要有一些状态(谁订阅什么).这种范例用于广播您正在谈论的场景类型.

实时Web技术的构建考虑了大量的同时连接 - 许多是从头开始的.如果您想创建一个可扩展的解决方案,您很可能会使用支持WebSockets的现有实时Web服务器,就像您决定实施自己的HTTP服务器一样,您不太可能想要实现自己的服务器它从头开始支持WebSockets.

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

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

WebSocket轮询是我以前没有考虑过的事情,我认为我之前在任何地方都没有看过它.客户应该说"我已准备好接收下一组数据,这就是我想要的东西"这个想法很有意思.WebSockets通常从请求/响应范例中脱颖而出,但可能存在WebSockets的效率提高和使用它们的请求/响应可能具有一些好处的情况.该SocketStream应用框架可能是值得,因为它可能是相关的样子; 在初始应用程序加载之后,所有通信都通过WebSockets执行,这意味着事件基本请求/响应功能使用WebSockets.

但是,由于我们讨论的是广播数据,我们需要回到PubSub范例,在这种情况下,拥有有效订阅更有意义,并且当有新数据可用时,新数据会分发给那些活动订阅(推送).您的所有应用程序需要知道的是,是否有任何活动订阅,以决定是否发布数据.那个问题已经解决了.