我已经将Faye与Ruby On Rails一起使用，对我来说几乎是0，因为我在另一台连接到我的Rails应用程序的服务器上运行Faye。
但是我遇到了一些问题，比如在Rails服务器上查询时间过长，一段时间后Faye连接失败并引发异常。
现在我正在调查Actioncontroller :: Live，大多数实现都使用Redis，这对我的启动来说有点太多了，但是我意识到我不能用Actioncontroller做订阅/发布风格的东西::活
我的问题：我应该转到Actioncontroller :: Live还是坚持Faye？虽然这些是我想要完成的事情：
我知道Faye使用Bayeux vs ActionController :: live使用SSE / HTTP。 我应该考虑与Socket.IO有关的任何事情吗？ SockJS？
我已经在这里阅读了有关此主题的一些问题，例如： Replace Faye with rails 4 server side events? Faye VS rails 4 streaming? 但我需要更多信息：
答案 0 :(得分：33)
这里有一些关于为什么我会坚持使用Faye的说明，这可能会让你更接近这个问题的答案：
浏览器兼容性
正如您在相关的stackoverflow问题中所读到的那样，Faye具有更好的浏览器兼容性。
<强>稳定性
Rails :: Live功能似乎还不是很稳定。目前Rails SSE正在积极开发。例如，您不太可能不受this issue的影响。
线程＆amp;阻止与异步非阻塞
您是否在应用程序中使用多线程？如果你不这样做，我绝对不会仅仅为Rails :: Live引入它，因为它开启了非线程安全宝石问题的可能性。服务器选择的局限性。
如果您确实有多线程，则每个客户端都会为您的应用程序保持一个线程。如果您的线程用完，您的应用程序将无法响应/死亡。考虑有多少线程需要满足高峰时间的用户打开多个浏览器选项卡，甚至是DOS攻击，其中有人打开大量空闲SSE / websocket连接以达到最大值并将您的应用程序关闭。如果您设置了大量的最大线程来支持许多空闲连接，那么您就有可能拥有许多可能存在问题的非空闲线程。对于阻止应用程序，没有SSE / websockets和没有彗星/长轮询更安全。根据我的理解，你的设置分别运行Faye。 Faye服务器运行Ruby EventMachine或Node.js，它们都是异步非阻塞的，并且不为每个打开的连接使用线程。它可以毫无问题地处理大量的并发连接。
我的观点是，正常的阻止Rails Web应用程序具有单独的异步非阻塞服务器，用于保持打开的连接（传递消息并使应用程序生效）是两种设置中最好的。这就是你对Rails + Faye所拥有的。
更新：Actioncable在Railsconf 2015上宣布。它如上所述运行非阻塞，但它是一个集成的官方Rails解决方案。拥有一个具有大规模社区的单一框架，一个集成的无阻塞连接处理程序，可以单独运行和配置，而一切都可以“开箱即用”，这是Rails的一大优势。
来自行动电缆自述文件： Action Cable由EventMachine和线程组合提供支持。连接处理所需的框架管道在EventMachine循环中处理，但实际的通道（用户指定的）工作在普通的Ruby线程中处理。这意味着只要您没有提交任何线程安全罪，就可以毫无问题地使用所有常规Rails模型。
要了解详情，您可以阅读ActionCable & Underlying architecture。