我正在使用 Rails ActionCable。
我主要可以在两种选择之间进行选择。其中之一是将多个渠道用于不同的功能。其他选项是使用具有多个条件的相同通道来创建相同的功能。
放大时哪个更好？构建应用时过度依赖 websockets (Actioncable) 有什么坏处？
谁能给我推荐一些解释 websockets、redis 缓存及其在应用程序扩展时的效果的好文章。
感谢你们期待积极的回应。
【问题讨论】：
标签： ruby-on-rails websocket actioncable
虽然我认为该问题与“Multiple websocket channels, single ws object?”重复，但我将添加一些具体的 ActionCable 注意事项以澄清。
放大时哪个更好？
单个 WebSocket 连接（通常）在扩展时会更好。
服务器对其可以处理的连接数有限制，这意味着为每个客户端添加 WebSocket 连接将消耗有限的服务器资源。
例如，如果每个客户端需要 2 个 WebSocket 连接而不是 1 个，则服务器的容量减少一半（从 100% 下降到 50%）。
在构建应用程序时过度依赖 websockets (Actioncable) 的缺点是什么？
某些机器运行不支持 WebSockets 的旧版浏览器。此外，WebSocket 应用程序和客户端通常更难编码，这意味着更高的维护成本。
话虽如此，WebSockets 是解决困扰 Web 应用程序多年的问题的绝佳解决方案，并且优于轮询技术。
总而言之，我认为应该忽略缺点，因为优点远远超过成本。
但是：
话虽如此，请注意目前Actioncable 的实现速度相当慢。
事实上，有人可能会争辩说实施如此缓慢以至于轮询会更好。
比较ActionCable to AnyCable 或服务器端Iodine WebSocket + Pub/Sub solution 会立即突出一个事实，即在修复之前，ActionCable 应该被其他解决方案替换。
进一步阅读：
我刚开始看this article about Ruby WebSockets, Push and Pub/Sub，写得很好。
我还写了一篇关于 WebSocket 的 Ruby 实现的主要问题以及服务器端 WebSocket 解决方案如何解决这些问题的文章。你可以read it here。
【讨论】：