以隊列爲中心的工作模式的失敗處理

Question

我打算使用我的應用程序中描述的here所描述的以隊列爲中心的設計。這基本上包括使用Azure隊列，其中工作請求從UI排隊。工作人員從隊列中讀取，處理並從隊列中刪除消息。

工作人員完成的'工作'在一個事務中，所以如果工人在完成之前失敗，在重新啓動時它會再次拾取相同的消息（因爲它沒有從隊列中刪除）並嘗試執行操作再次（最多重試的最大數量）

要縮放我可以使用兩種方法：

1. 多位工人每一個單獨的隊列。所以如果我有五個工人W1到W5，我有五個隊列Q1到Q5，每個工人知道從哪個隊列讀取，並且故障處理與一個隊列和一個工人的情況相似
2. 一個隊列和多個工人 。這裏的失敗/重試處理會涉及更多，最終可能會在消息隊列中使用「隱形」時間，以確保沒有兩名工作人員選擇相同的工作。必須計算不可見時間，以確保其足以完成工作，但又不足以在很長一段時間後執行重試。

想知道第一種方法是否是正確的方法嗎？上述第二種方法處理失敗的強大方法是什麼？

Answer 1

你會更好地採取方法2 - 一個隊列，但與多個工人。

這是更好，因爲：

• ，提供消息隊列只需要知道一個隊列終點的過程。這降低了這方面的複雜性;
• 標定從隊列中拉出，現在從任何代碼/配置變化解耦工人數 - 你可以放大和縮小更容易（在運行時）

如果你所擔心的visibility，最初可以選擇默認的timespan，然後如果工作人員看起來需要的時間太長，則可以定期呼叫UpdateMessage()來更新消息的可見性。

最後，如果您的員工超時並未能完成消息的處理，則會由其他員工再次提取以再次嘗試。您還可以使用消息的DequeueCount屬性來管理重試次數。

Answer 2

多個工人分別擁有一個隊列。所以，如果我有五個工人 W1至W5，我有5個隊列Q1到Q5和每個工人都知道哪個隊列 讀取和故障處理是一個 隊列，一個工人

隨着案情相似這種方法我看到以下問題：

• 這種方法使得你的體系結構緊密耦合（從而擊敗了使用隊列的全部目的）。由於每個工作角色都監聽一個專用隊列，因此負責推送隊列中消息的Web應用程序始終需要知道有多少員工正在運行。任何時候你擴大或縮小你的工作者角色，你都需要告訴Web應用程序，以便它能夠開始將消息推送到適當的隊列中。
• 如果某個工作者角色實例由於某種原因被關閉，則有可能某些消息可能無法處理，因爲其他工作者角色實例正在其專用隊列上工作。
• 根據Web應用程序如何在隊列中推送消息，可能存在使用/過度使用輔助角色實例的可能性。爲了獲得最佳利用率，Web應用程序應該瞭解工作程序角色使用情況，以便它可以決定將消息發送到哪個隊列。對於Web應用程序來說，這絕對不是理想的事情。

我相信＃2是正確的路要走。 @Brendan Green很好地回答了他對＃2的回答。