建站
咨詢
售后
建站咨詢
新聞中心
作者：仕祿
為閔行等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及閔行網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、閔行網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！
分布式系統(tǒng)設(shè)計(jì)是一項(xiàng)十分復(fù)雜且具有挑戰(zhàn)性的事情。其中，數(shù)據(jù)復(fù)制與一致性更是其中十分重要的一環(huán)。數(shù)據(jù)復(fù)制領(lǐng)域概念龐雜、理論性強(qiáng)，如果對應(yīng)的算法沒有理論驗(yàn)證大概率會(huì)出錯(cuò)。如果在設(shè)計(jì)過程中，不了解對應(yīng)理論所解決的問題以及不同理論之間的聯(lián)系，勢必?zé)o法設(shè)計(jì)出一個(gè)合理的分布式系統(tǒng)。
本系列文章分上下兩篇，以《數(shù)據(jù)密集型應(yīng)用系統(tǒng)設(shè)計(jì)（DDIA）》（下文簡稱《DDIA》）為主線，文中的核心理論講解與圖片來自于此書。在此基礎(chǔ)上，加入了日常工作中對這些概念的理解與個(gè)性化的思考，并將它們映射到Kafka中，跟大家分享一下如何將具體的理論應(yīng)用于實(shí)際生產(chǎn)環(huán)境中。
1. 簡介
1.1 簡介——使用復(fù)制的目的
在分布式系統(tǒng)中，數(shù)據(jù)通常需要被分散在多臺(tái)機(jī)器上，主要為了達(dá)到以下目的：
- 擴(kuò)展性，數(shù)據(jù)量因讀寫負(fù)載巨大，一臺(tái)機(jī)器無法承載，數(shù)據(jù)分散在多臺(tái)機(jī)器上可以有效地進(jìn)行負(fù)載均衡，達(dá)到靈活的橫向擴(kuò)展。
- 容錯(cuò)、高可用，在分布式系統(tǒng)中，單機(jī)故障是常態(tài)，在單機(jī)故障下仍然希望系統(tǒng)能夠正常工作，這時(shí)候就需要數(shù)據(jù)在多臺(tái)機(jī)器上做冗余，在遇到單機(jī)故障時(shí)其他機(jī)器就可以及時(shí)接管。
- 統(tǒng)一的用戶體驗(yàn)，如果系統(tǒng)客戶端分布在多個(gè)地域，通?？紤]在多個(gè)地域部署服務(wù)，以方便用戶能夠就近訪問到他們所需要的數(shù)據(jù)，獲得統(tǒng)一的用戶體驗(yàn)。
數(shù)據(jù)的多機(jī)分布的方式主要有兩種，一種是將數(shù)據(jù)分片保存，每個(gè)機(jī)器保存數(shù)據(jù)的部分分片（Kafka中稱為Partition，其他部分系統(tǒng)稱為Shard），另一種則是完全的冗余，其中每一份數(shù)據(jù)叫做一個(gè)副本（Kafka中稱為Replica），通過數(shù)據(jù)復(fù)制技術(shù)實(shí)現(xiàn)。在分布式系統(tǒng)中，兩種方式通常會(huì)共同使用，最后的數(shù)據(jù)分布往往是下圖的樣子，一臺(tái)機(jī)器上會(huì)保存不同數(shù)據(jù)分片的若干個(gè)副本。本系列博文主要介紹的是數(shù)據(jù)如何做復(fù)制，分區(qū)則是另一個(gè)主題，不在本文的討論范疇。
圖1 常見數(shù)據(jù)分布
復(fù)制的目標(biāo)需要保證若干個(gè)副本上的數(shù)據(jù)是一致的，這里的“一致”是一個(gè)十分不確定的詞，既可以是不同副本上的數(shù)據(jù)在任何時(shí)刻都保持完全一致，也可以是不同客戶端不同時(shí)刻訪問到的數(shù)據(jù)保持一致。一致性的強(qiáng)弱也會(huì)不同，有可能需要任何時(shí)候不同客端都能訪問到相同的新的數(shù)據(jù)，也有可能是不同客戶端某一時(shí)刻訪問的數(shù)據(jù)不相同，但在一段時(shí)間后可以訪問到相同的數(shù)據(jù)。因此，“一致性”是一個(gè)值得單獨(dú)抽出來細(xì)說的詞。在下一篇文章中，我們將重點(diǎn)介紹這個(gè)詞在不同上下文之間的含義。
此時(shí)，大家可能會(huì)有疑問，直接讓所有副本在任意時(shí)刻都保持一致不就行了，為啥還要有各種不同的一致性呢？我們認(rèn)為有兩個(gè)考量點(diǎn)，第一是性能，第二則是復(fù)雜性。
性能比較好理解，因?yàn)槿哂嗟哪康牟煌耆菫榱烁呖捎?，還有延遲和負(fù)載均衡這類提升性能的目的，如果只一味地為了地強(qiáng)調(diào)數(shù)據(jù)一致，可能得不償失。復(fù)雜性是因?yàn)榉植际较到y(tǒng)中，有著比單機(jī)系統(tǒng)更加復(fù)雜的不確定性，節(jié)點(diǎn)之間由于采用不大可靠的網(wǎng)絡(luò)進(jìn)行傳輸，并且不能共享統(tǒng)一的一套系統(tǒng)時(shí)間和內(nèi)存地址（后文會(huì)詳細(xì)進(jìn)行說明），這使得原本在一些單機(jī)系統(tǒng)上很簡單的事情，在轉(zhuǎn)到分布式系統(tǒng)上以后就變得異常復(fù)雜。這種復(fù)雜性和不確定性甚至?xí)屛覀儜岩?，這些副本上的數(shù)據(jù)真的能達(dá)成一致嗎？下一篇文章會(huì)專門詳細(xì)分析如何設(shè)計(jì)算法來應(yīng)對這種復(fù)雜和不確定性。
1.2 文章系列概述
本系列博文將分為上下兩篇，第一篇將主要介紹幾種常見的數(shù)據(jù)復(fù)制模型，然后介紹分布式系統(tǒng)的挑戰(zhàn)，讓大家對分布式系統(tǒng)一些稀奇古怪的故障有一些感性的認(rèn)識。第二篇文章將針對本篇中提到的問題，分別介紹事務(wù)、分布式共識算法和一致性，以及三者的內(nèi)在聯(lián)系，再分享如何在分布式系統(tǒng)中保證數(shù)據(jù)的一致性，進(jìn)而讓大家對數(shù)據(jù)復(fù)制技術(shù)有一個(gè)較為全面的認(rèn)識。此外，本系列還將介紹業(yè)界驗(yàn)證分布式算法正確性的一些工具和框架。接下來，讓我們一起開始數(shù)據(jù)復(fù)制之旅吧！
2. 數(shù)據(jù)復(fù)制模式
總體而言，最常見的復(fù)制模式有三種，分別為主從模式、多主節(jié)點(diǎn)模式、無主節(jié)點(diǎn)模式，下面分別進(jìn)行介紹。
2.1 最簡單的復(fù)制模式——主從模式
簡介
對復(fù)制而言，最直觀的方法就是將副本賦予不同的角色，其中有一個(gè)主副本，主副本將數(shù)據(jù)存儲(chǔ)在本地后，將數(shù)據(jù)更改作為日志，或者以更改流的方式發(fā)到各個(gè)從副本（后文也會(huì)稱節(jié)點(diǎn)）中。在這種模式下，所有寫請求就全部會(huì)寫入到主節(jié)點(diǎn)上，讀請求既可以由主副本承擔(dān)也可以由從副本承擔(dān)，這樣對于讀請求而言就具備了擴(kuò)展性，并進(jìn)行了負(fù)載均衡。但這里面存在一個(gè)權(quán)衡點(diǎn)，就是客戶端視角看到的一致性問題。這個(gè)權(quán)衡點(diǎn)存在的核心在于，數(shù)據(jù)傳輸是通過網(wǎng)絡(luò)傳遞的，數(shù)據(jù)在網(wǎng)絡(luò)中傳輸?shù)臅r(shí)間是不能忽略的。
圖2 同步復(fù)制與異步復(fù)制如上圖所示，在這個(gè)時(shí)間窗口中，任何情況都有可能發(fā)生。在這種情況下，客戶端何時(shí)算寫入完成，會(huì)決定其他客戶端讀到數(shù)據(jù)的可能性。這里我們假設(shè)這份數(shù)據(jù)有一個(gè)主副本和一個(gè)從副本，如果主副本保存后即向客戶端返回成功，這樣叫做異步復(fù)制（1）。而如果等到數(shù)據(jù)傳送到從副本1，并得到確認(rèn)之后再返回客戶端成功，稱為同步復(fù)制（2）。這里我們先假設(shè)系統(tǒng)正常運(yùn)行，在異步同步下，如果從副本承擔(dān)讀請求，假設(shè)reader1和reader2同時(shí)在客戶端收到寫入成功后發(fā)出讀請求，兩個(gè)reader就可能讀到不一樣的值。
為了避免這種情況，實(shí)際上有兩種角度的做法，第一種角度是讓客戶端只從主副本讀取數(shù)據(jù)，這樣，在正常情況下，所有客戶端讀到的數(shù)據(jù)一定是一致的（Kafka當(dāng)前的做法）；另一種角度則是采用同步復(fù)制，假設(shè)使用純的同步復(fù)制，當(dāng)有多個(gè)副本時(shí)，任何一個(gè)副本所在的節(jié)點(diǎn)發(fā)生故障，都會(huì)使寫請求阻塞，同時(shí)每次寫請求都需要等待所有節(jié)點(diǎn)確認(rèn)，如果副本過多會(huì)極大影響吞吐量。而如果僅采用異步復(fù)制并由主副本承擔(dān)讀請求，當(dāng)主節(jié)點(diǎn)故障發(fā)生切換時(shí)，一樣會(huì)發(fā)生數(shù)據(jù)不一致的問題。
很多系統(tǒng)會(huì)把這個(gè)決策權(quán)交給用戶，這里我們以Kafka為例，首先提供了同步與異步復(fù)制的語義（通過客戶端的acks參數(shù)確定），另外提供了ISR機(jī)制，而只需要ISR中的副本確認(rèn)即可，系統(tǒng)可以容忍部分節(jié)點(diǎn)因?yàn)楦鞣N故障而脫離ISR，那樣客戶端將不用等待其確認(rèn)，增加了系統(tǒng)的容錯(cuò)性。當(dāng)前Kafka未提供讓從節(jié)點(diǎn)承擔(dān)讀請求的設(shè)計(jì)，但在高版本中已經(jīng)有了這個(gè)Feature。這種方式使系統(tǒng)有了更大的靈活性，用戶可以根據(jù)場景自由權(quán)衡一致性和可用性。
主從模式下需要的一些能力
增加新的從副本（節(jié)點(diǎn)）1. 在Kafka中，我們所采取的的方式是通過新建副本分配的方式，以追趕的方式從主副本中同步數(shù)據(jù)。2. 數(shù)據(jù)庫所采用的的方式是通過快照+增量的方式實(shí)現(xiàn)。
a.在某一個(gè)時(shí)間點(diǎn)產(chǎn)生一個(gè)一致性的快照。
b.將快照拷貝到從節(jié)點(diǎn)。
c.從節(jié)點(diǎn)連接到主節(jié)點(diǎn)請求所有快照點(diǎn)后發(fā)生的改變?nèi)罩尽?nbsp;
d.獲取到日志后，應(yīng)用日志到自己的副本中，稱之為追趕。
e.可能重復(fù)多輪a-d。
處理節(jié)點(diǎn)失效
從節(jié)點(diǎn)失效——追趕式恢復(fù)
針對從節(jié)點(diǎn)失效，恢復(fù)手段較為簡單，一般采用追趕式恢復(fù)。而對于數(shù)據(jù)庫而言，從節(jié)點(diǎn)可以知道在崩潰前所執(zhí)行的最后一個(gè)事務(wù)，然后連接主節(jié)點(diǎn)，從該節(jié)點(diǎn)將拉取所有的事件變更，將這些變更應(yīng)用到本地記錄即可完成追趕。
對于Kafka而言，恢復(fù)也是類似的，Kafka在運(yùn)行過程中，會(huì)定期項(xiàng)磁盤文件中寫入checkpoint，共包含兩個(gè)文件，一個(gè)是recovery-point-offset-checkpoint，記錄已經(jīng)寫到磁盤的offset，另一個(gè)則是replication-offset-checkpoint，用來記錄高水位（下文簡稱HW），由ReplicaManager寫入，下一次恢復(fù)時(shí)，Broker將讀取兩個(gè)文件的內(nèi)容，可能有些被記錄到本地磁盤上的日志沒有提交，這時(shí)就會(huì)先截?cái)啵═runcate）到HW對應(yīng)的offset上，然后從這個(gè)offset開始從Leader副本拉取數(shù)據(jù)，直到認(rèn)追上Leader，被加入到ISR集合中
主節(jié)點(diǎn)失效——節(jié)點(diǎn)切換
主節(jié)點(diǎn)失效則會(huì)稍稍復(fù)雜一些，需要經(jīng)歷三個(gè)步驟來完成節(jié)點(diǎn)的切換。
- 確認(rèn)主節(jié)點(diǎn)失效，由于失效的原因有多種多樣，大多數(shù)系統(tǒng)會(huì)采用超時(shí)來判定節(jié)點(diǎn)失效。一般都是采用節(jié)點(diǎn)間互發(fā)心跳的方式，如果發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)在較長時(shí)間內(nèi)無響應(yīng)，則會(huì)認(rèn)定為節(jié)點(diǎn)失效。具體到Kafka中，它是通過和Zookeeper（下文簡稱ZK）間的會(huì)話來保持心跳的，在啟動(dòng)時(shí)Kafka會(huì)在ZK上注冊臨時(shí)節(jié)點(diǎn)，此后會(huì)和ZK間維持會(huì)話，假設(shè)Kafka節(jié)點(diǎn)出現(xiàn)故障（這里指被動(dòng)的掉線，不包含主動(dòng)執(zhí)行停服的操作），當(dāng)會(huì)話心跳超時(shí)時(shí)，ZK上的臨時(shí)節(jié)點(diǎn)會(huì)掉線，這時(shí)會(huì)有專門的組件（Controller）監(jiān)聽到這一信息，并認(rèn)定節(jié)點(diǎn)失效。
- 選舉新的主節(jié)點(diǎn)。這里可以通過通過選舉的方式（民主協(xié)商投票，通常使用共識算法），或由某個(gè)特定的組件指定某個(gè)節(jié)點(diǎn)作為新的節(jié)點(diǎn)（Kafka的Controller）。在選舉或指定時(shí)，需要盡可能地讓新主與原主的差距最小，這樣會(huì)最小化數(shù)據(jù)丟失的風(fēng)險(xiǎn)（讓所有節(jié)點(diǎn)都認(rèn)可新的主節(jié)點(diǎn)是典型的共識問題）--這里所謂共識，就是讓一個(gè)小組的節(jié)點(diǎn)就某一個(gè)議題達(dá)成一致，下一篇文章會(huì)重點(diǎn)進(jìn)行介紹。
- 重新配置系統(tǒng)是新的主節(jié)點(diǎn)生效，這一階段基本可以理解為對集群的元數(shù)據(jù)進(jìn)行修改，讓所有外界知道新主節(jié)點(diǎn)的存在（Kafka中Controller通過元數(shù)據(jù)廣播實(shí)現(xiàn)），后續(xù)及時(shí)舊的節(jié)點(diǎn)啟動(dòng)，也需要確保它不能再認(rèn)為自己是主節(jié)點(diǎn)，從而承擔(dān)寫請求。
問題
雖然上述三個(gè)步驟較為清晰，但在實(shí)際發(fā)生時(shí)，還會(huì)存在一些問題：
- 假設(shè)采用異步復(fù)制，在失效前，新的主節(jié)點(diǎn)與原主節(jié)點(diǎn)的數(shù)據(jù)存在Gap，選舉完成后，原主節(jié)點(diǎn)很快重新上線加入到集群，這時(shí)新的主節(jié)點(diǎn)可能會(huì)收到?jīng)_突的寫請求，此時(shí)還未完全執(zhí)行上述步驟的第三步，也就是原主節(jié)點(diǎn)沒有意識到自己的角色發(fā)生變化，還會(huì)嘗試向新主節(jié)點(diǎn)同步數(shù)據(jù)。這時(shí)，一般的做法是，將原主節(jié)點(diǎn)上未完成復(fù)制的寫請求丟掉，但這又可能會(huì)發(fā)生數(shù)據(jù)丟失或不一致，假設(shè)我們每條數(shù)據(jù)采用MySQL的自增ID作為主鍵，并且使用Redis作為緩存，假設(shè)發(fā)生了MySQL的主從切換，從節(jié)點(diǎn)的計(jì)數(shù)器落后于主節(jié)點(diǎn)，那樣可能出現(xiàn)應(yīng)用獲取到舊的自增ID，這樣就會(huì)與Redis上對應(yīng)ID取到的數(shù)據(jù)不一致，出現(xiàn)數(shù)據(jù)泄露或丟失。
- 假設(shè)上面的問題，原主節(jié)點(diǎn)因?yàn)橐恍┕收嫌肋h(yuǎn)不知道自己角色已經(jīng)變更，則可能發(fā)生“腦裂”，兩個(gè)節(jié)點(diǎn)同時(shí)操作數(shù)據(jù)，又沒有相應(yīng)解決沖突（沒有設(shè)計(jì)這一模塊），就有可能對數(shù)據(jù)造成破壞。
- 此外，對于超時(shí)時(shí)間的設(shè)定也是個(gè)十分復(fù)雜的問題，過長會(huì)導(dǎo)致服務(wù)不可用，設(shè)置過短則會(huì)導(dǎo)致節(jié)點(diǎn)頻繁切換，假設(shè)本身系統(tǒng)處于高負(fù)載狀態(tài)，頻繁角色切換會(huì)讓負(fù)載進(jìn)一步加重（團(tuán)隊(duì)內(nèi)部對Kafka僵尸節(jié)點(diǎn)的處理邏輯）。
異步復(fù)制面臨的主要問題——復(fù)制滯后
如前文所述，如果我們使用純的同步復(fù)制，任何一臺(tái)機(jī)器發(fā)生故障都會(huì)導(dǎo)致服務(wù)不可寫入，并且在數(shù)較多的情況下，吞吐和可用性都會(huì)受到比較大的影響。很多系統(tǒng)都會(huì)采用半步復(fù)制或異步復(fù)制來在可用性和一致性之間做權(quán)衡。在異步復(fù)制中，由于寫請求寫到主副本就返回成功，在數(shù)據(jù)復(fù)制到其他副本的過程中，如果客戶端進(jìn)行讀取，在不同副本讀取到的數(shù)據(jù)可能會(huì)不一致，《DDIA》將這個(gè)種現(xiàn)象稱為復(fù)制滯后（Replication Lag），存在這種問題的復(fù)制行為所形成的數(shù)據(jù)一致性統(tǒng)稱為最終一致性。未來還會(huì)重點(diǎn)介紹一下一致性和共識，但在本文不做過多的介紹，感興趣的同學(xué)可以提前閱讀《Problems with Replication Lag》這一章節(jié)。
2.2 多主節(jié)點(diǎn)復(fù)制
前文介紹的主從復(fù)制模型中存在一個(gè)比較嚴(yán)重的弊端，就是所有寫請求都需要經(jīng)過主節(jié)點(diǎn)，因?yàn)橹淮嬖谝粋€(gè)主節(jié)點(diǎn)，就很容易出現(xiàn)性能問題。雖然有從節(jié)點(diǎn)作為冗余應(yīng)對容錯(cuò)，但對于寫入請求實(shí)際上這種復(fù)制方式是不具備擴(kuò)展性的。
此外，如果客戶端來源于多個(gè)地域，不同客戶端所感知到的服務(wù)相應(yīng)時(shí)間差距會(huì)非常大。因此，有些系統(tǒng)順著傳統(tǒng)主從復(fù)制進(jìn)行延伸，采用多個(gè)主節(jié)點(diǎn)同時(shí)承擔(dān)寫請求，主節(jié)點(diǎn)接到寫入請求之后將數(shù)據(jù)同步到從節(jié)點(diǎn)，不同的是，這個(gè)主節(jié)點(diǎn)可能還是其他節(jié)點(diǎn)的從節(jié)點(diǎn)。復(fù)制模式如下圖所示，可以看到兩個(gè)主節(jié)點(diǎn)在接到寫請求后，將數(shù)據(jù)同步到同一個(gè)數(shù)據(jù)中心的從節(jié)點(diǎn)。此外，該主節(jié)點(diǎn)還將不斷同步在另一數(shù)據(jù)中心節(jié)點(diǎn)上的數(shù)據(jù)，由于每個(gè)主節(jié)點(diǎn)同時(shí)處理其他主節(jié)點(diǎn)的數(shù)據(jù)和客戶端寫入的數(shù)據(jù)，因此需要模型中增加一個(gè)沖突處理模塊，最后寫到主節(jié)點(diǎn)的數(shù)據(jù)需要解決沖突。
圖3 多主節(jié)點(diǎn)復(fù)制
使用場景
a. 多數(shù)據(jù)中心部署
一般采用多主節(jié)點(diǎn)復(fù)制，都是為了做多數(shù)據(jù)中心容災(zāi)或讓客戶端就近訪問（用一個(gè)高大上的名詞叫做異地多活），在同一個(gè)地域使用多主節(jié)點(diǎn)意義不大，在多個(gè)地域或者數(shù)據(jù)中心部署相比主從復(fù)制模型有如下的優(yōu)勢：
- 性能提升：性能提升主要表現(xiàn)在兩個(gè)核心指標(biāo)上，首先從吞吐方面，傳統(tǒng)的主從模型所有寫請求都會(huì)經(jīng)過主節(jié)點(diǎn)，主節(jié)點(diǎn)如果無法采用數(shù)據(jù)分區(qū)的方式進(jìn)行負(fù)載均衡，可能存在性能瓶頸，采用多主節(jié)點(diǎn)復(fù)制模式下，同一份數(shù)據(jù)就可以進(jìn)行負(fù)載均衡，可以有效地提升吞吐。另外，由于多個(gè)主節(jié)點(diǎn)分布在多個(gè)地域，處于不同地域的客戶端可以就近將請求發(fā)送到對應(yīng)數(shù)據(jù)中心的主節(jié)點(diǎn)，可以最大程度地保證不同地域的客戶端能夠以相似的延遲讀寫數(shù)據(jù)，提升用戶的使用體驗(yàn)。
- 容忍數(shù)據(jù)中心失效：對于主從模式，假設(shè)主節(jié)點(diǎn)所在的數(shù)據(jù)中心發(fā)生網(wǎng)絡(luò)故障，需要發(fā)生一次節(jié)點(diǎn)切換才可將流量全部切換到另一個(gè)數(shù)據(jù)中心，而采用多主節(jié)點(diǎn)模式，則可無縫切換到新的數(shù)據(jù)中心，提升整體服務(wù)的可用性。
b. 離線客戶端操作
除了解決多個(gè)地域容錯(cuò)和就近訪問的問題，還有一些有趣的場景，其中一個(gè)場景則是在網(wǎng)絡(luò)離線的情況下還能繼續(xù)工作，例如我們筆記本電腦上的筆記或備忘錄，我們不能因?yàn)榫W(wǎng)絡(luò)離線就禁止使用該程序，我們依然可以在本地愉快的編輯內(nèi)容（圖中標(biāo)記為Offline狀態(tài)），當(dāng)我們連上網(wǎng)之后，這些內(nèi)容又會(huì)同步到遠(yuǎn)程的節(jié)點(diǎn)上，這里面我們把本地的App也當(dāng)做其中的一個(gè)副本，那么就可以承擔(dān)用戶在本地的變更請求。聯(lián)網(wǎng)之后，再同步到遠(yuǎn)程的主節(jié)點(diǎn)上。
圖4 Notion界面
c. 協(xié)同編輯
這里我們對離線客戶端操作進(jìn)行擴(kuò)展，假設(shè)我們所有人同時(shí)編輯一個(gè)文檔，每個(gè)人通過Web客戶端編輯的文檔都可以看做一個(gè)主節(jié)點(diǎn)。這里我們拿美團(tuán)內(nèi)部的學(xué)城（內(nèi)部的Wiki系統(tǒng)）舉例，當(dāng)我們正在編輯一份文檔的時(shí)候，基本上都會(huì)發(fā)現(xiàn)右上角會(huì)出現(xiàn)“xxx也在協(xié)同編輯文檔”的字樣，當(dāng)我們保存的時(shí)候，系統(tǒng)就會(huì)自動(dòng)將數(shù)據(jù)保存到本地并復(fù)制到其他主節(jié)點(diǎn)上，各自處理各自端上的沖突。
另外，當(dāng)文檔出現(xiàn)了更新時(shí)，學(xué)城會(huì)通知我們有更新，需要我們手動(dòng)點(diǎn)擊更新，來更新我們本地主節(jié)點(diǎn)的數(shù)據(jù)。書中說明，雖然不能將協(xié)同編輯完全等同于數(shù)據(jù)庫復(fù)制，但卻是有很多相似之處，也需要處理沖突問題。
沖突解決
通過上面的分析，我們了解到多主復(fù)制模型最大挑戰(zhàn)就是解決沖突，下面我們簡單看下《DDIA》中給出的通用解法，在介紹之前，我們先來看一個(gè)典型的沖突。
a. 沖突實(shí)例
圖5 沖突實(shí)例
在圖中，由于多主節(jié)點(diǎn)采用異步復(fù)制，用戶將數(shù)據(jù)寫入到自己的網(wǎng)頁就返回成功了，但當(dāng)嘗試把數(shù)據(jù)復(fù)制到另一個(gè)主節(jié)點(diǎn)時(shí)就會(huì)出問題，這里我們?nèi)绻僭O(shè)主節(jié)點(diǎn)更新時(shí)采用類似CAS的更新方式時(shí)更新時(shí)，都會(huì)由于預(yù)期值不符合從而拒絕更新。針對這樣的沖突，書中給出了幾種常見的解決思路。
b. 解決思路
1. 避免沖突
所謂解決問題最根本的方式則是盡可能不讓它發(fā)生，如果能夠在應(yīng)用層保證對特定數(shù)據(jù)的請求只發(fā)生在一個(gè)節(jié)點(diǎn)上，這樣就沒有所謂的“寫沖突”了。繼續(xù)拿上面的協(xié)同編輯文檔舉例，如果我們把每個(gè)人的都在填有自己姓名表格的一行里面進(jìn)行編輯，這樣就可以最大程度地保證每個(gè)人的修改范圍不會(huì)有重疊，沖突也就迎刃而解了
2. 收斂于一致狀態(tài)
然而，對更新標(biāo)題這種情況而言，沖突是沒法避免的，但還是需要有方法解決。對于單主節(jié)點(diǎn)模式而言，如果同一個(gè)字段有多次寫入，那么最后寫入的一定是最新的。ZK、KafkaController、KafkaReplica都有類似Epoch的方式去屏蔽過期的寫操作，由于所有的寫請求都經(jīng)過同一個(gè)節(jié)點(diǎn)，順序是絕對的，但對于多主節(jié)點(diǎn)而言，由于沒有絕對順序的保證，就只能試圖用一些方式來決策相對順序，使沖突最終收斂，這里提到了幾種方法：
給每個(gè)寫請求分配Uniq-ID，例如一個(gè)時(shí)間戳，一個(gè)隨機(jī)數(shù)，一個(gè)UUID或Hash值，最終取最高的ID作為最新的寫入。如果基于時(shí)間戳，則稱作最后寫入者獲勝（LWW），這種方式看上去非常直接且簡單，并且非常流行。但很遺憾，文章一開始也提到了，分布式系統(tǒng)沒有辦法在機(jī)器間共享一套統(tǒng)一的系統(tǒng)時(shí)間，所以這個(gè)方案很有可能因?yàn)檫@個(gè)問題導(dǎo)致數(shù)據(jù)丟失（時(shí)鐘漂移）。
每個(gè)副本分配一個(gè)唯一的ID，ID高的更新優(yōu)先級高于地域低的，這顯然也會(huì)丟失數(shù)據(jù)。當(dāng)然，我們可以用某種方式做拼接，或利用預(yù)先定義的格式保留沖突相關(guān)信息，然后由用戶自行解決。
3. 用戶自行處理
其實(shí)，把這個(gè)操作直接交給用戶，讓用戶自己在讀取或?qū)懭肭斑M(jìn)行沖突解決，這種例子也是屢見不鮮，Github采用就是這種方式。
這里只是簡單舉了一些沖突的例子，其實(shí)沖突的定義是一個(gè)很微妙的概念?！禗DIA》第七章介紹了更多關(guān)于沖突的概念，感興趣同學(xué)可以先自行閱讀，在下一篇文章中也會(huì)提到這個(gè)問題。
c. 處理細(xì)節(jié)介紹
此外，在書中將要結(jié)束《復(fù)制》這一章時(shí)，也詳細(xì)介紹了如何進(jìn)行沖突的處理，這里也簡單進(jìn)行介紹。這里我們可以思考一個(gè)問題，為什么會(huì)發(fā)生沖突？通過閱讀具體的處理手段后，我們可以嘗試這樣理解，正是因?yàn)槲覀儗κ录l(fā)生的先后順序不確定，但這些事件的處理主體都有重疊（比如都有設(shè)置某個(gè)數(shù)據(jù)的值）。通過我們對沖突的理解，加上我們的常識推測，會(huì)有這樣幾種方式可以幫我們來判斷事件的先后順序。
1. 直接指定事件順序
對于事件發(fā)生的先后順序，我們一個(gè)最直觀的想法就是，兩個(gè)請求誰新要誰的，那這里定義“最新”是個(gè)問題，一個(gè)很簡單的方式是使用時(shí)間戳，這種算法叫做最后寫入者獲勝LWW。
但分布式系統(tǒng)中沒有統(tǒng)一的系統(tǒng)時(shí)鐘，不同機(jī)器上的時(shí)間戳無法保證精確同步，那就可能存在數(shù)據(jù)丟失的風(fēng)險(xiǎn)，并且由于數(shù)據(jù)是覆蓋寫，可能不會(huì)保留中間值，那么最終可能也不是一致的狀態(tài)，或出現(xiàn)數(shù)據(jù)丟失。如果是一些緩存系統(tǒng)，覆蓋寫看上去也是可以的，這種簡單粗暴的算法是非常好的收斂沖突的方式，但如果我們對數(shù)據(jù)一致性要求較高，則這種方式就會(huì)引入風(fēng)險(xiǎn)，除非數(shù)據(jù)寫入一次后就不會(huì)發(fā)生改變。
2. 從事件本身推斷因果關(guān)系和并發(fā)
上面直接簡單粗暴的制定很明顯過于武斷，那么有沒有可能時(shí)間里面就存在一些因果關(guān)系呢，如果有我們很顯然可以通過因果關(guān)系知道到底需要怎樣的順序，如果不行再通過指定的方式呢？例如：
圖6 違背因果關(guān)系示例
這里是書中一個(gè)多主節(jié)點(diǎn)復(fù)制的例子，這里ClientA首先向Leader1增加一條數(shù)據(jù)x=1，然Leader1采用異步復(fù)制的方式，將變更日志發(fā)送到其他的Leader上。在復(fù)制過程中，ClientB向Leader3發(fā)送了更新請求，內(nèi)容則是更新Key為x的Value，使Value=Value+1。
原圖中想表達(dá)的是，update的日志發(fā)送到Leader2的時(shí)間早于insert日志發(fā)送到Leader2的時(shí)間，會(huì)導(dǎo)致更新的Key不存在。但是，這種所謂的事件關(guān)系本身就不是完全不相干的，書中稱這種關(guān)系為依賴或者Happens-before。
我們可能在JVM的內(nèi)存模型（JMM）中聽到過這個(gè)詞，在JMM中，表達(dá)的也是多個(gè)線程操作的先后順序關(guān)系。這里，如果我們把線程或者請求理解為對數(shù)據(jù)的操作（區(qū)別在于一個(gè)是對本地內(nèi)存數(shù)據(jù)，另一個(gè)是對遠(yuǎn)程的某處內(nèi)存進(jìn)行修改），線程或客戶端都是一種執(zhí)行者（區(qū)別在于是否需要使用網(wǎng)絡(luò)），那這兩種Happens-before也就可以在本質(zhì)上進(jìn)行統(tǒng)一了，都是為了描述事件的先后順序而生。
書中給出了檢測這類事件的一種算法，并舉了一個(gè)購物車的例子，如圖所示（以餐廳掃碼點(diǎn)餐的場景為例）：
圖7 掃碼點(diǎn)餐示例
圖中兩個(gè)客戶端同時(shí)向購物車?yán)锓艝|西，事例中的數(shù)據(jù)庫假設(shè)只有一個(gè)副本。
- 首先Client1向購物車中添加牛奶，此時(shí)購物車為空，返回版本1，Value為[牛奶]。
- 此時(shí)Client2向其中添加雞蛋，其并不知道Client1添加了牛奶，但服務(wù)器可以知道，因此分配版本號為2，并且將雞蛋和牛奶存成兩個(gè)單獨(dú)的值，最后將兩個(gè)值和版本號2返回給客戶端。此時(shí)服務(wù)端存儲(chǔ)了[雞蛋] 2 [牛奶]1。
- 同理，Client1添加面粉，這時(shí)候Client1只認(rèn)為添加了[牛奶]，因此將面粉與牛奶合并發(fā)送給服務(wù)端[牛奶，面粉]，同時(shí)還附帶了之前收到的版本號1，此時(shí)服務(wù)端知道，新值[牛奶，面粉]可以替換同一個(gè)版本號中的舊值[牛奶]，但[雞蛋]是并發(fā)事件，分配版本號3，返回值[牛奶，面粉] 3 [雞蛋]2。
- 同理，Client2向購物車添加[火腿]，但在之前的請求中，返回了[雞蛋][牛奶]，因此和火腿合并發(fā)送給服務(wù)端[雞蛋，牛奶，火腿]，同時(shí)附帶了版本號2，服務(wù)端直接將新值覆蓋之前版本2的值[雞蛋]，但[牛奶，面粉]是并發(fā)事件，因此存儲(chǔ)值為[牛奶，面粉] 3 [雞蛋，牛奶，火腿] 4并分配版本號4。
- 最后一次Client添加培根，通過之前返回的值里，知道有[牛奶，面粉，雞蛋]，Client將值合并[牛奶，面粉，雞蛋，培根]聯(lián)通之前的版本號一起發(fā)送給服務(wù)端，服務(wù)端判斷[牛奶，面粉，雞蛋，培根]可以覆蓋之前的[牛奶，面粉]但[雞蛋，牛奶，火腿]是并發(fā)值，加以保留。
通過上面的例子，我們看到了一個(gè)根據(jù)事件本身進(jìn)行因果關(guān)系的確定。書中給出了進(jìn)一步的抽象流程：
- 服務(wù)端為每個(gè)主鍵維護(hù)一個(gè)版本號，每當(dāng)主鍵新值寫入時(shí)遞增版本號，并將新版本號和寫入值一起保存。
- 客戶端寫主鍵，寫請求比包含之前讀到的版本號，發(fā)送的值為之前請求讀到的值和新值的組合，寫請求的相應(yīng)也會(huì)返回對當(dāng)前所有的值，這樣就可以一步步進(jìn)行拼接。
- 當(dāng)服務(wù)器收到有特定版本號的寫入時(shí)，覆蓋該版本號或更低版本號的所有值，保留高于請求中版本號的新值（與當(dāng)前寫操作屬于并發(fā)）。
有了這套算法，我們就可以檢測出事件中有因果關(guān)系的事件與并發(fā)的事件，而對于并發(fā)的事件，仍然像上文提到的那樣，需要依據(jù)一定的原則進(jìn)行合并，如果使用LWW，依然可能存在數(shù)據(jù)丟失的情況。因此，需要在服務(wù)端程序的合并邏輯中需要額外做些事情。
在購物車這個(gè)例子中，比較合理的是合并新值和舊值，即最后的值是[牛奶，雞蛋，面粉，火腿，培根]，但這樣也會(huì)導(dǎo)致一個(gè)問題，假設(shè)其中的一個(gè)用戶刪除了一項(xiàng)商品，但是union完還是會(huì)出現(xiàn)在最終的結(jié)果中，這顯然不符合預(yù)期。因此可以用一個(gè)類似的標(biāo)記位，標(biāo)記記錄的刪除，這樣在合并時(shí)可以將這個(gè)商品踢出，這個(gè)標(biāo)記在書中被稱為墓碑（Tombstone）。
2.3 無主節(jié)點(diǎn)復(fù)制
之前介紹的復(fù)制模式都是存在明確的主節(jié)點(diǎn)，從節(jié)點(diǎn)的角色劃分的，主節(jié)點(diǎn)需要將數(shù)據(jù)復(fù)制到從節(jié)點(diǎn)，所有寫入的順序由主節(jié)點(diǎn)控制。但有些系統(tǒng)干脆放棄了這個(gè)思路，去掉了主節(jié)點(diǎn)，任何副本都能直接接受來自客戶端的寫請求，或者再有一些系統(tǒng)中，會(huì)給到一個(gè)協(xié)調(diào)者代表客戶端進(jìn)行寫入（以Group Commit為例，由一個(gè)線程積攢所有客戶端的請求統(tǒng)一發(fā)送），與多主模式不同，協(xié)調(diào)者不負(fù)責(zé)控制寫入順序，這個(gè)限制的不同會(huì)直接影響系統(tǒng)的使用方式。
處理節(jié)點(diǎn)失效
假設(shè)一個(gè)數(shù)據(jù)系統(tǒng)擁有三個(gè)副本，當(dāng)其中一個(gè)副本不可用時(shí)，在主從模式中，如果恰好是主節(jié)點(diǎn)，則需要進(jìn)行節(jié)點(diǎn)切換才能繼續(xù)對外提供服務(wù)，但在無主模式下，并不存在這一步驟，如下圖所示：
圖8 Quorum寫入處理節(jié)點(diǎn)失效
這里的Replica3在某一時(shí)刻無法提供服務(wù)，此時(shí)用戶可以收到兩個(gè)Replica的寫入成功的確認(rèn)，即可認(rèn)為寫入成功，而完全可以忽略那個(gè)無法提供服務(wù)的副本。當(dāng)失效的節(jié)點(diǎn)恢復(fù)時(shí)，會(huì)重新提供讀寫服務(wù)，此時(shí)如果客戶端向這個(gè)副本讀取數(shù)據(jù)，就會(huì)請求到過期值。為了解決這個(gè)問題，這里客戶端就不是簡單向一個(gè)節(jié)點(diǎn)請求數(shù)據(jù)了，而是向所有三個(gè)副本請求，這時(shí)可能會(huì)收到不同的響應(yīng)，這時(shí)可以通過類似版本號來區(qū)分?jǐn)?shù)據(jù)的新舊（類似上文中并發(fā)寫入的檢測方式）。這里可能有一個(gè)問題，副本恢復(fù)之后難道就一直讓自己落后于其他副本嗎？這肯定不行，這會(huì)打破一致性的語義，因此需要一個(gè)機(jī)制。有兩種思路：
- 客戶端讀取時(shí)對副本做修復(fù)，如果客戶端通過并行讀取多個(gè)副本時(shí)，讀到了過期的數(shù)據(jù)，可以將數(shù)據(jù)寫入到舊副本中，以便追趕上新副本。
- 反熵查詢，一些系統(tǒng)在副本啟動(dòng)后，后臺(tái)會(huì)不斷查找副本之間的數(shù)據(jù)diff，將diff寫到自己的副本中，與主從復(fù)制模式不同的是，此過程不保證寫入的順序，并可能引發(fā)明顯的復(fù)制滯后。
讀寫Quorum
上文中的實(shí)例我們可以看出，這種復(fù)制模式下，要想保證讀到的是寫入的新值，每次只從一個(gè)副本讀取顯然是有問題的，那么需要每次寫幾個(gè)副本呢，又需要讀取幾個(gè)副本呢？這里的一個(gè)核心點(diǎn)就是讓寫入的副本和讀取的副本有交集，那么我們就能夠保證讀到新值了。
直接上公式： 。其中N為副本的數(shù)量，w為每次并行寫入的節(jié)點(diǎn)數(shù)，r為每次同時(shí)讀取的節(jié)點(diǎn)數(shù)，這個(gè)公式非常容易理解，就不做過多贅述。不過這里的公式雖然看著比較直白也簡單，里面卻蘊(yùn)含了一些系統(tǒng)設(shè)計(jì)思考：
- 一般配置方法，取
- w，r與N的關(guān)系決定了能夠容忍多少的節(jié)點(diǎn)失效
- 假設(shè)N=3, w=2, r=2，可以容忍1個(gè)節(jié)點(diǎn)故障。
- 假設(shè)N=5，w=3, r=3 可以容忍2個(gè)節(jié)點(diǎn)故障。
- N個(gè)節(jié)點(diǎn)可以容忍可以容忍個(gè)節(jié)點(diǎn)故障。
- 在實(shí)際實(shí)現(xiàn)中，一般數(shù)據(jù)會(huì)發(fā)送或讀取所有節(jié)點(diǎn)，w和r決定了我們需要等待幾個(gè)節(jié)點(diǎn)的寫入或讀取確認(rèn)。
Quorum一致性的局限性
看上去這個(gè)簡單的公式就可以實(shí)現(xiàn)很強(qiáng)大的功能，但這里有一些問題值得注意：
- 首先，Quorum并不是一定要求多數(shù)，重要的是讀取的副本和寫入副本有重合即可，可以按照讀寫的可用性要求酌情考慮配置。
- 另外，對于一些沒有很強(qiáng)一致性要求的系統(tǒng)，可以配置w+r <= N，這樣可以等待更少的節(jié)點(diǎn)即可返回，這樣雖然有可能讀取到一個(gè)舊值，但這種配置可以很大提升系統(tǒng)的可用性，當(dāng)網(wǎng)絡(luò)大規(guī)模故障時(shí)更有概率讓系統(tǒng)繼續(xù)運(yùn)行而不是由于沒有達(dá)到Quorum限制而返回錯(cuò)誤。
- 假設(shè)在w+r>N的情況下，實(shí)際上也存在邊界問題導(dǎo)致一些一致性問題：
首先假設(shè)是Sloppy Quorum（一個(gè)更為寬松的Quorum算法），寫入的w和讀取的r可能完全不相交，因此不能保證數(shù)據(jù)一定是新的。
如果兩個(gè)寫操作同時(shí)發(fā)生，那么還是存在沖突，在合并時(shí)，如果基于LWW，仍然可能導(dǎo)致數(shù)據(jù)丟失。
如果寫讀同時(shí)發(fā)生，也不能保證讀請求一定就能取到新值，因?yàn)閺?fù)制具有滯后性（上文的復(fù)制窗口）。
如果某些副本寫入成功，其他副本寫入失敗（磁盤空間滿）且總的成功數(shù)少于w，那些成功的副本數(shù)據(jù)并不會(huì)回滾，這意味著及時(shí)寫入失敗，后續(xù)還是可能讀到新值。
雖然，看上去Quorum復(fù)制模式可以保證獲取到新值，但實(shí)際情況并不是我們想象的樣子，這個(gè)協(xié)議到最后可能也只能達(dá)到一個(gè)最終的一致性，并且依然需要共識算法的加持。
2.4 本章小結(jié)
以上我們介紹了所有常見的復(fù)制模式，我們可以看到，每種模式都有一定的應(yīng)用場景和優(yōu)缺點(diǎn)，但是很明顯，光有復(fù)制模式遠(yuǎn)遠(yuǎn)達(dá)不到數(shù)據(jù)的一致性，因?yàn)榉植际较到y(tǒng)中擁有太多的不確定性，需要后面各種事務(wù)、共識算法的幫忙才能去真正對抗那些“稀奇古怪”的問題。到這里，可能會(huì)有同學(xué)就會(huì)問，到底都是些什么稀奇古怪的問題呢？相比單機(jī)系統(tǒng)又有那些獨(dú)特的問題呢？下面本文先來介紹分布式系統(tǒng)中的幾個(gè)最典型的挑戰(zhàn)（Trouble），讓一些同學(xué)小小地“絕望”一下，然后我們會(huì)下一篇文章中再揭曉答案。
3. 分布式系統(tǒng)的挑戰(zhàn)
這部分存在的意義主要想讓大家理解，為什么一些看似簡單的問題到了分布式系統(tǒng)中就會(huì)變得異常復(fù)雜。順便說一聲，這一章都是一些“奇葩”現(xiàn)象，并沒有過于復(fù)雜的推理和證明，希望大家能夠較為輕松愉悅地看完這些內(nèi)容。
3.1 部分失效
這是分布式系統(tǒng)中特有的一個(gè)名詞，這里先看一個(gè)現(xiàn)實(shí)當(dāng)中的例子。假設(shè)老板想要處理一批文件，如果讓一個(gè)人做，需要十天。但老板覺得有點(diǎn)慢，于是他靈機(jī)一動(dòng)，想到可以找十個(gè)人來搞定這件事，然后自己把工作安排好，認(rèn)為這十個(gè)人一天正好干完，于是向他的上級信誓旦旦地承諾一天搞定這件事。他把這十個(gè)人叫過來，把任務(wù)分配給了他們，他們彼此建了個(gè)微信群，約定每個(gè)小時(shí)在群里匯報(bào)自己手上的工作進(jìn)度，并強(qiáng)調(diào)在晚上5點(diǎn)前需要通過郵件提交最后的結(jié)果。于是老版就去愉快的喝茶去了，但是現(xiàn)實(shí)卻讓他大跌眼鏡。
首先，有個(gè)同學(xué)家里信號特別差，報(bào)告進(jìn)度的時(shí)候只成功報(bào)告了3個(gè)小時(shí)的，然后老板在微信里問，也收不到任何回復(fù)，最后結(jié)果也沒法提交。另一個(gè)同學(xué)家的表由于長期沒換電池，停在了下午四點(diǎn)，結(jié)果那人看了兩次表都是四點(diǎn)，所以一點(diǎn)都沒著急，中間還看了個(gè)電影，慢慢悠悠做完交上去了，他還以為老板會(huì)表揚(yáng)他，提前了一小時(shí)交，結(jié)果實(shí)際上已經(jīng)是晚上八點(diǎn)了。還有一個(gè)同學(xué)因?yàn)榍耙惶鞗]睡好，效率極低，而且也沒辦法再去高強(qiáng)度的工作了。結(jié)果到了晚上5點(diǎn)，只有7個(gè)人完成了自己手頭上的工作。
這個(gè)例子可能看起來并不是非常恰當(dāng)，但基本可以描述分布式系統(tǒng)特有的問題了。在分布式的系統(tǒng)中，我們會(huì)遇到各種“稀奇古怪”的故障，例如家里沒信號（網(wǎng)絡(luò)故障)，不管怎么叫都不理你，或者斷斷續(xù)續(xù)的理你。另外，因?yàn)槊總€(gè)人都是通過自己家的表看時(shí)間的，所謂的5點(diǎn)需要提交結(jié)果，在一定程度上舊失去了參考的絕對價(jià)值。因此，作為上面例子中的“老板”，不能那么自信的認(rèn)為一個(gè)人干工作需要10天，就可以放心交給10個(gè)人，讓他們一天搞定。
我們需要有各種措施來應(yīng)對分派任務(wù)帶來的不確定性，回到分布式系統(tǒng)中，部分失效是分布式系統(tǒng)一定會(huì)出現(xiàn)的情況。作為系統(tǒng)本身的設(shè)計(jì)人員，我們所設(shè)計(jì)的系統(tǒng)需要能夠容忍這種問題，相對單機(jī)系統(tǒng)來說，這就帶來了特有的復(fù)雜性。
3.2 分布式系統(tǒng)特有的故障
不可靠的網(wǎng)絡(luò)
對于一個(gè)純的分布式系統(tǒng)而言，它的架構(gòu)大多為Share Nothing架構(gòu)，即使是存算分離這種看似的Share Storage，它的底層存儲(chǔ)一樣是需要解決Share Nothing的。所謂Nothing，這里更傾向于叫Nothing but Network，網(wǎng)絡(luò)是不同節(jié)點(diǎn)間共享信息的唯一途徑，數(shù)據(jù)的傳輸主要通過以太網(wǎng)進(jìn)行傳輸，這是一種異步網(wǎng)絡(luò)，也就是網(wǎng)絡(luò)本身并不保證發(fā)出去的數(shù)據(jù)包一定能被接到或是何時(shí)被收到。這里可能發(fā)生各種錯(cuò)誤，如下圖所示：
圖9 不可靠的網(wǎng)絡(luò)
- 請求丟失
- 請求正在某個(gè)隊(duì)列中等待
- 遠(yuǎn)程節(jié)點(diǎn)已經(jīng)失效
- 遠(yuǎn)程節(jié)點(diǎn)無法響應(yīng)
- 遠(yuǎn)程節(jié)點(diǎn)已經(jīng)處理完請求，但在ack的時(shí)候丟包
- 遠(yuǎn)程接收節(jié)點(diǎn)已經(jīng)處理完請求，但回復(fù)處理很慢
本文認(rèn)為，造成網(wǎng)絡(luò)不可靠的原因不光是以太網(wǎng)和IP包本身，其實(shí)應(yīng)用本身有時(shí)候異常也是造成網(wǎng)絡(luò)不可靠的一個(gè)誘因。因?yàn)?，我們所采用的?jié)點(diǎn)間傳輸協(xié)議大多是TCP，TCP是個(gè)端到端的協(xié)議，是需要發(fā)送端和接收端兩端內(nèi)核中明確維護(hù)數(shù)據(jù)結(jié)構(gòu)來維持連接的，如果應(yīng)用層發(fā)生了下面的問題，那么網(wǎng)絡(luò)包就會(huì)在內(nèi)核的Socket Buffer中排隊(duì)得不到處理，或響應(yīng)得不到處理。
- 應(yīng)用程序GC。
- 處理節(jié)點(diǎn)在進(jìn)行重的磁盤I/O，導(dǎo)致CPU無法從中斷中恢復(fù)從而無法處理網(wǎng)絡(luò)請求。
- 由于內(nèi)存換頁導(dǎo)致的顛簸。
這些問題和網(wǎng)絡(luò)本身的不穩(wěn)定性相疊加，使得外界認(rèn)為的網(wǎng)絡(luò)不靠譜的程度更加嚴(yán)重。因此這些不靠譜，會(huì)極大地加重上一章中的 復(fù)制滯后性，進(jìn)而帶來各種各樣的一致性問題。
應(yīng)對之道
網(wǎng)絡(luò)異常相比其他單機(jī)上的錯(cuò)誤而言，可能多了一種不確定的返回狀態(tài)，即延遲，而且延遲的時(shí)間完全無法預(yù)估。這會(huì)讓我們寫起程序來異常頭疼，對于上一章中的問題，我們可能無從知曉節(jié)點(diǎn)是否失效，因?yàn)槟惆l(fā)的請求壓根可能不會(huì)有人響應(yīng)你。因此，我們需要把上面的“不確定”變成一種確定的形式，那就是利用“超時(shí)”機(jī)制。這里引申出兩個(gè)問題：
1. 假設(shè)能夠檢測出失效，我們應(yīng)該如何應(yīng)對？
a. 負(fù)載均衡需要避免往失效的節(jié)點(diǎn)上發(fā)數(shù)據(jù)（服務(wù)發(fā)現(xiàn)模塊中的健康檢查功能）。
b. 如果在主從復(fù)制中，如果主節(jié)點(diǎn)失效，需要出發(fā)選舉機(jī)制（Kafka中的臨時(shí)節(jié)點(diǎn)掉線，Controller監(jiān)聽到變更觸發(fā)新的選舉，Controller本身的選舉機(jī)制）。
c. 如果服務(wù)進(jìn)程崩潰，但操作系統(tǒng)運(yùn)行正常，可以通過腳本通知其他節(jié)點(diǎn)，以便新的節(jié)點(diǎn)來接替（Kafka的僵尸節(jié)點(diǎn)檢測，會(huì)觸發(fā)強(qiáng)制的臨時(shí)節(jié)點(diǎn)掉線）。
d. 如果路由器已經(jīng)確認(rèn)目標(biāo)節(jié)點(diǎn)不可訪問，則會(huì)返回ICMP不可達(dá)（ping不通走下線）。
2. 如何設(shè)置超時(shí)時(shí)間是合理的？
很遺憾地告訴大家，這里面實(shí)際上是個(gè)權(quán)衡的問題，短的超時(shí)時(shí)間會(huì)更快地發(fā)現(xiàn)故障，但同時(shí)增加了誤判的風(fēng)險(xiǎn)。這里假設(shè)網(wǎng)絡(luò)正常，那么如果端到端的ping時(shí)間為d，處理時(shí)間為r，那么基本上請求會(huì)在2d+r的時(shí)間完成。但在現(xiàn)實(shí)中，我們無法假設(shè)異步網(wǎng)絡(luò)的具體延遲，實(shí)際情況可能會(huì)更復(fù)雜。因此這是一個(gè)十分靠經(jīng)驗(yàn)的工作。
3.2 不可靠的時(shí)鐘
說完了“信號”的問題，下面就要說說每家的“鐘表”——時(shí)鐘了，它主要用來做兩件事：
- 描述當(dāng)前的絕對時(shí)間
- 描述某件事情的持續(xù)時(shí)間
在DDIA中，對于這兩類用途給出了兩種時(shí)間，一類成為墻上時(shí)鐘，它們會(huì)返回當(dāng)前的日期和時(shí)間，例如clock_gettime(CLOCK_REALTIME) 或者System.currentTimeMills，但這類反應(yīng)精確時(shí)間的API，由于時(shí)鐘同步的問題，可能會(huì)出現(xiàn)回?fù)艿那闆r。因此，作為持續(xù)時(shí)間的測量通常采用單調(diào)時(shí)鐘，例如clock_gettime(CLOCK_MONOTONIC) 或者System.nanoTime。高版本的Kafka中把請求的相應(yīng)延遲計(jì)算全部換成了這個(gè)API實(shí)現(xiàn)，應(yīng)該也是這個(gè)原因。
這里時(shí)鐘同步的具體原理，以及如何會(huì)出現(xiàn)不準(zhǔn)確的問題，這里就不再詳細(xì)介紹了，感興趣的同學(xué)可以自行閱讀書籍。下面將介紹一下如何使用時(shí)間戳來描述事件順序的案例，并展示如何因時(shí)鐘問題導(dǎo)致事件順序判斷異常的：
圖10 不可靠的時(shí)鐘
這里我們發(fā)現(xiàn)，Node1的時(shí)鐘比Node3快，當(dāng)兩個(gè)節(jié)點(diǎn)在處理完本地請求準(zhǔn)備寫Node2時(shí)發(fā)生了問題，原本ClientB的寫入明顯晚于ClientA的寫入，但最終的結(jié)果，卻由于Node1的時(shí)間戳更大而丟棄了本該保留的x+=1，這樣，如果我們使用LWW，一定會(huì)出現(xiàn)數(shù)據(jù)不符合預(yù)期的問題。
由于時(shí)鐘不準(zhǔn)確，這里就引入了統(tǒng)計(jì)學(xué)中的置信區(qū)間的概念，也就是這個(gè)時(shí)間到底在一個(gè)什么樣的范圍里，一般的API是無法返回類似這樣的信息的。不過，Google的TrueTime API則恰恰能夠返回這種信息，其調(diào)用結(jié)果是一個(gè)區(qū)間，有了這樣的API，確實(shí)就可以用來做一些對其有依賴的事情了，例如Google自家的Spanner，就是使用TrueTime實(shí)現(xiàn)快照隔離。
如何在這艱難的環(huán)境中設(shè)計(jì)系統(tǒng)
上面介紹的問題是不是挺“令人絕望”的？你可能發(fā)現(xiàn)，現(xiàn)在時(shí)間可能是錯(cuò)的，測量可能是不準(zhǔn)的，你的請求可能得不到任何響應(yīng)，你可能不知道它是不是還活著......這種環(huán)境真的讓設(shè)計(jì)分布式系統(tǒng)變得異常艱難，就像是你在100個(gè)人組成的大部門里面協(xié)調(diào)一些工作一樣，工作量異常的巨大且復(fù)雜。
但好在我們并不是什么都做不了，以協(xié)調(diào)這件事為例，我們肯定不是武斷地聽取一個(gè)人的意見，讓我們回到學(xué)生時(shí)代。我們需要評選一位班長，肯定我們都經(jīng)歷過投票、唱票的環(huán)節(jié)，最終得票最多的那個(gè)人當(dāng)選，有時(shí)可能還需要設(shè)置一個(gè)前提，需要得票超過半數(shù)。
映射到分布式系統(tǒng)中也是如此，我們不能輕易地相信任何一臺(tái)節(jié)點(diǎn)的信息，因?yàn)樗刑嗟牟淮_定，因此更多的情況下，在分布式系統(tǒng)中如果我們需要就某個(gè)事情達(dá)成一致，也可以采取像競選或議會(huì)一樣，大家協(xié)商、投票、仲裁決定一項(xiàng)提議達(dá)成一致，真相由多數(shù)人商議決定，從而達(dá)到大家的一致和統(tǒng)一，這也就是后面要介紹的分布式共識協(xié)議。這個(gè)協(xié)議能夠容忍一些節(jié)點(diǎn)的部分失效，或者莫名其妙的故障帶來的問題，讓系統(tǒng)能夠正常地運(yùn)行下去，確保請求到的數(shù)據(jù)是可信的。
下面給出一些實(shí)際分布式算法的理論模型，根據(jù)對于延遲的假設(shè)不同，這里介紹三種系統(tǒng)模型。
1. 同步模型
該模型主要假設(shè)網(wǎng)絡(luò)延遲是有界的，我們可以清楚地知道這個(gè)延遲的上下界，不管出現(xiàn)任何情況，它都不會(huì)超出這個(gè)界限。
2. 半同步模型（大部分模型都是基于這個(gè)假設(shè)）
半同步模型認(rèn)為大部分情況下，網(wǎng)絡(luò)和延遲都是正常的，如果出現(xiàn)違背的情況，偏差可能會(huì)非常大。
3. 異步模型
對延遲不作任何假設(shè)，沒有任何超時(shí)機(jī)制。而對于節(jié)點(diǎn)失效的處理，也存在三種模型，這里我們忽略惡意謊言的拜占庭模型，就剩下兩種。
1.崩潰-終止模型（Crash-Stop）：該模型中假設(shè)一個(gè)節(jié)點(diǎn)只能以一種方式發(fā)生故障，即崩潰，可能它會(huì)在任意時(shí)刻停止響應(yīng)，然后永遠(yuǎn)無法恢復(fù)。
2.崩潰-恢復(fù)模型：節(jié)點(diǎn)可能在任何時(shí)刻發(fā)生崩潰，可能會(huì)在一段時(shí)間后恢復(fù)，并再次響應(yīng)，在該模型中假設(shè)，在持久化存儲(chǔ)中的數(shù)據(jù)將得以保存，而內(nèi)存中的數(shù)據(jù)會(huì)丟失。
而多數(shù)的算法都是基于半同步模型+崩潰-恢復(fù)模型來進(jìn)行設(shè)計(jì)的。
Safety and Liveness
這兩個(gè)詞在分布式算法設(shè)計(jì)時(shí)起著十分關(guān)鍵的作用，其中安全性（Safety）表示沒有意外發(fā)生，假設(shè)違反了安全性原則，我們一定能夠指出它發(fā)生的時(shí)間點(diǎn)，并且安全性一旦違反，無法撤銷。而活性（Liveness）則表示“預(yù)期的事情最終一定會(huì)發(fā)生”，可能我們無法明確具體的時(shí)間點(diǎn)，但我們期望它在未來某個(gè)時(shí)間能夠滿足要求。在進(jìn)行分布式算法設(shè)計(jì)時(shí)，通常需要必須滿足安全性，而活性的滿足需要具備一定的前提。
4. 總結(jié)
以上就是第一篇文章的內(nèi)容，簡單做下回顧，本文首先介紹了復(fù)制的三種常見模型，分別是主從復(fù)制、多主復(fù)制和無主復(fù)制，然后分別介紹了這三種模型的特點(diǎn)、適用場景以及優(yōu)缺點(diǎn)。接下來，我們用了一個(gè)現(xiàn)實(shí)生活中的例子，向大家展示了分布式系統(tǒng)中常見的兩個(gè)特有問題，分別是節(jié)點(diǎn)的部分失效以及無法共享系統(tǒng)時(shí)鐘的問題，這兩個(gè)問題為我們設(shè)計(jì)分布式系統(tǒng)帶來了比較大的挑戰(zhàn)。如果沒有一些設(shè)計(jì)特定的措施，我們所設(shè)計(jì)的分布式系統(tǒng)將無法很好地滿足設(shè)計(jì)的初衷，用戶也無法通過分布式系統(tǒng)來完成自己想要的工作。以上這些問題，我們會(huì)下篇文章《Replication（下）：事務(wù)，一致性與共識》中逐一進(jìn)行解決，而事務(wù)、一致性、共識這三個(gè)關(guān)鍵詞，會(huì)為我們在設(shè)計(jì)分布式系統(tǒng)時(shí)保駕護(hù)航。
5. 作者簡介
仕祿，美團(tuán)基礎(chǔ)研發(fā)平臺(tái)/數(shù)據(jù)科學(xué)與平臺(tái)部工程師。
文章題目：Replication（上）：常見的復(fù)制模型&分布式系統(tǒng)的挑戰(zhàn)
當(dāng)前路徑：http://m.fisionsoft.com.cn/article/ccsiiii.html
