雲計算設計模式（十三）——上司人選舉模式雲計算設計模式（十三）——上司人選舉模式

通過協調合作，在分布式應用程式的任務執行個體集合執行的操作，選舉一個執行個體作為承擔管理的其他執行個體責任的上司者。這個模式可以有助于確定任務執行個體不互相沖突，導緻争用共享資源，或與其他的任務執行個體正在執行的工作無意中幹擾。

一個典型的雲應用包括行動協調的方式很多任務。這些任務都可以是執行個體運作相同的代碼和需要通路相同的資源，或者它們可能是可并行工作，以執行複雜計算的各個部分。

任務執行個體可能為多的時間自主運作，但它也可能是必要的，以協調各執行個體的操作，以確定它們不發生沖突，導緻争用共享資源，或無意中妨礙工作，其他的任務執行個體正在執行。例如：

•在基于雲的系統，該系統實作了橫向擴充，同一個任務的多個執行個體可以與每個執行個體服務于不同的使用者同時運作。如果這些執行個體寫入到共享資源，也可能是必要的，以協調它們的操作，以防止每個執行個體從盲目地覆寫由他人進行的更改。

•如果任務正在執行複雜的計算以并行的單個元素，其結果将需要被聚合時，他們都完成了。

由于任務執行個體都是同行，沒有天生的上司者，能夠充當協調員或聚合器。

單個任務執行個體應選充當上司者，這種情況下應協調其他從屬任務執行個體的操作。如果所有的任務執行個體都運作相同的代碼，他們可能都能夠充當上司者。是以，選舉過程必須謹慎管理，以防止兩個或多個執行個體接管上司者的角色在同一時間。

該系統必須選擇的上司者提供了一個堅固的機構。這種機制必須能夠應付諸如網絡中斷或程序故障事件。在許多解決方案中，下屬的工作情況監控的上司者，通過某種類型的心跳機制，或通過輪詢。如果指定的上司者意外終止或網絡故障使得上司者不通下屬的工作情況，有必要為他們選出了新的上司人。

有可用于選舉的上司者之間的一組任務在分布式環境中，包括幾個政策：

•與排名最低的執行個體或程序ID選擇任務執行個體。

•競速獲得一個共享的分布式互斥。第一個任務執行個體擷取該互斥鎖處于領先地位。然而，系統必須保證，如果上司者終止或變得與系統的其餘部分斷開，該互斥被釋放，以允許另一個任務執行個體成為上司者。

•實施的共同上司人選舉算法，如惡霸算法或環算法之一。這些算法是相對簡單的，但也有一些更複雜的技術提供。這些算法假定每個候選參選具有唯一的ID，并且，它們可以用可靠的方式在其他候選人進行通信。

在決定如何實作這個模式時，請考慮以下幾點：

•選出一個上司者的過程應該是彈性的瞬時和永久失效。

•必須能夠檢測到當上司失敗，或變成不可用（可能是由于通訊故障）。在這是需要這種檢測的速度将取決于系統。有些系統可能能夠發揮作用了一會兒沒有一個上司者，在此期間造成的上司人變得不可用瞬時故障可能已被排除。在其他情況下，可能有必要立即檢測領袖失敗并引發新的選舉。

•在實作自動縮放水準的系統中，如果系統鱗背面和關閉一些計算資源的上司者可能被終止。

•使用一個共享的分布式互斥引入外部服務，提供了互斥鎖的可用性依賴。該服務可以構成一個單點故障。如果此服務應該以任何理由變得不可用時，系統将無法選出一個上司者。

•使用一個專用程序的上司者是一個比較簡單的方法。然而，如果該過程失敗，可能有顯著延遲而被重新啟動，并且将得到的延遲可能影響其他程序的性能和響應時間，如果他們正在等待上司人來協調的動作。

•實施的上司人選舉算法之一手動為調整和優化代碼的最大靈活性。

使用此模式時，在分布式應用程式的任務，比如雲托管解決方案，需要認真協調，也沒有天生的上司者。

注意：

避免使上司者在系統中的瓶頸。上司者的目的是協調的附屬任務完成的工作，它不一定有機會參加這項工作本身，盡管它應該是有能力這樣做，如果任務沒有當選上司人。

這種模式可能不适合：

•如果有一個天生的上司者或專用的過程，可以随時充當上司者。例如，有可能實作一個單程序，其協調該任務的執行個體。如果這個過程失敗或變得不健康，系統可以将其關閉并重新啟動它。

•如果任務之間的協調，可以很容易地通過使用更輕便的機構來實作的。例如，如果幾個任務執行個體僅僅需要對共享資源的通路協調，一個最好的解決辦法可能是使用樂觀或悲觀鎖來控制通路該資源。

•如果一個第三方的解決方案是比較合适的。例如，微軟的Azure

HDInsight服務（基于Apache

Hadoop的）使用所提供的ApacheZookeeper協調的map / reduce的彙總任務和彙總資料的服務。它也可以安裝并在Azure的虛拟機配置動物園管理者，并将其內建到自己的解決方案，或使用可從微軟開放技術的動物園管理者預置的虛拟機映像。欲了解更多資訊，請參閱Apache的動物園管理者在微軟的Azure在微軟開放技術的網站。

在列入可用于本指南中的示例代碼中LeaderElection解決方案DistributedMutex項目展示了如何使用租賃在Azure存儲BLOB提供了一種機制，實作共享的分布式互斥。此互斥鎖可以用來選擇在Azure雲服務的上司者之間的一組角色的執行個體。第一個角色執行個體獲得租約當選的上司人，并保持領先直至其租賃或直到它無法續租。其他角色執行個體可以繼續監視在上司不再可用的情況下将BLOB租賃。

一個BLOB租賃是在一個blob的排他寫鎖。單個BLOB可以是一整租的在任何一個時間點的問題。角色執行個體可以請求租約在指定的斑點，而且将被授予租約，如果沒有其他租賃在同一個斑點，是由這個或任何其他作用，比如舉行，否則将抛出一個異常。

為了減少一個故障角色執行個體保留無限期租用的可能性，指定了一輩子的租約。當此期滿後，租賃變為可用。然而，當一個角色執行個體持有的租賃也可以請求租約到期，并且将被授予租約的時間再延長。角色執行個體可以不斷重複這一過程，如果它希望保留租約。

有關如何租用一個blob的詳細資訊，請參閱租賃斑點（REST

API）在MSDN上。

在該執行個體中BlobDistributedMutex類包含RunTaskWhenMutexAquired方法，使一個角色執行個體試圖獲得租約在指定的斑點。團塊（名稱，容器和儲存的帳戶）的細節傳遞給構造在一個BlobSettings對象被建立的BlobDistributedMutex對象時（這個對象是包含在示例代碼的簡單結構）。構造函數也接受一個任務，它引用的角色執行個體應該運作，如果它成功收購租賃在BLOB和當選上司人的代碼。需要注意的是處理獲得租約的低層次細節中的代碼名為BlobLeaseManager一個單獨的輔助類實作。

代碼示例中的RunTaskWhenMutexAquired上述方法調用以下代碼示例來實際獲得的租賃所示的RunTaskWhenBlobLeaseAcquired方法。該RunTaskWhenBlobLeaseAcquired方法異步運作。如果租賃的成功擷取，角色執行個體已經當選的上司者。該taskToRunWhenLeaseAcquired委托的目的是為了執行協調其它角色執行個體的工作。如果未取得租賃，另一個角色執行個體已當選為上司人和目前角色執行個體仍然是一個下屬。注意，TryAcquireLeaseOrWait方法是使用BlobLeaseManager對象擷取租賃一個輔助方法。

由上司開始的任務還異步執行。雖然這個任務正在運作，下面的代碼示例所示的RunTaskWhenBlobLeaseAquired方法周期性地嘗試續訂租約。這個動作有助于確定該角色執行個體保持領先。在簡單解決方案中，續訂請求之間的延遲小于對租賃期限，以防止另一角色執行個體當選的上司人指定的時間。如果更新失敗，以任何理由，任務被取消。如果租用未能被更新或任務被取消（可能為角色執行個體關停的結果），租賃被釋放。在這一點上，這個或另一個角色執行個體可能被選為上司者。下面的代碼提取物顯示出此過程的一部分。

該KeepRenewingLease方法是使用BlobLeaseManager對象續租另一個helper方法。該CancelAllWhenAnyCompletes方法取消指定為前兩個參數的任務。

圖1示出了BlobDistributedMutex類的功能。

圖1 - 使用BlobDistributedMutex類選出一個上司者和運作協調操作的任務

下面的代碼示例顯示了如何使用BlobDistributedMutex類的輔助角色。此代碼擷取租賃了一個名為MyLeaderCoordinatorTask在開發的倉儲租賃容器中的blob，并指定在MyLeaderCoordinatorTask方法定義的代碼應該運作，如果角色執行個體當選的上司人。

請注意有關樣品溶液中的以下幾點：

•BLOB是一個潛在的單點故障。如果Blob服務不可用，或的blob是人迹罕至，上司者将無法續租，并沒有其他的作用，比如将能夠獲得租約。在這種情況下，沒有作用，例如将能夠充當上司者。然而，的blob服務被設計為彈性的，所述的blob的服務，以便徹底失敗被認為是極不可能的。

•如果被上司者攤位正在執行的任務，上司者可能會繼續續租，防止任何其他角色執行個體從獲得租約，并接管了上司作用，以協調任務。在現實世界中，上司者的健康應該頻繁地進行檢查。

•在選舉過程具有不确定性。你不能做任何假設哪個角色執行個體将得到的blob租約，成為上司者。

•不應使用任何其他目的用作的blob租賃的目标的的blob。如果一個角色執行個體嘗試将資料存儲在該的blob，該資料将不能被通路，除非該角色執行個體是上司者和持有的的blob租約。