《面向模式的軟體體繫結構3-資源管理員模式》讀書筆記（7）— Coordinator模式

3.3 Coordinator模式

      Coordinator（協調者）模式描述了如何通過協調涉及多個參與者（每個參與者都包含資源、資源使用者和資源提供者）的任務的完成來維護系統的一致性。這個模式提出了一個解決方案，使得在涉及多個參與者的任務中，或者所有參與者的任務都完成，或者一項任務都沒有完成。這確保了系統總是處於一致的狀態。

 

1.問題

      很多系統都會執行涉及不止一個參與者的任務。一個參與者是一個主動實體，既包含資源使用者，也包含資源提供者。此外，在某些情況下，資源（比如服務）可以是主動的，所以會直接參与任務。參與者可能位於同一個進程中，也有可能跨越了多個進程、多個節點，每個參與者都會順序執行任務的一部分。為了讓任務獲得整件的成功，每個參與者執行的工作都必須成功。如果任務成功執行，那麼改變就應該讓系統保持在一致的狀態。但是，考慮一下如果一個參與者執行的工作失敗了，會發生什麼。如果這項工作位於任務執行序列的較後面的階段，那麼已經有很多參與者完成了其工作。這些參與者的工作會給系統造成改變。但是，失敗的參與者無法對系統造成必要的改變，結果就是，系統的改變是不一致的。這可能會導致不穩定甚至出錯的系統。在這樣的系統中，部分失敗甚至比全域失敗更糟糕。

      一個可能的解決方案是在參與者之間引入點對點的通訊。每個參與者都把自己的工作結果傳達給別的參與者，並採取必要的步驟以保證系統狀態一致。但是，這樣的解決方案要求所有參與者都關注任務涉及的其他所有參與者，這是不現實的。此外，這樣的解決方案對參與者數量的延展性也很糟糕。為瞭解決這些問題，需關注以下幾點：

      1）一致性（Consistency）。一項任務應該要麼為系統建立新的合法的狀態，要麼（若發生了錯誤）把所有的資料都恢複到任務開始前的狀態。

      2）原子性（Atomicity）。在涉及兩個或多個參與者的任務中，或者所有參與者的工作都完成，或者所有工作都沒有完成（雖然參與者是彼此獨立的）。

      3）位置透明性（Location transparency）。解決方案應當可以用於分布式系統，雖然分布式系統比整體式系統更有可能遭遇局部失敗。

      4）延展性（Scalability）。解決方案應當對參與者的數目具有延展性，而不會顯著地降低效能。

      5）透明性（Transparency）。解決方案對系統使用者應該是透明的，並且應該盡量減少對代碼改動的要求。

 

2.解決方案

      引入協調者，負責所有參與者執行和完成任務。所有參與者執行的工作都分成兩個階段：準備（prepare）和提交（commit）。

      在第一階段，協調者要求每個參與者準備完成的工作。每個參與者必須用這個階段來檢查一致性並判斷執行結果是否會失敗。如果某個參與者的準備階段沒有返回成功，那麼協調者就停止任務的執行順序。協調者會要求所有成功完成準備階段的參與者都中止並恢複任務開始前的狀態。因為參與者都還沒有做出永久性的改變，所以系統狀態保持了一致。

      如果所有的參與者都成功地完成了準備階段，那麼協調者就發起每個參與者的提交階段。參與者會在這個階段做實際的工作。因為每個參與者都在準備階段表明工作會成功，所以提交階段會成功，整個任務被成功執行。

 

3.結構

      任務（Task）是一個單元的工作，它涉及多個參與者。

      參與者（Participant）是一個主動實體，它會完成任務的一部分工作。參與者可以包含資源使用者，資源提供者和資源。

      協調者（Coordinator）是負責協調任務整體完成的實體。

      客戶（Client）是任務的發起者。客戶指導協調者執行任務。

       

 

        

 

4.實現

1）識別參與者。任何參與者，只要其工作需要被協調，那麼就必須在一開始就識別出來。在資源管理的背景中，參與者可能是資源使用者，資源提供者或者資源本身。資源使用者可以成為參與者，如果它主動地試圖擷取、使用以及釋放多個資源，從而需要協調的話；資源提供者也可以是參與者，如果它試圖向資源使用者提供一個或多個資源的時候需要協調；資源（比如服務）也可以是參與者，如果它是主動的，並且因而能夠直接參与任務。

2）定義協調介面。應該定義一個將被執行任務的一部分工作的參與者實現的協調介面。

public interface Coordination{

    public boolean prepare();

    public void abort();

    public void commit();

}

    協調者使用prepare()方法來對每個參與者發起準備階段。每個參與者都會使用這個階段來檢查一致性，並判斷執行是否會導致失敗。傳回值true意味著準備階段成功，因此提交階段也會成功。傳回值false意味著準備階段失敗，因此參與者將無法成功執行提交階段。

    如果在準備階段任一參與者返回了false，那麼協調者將會中止任務的執行。它會調用每個已經從準備階段成功返回的參與者的abort()方法。這就向參與者表明，任務被中止，它們需要執行所有必要的清除操作。

3）定義協調者介面。協調者介面應該為客戶提供了開始或者結束任務的方法。此外，它還應該允許任務的參與者註冊。在參與者可以註冊它們之前，它們必須可以發現協調者。為了做到這一點，參與者可以使用Lookup模式。

public interface Coordinator {

    public void beginTask();

    public void register(Coordination participant);

    public boolean commitTask();
}

    客戶使用beginTask()方法來定義任務的開始。此時，協調者不做任何事情。當任務一開始，任務的參與者就用register()方法向協調者註冊。一旦所有的參與者都註冊了，客戶就執行協調者的commitTask()方法。這時協調者而言意味著兩件事件——首先，所有的任務參與者都已經註冊；其次，協調者可以開始協調參與者執行任務了。現在協調者使用協調介面定義的兩個階段的提交協議來確保參與者完成任務。

4）處理錯誤條件。使用協調者允許參與者表明它們負責的工作是否成功。如果任一參與者表明它的工作沒有成功，那麼協調者就可以中止任務，而不會導致系統狀態的任何持久不一致性。如果所有的參與者都表明準備階段成功，那麼協調者就接著對所有參與者執行提交階段。但是，還是會有這樣的可能性：一個或者多個參與者在提交階段失敗，雖然它們的準備階段成功完成了。這可能是由參與者無法控制的因素導致的，比如串連被斷開了。為了處理這樣的錯誤條件，參與者可以在執行它們負責的任務部分之前可選地維持狀態資訊。如果一個參與者提交失敗，那麼協調者可以對剩下的提交成功的參與者調用rollback()方法。這會給參與者一次機會，讓它們恢複在執行任務之前的狀態，不過，這樣的功能要求維護狀態資訊，可能代價高昂。

 

5.結論

優點：

1）原子性（Atomicity）。Coordinator模式確保了在涉及兩個或者多個參與者的任務中，或者所有參與者的工作都完成，或者所有工作都沒有完成。準備階段確保了所有參與者都能夠完成工作。如果任一參與者在準備階段返回失敗，那麼任務就會被執行，這確保了沒有任何參與者完成工作。

2）一致性（Consistency）。Coordinator模式確保了系統狀態保持一致。如果一項任務被成功執行，那麼就為系統建立了新的合法的狀態。另一方面，如果發生了任何失敗，那麼Coordinator模式確保所有的資料都回複到任務開始之前的狀態。因為每個任務都是原子的，要麼所有參與者都完成它們的工作，要麼沒有參與者完成任何工作。在這兩種情況下，結果都是系統處於一致的狀態。

3）延展性（Scalability）。解決方案對於參與者的資料具有延展性。增加參與者的數目不會影響任務的執行。隨著參與者資料的增加，其中一個參與者失敗的可能性也增加了。但是，使用這個模式，失敗會在準備階段被檢測到，從而確保了系統處於一致的狀態。

4）透明性（Transparency）。使用Coordinator模式對於使用者是透明的，因為任務的兩步提交式執行對於使用者是不可見的。

 

缺點：

1）額外開銷（Overhead）。Coordinator模式要求每項任務都分割成兩個階段，這會導致涉及所有參與者的執行序列被重複兩次。如果參與者是分布的，那麼這就意味著兩倍的遠程調用資料，這還可能會導致失去透明性。

2）額外的職責（Additional responsibility）。Coordinator模式為參與者增加了額外的職責，它們還需要向協調者註冊。如果參與者是分布的，那麼註冊過程會導致參與者執行遠程調用。