2011-08-31 71 views
5

我在想同步運行相同角色的多個azure實例的最佳做法。 更準確地說,我想阻止幾個工人角色在同一個工作單元上工作。Azure角色間同步

Azure隊列在這個問題上似乎沒有幫助。 一種選擇是使用帶鎖和存儲過程的sql表;但在Azure中使用sql同步似乎有點尷尬。

任何想法?

編輯,我詳細的(但簡單的問題)如下:

  • ñ目標。
  • 必須以指定的時間間隔(例如30秒 - 每個目標不同)對每個目標執行一個工作單元。
  • 我有m工人(託管在h實例)。
  • 處理工作單元可能需要10秒到1小時之間的任何時間。

的想法是,我有一個調度是把工作單位在Azure的隊列,並且每個工人將這些讀取並處理它們。

問題:

  • worker1開始對1單元(這是關於目標1)工作 - 這個人會需要很長時間,說10分鐘
  • 經過30秒
  • 的調度程序爲目標1提供另一個工作單元,比如說說單元13
  • worker2開始工作unit13,對同一目標1 - 不好

我有一些想法,但他們似乎並不陰天不夠,所以我有興趣看看你會爲這個問題申請什麼解決方案。

+2

爲什麼你認爲隊列在這裏不起作用?隊列是協調需要一次完成的工作的傳統方式。確實有一些細微差別,但90%的情況是與隊列。 – dunnry

+0

我同意戴維的回答,排隊通常是一個不錯的選擇。雖然有時候你不能排隊。但是,如果是這種情況,請詳細描述您的問題,我們會盡力提供更好的答案。 –

+0

與此同時,我已經發布了一個用於Azure UserVoice的創意 - http://entlib.uservoice.com/forums/101257-windows-azure-integration-pack/suggestions/2050987-distributed-synchronization?ref=title在隊列不起作用的情況下可能對這些情況有用 –

回答

2

dunnry是spot-on:隊列很適合阻止多個實例在同一個工作項上工作。當您撥打GetMessage時,您檢索的消息現在對於您指定的時間範圍是不可見的(默認值:30秒)。在那個時間段內,沒有其他讀者可以檢索到這個隊列消息。

話雖如此:您需要確保您的處理是冪等的。在處理時間超過隱形時間範圍的情況下,消息將再次變爲可見。此時,原來的閱讀器不能刪除該消息,而其他閱讀器可以通過閱讀該消息(使其再次不可見)。在這種情況下,您可能會重新處理相同的消息。作爲一般規則,您需要仔細設置超時窗口以避免出現這種情況。

注意:每個CloudQueueMessage都有一個DequeueCount屬性,因此您可以確定消息是否被多次查看過(因此您也可以處理毒訊息)。

+0

一個小小的說明 - 最後一個彈出式收據的所有者是唯一一個可以刪除隊列消息的人。因此,即使在郵件再次「可見」的情況下,只要郵件沒有在臨時郵件中退出(這將生成新郵件收據),它仍然可以被原始閱讀器刪除。 – dunnry