EventMachine的問題（並考慮Sinatra異步）

Question

我一直在試圖找到一個處理異步請求和組織需要重複的作業的好方法，而eventmachine似乎是一個好方法，但我發現了一些帖子試圖阻止用戶使用eventmachine（例如https://github.com/kyledrake/sinatra-synchrony）。我想知道他們提到的問題是什麼？ （如果有人會很好，還有什麼替代方案？）

Answer 1

考慮到你基本上是在尋找一個工作隊列，請看Background Jobs at Ruby Toolbox，你會發現很多不錯的選擇。可管理性對速度是這樣的，

1. 延遲招聘
2. Sidekiq/Resque
3. Beanstalkd

與DJ是最慢的，最易於管理和beanstalkd是最快和最不可控的。你最好的選擇可能是sidekiq或resque，它們都依賴於redis來管理隊列。

我會阻止你使用EventMachine的原因是：

1. 很難推論反應器模式。
2. 纖維將反應堆模式的末端回調金字塔視爲同步代碼，但第三方應用程序中的纖維支持往往會咬你。
3. 當涉及到與網絡相關的代碼時，您僅限於非常有限的生態系統。
4. 很難不阻止反應堆，當你這樣做的時候很難抓住它。
5. 有完成後臺處理的解決方案，你不需要自己編寫代碼。
6. 它不再被真正維護，只需看看github上的最後提交和發佈列表。
7. 有celluloid和celluloid-io和dcell。

其實，西納特拉同步性人概括起來好：

這種寶石不應該被視爲一個新的應用程序。使用Ruby而不是EventMachine來使用線程更好。當新版本的Ruby發佈時，它也趨於 中斷，而EM本身不是 保持非常好，並且有一些相當基本的問題。

我不會再維持這個寶石了。如果有人對 感興趣，請隨時諮詢，但我建議您不要再使用 EventMachine或sinatra-synchrony。

Answer 2

使用EM如果它適合您的工作流程。只要你不太瘋狂，回調可以很好地工作。在我上一份工作中，我們在EM之上建立了很多軟件。

對第三方協議有很好的支持，只需看看the protocol implementations page即可。

至於阻塞反應堆，你只需要確保你不會在主線程上工作，如果你這樣做，確保它的工作快速。有些事情你可以做，以確定這是否工作。最簡單的方法就是在代碼中添加延遲檢查。這就像爲每x秒添加一個定期計時器並記錄消息（在開發中）一樣簡單。打印電話之間的時間會告訴你反應堆已經變得多麼滯後。這個時間越長，那麼你的x值越多，你在主線程上做的工作就越多。

所以，我會說，爲自己嘗試。嘗試賽璐珞，嘗試直線上線，嘗試與EM同步和光纖EM。

這真的歸結爲個人喜好。