【正文】 復進行。例如，不好的傳輸介質(zhì)可能很容易使得數(shù)據(jù)包被破壞。但是，像我們在本章后面將看到的那樣，從故障中自動恢復說起來簡單，做起來就難了。高度可靠的系統(tǒng)可以在一個相對較長的時間內(nèi)持續(xù)工作而不被中斷。特別是，當故障發(fā)生時，分布式系統(tǒng)應該在進行恢復的同時繼續(xù)以可接受的方式進行操作，也就是說，它應該能容忍錯誤，在發(fā)生錯誤時某種程度上可以繼續(xù)操作。這個故障也許會影響到其他組件的正確操作，但同時也有可能完全不影響其他組件。換句話說，高度可用的系統(tǒng)在任何給定的時刻都能及時地工作。過去的很多例子 (以后也還會有更多的例子 )都說明了要建立安全的系統(tǒng)是多么困難。在這種環(huán)境下，被破壞了意味著接收者可能錯誤地得到某位的值 (例如把 0讀成 1)，甚至無法探測到有什么東西到達了。對我們來說最重要的問題是容錯 (fault tolerance)，它意味著系統(tǒng)即使在發(fā)生故障時也能提供服務。芯片燃燒、軟件錯誤和磁盤頭損壞都是持久性故障的例子。 11 典型故障 圖 不同類型的故障 故障類型 說明 崩潰性故障 服務器停機，但是在停機之前工作正常 遺漏性故障 接收故障 發(fā)送故障 服務器不能響應到來的請求 服務器不能接收到來的消息 服務器不能發(fā)送消息 定時故障 服務器的響應在指定的時間間隔之外 響應故障 值故障 狀態(tài)轉(zhuǎn)換故障 服務器的響應不正確 響應的值錯誤 服務器偏離了正確的控制流 隨意性故障 服務器可能在隨意的時間產(chǎn)生隨意的響應 12 典型故障 ?如果服務器過早停機但在停止之前工作正常，就發(fā)生了崩潰性故障。在發(fā)生接收遺漏性故障的情況下，首先服務器可能永遠不會接收到請求。 ?另外一種故障類型與時間有關。特別是，發(fā)生故障的服務器可能會錯誤地采取一種從來沒有初始化的默認行為來進行處理，此時就發(fā)生這種故障。有三種可能：信息冗余、時間冗余和物理冗余。 ?在物理冗余中，通過添加額外的裝備或進程使系統(tǒng)作為一個整體來容忍部分組件的失效或故障成為可能。 21 進程恢復 ?容忍失敗進程的關鍵方法是把多個同樣的進程組織到一個組中。 ?引入組的目的在于允許把進程的集合作為單一的抽象概念來處理。協(xié)調(diào)者決定哪個工作者最適合，然后把請求轉(zhuǎn)發(fā)給它。協(xié)調(diào)者的故障會使整個組崩潰，但是只要它保持運行，就可以獨自做出決定，不需要其他進程參加。 ?與之相反的方法是以分布式的方法來管理組成員。即，從進程加入一個組開始，它就必須接收發(fā)送給該組的所有消息。像前面討論過的那樣，有兩種方法來進行復制：通過基于主進程的協(xié)議或通過復制寫協(xié)議。 ?使用進程組進行容錯中一個重要的問題是需要多少復制。這樣，即使在容錯系統(tǒng)中也需要某種統(tǒng)計分析。例如，選擇一個協(xié)調(diào)者，決定是否提交一個事務，在工作者之間劃分任務以及同步。如果兩支藍軍可以協(xié)調(diào)他們對紅軍的攻擊，那么他們就能獲得勝利。然后 A讓使者去告訴 B他 (B)的消息已經(jīng)到達，可以進行戰(zhàn)斗。如果沒有到達，就沒有完成協(xié)議，其他的司令官也不會發(fā)起攻擊。但是有 n個將軍是叛徒 (故障 )，他們通過給忠誠的將軍發(fā)送錯誤的和矛盾的信息 (模擬故障進程 )來阻止他們達成協(xié)議。在第 1步中，每個將軍發(fā)送一個 (可靠的 )消息給其他所有將軍以宣布他的兵力，忠誠的將軍說的是實話；而叛徒則向別的將軍說謊。如果哪個值為多數(shù)，就把它放到結(jié)果向量中。換句話說，只有當三分之二以上的進程正常工作時才可能達成協(xié)議。這種系統(tǒng)中的問題在于無法區(qū)分任意慢的進程與崩潰的進程。隨意性故障可能以重復消息的形式發(fā)生，造成他的原因是在計算機網(wǎng)絡中可能把消息緩沖一個相對較長的時間，然后在原始發(fā)送者發(fā)出重新傳送命令時把消息重新發(fā)到網(wǎng)絡中。 48 可靠的客戶 服務器通信 ?RPC的目標是通過使遠程過程調(diào)用與本地調(diào)用看上去相同來隱藏通信。直觀地說，它意味著發(fā)送到一個進程組的消息被傳遞給該組中的每個成員。 52 基于組的可靠多播方法 ?只要接收者的數(shù)目有限，那么這種較弱形式的可靠多播實現(xiàn)起來相對容易。作為選擇，發(fā)送者可以在某個時間內(nèi)沒有接收到所有確認的情況下自動重發(fā)消息。因為發(fā)送者永遠不會知道消息是否已被傳送到所有的接收者，它應該總是準備處理來自接收者的要求重發(fā)舊消息的請求。分布式提供了可靠的多播功能。在這一點上，讓它與其他副本保持狀態(tài)一致是基本的要求。加入一個組需要使它的狀態(tài)與其他的組成員保持一致。 ?原子多播的總體思想是多播消息 m應該唯一地跟它應該傳送到的一個進程表相關聯(lián)?，F(xiàn)在有兩個多播消息在同時進行傳輸：m和 vc。 63 虛擬同步 ?考慮圖 4個進程。即 ， 視圖改變作為一個屏障 ， 不能跨越它進行多播 。 ?在實踐中需要更復雜的方法，最常用的是兩階段提交協(xié)議，但它的缺點是不能有效地處理協(xié)調(diào)者失敗的情況。假定沒有故障發(fā)生，協(xié)議就由以下兩個階段組成，每個階段又由兩步組成。如果參與者接收到一個 Global_Commit消息，那么它就在本地提交事務，否則接收到一個 Global_Abort消息時，就在本地取消事務。 ? 沒有一個這樣的狀態(tài)：它不能做出最后決定，而且可以從它直接轉(zhuǎn)換到 Commit狀態(tài)。從本質(zhì)上說，有兩種形式的錯誤恢復。 77 恢復 ? 考慮一下可靠通信的實現(xiàn)，很容易解釋前向錯誤恢復與回退錯誤恢復之間的區(qū)別。如果沒有足夠的分組被傳送，發(fā)送者就不得不繼續(xù)發(fā)送分組直到先前丟失的分組可以被重建為止。 79 恢復 ? 第二，因為回退錯誤恢復機制不依賴于實際使用的分布式應用程序，不能保證一旦進行了恢復就不再發(fā)生相同或類似的失敗。在這種情況下，在沒有設臵檢查點后，一個進程在發(fā)送消息之前對它進行記錄 (稱為基于發(fā)送者的日志 )。但是，如果使用了消息日志，那么就會發(fā)生從上次檢查點之后事件的真實重放。要在進程或系統(tǒng)失敗之后進行恢復，就需要我們從這些局部狀態(tài)中建立一致的全局狀態(tài)。圖 。 87 獨立檢查點 ? 由于進程獨立地設臵本地檢查點，所以這種方法也被稱為獨立的檢查點方法。然后，當 Pj采用檢查點 CP[j](n)時，它就把這個依賴關系與恢復信息的其他部分一起寫入它的本地穩(wěn)定存儲中。相反，需要把狀態(tài)保存到本地穩(wěn)定存儲中，它還造成一些額外開銷，因此，協(xié)調(diào)檢查點使用得更為普遍，它也比獨立檢查點更為簡單。其原因在于任何跟隨在設臵檢查點的請求之后的消息都不被認為是本地檢查點的一部分。當確認所有的進程之后，使用第二次多播來引發(fā)實際的檢查點，然后所有的進程繼續(xù)執(zhí)行。假如，一個事件可能是一條指令的執(zhí)行、一條消息的發(fā)送等。 ? 孤兒進程就是在其他進程崩潰之后還存在的進程，但是它的狀態(tài)與恢復之后的崩潰進程不一致。另外還有一個傳送號碼用來確定它應該在何時被傳送給接收應用程序。當一個進程傳送消息 m時，它就也成為 COPY(m)的成員。即， DEP(m)中的所有進程都應該已經(jīng)崩潰了。 ? 最壞的情況就是 P在 m還沒有被記錄的時候就崩潰了。 ? 像在 (Einozahy等 1996)中指出的那樣，悲觀日志要比樂觀的方法簡單得多，所以在實際的分布式設計中它是消息日志的首選方法。因此，沒有其他進程會依賴于 m的傳送，就沒有了重放 m的傳輸?shù)目赡苄?。即，不論何時一個進程要依賴于m的傳送，那么它就總要保持 m的一份拷貝。如果所有這些進程都崩潰了，那么重放 m的傳輸顯然就是不可能的。因此可以使用重放穩(wěn)定消息的傳輸來進行恢復。進程 Q從進程 P與 R那里分別接收到消息 m1和 m2，然后把消息 m2發(fā)送給 R。但是，這個時刻之后進程的執(zhí)行就是完全確定的。在分布式系統(tǒng)中有一種重要的技術消息日志。 92 協(xié)調(diào)檢查點 ? 對這種算法的一種改進是只對那些依賴協(xié)調(diào)者的恢復的進程多播檢查點請求而忽略其他進程。協(xié)調(diào)檢查點的主要優(yōu)點是所保存的狀態(tài)自動保持全局一致，這樣就可以避免導致多米諾效應的折疊回退。要確保全局一致性，我們需要確保所有從 Pi那里接收到了按間隔 Int[i](m)發(fā)送的消息的進程都回退到在接收這個消息之前的檢查點狀態(tài)。獨立檢查點的另一個缺點是每個本地存儲都需要按時清理，例如通過運行一個特定的分布式垃圾收集器來進行清理。與此類似，進程 P1也需要進行回退。即，恢復線就對應于最近的一致性切面，圖 。 82 檢查點 ? 在容錯的分布式系統(tǒng)中，回退錯誤恢復需要系統(tǒng)把它的狀態(tài)有規(guī)律地保存到穩(wěn)定存儲中。這種方法也稱為接收者的日志。即，回退錯誤恢復機制通常不能提供完全的故障透明性。 78 恢復 ? 一般來說，回退錯誤恢復技術作為一種從分布式系統(tǒng)故障中恢復的機制被廣泛應用。實際上，分組重發(fā)就是嘗試著回退到以前的正確狀態(tài)，也就是發(fā)送丟失的分組時的狀態(tài)。要做到這一點，必須定時記錄系統(tǒng)的狀態(tài)，以便當發(fā)生錯誤時恢復到記錄的狀態(tài)。在這種情況下，其余的可能操作進程不能做出最后的決定，不得不在崩潰的進程恢復之前阻塞。因此參與者可能在協(xié)調(diào)者恢復之前保持阻塞。 2. 當參與者接收到 Vote_Request消息時，就向協(xié)調(diào)者返回一個Vote_Commit消息通知協(xié)調(diào)者它已經(jīng)準備好本地提交事務中屬于它的部分，否則就返回一個 Vote_Abort消息。 68 分布式提交 ?前面討論的原子多播問題是一個稱為分布式提交的更一般化問題中一個例子。 在視圖改變時進行的所有多播都在視圖改變生效之前完成 。在多播了一些消息之后，進程 P3崩潰了。 62 虛擬同步 ?這里出現(xiàn)了一個問題，如果 m沒有被傳送到任何一個進程，怎么能說這種協(xié)議是可靠的多播協(xié)議呢 ?原則上，只有一種情況下 m的傳送允許失?。寒斀M成員關系的改變是由于 m的發(fā)送者崩潰造成的結(jié)果時。很重要的一點是列表中的每個進程都具有相同的視圖。當一個副本從故障中恢復并重復加入組時，原子多播強制它與組的其他成員一致。 58 原子多播 ?現(xiàn)在假定底層的分布式系統(tǒng)支持原子多播。因此，復制的數(shù)據(jù)庫作為一組進程被建立，每個進程用于一個副本。但是，刪除一條消息是在冒險，因為重發(fā)的請求有可能不能得到響應。如果有 N個接收者，那么發(fā)送者必須準備接收至少 N個確認。假定底層的通信系統(tǒng)只需要不可靠的多播，那么這意味著多播消息會以某種方式丟失，它只能傳遞給其中一些接收者而不是全部。在前一種情況下，如果能保證所有正常的組成員接收到消息，那么就認為多播是可靠的。 ?區(qū)分 RPC系統(tǒng)中發(fā)生 5種失敗形式： ?客戶不能定位服務器； ?客戶到服務器的請求消息丟失； ?服務器在收到請求之后崩潰； ?從服務器到客戶的響應消息丟失； ?客戶在發(fā)送請求之后崩潰。 TCP可以通過確認