你这个设计就有问题。 你要么就轮询，每次返回状态，前端判断是否改变。 要么就长链接，发生改变之后主动推送给前端。

看看 ActionCable。

可以使用 ActionCable + Fork 一个新进程解决耗时操作问题。

class ExambleController < ApplicationController
  def create
    Process.fork do 
      Foo.loop(1000000) do |bar|
        ActionCable.server.broadcast(channel_id , {bar: bar})
        sleep 0.1
      end
    end
  end
end

可以用 https://github.com/SamSaffron/message_bus

项目 rails 版本低，ruby2.1.8，rails4.2.5 貌似不支持 actioncable

message_bus 貌似不支持 thin 服务

项目 rails 和 ruby 版本低，不能用 actioncable

其实现在就是想解决长连接的情况不阻塞其他请求。

为什么非要这么设计呢？这样设计交互的需求是什么？actioncable 的方式本质上是走 websocket 嘛，让服务器端来负责 Push。actioncable 不行，那就 faye 之类的。

支持的吧

每次都直接返回状态，这样代价也不大吧。你的长轮循频率多少？是怕响应不及时还是增加太多负载？

那分开两个接口，一个创建任务的接口，另一个查询任务状态的接口。创建任务的接口把任务放到任务队列去做；查询任务的接口检查任务状态，Ajax 轮询任务状态接口。两个接口都是立即返回。

http 长连，ror 并发应该上不来。可以考虑一单独启动一个新版 rails 服务做长连。旧服务只负责写。这要把 actioncable 写相关的代码引进来、然后两个服务连一个 redis 就行。

分服务的方法倒是可行的。