使用排隊或REST Web服務協調分佈式Python進程

Question

服務器A有一個將n個數據庫表作爲平面文件導出的過程。 服務器B包含一個將平面文件加載到DW設備數據庫的實用程序。

進程在服務器A上運行，該服務器導出並壓縮大約50-75個表。每次導出表格和生成文件時，都會生成.flag文件。

服務器B有一個bash進程，它會重複檢查服務器A生成的每個.flag文件。它通過連接到A並檢查文件的存在來執行此操作。如果標誌文件存在，則服務器B將從服務器A scp文件解壓縮並將其加載到分析數據庫中。如果該文件尚不存在，它將睡眠n秒鐘，然後重試。對於服務器B期望在服務器A上找到的每個表/文件重複該過程。該過程連續執行，一次處理單個文件。

此外：服務器A上運行的進程無法將文件「推送」到服務器B.由於文件大小和地理位置的關係，服務器A無法將平面文件加載到DW設備中。

我覺得這個過程很繁瑣，所以恰巧要重寫/修改。我正在提出一個基於消息傳遞的解決方案。我最初以爲這將是RabbitMQ的一個很好的候選人（或類似），其中

• 服務器A會寫一個文件，壓縮它，然後產生一個消息隊列。

• 服務器B將訂閱隊列並處理消息正文中指定的文件。

我覺得，一個基於消息的方法將不僅節省了時間，因爲這將消除每個表的檢查等待的重複週期，也允許我們並行運行的過程（因爲沒有依賴關係）。

我向我的團隊展示了一個使用RabbitMQ的概念驗證，他們都接受使用消息。他們中的一些人很快確定了我們將從基於消息的處理中受益的其他機會。我們將從實施消息傳遞中受益的一個領域是實時填充我們的DW維度，而不是通過批量填充。

然後，我想到基於MQ的解決方案可能會因爲低容量（50-75個任務）而過度使用。考慮到我們的操作團隊必須安裝RabbitMQ（及其依賴項，包括Erlang），這可能是過度的，它會引發新的管理難題。

然後我意識到這可以通過基於REST的解決方案變得更簡單。服務器A可以生成一個文件，然後對服務器B上的簡單（web.py）Web服務進行HTTP調用。服務器B然後可以根據所調用的URL啓動傳輸和加載過程。考慮到傳輸，解壓縮和加載每個文件所需的時間，我可能會使用Python的多處理來創建一個加載每個文件的子進程。

我在考慮基於REST的解決方案，因爲它更簡單。在我看來，使用MQ將更適合更高容量的任務，但我們只是在談論（現在）的50-75個操作，可能會有更多的任務。

鑑於我的要求和數量，基於REST的解決方案是一個很好的解決方案嗎？是否有其他框架或OSS產品已經這樣做？我期望添加消息而不會造成其他管理和開發難題。

Answer 1

消息代理如兔包含許多問題的實際解決方案：

• 多個生產者和消費者沒有消息的重複的風險被支撐
• 原子單元工作的和邏輯提供事務完整性，防止在發生故障時重複和丟失消息
• 橫向擴展 - 大多數成熟的代理可以集羣化，以便多個機器上存在單個隊列
• 無集合點消息傳遞 - 它是沒有必要的發送者和接收者在同一時間運行，因此可以帶來停機維護，而不會影響FIFO的順序

的其他

保存取決於你正在考慮在特定的Web服務平臺，您可能會發現您需要其中的一些功能，並且必須在不使用代理的情況下自行實施。 Web服務協議和格式（如HTTP，SOAP，JSON等）不能爲您解決這些問題。

在我以前的工作中，項目管理人員很早就開始使用消息代理，但後來團隊最終實現了快速和骯髒的邏輯，旨在解決上述Web服務體系結構中的一些相同問題。我們沒有多少時間來提供商業價值，因爲我們正在修復這麼多的併發和錯誤恢復問題。

因此，儘管消息代理似乎在其表面就像一個重量級的解決方案，而實際上可能比你現在需要的，但它有很多的好處，你可能以後需要還沒有意識到這一點。

Answer 2

至於wberry提到，一個REST或Web鉤基礎的解決方案可以是功能性的，但不會是很寬容失敗。預先支付運營費用以進行消息傳遞將支付長期股息，因爲您會發現其他問題，這些問題非常適合消息傳遞模型。

關於其他OSS選項;如果您正在考慮除此特定用例外的基於流的處理，我建議您參閱Apache Kafka。 Kafka爲RabbitMQ提供了類似的消息語義，但是專注於處理消息流（更不用說，已經在LinkedIn的生產環境中進行過測試）。