Rails 3 I/O到後臺進程

Question

簡短版本：我需要從Rails控制器（使用Rails 3）啓動子進程（Ruby腳本），並將子進程中的消息呈現給網頁，並將信息從Rails視圖傳遞到子流程。

的設置：我有一個Ruby腳本，與被稱爲Ivy軟件消息總線系統進行通信，使用R​​uby 1.9.3發送控制消息和接收來自某些硬件我的網絡上的其他地方運行的消息。我不能在這裏使用另一種消息傳遞系統，它必須是常春藤。該腳本當前將消息寫入stdout。

問題1：我想啓動這個腳本作爲一個子進程（或線程，我願意接受建議）從一個Rails應用程序的控制器。我希望能夠接收來自此腳本的消息，以便它們可以顯示在網頁上。沒有必要將這些消息持久地存儲在數據庫中，所以我正在考慮使用Rails緩存來臨時存儲和訪問這些消息，並可能使用AJAX在一段時間內對緩存中的新消息進行輪詢。這可能嗎？

問題2：即相同的Rails應用需要能夠從網頁發送控制消息（例如，通過與按鈕，下拉菜單或一些其他UI元素交互的用戶）的常春藤子，使得這些控制消息可以傳播到硬件。

我特地到像Sidekiq，Delayed Job，以及其他可能的解決方案，但我無法通過瀏覽文檔，這些潛在的解決方案可以解決兩個問題1和2。所以找到確鑿的證據，我的問題如下：

1. 像Sidekiq或DelayedJob這樣的現成解決方案可以處理此任務嗎？
2. 是否有一些內置到Rails的方式已經可以實現這一點？
3. 這個問題與觀點接壤，但我會反問。我還有其他的追求Rails的理由，但是如果這項任務會非常困難，他們可能會被拋棄。使用Rails做這樣的事情是非常痛苦的，我應該研究其他解決方案嗎？

Answer 1

聽起來有3個顧慮：

1. 監控的消息
2. 發送在ivybus命令ivybus
3. 用戶交互（網絡接口）

Rails框架是隻解決關注號碼3.這就是它設計的目的。但是，這並不意味着Ruby/Rails不適合這項工作。這裏有一些想法我有設置此功能：

關注1絕對應該是某種後臺作業的範圍內發生的事情。它不應該成爲標準Web請求的一部分。我認爲關注2在後臺工作中也會更好。在可能的情況下，任何容易出錯或可能長時間運行的任務都應該儘量避免使用Web請求。

有幾種方法可以將這些任務轉換爲背景。 Sidekiq是關注問題2（發送命令）的完美解決方案。控制器會收到用戶做出某個動作的請求，然後控制器會向後臺工作人員提交一份工作來執行此操作。 Sidekiq也可以解決問題1（監控），但是您必須創建定期作業（如輪詢）才能繼續檢查新界面的消息。 Sidekiq不是用來運行無限期運行的工作。

解決關注1，最可靠的方法是創建一個守護進程。看起來似乎有點過分，但像「守護進程」這樣的寶石讓這個任務變得非常簡單。這個守護進程可以監視接口並將你關心的數據推送到某種數據存儲（MySQL，Redis等）中。

您可以使用一個或兩個backgrounding解決方案，並解決了這個問題，但我絕對認爲你需要一個單獨的進程來管理至少第一關注。這會讓關注點3（您的Web應用程序）只處理從數據存儲中讀取數據並將其呈現給用戶，並將某些請求（命令）轉換爲後臺作業。這可以讓你的Rails應用程序盡其所能，但仍然可以讓你做你需要的一切。

Answer 2

Rails（大部分）很好。

Sidekiq或Resque是進行常春藤投票的好方法。您可以安排工作人員定期輪詢新消息。

儘管Rails 4可以實時流式傳輸，但它尚未準備好迎接黃金時段。我建議使用類似Node.js/Socket.io的設置來通過WebSockets與客戶端瀏覽器交談。或者，如果不需要花哨的實時更新，並且客戶端的數量會很少，只需讓工作人員將結果轉儲到數據庫中並讓瀏覽器輪詢更新。

但是，常春藤是粘滯點。我從Ruby/Rails應用程序中看不到有關與Ivy交談的內容。也許你可以使用JRUby，然後使用其中一個Java包裝器。

既然你不是超級結婚的Rails，它可能會更容易做到這一點在Python或Perl，因爲常春藤人已經有用這些語言編寫的工具。