Celery是否適合與許多小型分佈式系統一起使用？

Question

我正在寫一些軟件，它將通過間歇的3G（或類似的）連接在「現場」管理幾百個small systems。

家庭基地將需要發送作業到現場系統（例如，「報告你的狀態」，「更新你的軟件」等），而現場系統需要將作業發送回服務器（例如，「檢測到故障」，「這是一些數據」等）。

我花了一些時間看Celery它似乎是一個完美的結合：celeryd在大本營運行可以收集在該領域的系統工作，一celeryd場上系統能夠收集工作運行服務器和這些作業可以在客戶端變得可用時進行交換。

那麼，芹菜很適合這個問題嗎？特別是：

• 大多數任務將被定向到一個單獨的工作人員（例如，「將'get_status'作業發送到'system51'」） - 這會是一個問題嗎？
• 它是否優雅地處理不利的網絡條件（例如，連接死亡）？
• 只有當RabbitMQ被用作後端時，哪些功能纔可用？ （我不想在現場系統上運行RabbitMQ）
• 如果我像描述的那樣使用它，芹菜是否會讓我的生活變得困難？

謝謝！

（這將是有效的建議，芹菜是矯枉過正，但也有其他原因，這將讓我的生活更輕鬆，所以我想考慮）

Answer 1

大多數任務的將被引導到 個體勞動者（例如，「送 ‘GET_STATUS’作業‘system51’」） - 這將是一個問題？

根本不是。只需爲每個工作人員創建一個隊列，例如說每個節點監聽稱爲default循環賽隊列及其節點名稱後，每個節點都有自己的隊列名爲：

(a)$ celeryd -n a.example.com -Q default,a.example.com 
(b)$ celeryd -n b.example.com -Q default,b.example.com 
(c)$ celeryd -n c.example.com -Q default,c.example.com 

直接路由任務的節點很簡單：

$ get_status.apply_async(args, kwargs, queue="a.example.com") 

或使用Router配置：

# Always route "app.get_status" to "a.example.com" 
CELERY_ROUTES = {"app.get_status": {"queue": "a.example.com"}} 

是否妥善處理不良 網絡狀況（例如， 連接死亡）？

工作人員從代理連接故障中恢復正常。 （從RabbitMQ的至少，我不知道其他所有的後端，但這 容易測試和修復（你只需要添加相關的例外列表）

對於客戶端，您可以隨時嘗試發送任務，如果連接中斷， 或者你可以設置HA與RabbitMQ的：http://www.rabbitmq.com/pacemaker.html

如果RabbitMQ的被用作 後端什麼功能僅適用（我寧願不運行野外系統上的RabbitMQ ）

遠程控制命令，只支持「直接」交換（不是「主題」或「扇出」）。但是這將在Kombu (http://github.com/ask/kombu)中得到支持。

我會認真的重新考慮使用RabbitMQ。你爲什麼認爲這不合適？ 恕我直言，我不會在別處尋找這樣的系統，（除非可能ZeroMQ，如果系統 是暫時的，你不需要消息持久性）。

是否有任何其他原因芹菜可以使我的生活 困難，如果我像我所描述的那樣使用它？

我想不出上面描述的任何東西。由於併發模型 是多處理，它確實需要一些內存（我正在努力增加對 線程池和eventlet池的支持，這在某些情況下可能有所幫助）。

這將是有效的建議，芹菜是矯枉過正，但也有其他 原因，這將讓我的生活更輕鬆，所以我想 考慮）

在這種情況下，我認爲你輕易使用矯枉過正的字眼。它確實取決於 多少代碼和測試你需要編寫沒有它。我認爲 最好是改進一個已經存在的通用解決方案，理論上它聽起來像是應該適合你的應用的 。

Answer 2

我可能會成立一個（Django的） Web服務來接受請求。 Web服務可以完成驗證請求和錯誤請求的工作。然後芹菜可以做這項工作。

這將要求遠程設備輪詢Web服務以查看他們的工作是否已完成。這可能也可能不合適，取決於你在做什麼。