如果您对许多用户(和服务器)设置了复杂的需求,那么您的websocket基础架构(服务器[s])将如何扩展,尤其是广播?
当然,广播不是任何websocket规范的一部分,但它甚至在基本的聊天示例中也是如此(a.k.a.webocket的hello world)。
客户端(请求新数据)解决方案似乎仍然比服务器端(广播)解决方案更具可扩展性,具有websockets的低延迟和相对便宜(http无头)性质。
编辑:
好的,只是认为你想用websocket实现替换所有的ajax代码,这可能意味着在很多不同的上下文中有这么多的连接。如果您想跟踪广播的每种可能情况,这会给您的系统增加极大的复杂性。
低(网络/线程等)级别的实现建议也是问题的一部分,而不是解决方案,因为这意味着您必须编写一个特殊服务器,而不像一般的http服务器。
此外,广播给桌面带来某种状态性,不容易扩展。考虑添加更多服务器和负载平衡。
答案 0 :(得分:15)
扩展实时网络解决方案可能是一个复杂的问题,但像Pusher(我工作的人)这样的服务已经解决了问题,而且self hosted realtime web solutions确定了最明确的解决方案 - {{ 3}}很好理解并且已经解决了很多次,为了解决问题,需要有一些状态(谁订阅了什么)。这种范例用于广播您正在谈论的场景类型。
实时网络技术的构建充分考虑了大量的同步连接 - 很多都是从头开始的。如果您想创建一个可扩展的解决方案,您很可能会使用支持WebSockets的现有实时Web服务器,就像您决定实施自己的HTTP服务器一样,您不太可能想要实现自己的服务器它从头开始支持WebSockets。
专用的实时Web服务器还允许您将应用程序逻辑与实时通信机制(关注点分离)分开。您的应用程序可能需要维护某些状态,但实时技术涉及管理订阅和连接。如何实现应用程序与实时Web技术之间的通信取决于您,但经常使用消息队列,具体而言PubSub paradigm在此领域非常流行。
HTTP轮询在概念上可能更容易理解 - 您可以维护无状态,并且每个HTTP轮询请求都可以准确指定您要查找的内容。但它绝对意味着您需要更快地开始扩展(添加更多资源来处理负载)。
WebSocket民意调查是我以前没有考虑过的事情,我认为我之前在任何地方都没有看到过它;客户应该说“我已准备好接收下一组数据,这就是我想要的东西”这个想法很有意思。 WebSockets通常从请求/响应范例中脱颖而出,但可能存在WebSockets的效率提高和使用它们的请求/响应可能具有一些好处的情况。 redis应用程序框架可能值得一看,因为它可能是相关的;在初始应用程序加载之后,所有通信都通过WebSockets执行,这意味着事件基本请求/响应功能使用WebSockets。
然而,由于我们谈论的是广播数据,我们需要回到PubSub范例,在这种情况下,拥有有效订阅更有意义,并且当新数据可用时,新数据将分发给那些活动订阅(推送)。您的所有应用程序需要知道的是,是否有任何活动订阅,以决定是否发布数据。那个问题已经解决了。
答案 1 :(得分:1)
websockets的想法是保持与每个客户端的持久连接。当您想要发送给每个客户的新数据时,您已经知道所有客户是谁,所以您应该发送它。
听起来您希望每个客户端不断向服务器发送请求以获取新数据。为什么?这似乎会浪费每个人的带宽,我不知道为什么你认为它会更具可扩展性。也许您可以为您的问题添加更多细节,例如您正在播放的信息类型,频率,字节数,客户数等等。
为什么不将开放的websocket连接视为来自客户端的更多数据的持久请求?