如果您有一个包含许多用户（和服务器）的复杂要求，您的 websocket 基础设施（服务器）将如何扩展，尤其是广播？
当然，广播不是任何 websocket 规范的一部分，但它甚至存在于基本的聊天示例中（又名 websocket 的 hello world）。
客户端（请求新数据）解决方案似乎仍然比服务器端（广播）解决方案更具可扩展性，因为 Websocket 具有低延迟和相对便宜（http 无头）的特性。
Edit:
好吧，假设您想用 websocket 实现替换所有 ajax 代码，这可能意味着在如此多的不同上下文中存在如此多的连接。如果您想跟踪每个可能的广播场景，这会给您的系统增加巨大的复杂性。
低（网络/线程等）级别的实现建议也是问题的一部分，而不是解决方案，因为这意味着您必须编写与一般 http 服务器不同的特殊服务器。
此外，广播带来了某种无法轻易扩展的状态特性。考虑添加更多服务器和负载平衡。
扩展实时网络解决方案可能是一个复杂的问题，但像这样的服务Pusher http://pusher.com（我为之工作的人）已经解决了，并且有最明确的解决方案定义为自托管实时网络解决方案 http://www.leggetter.co.uk/real-time-web-technologies-guide#self-hosted - the 发布订阅范式 http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern很好理解并且已经被解决了很多次，为了解决问题需要有某种状态（谁在订阅什么）。该范例用于广播您正在讨论的场景类型。
实时网络技术在构建时就考虑到了大量的同时连接——许多是从头开始的。如果您想创建一个可扩展的解决方案，您很可能会使用支持 WebSocket 的现有实时 Web 服务器，就像您不太可能决定实现自己的 HTTP 服务器一样，您不太可能想要实现自己的服务器它从头开始支持 WebSockets。
专用实时 Web 服务器还允许您将应用程序逻辑与实时通信机制分开（关注点分离）。您的应用程序可能需要维护某种状态，但实时技术负责管理订阅和连接。如何实现应用程序和实时 Web 技术之间的通信取决于您，但经常使用消息队列，特别是redis http://redis.io在这个领域很受欢迎。
HTTP 轮询在概念上可能更容易理解 - 您可以保持无状态性，并且对于每个 HTTP 轮询请求，您可以准确指定您要查找的内容。但这绝对意味着您需要更快地开始扩展（添加更多资源来处理负载）。
WebSocket 轮询是我以前没有考虑过的东西，我想我以前也没有在任何地方看到过它的建议；客户应该说“我已经准备好接受下一组数据，这就是我想要的”，这是一个有趣的想法。 WebSocket 通常已经脱离了请求/响应范式，但在某些情况下，WebSocket 的效率提高以及使用它们的请求/响应可能会带来一些好处。这套接字流 https://github.com/socketstream/socketstream应用程序框架可能值得一看，因为它可能是相关的；初始应用程序加载后，所有通信都通过 WebSocket 执行，这意味着事件基本请求/响应功能使用 WebSocket。
然而，由于我们正在讨论广播数据，因此我们需要回到 PubSub 范例，在这种范例中，拥有活动订阅更有意义，并且当新数据可用时，新数据将分发到这些活动订阅（推送）。您的应用程序需要知道的是是否有任何活动订阅，以便决定是否发布数据。这个问题已经解决了。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
