问题描述
我已经将 Faye 与 Ruby On Rails 一起使用，对我来说几乎是 0 成本，因为我正在另一台连接到我的 Rails 应用程序的服务器上运行 Faye.
I have already used Faye with Ruby On Rails, it's almost at 0 cost for me, because I'm running Faye over another server connected to my Rails App.
但是，我遇到了一些问题，例如当 Rails 服务器上的查询时间过长时，一段时间后 Faye Connection 会失败并引发异常.
However I have faced some problems like when a query takes too long on the Rails server, after a while the Faye Connection would fail and raise an exception.
现在我正在研究 Actioncontroller::Live ，大多数实现都使用 Redis，这对我的启动来说有点昂贵，但是我意识到我无法使用 Actioncontroller 进行订阅/发布样式的事情::直播.
Now what I'm looking into the Actioncontroller::Live , most of the implementations are using Redis, which will be a bit costy for my startup, however I realized I can't do subscribe/publish style things with the Actioncontroller::Live.
我的问题:我应该转向 Actioncontroller::Live 还是坚持使用 Faye?虽然这些是我想要完成的事情:
My question: should I move over to Actioncontroller::Live or stick to Faye ? While these are the things that I want to accomplish:
- 评论/提要后更新
- 通知系统，基于发布/订阅，类似于 Faye.
- 异常处理
- 可扩展性 > 更多用户更多连接
我知道 Faye 使用 Bayeux，而 ActionController::live 使用 SSE/HTTP.我应该考虑与 Socket.IO 相关的任何事情吗?SockJS ?
I know that Faye uses Bayeux vs ActionController::live uses SSE/ HTTP.Should I consider anything related to Socket.IO ? SockJS ?
我已经在这里阅读了有关此主题的一些问题，例如:用 rails 4 服务器替换 Faye会外活动?Faye VS rails 4 流媒体?但我需要更多信息:
I have already read through some of the question about this topic on here like:Replace Faye with rails 4 server side events? Faye VS rails 4 streaming?But I need more info:
推荐答案
这里有一些关于为什么我会坚持使用 Faye 的说明，这可能会让你更接近这个问题的答案:
Here's some notes on why I would stick with Faye, which might bring you closer to an answer on this question:
浏览器兼容性
正如您在相关的 stackoverflow 问题中所读到的，Faye 具有更好的浏览器兼容性.
As you read in the related stackoverflow question, Faye has better browser compatibility.
稳定性
Rails::Live 功能似乎还不是很稳定.Rails SSE 目前正在积极开发中.例如，您不太可能不受这个问题的影响.
Rails::Live functionality doesn't seem to be very stable yet. There's currently active development on Rails SSE. As an example, it's quite unlikely that you won't be affected by this issue.
线程&阻塞 vs 异步非阻塞
您在应用程序中使用多线程吗?如果你不这样做，我绝对不会只为 Rails::Live 引入它，因为它开启了非线程安全 gem 问题的可能性 &服务器选择的限制.
Do you use multi-threading in your application? If you don't, I definitely wouldn't introduce it just for Rails::Live as it opens up the possibility of non-threadsafe gem issues & limitations of server choices.
如果您确实有多线程，则每个客户端都会为您的应用程序打开一个线程.如果线程用完，您的应用程序将无响应/死机.考虑您需要多少线程来满足用户打开多个浏览器选项卡的高峰时间，甚至是 DOS 攻击(有人打开大量空闲的 SSE/websocket 连接以达到最大值并关闭您的应用程序).如果您设置了大量的最大线程来支持许多空闲连接，那么您就有可能拥有那么多可能有其自身问题的非空闲线程.没有 SSE/websockets 和没有彗星/长轮询对于阻止应用程序更安全.据我了解，您的设置单独运行 Faye.Faye 服务器运行 Ruby EventMachine 或 Node.js，它们都是异步非阻塞的，并且不为每个打开的连接使用线程.它可以毫无问题地处理大量并发连接.
If you do have multi-threading, each client will keep a thread open to your application. If you run out of threads your application will be unresponsive/dead. Consider how many threads you need to cater for peak times with users having multiple browser tabs open, or even DOS attacks where someone opens up a huge amount of idle SSE/websocket connections to reach your max and take your app down. If you set a high amount of max threads to support many idle connections, you open up the possibility of having that many non-idle threads which could have it's own problems. No SSE/websockets and no comet/long polling is much safer for blocking apps. From what I understand, your setup runs Faye separately. The Faye server runs Ruby EventMachine or Node.js which are both asynchronous non-blocking and do not use a thread for each open connection. It can handle a huge amount of concurrent connections without problems.
我的观点是，具有单独异步非阻塞服务器的普通阻塞 Rails Web 应用程序用于保持打开的连接(传递消息并使应用程序生效)是两种设置中最好的.这就是 Rails + Faye 所拥有的.
My opinion is that a normal blocking Rails web application with a separate asynchronous non-blocking server for connections that stay open (to pass messages & make the app live) is the best of both setup. This is what you have with Rails + Faye.
更新:Actioncable 在 Railsconf 2015 上宣布.它运行在非-blocking 如上所述，但它是一个集成的官方 Rails 解决方案.拥有一个拥有庞大社区的单一框架，一个用于 websocket 的集成非阻塞连接处理程序，您可以在一切开箱即用"的情况下单独运行和配置它，这是 Rails 的一大优势.
Update: Actioncable was announced at Railsconf 2015. It runs non-blocking as described above, but it's an integrated official Rails solution. Having a single framework with a massive community, an integrated non-blocking connection handler for websockets that you can run and configure separately while everything works "out of the box" is a big advantage of Rails.
来自 Action Cable 自述文件:Action Cable 由 EventMachine 和线程的组合提供支持.连接处理所需的框架管道在 EventMachine 循环中处理，但用户指定的实际通道工作在普通 Ruby 线程中处理.这意味着您可以毫无问题地使用所有常规 Rails 模型，只要您没有犯任何线程安全错误.
要了解更多信息，您可以阅读 ActionCable &底层架构.
To learn more you can read up on ActionCable & Underlying architecture.
这篇关于关于选择 Faye 或 Rails 4 Actioncontroller::Live 的困惑的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！