分布式系統(tǒng)與單節(jié)點(diǎn)系統(tǒng)的本質(zhì)區(qū)別是什么

1、 分布式系統(tǒng)與單節(jié)點(diǎn)系統(tǒng)的本質(zhì)區(qū)別是什么？ 分布式系統(tǒng)與單節(jié)點(diǎn)系統(tǒng)的本質(zhì)區(qū)別是什么？我們通過一個(gè)簡單的例子來說明。在單線程程序中，我們定義變量和執(zhí)行過程（即一組步驟）。例如，我們可以定義一個(gè)變量，并對它執(zhí)行簡單的算術(shù)運(yùn)算：int x = 1;x += 2;x *= 2;這里我們只會(huì)得到唯一的執(zhí)行歷史：聲明一個(gè)變量，把它加上2，再乘以2，然后得到結(jié)果6。假設(shè)這些運(yùn)算不是由單個(gè)線程執(zhí)行的，而是有兩個(gè)線程讀寫變量x，我們就需要考慮并發(fā)執(zhí)行的問題。1 并發(fā)執(zhí)行一旦兩個(gè)執(zhí)行線程都能訪問變量，除非我們在線程間同步這些步驟，否則這些并發(fā)步驟的執(zhí)行結(jié)果是無法預(yù)知的。如圖8-1所示，我們得到了4個(gè)可能的結(jié)果。注

2、1a) x = 2，如果兩個(gè)線程都讀到初始值，加法寫入結(jié)果，但被乘法的結(jié)果覆蓋了。b) x = 3，如果兩個(gè)線程都讀到初始值，乘法寫入結(jié)果，但被加法的結(jié)果覆蓋了。c) x = 4，如果乘法讀到初始值，且乘法在加法之前執(zhí)行。d) x = 6，如果加法讀到初始值，且加法在乘法之前執(zhí)行。即便僅在單個(gè)節(jié)點(diǎn)上，我們就已經(jīng)遇到了分布式系統(tǒng)中的第一個(gè)問題：并發(fā)。每個(gè)并發(fā)程序都具有分布式系統(tǒng)的某些特性。線程訪問共享狀態(tài)，在本地執(zhí)行一些運(yùn)算，再將結(jié)果傳回共享變量。圖1：并發(fā)執(zhí)行中可能的交錯(cuò)情形為了精確定義執(zhí)行歷史并減少可能的結(jié)果數(shù)量，我們需要一致性模型。一致性模型描述并發(fā)執(zhí)行的過程，并且確定了運(yùn)算執(zhí)行以及對其他

3、參與者可見的順序。使用不同的一致性模型，我們可以約束或放松系統(tǒng)可能的狀態(tài)數(shù)量。分布式系統(tǒng)和并發(fā)計(jì)算在術(shù)語和學(xué)術(shù)研究上有許多重疊之處，但也存在一些差異。并發(fā)系統(tǒng)中存在共享內(nèi)存，進(jìn)程可以用它來交換信息。在分布式系統(tǒng)中，各個(gè)進(jìn)程擁有自己的本地狀態(tài)，參與者之間通過傳遞消息進(jìn)行通信。并發(fā)和并行我們經(jīng)?；Q使用并發(fā)和并行計(jì)算這兩個(gè)術(shù)語，但是這兩個(gè)概念在語義上有細(xì)微的差異。當(dāng)兩個(gè)步驟序列并發(fā)執(zhí)行時(shí)，二者都在進(jìn)行中，但任意時(shí)刻都只有其中一個(gè)在執(zhí)行。當(dāng)兩個(gè)步驟序列并行執(zhí)行時(shí)，它們的步驟可以（在某一時(shí)刻）同時(shí)執(zhí)行。并發(fā)的操作時(shí)間上存在重疊，而并行的操作由多個(gè)處理器執(zhí)行WEIKUM01。Erlang編程語言的創(chuàng)建者

4、Joe Armstrong舉過一個(gè)例子：并發(fā)執(zhí)行就像一臺咖啡機(jī)前排了兩隊(duì)，而并行執(zhí)行就像兩臺咖啡機(jī)前排了兩隊(duì)。即便如此，絕大部分資料都用術(shù)語“并發(fā)”來描述擁有多個(gè)并行執(zhí)行線程的系統(tǒng)，而“并行”這個(gè)詞則很少見。分布式系統(tǒng)中的共享狀態(tài)我們可以嘗試在分布式系統(tǒng)中引入共享內(nèi)存的概念，例如，單一信息源（比如數(shù)據(jù)庫）。即使我們解決了并發(fā)訪問的問題，我們依然無法保證所有進(jìn)程都是同步的。為了訪問數(shù)據(jù)庫，進(jìn)程需要通過通信介質(zhì)發(fā)送和接受消息，以查詢或修改狀態(tài)。但是，如果一個(gè)進(jìn)程很久都沒有從數(shù)據(jù)庫得到響應(yīng)會(huì)如何？為了回答這個(gè)問題，我們首先要定義什么是很久。為此，必須從同步性的角度來描述系統(tǒng)：通信是否是全異步的？是否

5、存在某些時(shí)序假設(shè)？如果存在的話，這些時(shí)序假設(shè)將允許我們引入操作超時(shí)和重試機(jī)制。我們無從知曉數(shù)據(jù)庫沒有響應(yīng)是因?yàn)檫^載、不可用、響應(yīng)太慢還是網(wǎng)絡(luò)問題。這描述了崩潰的本質(zhì)進(jìn)程可能以各種方式崩潰：可能因某種原因無法繼續(xù)執(zhí)行后面的算法步驟；可能遇到了臨時(shí)性的故障；也可能是消息丟失。我們需要定義一個(gè)故障模型并描述故障可能發(fā)生的方式，然后再?zèng)Q定如何處理它們。如果系統(tǒng)在故障發(fā)生時(shí)仍然能繼續(xù)正常運(yùn)行，我們將這樣的特性稱為容錯(cuò)性。故障是不可避免的，所以我們需要構(gòu)建出具有可靠組件的系統(tǒng)。消除單點(diǎn)故障，比如前文提到的單節(jié)點(diǎn)數(shù)據(jù)庫，可能是我們朝此方向邁出的第一步。我們可以引入一些冗余，增設(shè)備份數(shù)據(jù)庫。然而這就引出了另一

6、個(gè)問題：如何使共享狀態(tài)的多個(gè)副本保持同步？到目前為止，在我們這個(gè)簡單系統(tǒng)中引入共享狀態(tài)所帶來的問題比答案還多?，F(xiàn)在我們知道，共享狀態(tài)不像引入數(shù)據(jù)庫那樣簡單，還必須采取更細(xì)化的方法，即基于消息傳遞來描述各個(gè)獨(dú)立進(jìn)程之間的交互。2 分布式計(jì)算的誤區(qū)理想情況下，當(dāng)兩臺計(jì)算機(jī)在網(wǎng)絡(luò)上通信時(shí)，一切都能正常工作：進(jìn)程開啟一個(gè)連接、發(fā)送數(shù)據(jù)、收到響應(yīng)，每個(gè)人都很開心。但是假設(shè)所有操作總會(huì)成功并且沒有任何錯(cuò)誤是很危險(xiǎn)的，因?yàn)楫?dāng)某些東西出問題時(shí)，我們的假設(shè)也就不成立了，那時(shí)系統(tǒng)的行為將變得難以預(yù)測。大多數(shù)時(shí)候，假設(shè)網(wǎng)絡(luò)可靠是合理的。網(wǎng)絡(luò)至少在一定程度上可靠才能有用。我們都曾經(jīng)歷過這樣的情況，當(dāng)我們嘗試連接到遠(yuǎn)程

7、服務(wù)器時(shí)，卻收到了一個(gè)“網(wǎng)絡(luò)不可達(dá)”的錯(cuò)誤。即使能建立連接，一個(gè)成功的初始連接也無法保證這條鏈路是穩(wěn)定的，連接隨時(shí)可能中斷。消息可能送達(dá)了對端，但對端的響應(yīng)卻可能丟失了，也有可能在對端的響應(yīng)發(fā)送之前連接就中斷了。網(wǎng)絡(luò)交換機(jī)會(huì)有故障，電纜可能斷開，網(wǎng)絡(luò)配置也隨時(shí)可能發(fā)生變化。我們構(gòu)建系統(tǒng)時(shí)需要適當(dāng)?shù)靥幚硭羞@些情況。連接可以是穩(wěn)定的，但我們不能期望遠(yuǎn)程調(diào)用能像本地調(diào)用一樣快。我們應(yīng)盡可能少地對延遲做出假設(shè)，并且永遠(yuǎn)不要假設(shè)延遲為零。一條消息要想到達(dá)遠(yuǎn)程服務(wù)器，需要穿過若干個(gè)軟件層和一個(gè)物理媒介（比如光纖或電纜），所有這些操作都不是瞬間完成的。Michael Lewis在他所著的書Flash Bo

8、ys（Simon and Schuster公司出版）中講述了這樣一個(gè)故事，公司花費(fèi)數(shù)百萬美元把延遲降低幾毫秒，從而能比競爭對手更快地訪問交易所。這是一個(gè)把延遲作為競爭優(yōu)勢的絕佳例子，然而值得一提的是，根據(jù)其他一些研究，比如文獻(xiàn)BARTLETT16，過時(shí)報(bào)價(jià)套利（通過比競爭對手更快地得知價(jià)格并執(zhí)行交易來獲取利潤）并不能使快速交易者從市場中獲利。從上述教訓(xùn)當(dāng)中學(xué)習(xí)，我們增加了重試和重連機(jī)制，并去掉了關(guān)于瞬間執(zhí)行的假設(shè)，但是事實(shí)證明這還不夠：當(dāng)我們增加消息的數(shù)量、發(fā)送速率和大小，并向現(xiàn)有網(wǎng)絡(luò)中添加新的進(jìn)程時(shí)，我們不應(yīng)該假設(shè)帶寬是無限的。1994年，Peter Deutsch發(fā)布過一個(gè)如今很有名的斷言

9、列表，標(biāo)題為“分布式計(jì)算的誤區(qū)”，描述了分布式計(jì)算中易被忽視的一些方面。除了網(wǎng)絡(luò)可靠性、延遲和帶寬假設(shè)，它還提到了其他問題，比如，網(wǎng)絡(luò)的安全性、可能存在的攻擊者、有意或無意的拓?fù)渥兓伎赡艽蚱莆覀兊囊恍┘僭O(shè)，這些假設(shè)包括：某一資源存在性和所在位置，網(wǎng)絡(luò)傳輸所消耗的時(shí)間和資源，以及最后存在一個(gè)擁有整個(gè)網(wǎng)絡(luò)的知識和控制權(quán)的權(quán)威個(gè)體。Deutsch的列表可以說非常詳盡，但它側(cè)重于通過鏈路傳遞消息時(shí)可能出錯(cuò)的地方。這些擔(dān)憂是合理的，而且描述了最通用、最底層的復(fù)雜性，但不幸的是，在設(shè)計(jì)和實(shí)現(xiàn)分布式系統(tǒng)時(shí)，我們還做出了很多其他假設(shè)，這些假設(shè)也可能在運(yùn)行中導(dǎo)致問題。2.1 處理在遠(yuǎn)程進(jìn)程響應(yīng)剛剛收到的消息之

10、前，它還需要在本地執(zhí)行一些工作，因此我們不能假定處理是瞬時(shí)完成的。只考慮網(wǎng)絡(luò)延遲還不夠，因?yàn)檫h(yuǎn)程進(jìn)程執(zhí)行的操作也不是立即完成的。此外，我們還無法保證消息送達(dá)后會(huì)立刻被處理。消息可能會(huì)進(jìn)入遠(yuǎn)程服務(wù)器的等待隊(duì)列中，等到所有更早到達(dá)的消息處理完后才被處理。節(jié)點(diǎn)可能相距很近，也可能很遠(yuǎn)，各節(jié)點(diǎn)可能有不同的CPU、內(nèi)存和磁盤配置，可能運(yùn)行不同的軟件版本和配置。我們不能期望它們以相同的速度處理請求。如果完成一項(xiàng)任務(wù)需要等待幾個(gè)并行工作的遠(yuǎn)程服務(wù)器響應(yīng)，則整個(gè)執(zhí)行的完成時(shí)間取決于最慢的服務(wù)器。與普遍存在的看法相反，隊(duì)列容量并非是無限的，堆積更多的請求不會(huì)對系統(tǒng)有任何好處。當(dāng)生產(chǎn)者產(chǎn)生消息的速度大于消費(fèi)者能夠

11、處理的速度時(shí)，我們可以使用背壓（backpressure）策略減慢生產(chǎn)者的速度。背壓是分布式系統(tǒng)中人們了解和應(yīng)用最少的概念之一，通常是事后才建立，而不是將其視為系統(tǒng)設(shè)計(jì)必需的一個(gè)組成部分。盡管增加隊(duì)列容量聽起來像是個(gè)好主意可以幫助我們管道化、并行化以及有效地調(diào)度請求，但是，如果消息僅僅是停在隊(duì)列中等待處理，什么也不會(huì)發(fā)生。增大隊(duì)列大小可能對延遲產(chǎn)生負(fù)面影響，因?yàn)檫@并不會(huì)改善處理速度。通常，進(jìn)程本地隊(duì)列是用于實(shí)現(xiàn)以下目標(biāo)：解耦使接收和處理在時(shí)間上分開，并各自獨(dú)立發(fā)生。流水線化不同階段的請求由系統(tǒng)中獨(dú)立的部分處理。負(fù)責(zé)接收消息的子系統(tǒng)不用阻塞到上一條消息處理完成。吸收瞬時(shí)突發(fā)流量系統(tǒng)負(fù)載可能經(jīng)常變

12、化，但是請求到達(dá)的間隔時(shí)間對負(fù)責(zé)處理請求的組件是隱藏的?？傮w的系統(tǒng)延遲會(huì)由于排隊(duì)而增加，但這通常仍比響應(yīng)失敗并重試請求更好。隊(duì)列大小取決于工作負(fù)載和應(yīng)用程序。對于相對穩(wěn)定的工作負(fù)載，我們可以通過測量任務(wù)處理時(shí)間以及各任務(wù)的平均排隊(duì)時(shí)間來確定隊(duì)列大小，從而確保在提升吞吐量的同時(shí)，延遲仍保持在可接受的范圍內(nèi)。在這種情況下，隊(duì)列大小相對較小。對于不可預(yù)測的工作負(fù)載，可能會(huì)出現(xiàn)任務(wù)提交的突發(fā)流量，這時(shí)隊(duì)列大小也應(yīng)當(dāng)考慮突發(fā)流量和高負(fù)載。即使遠(yuǎn)程服務(wù)器可以快速地處理請求，也并不意味著我們總是能獲得正面的響應(yīng)。它也可能回應(yīng)一個(gè)失?。簾o法進(jìn)行寫操作、要查找的值不存在或是觸發(fā)了bug?？傊词故亲铐樌那闆r

13、也需要我們的關(guān)注。2.2 時(shí)鐘和時(shí)間時(shí)間是一種幻覺，尤其是午餐時(shí)間。 FordPrefect,TheHitchhiker抯GuidetotheGalaxy假設(shè)不同的遠(yuǎn)程計(jì)算機(jī)上的時(shí)鐘都同步也很危險(xiǎn)。再加上延遲為零以及處理是瞬時(shí)的這些假設(shè)，將會(huì)導(dǎo)致不同的特質(zhì)，尤其是在時(shí)序和實(shí)時(shí)數(shù)據(jù)處理中。例如，當(dāng)從時(shí)間感知不同的參與者收集和聚合數(shù)據(jù)時(shí)，你必須了解它們之間的時(shí)間漂移并相應(yīng)地對時(shí)間進(jìn)行歸一化，而不是依賴源時(shí)間戳。除非使用特殊的高精度時(shí)間源，否則不能依賴時(shí)間戳進(jìn)行同步或排序。當(dāng)然，這并不意味著我們完全不能或不該依賴時(shí)間：說到底，任何同步系統(tǒng)都依靠本地時(shí)鐘實(shí)現(xiàn)超時(shí)。我們必須始終注意進(jìn)程之間可能存在的時(shí)間

14、誤差，以及傳遞和處理消息所需的時(shí)間。例如，Spanner（參見13.5節(jié)）使用特殊的時(shí)間API，該API返回時(shí)間戳和不確定性界限以施加嚴(yán)格的事務(wù)順序。一些故障檢測算法依賴于共享的時(shí)間概念，要求時(shí)鐘漂移始終在允許的范圍內(nèi)才能確保正確性GUPTA01。除了分布式系統(tǒng)中的時(shí)鐘同步非常困難之外，當(dāng)前時(shí)間也在不斷變化：你可以從操作系統(tǒng)請求當(dāng)前的POSIX時(shí)間戳，并在執(zhí)行幾個(gè)步驟后請求另一個(gè)當(dāng)前時(shí)間戳，兩次結(jié)果是不同的。盡管這是一個(gè)明顯的現(xiàn)象，但是了解時(shí)間的來源以及時(shí)間戳捕獲的確切時(shí)刻至關(guān)重要。了解時(shí)鐘源是否是單調(diào)的（即永遠(yuǎn)不會(huì)后退），以及與調(diào)度時(shí)間相關(guān)的操作可能偏移多少，可能也會(huì)有所幫助。2.3 狀態(tài)一

15、致性之前說到的假設(shè)大多屬于“幾乎總是錯(cuò)的”一類，但是，還有一些假設(shè)最好歸入“并非總是對的”一類。這類假設(shè)幫助我們走思維捷徑，通過以特定方式思考來簡化模型，忽略某些棘手的邊緣情形。分布式算法并不總是保證狀態(tài)嚴(yán)格一致。一些方法具有較寬松的約束，允許各副本之間的狀態(tài)存在分歧，并依賴沖突解決（檢測和解決系統(tǒng)內(nèi)分歧狀態(tài)的能力）和讀取時(shí)數(shù)據(jù)修復(fù)（讀取期間，當(dāng)各副本響應(yīng)不同結(jié)果時(shí)，使副本恢復(fù)同步的能力）。有關(guān)這些概念的更多信息參見第12章。假定狀態(tài)在節(jié)點(diǎn)間完全一致可能會(huì)導(dǎo)致難以察覺的bug。最終一致的分布式數(shù)據(jù)庫可能具有這樣的邏輯：讀取時(shí)通過查詢Quorum的節(jié)點(diǎn)來處理副本不一致，但是假定數(shù)據(jù)庫表結(jié)構(gòu)和集群

16、視圖是強(qiáng)一致的。除非我們確保這些信息的一致性，否則依賴該假設(shè)可能會(huì)造成嚴(yán)重的后果。例如，Apache Cassandra曾有一個(gè)bug，其原因是表結(jié)構(gòu)變更在不同時(shí)刻傳播到各個(gè)服務(wù)器。如果在表結(jié)構(gòu)傳播過程中嘗試從數(shù)據(jù)庫讀取數(shù)據(jù)，則可能會(huì)讀到損壞的數(shù)據(jù)，因?yàn)橐慌_服務(wù)器以某種表結(jié)構(gòu)進(jìn)行編碼，而另一臺服務(wù)器使用不同的表結(jié)構(gòu)對其進(jìn)行解碼。另一個(gè)例子是由環(huán)的視圖分歧引起的bug：如果一個(gè)節(jié)點(diǎn)假定另一個(gè)節(jié)點(diǎn)保存了某個(gè)鍵的數(shù)據(jù)記錄，但另一個(gè)節(jié)點(diǎn)具有不同的集群視圖，此時(shí)讀寫數(shù)據(jù)可能會(huì)導(dǎo)致數(shù)據(jù)記錄被錯(cuò)誤放置，或是獲得一個(gè)空的響應(yīng)，雖然數(shù)據(jù)實(shí)際上好端端地存放在另一個(gè)節(jié)點(diǎn)上。即使完全的解決方案成本很高，我們也最好事先

17、考慮各種可能的問題。通過了解和處理這些情況，你能以更自然的方式解決問題，比如內(nèi)置防護(hù)措施或修改設(shè)計(jì)。2.4 本地和遠(yuǎn)程執(zhí)行將復(fù)雜性隱藏在API內(nèi)部可能很危險(xiǎn)。例如，對于本地?cái)?shù)據(jù)集上的一個(gè)迭代器，即使你對存儲(chǔ)引擎不熟悉，也可以合理地推測內(nèi)部行為。理解遠(yuǎn)程數(shù)據(jù)集上的迭代過程則是一個(gè)完全不同的問題：你需要理解一致性、傳遞語義、數(shù)據(jù)協(xié)調(diào)、分頁、合并、并發(fā)訪問含義以及許多其他事情。簡單地將兩者隱藏在同一個(gè)接口后，即便有用，也可能會(huì)產(chǎn)生誤導(dǎo)。調(diào)試、配置和可觀察性可能需要額外的API參數(shù)。我們應(yīng)該始終牢記，本地執(zhí)行和遠(yuǎn)程執(zhí)行是不同的。隱藏遠(yuǎn)程調(diào)用最明顯的問題是延遲：遠(yuǎn)程調(diào)用的成本比本地調(diào)用高很多倍，因?yàn)樗?/p>

18、及雙向網(wǎng)絡(luò)傳輸、序列化/反序列化以及許多其他步驟。交錯(cuò)使用本地調(diào)用和阻塞的遠(yuǎn)程調(diào)用可能會(huì)導(dǎo)致性能下降和預(yù)期之外的副作用VINOSKI08。2.5 處理故障的需要?jiǎng)傞_始構(gòu)建系統(tǒng)的時(shí)候，我們可以假設(shè)所有節(jié)點(diǎn)都可以正常工作，但如果總是這么想就很危險(xiǎn)了。在長時(shí)間運(yùn)行的系統(tǒng)中，節(jié)點(diǎn)可能會(huì)關(guān)機(jī)維護(hù)（通常會(huì)有個(gè)優(yōu)雅關(guān)閉的過程）或因?yàn)榉N種原因（例如軟件問題、內(nèi)存耗盡（out-of-memory killer KERRISK10）、運(yùn)行時(shí)bug、硬件問題等）而崩潰。進(jìn)程會(huì)發(fā)生故障，而你能做的最好的事情就是做好準(zhǔn)備并知道如何處理它們。如果遠(yuǎn)程服務(wù)器沒有響應(yīng)，我們并不總是知道確切的原因。這可能是由系統(tǒng)崩潰、網(wǎng)絡(luò)故障

19、、遠(yuǎn)程進(jìn)程或中間鏈路太慢導(dǎo)致的。一些分布式算法使用心跳協(xié)議和故障檢測機(jī)制來確定哪些參與者還活著且可達(dá)。2.6 網(wǎng)絡(luò)分區(qū)和部分故障當(dāng)兩個(gè)或更多服務(wù)器無法相互通信時(shí)，我們稱這種情況為網(wǎng)絡(luò)分區(qū)。Seth Gilbert和Nancy Lynch在Perspectives on the CAP Theorem GILBERT12中區(qū)分了以下兩種情況：兩個(gè)參與者無法相互通信；幾組參與者彼此隔開，無法交換消息并繼續(xù)運(yùn)行算法。網(wǎng)絡(luò)的總體不可靠性（數(shù)據(jù)包丟失、重傳、延遲難以預(yù)測）令人煩惱但尚可容忍，而網(wǎng)絡(luò)分區(qū)則會(huì)造成更多的麻煩，因?yàn)楦鱾€(gè)獨(dú)立的分組可以繼續(xù)執(zhí)行并產(chǎn)生沖突的結(jié)果。網(wǎng)絡(luò)鏈路的故障也可能是不對稱的：消息

20、仍然能從一個(gè)進(jìn)程傳遞到另一個(gè)進(jìn)程，反之則不行。為了構(gòu)建在一個(gè)或多個(gè)進(jìn)程出現(xiàn)故障的情況下仍健壯的系統(tǒng)，我們必須考慮部分故障的情況TANENBAUM06，如何讓系統(tǒng)在部分不可用或運(yùn)行不正常的情況下仍能繼續(xù)工作。故障很難檢測，并且在系統(tǒng)的不同部分看來，不總是以相同的方式可見。設(shè)計(jì)高可用性系統(tǒng)時(shí)，我們應(yīng)該始終考慮邊緣情形：如果我們確實(shí)復(fù)制了數(shù)據(jù)卻沒有收到確認(rèn)該怎么辦？要重試嗎？在發(fā)送了確認(rèn)的節(jié)點(diǎn)上，數(shù)據(jù)仍可用于讀取嗎？墨菲定律注2告訴我們故障一定會(huì)發(fā)生。編程界又補(bǔ)充道，故障將以最壞的方式發(fā)生。因此，作為分布式系統(tǒng)工程師，我們的工作是盡可能減少可能出現(xiàn)錯(cuò)誤的場景，并為故障做好準(zhǔn)備包括這些故障可能導(dǎo)致的破

21、壞。避免一切故障是不可能的，但我們?nèi)钥梢詷?gòu)建一個(gè)彈性的系統(tǒng)，使之在故障出現(xiàn)時(shí)仍然能正常運(yùn)行。設(shè)計(jì)應(yīng)對故障的最佳方式是進(jìn)行故障測試。我們無法考慮清楚每種可能的故障場景，并預(yù)測多個(gè)進(jìn)程的行為。最好的解決方法就是通過測試工具來制造網(wǎng)絡(luò)分區(qū)、模擬比特位腐爛GRAY05、增加延遲、使時(shí)鐘發(fā)生偏移以及放大相對處理速度?，F(xiàn)實(shí)世界中分布式系統(tǒng)的設(shè)置可能是對抗性的、不友好的，甚至是“有創(chuàng)造性的”（然而，以非常敵對的方式），因此測試工作應(yīng)當(dāng)嘗試覆蓋盡可能多的場景。過去幾年中出現(xiàn)了一些開源項(xiàng)目，它們能幫助我們構(gòu)造出各種故障場景。Toxiproxy用于模擬網(wǎng)絡(luò)問題：限制帶寬、引入延遲、超時(shí)等。Chaos Monkey

22、的方法更為激進(jìn)，它通過隨機(jī)關(guān)閉服務(wù)使工程師直面生產(chǎn)環(huán)境故障的風(fēng)險(xiǎn)。CharybdeFS模擬文件系統(tǒng)及硬件錯(cuò)誤與故障。你可以用這些工具來測試軟件，以確保在這些故障出現(xiàn)時(shí)軟件仍能正確工作。CrashMonkey是一個(gè)與文件系統(tǒng)無關(guān)的記錄重放測試框架，用于測試持久性文件的數(shù)據(jù)及元數(shù)據(jù)一致性。設(shè)計(jì)分布式系統(tǒng)時(shí)，我們必須認(rèn)真考慮容錯(cuò)性、彈性，以及可能的故障場景和邊緣情形。類似于“足夠多的眼睛，就可讓所有問題浮現(xiàn)”，我們可以說足夠大的集群最終一定會(huì)命中所有可能的問題。與此同時(shí)，只要有足夠多的測試，我們最終能夠發(fā)現(xiàn)每個(gè)存在的問題。2.7 級聯(lián)故障我們做不到總是完全隔離故障：被高負(fù)載壓垮的進(jìn)程會(huì)增加集群其余部

23、分的負(fù)載，從而使其他節(jié)點(diǎn)更有可能發(fā)生故障。級聯(lián)故障能夠從系統(tǒng)的一部分傳播到另一部分，擴(kuò)大了問題的范圍。有時(shí)，級聯(lián)故障甚至可能來源于完全善意的目的。例如，某個(gè)節(jié)點(diǎn)離線了一段時(shí)間，因而沒有接收到最近的更新。當(dāng)它恢復(fù)在線時(shí)，樂于助人的其他節(jié)點(diǎn)希望幫助它追趕上最近的變化，于是開始向它發(fā)送缺失的數(shù)據(jù)，而這又導(dǎo)致網(wǎng)絡(luò)資源耗盡，或是導(dǎo)致該節(jié)點(diǎn)啟動(dòng)后短時(shí)間內(nèi)再次發(fā)生故障。為了防止系統(tǒng)的故障擴(kuò)散并妥善處理故障場景，我們可以使用斷路器（或熔斷機(jī)制）。在電氣工程中，斷路器可通過中斷電流來保護(hù)昂貴且難以更換的部件，使其免受電流過載或短路的影響。在軟件開發(fā)中，熔斷機(jī)制會(huì)監(jiān)視故障，并使用回退（fallback）機(jī)制保護(hù)整個(gè)系統(tǒng)：避免使用出故障的服務(wù)，給它一些時(shí)間進(jìn)行恢復(fù)，并妥善處理失敗的調(diào)用。當(dāng)與某一臺服務(wù)器的連接失敗或服務(wù)器沒有響應(yīng)時(shí)，客戶端將開始循環(huán)重連。那時(shí)候，過載的服務(wù)器已經(jīng)難以應(yīng)付新的連接請求，因而客戶端的循環(huán)重試也無濟(jì)于事。為了避免這一情況，我們可以使用退避（backoff）策略，客戶端不要立即重試，而是等待一段時(shí)間。退避通過合理安排重試、增加后續(xù)請求之間的時(shí)間窗口來避免問題擴(kuò)大。退避