分布式存儲架構(gòu)技術(shù)解析

1、 分布式存儲架構(gòu)技術(shù)解析 目 錄 TOC o 1-3 h z u HYPERLINK l _Toc66478145 分布式存儲架構(gòu)技術(shù)解析 PAGEREF _Toc66478145 h 1 HYPERLINK l _Toc66478146 一、集中存儲結(jié)構(gòu) PAGEREF _Toc66478146 h 4 HYPERLINK l _Toc66478147 二、分布式存儲 PAGEREF _Toc66478147 h 5 HYPERLINK l _Toc66478148 1 、分布式存儲的興起 PAGEREF _Toc66478148 h 5 HYPERLINK l _Toc66478149 2

2、 、分布式存儲的重要性 PAGEREF _Toc66478149 h 6 HYPERLINK l _Toc66478150 3 、分布式存儲的種類和比較 PAGEREF _Toc66478150 h 7 HYPERLINK l _Toc66478151 A、 中間控制節(jié)點(diǎn)架構(gòu) PAGEREF _Toc66478151 h 7 HYPERLINK l _Toc66478152 B、 完全無中心架構(gòu) 計(jì)算模式 PAGEREF _Toc66478152 h 7 HYPERLINK l _Toc66478153 C、 完全無中心架構(gòu) 一致性哈希 PAGEREF _Toc66478153 h 9 HYP

3、ERLINK l _Toc66478154 D 、分布式存儲的比較 PAGEREF _Toc66478154 h 9 HYPERLINK l _Toc66478155 三、分布式理論淺析 PAGEREF _Toc66478155 h 11 HYPERLINK l _Toc66478156 1 、一致性和可用性 PAGEREF _Toc66478156 h 11 HYPERLINK l _Toc66478157 A 、線性一致性 PAGEREF _Toc66478157 h 11 HYPERLINK l _Toc66478158 B 、順序一致性 PAGEREF _Toc66478158 h 1

4、2 HYPERLINK l _Toc66478159 C 、因果一致性 PAGEREF _Toc66478159 h 13 HYPERLINK l _Toc66478160 D 、最終一致性 PAGEREF _Toc66478160 h 13 HYPERLINK l _Toc66478161 E 、可用性 PAGEREF _Toc66478161 h 13 HYPERLINK l _Toc66478162 F 、分布式系統(tǒng)的一致性 PAGEREF _Toc66478162 h 14 HYPERLINK l _Toc66478163 2 、數(shù)據(jù)分布 PAGEREF _Toc66478163 h

5、15 HYPERLINK l _Toc66478164 A 、哈希分布（ Swift ） PAGEREF _Toc66478164 h 16 HYPERLINK l _Toc66478165 B 、順序分布（ Bigtable ） PAGEREF _Toc66478165 h 17 HYPERLINK l _Toc66478166 C 、 CRUSH 分布 PAGEREF _Toc66478166 h 18 HYPERLINK l _Toc66478167 3 、復(fù)制 PAGEREF _Toc66478167 h 19 HYPERLINK l _Toc66478168 A 、強(qiáng)同步復(fù)制 PAG

6、EREF _Toc66478168 h 19 HYPERLINK l _Toc66478169 B 、異步復(fù)制 PAGEREF _Toc66478169 h 20 HYPERLINK l _Toc66478170 C 、 NWR 復(fù)制 PAGEREF _Toc66478170 h 20 HYPERLINK l _Toc66478171 4 、分布式協(xié)議 PAGEREF _Toc66478171 h 21 HYPERLINK l _Toc66478172 A 、兩階段提交 PAGEREF _Toc66478172 h 21 HYPERLINK l _Toc66478173 B 、三階段提交 PA

7、GEREF _Toc66478173 h 22 HYPERLINK l _Toc66478174 C 、 Paxos 協(xié)議 PAGEREF _Toc66478174 h 22 HYPERLINK l _Toc66478175 D 、 Raft 協(xié)議 PAGEREF _Toc66478175 h 23 HYPERLINK l _Toc66478176 5、跨機(jī)房部署 PAGEREF _Toc66478176 h 25 HYPERLINK l _Toc66478177 A 、集群整體切換 PAGEREF _Toc66478177 h 25 HYPERLINK l _Toc66478178 B 、單

8、個(gè)集群跨機(jī)房 PAGEREF _Toc66478178 h 26 HYPERLINK l _Toc66478179 C 、 Paxos 選主副本 PAGEREF _Toc66478179 h 26 HYPERLINK l _Toc66478180 1、 Google 文件系統(tǒng)（ GFS ） PAGEREF _Toc66478180 h 27 HYPERLINK l _Toc66478181 2、 Taobao 文件系統(tǒng)（ TFS ） PAGEREF _Toc66478181 h 28 HYPERLINK l _Toc66478182 3、 Fackbook Haystack 文件系統(tǒng) PAGE

9、REF _Toc66478182 h 29 HYPERLINK l _Toc66478183 4、 CDN 內(nèi)容分發(fā)網(wǎng)絡(luò) PAGEREF _Toc66478183 h 31 HYPERLINK l _Toc66478184 五、分布式鍵值系統(tǒng) PAGEREF _Toc66478184 h 33 HYPERLINK l _Toc66478185 1、 Amazon Dynamo PAGEREF _Toc66478185 h 34 HYPERLINK l _Toc66478186 B 、 Gossip 協(xié)議 PAGEREF _Toc66478186 h 35 HYPERLINK l _Toc664

10、78187 2、 Taobao Tiar PAGEREF _Toc66478187 h 36 HYPERLINK l _Toc66478188 A 、 Tair 使用場景 PAGEREF _Toc66478188 h 36 HYPERLINK l _Toc66478189 B 、 Tair 的架構(gòu) PAGEREF _Toc66478189 h 36 HYPERLINK l _Toc66478190 C 、數(shù)據(jù)分布均衡性 PAGEREF _Toc66478190 h 37 HYPERLINK l _Toc66478191 D 、容錯(cuò) PAGEREF _Toc66478191 h 38 HYPER

11、LINK l _Toc66478192 E 、數(shù)據(jù)遷移 PAGEREF _Toc66478192 h 38 HYPERLINK l _Toc66478193 3、 ETCD PAGEREF _Toc66478193 h 38 HYPERLINK l _Toc66478194 A 、 ETCD 的特點(diǎn) PAGEREF _Toc66478194 h 39 HYPERLINK l _Toc66478195 B 、提供的能力 PAGEREF _Toc66478195 h 39 HYPERLINK l _Toc66478196 C 、 ETCD 架構(gòu) PAGEREF _Toc66478196 h 39

12、HYPERLINK l _Toc66478197 4 、產(chǎn)品選型比較（ Etcd ， Zookeeper ， Consul 比較） PAGEREF _Toc66478197 h 41【摘要】本文介紹了分布式存儲的架構(gòu)類型、分布式理論、不同的分布式文件系統(tǒng)和分布式鍵值系統(tǒng)等，較為系統(tǒng)詳盡，可閱讀收藏。一、集中存儲結(jié)構(gòu)說到分布式存儲，我們先來看一下傳統(tǒng)的存儲是怎么個(gè)樣子。傳統(tǒng)的存儲也稱為集中式存儲， 從概念上可以看出來是具有集中性的，也就是整個(gè)存儲是集中在一個(gè)系統(tǒng)中的，但集中式存儲并不是一個(gè)單獨(dú)的設(shè)備，是集中在一套系統(tǒng)當(dāng)中的多個(gè)設(shè)備，比如下圖中的 EMC 存儲就需要幾個(gè)機(jī)柜來存放。在這個(gè)存儲系統(tǒng)中

13、包含很多組件，除了核心的機(jī)頭（控制器）、磁盤陣列（ JBOD ）和交換機(jī)等設(shè)備外，還有管理設(shè)備等輔助設(shè)備。結(jié)構(gòu)中包含一個(gè)機(jī)頭，這個(gè)是存儲系統(tǒng)中最為核心的部件。通常在機(jī)頭中有包含兩個(gè)控制器，互為備用， 避免硬件故障導(dǎo)致整個(gè)存儲系統(tǒng)的不可用。機(jī)頭中通常包含前端端口和后端端口，前端端口用戶為服務(wù)器提供存儲服務(wù)，而后端端口用于擴(kuò)充存儲系統(tǒng)的容量。通過后端端口機(jī)頭可以連接更多的存儲設(shè)備，從而形成一個(gè)非常大的存儲資源池。在整個(gè)結(jié)構(gòu)中，機(jī)頭中是整個(gè)存儲系統(tǒng)的核心部件，整個(gè)存儲系統(tǒng)的高級功能都在其中實(shí)現(xiàn)?？刂破髦械能浖?shí)現(xiàn)對磁盤的管理，將磁盤抽象化為存儲資源池，然后劃分為 LUN 提供給服務(wù)器使用。這里的 L

14、UN 其實(shí)就是在服務(wù)器上看到的磁盤 。當(dāng)然，一些集中式存儲本身也是文件服務(wù)器，可以提供共享文件服務(wù)。無論如何，從上面我們可以看出集中式存儲 最大的特點(diǎn)是有一個(gè)統(tǒng)一的入口，所有數(shù)據(jù)都要經(jīng)過這個(gè)入口，這個(gè)入口就是存儲系統(tǒng)的機(jī)頭。這也就是集中式存儲區(qū)別于分布式存儲最顯著的特點(diǎn)。如下圖所示：二、分布式存儲分布式存儲最早是由谷歌提出的，其目的是通過廉價(jià)的服務(wù)器來提供使用與大規(guī)模，高并發(fā)場景下的 Web 訪問問題。它 采用可擴(kuò)展的系統(tǒng)結(jié)構(gòu)，利用多臺存儲服務(wù)器分擔(dān)存儲負(fù)荷，利用位置服務(wù)器定位存儲信息，它不但提高了系統(tǒng)的可靠性、可用性和存取效率，還易于擴(kuò)展。1 、分布式存儲的興起分布式存儲的興起與互聯(lián)網(wǎng)的發(fā)展

15、密不可分，互聯(lián)網(wǎng)公司由于其數(shù)據(jù)量大而資本積累少，而通常都使用大規(guī)模分布式存儲系統(tǒng)。與傳統(tǒng)的高端服務(wù)器、高端存儲器和高端處理器不同的是，互聯(lián)網(wǎng)公司的分布式存儲系統(tǒng)由數(shù)量眾多的、低成本和高性價(jià)比的普通 PC 服務(wù)器通過網(wǎng)絡(luò)連接而成。其主要原因有以下三點(diǎn)（1） 互聯(lián)網(wǎng)的業(yè)務(wù)發(fā)展很快，而且注意成本消耗，這就使得存儲系統(tǒng)不能依靠傳統(tǒng)的縱向擴(kuò)展的方式，即先買小型機(jī)，不夠時(shí)再買中型機(jī)，甚至大型機(jī)?；ヂ?lián)網(wǎng)后端的分布式系統(tǒng)要求支持橫向擴(kuò)展，即通過增加普通 PC 服務(wù)器來提高系統(tǒng)的整體處理能力。（2） 普通 PC 服務(wù)器性價(jià)比高，故障率也高，需要在軟件層面實(shí)現(xiàn)自動(dòng)容錯(cuò)，保證數(shù)據(jù)的一致性。（3） 另外，隨著服務(wù)器的

16、不斷加入，需要能夠在軟件層面實(shí)現(xiàn)自動(dòng)負(fù)載均衡，使得系統(tǒng)的處理能力得到線性擴(kuò)展。2 、分布式存儲的重要性從單機(jī)單用戶到單機(jī)多用戶，再到現(xiàn)在的網(wǎng)絡(luò)時(shí)代，應(yīng)用系統(tǒng)發(fā)生了很多的變化。而分布式系統(tǒng)依然是目前很熱門的討論話題，那么，分布式系統(tǒng)給我們帶來了什么，或者說是為什么要有分布式系統(tǒng)呢？（1）升級單機(jī)處理能力的性價(jià)比越來越低；企業(yè)發(fā)現(xiàn)通過更換硬件做垂直擴(kuò)展的方式來提升性能會越來越不劃算；（2）單機(jī)處理能力存在瓶頸；某個(gè)固定時(shí)間點(diǎn)，單顆處理器有自己的性能瓶頸，也就說即使愿意花更多的錢去買計(jì)算能力也買不到了；（3）出于穩(wěn)定性和可用性的考慮如果采用單擊系統(tǒng)，那么在這臺機(jī)器正常的時(shí)候一切 OK ，一旦出問題，

17、那么系統(tǒng)就完全不能用了。當(dāng)然，可以考慮做容災(zāi)備份等方案，而這些方案就會讓系統(tǒng)演變?yōu)榉植际较到y(tǒng)了；（4）云存儲和大數(shù)據(jù)發(fā)展的必然要求云存儲和大數(shù)據(jù)是構(gòu)建在分布式存儲之上的應(yīng)用。移動(dòng)終端的計(jì)算能力和存儲空間有限，而且有在多個(gè)設(shè)備之間共享資源的強(qiáng)烈的需求，這就使得網(wǎng)盤、相冊等云存儲應(yīng)用很快流行起來。然而，萬變不離其宗，云存儲的核心還是后端的大規(guī)模分布式存儲系統(tǒng)。大數(shù)據(jù)則更近一步，不僅需要存儲海量數(shù)據(jù)，還需要通過合適的計(jì)算框架或者工具對這些數(shù)據(jù)進(jìn)行分析，抽取其中有價(jià)值的部分。如果沒有分布式存儲，便談不上對大數(shù)據(jù)進(jìn)行分析。仔細(xì)分析還會發(fā)現(xiàn)，分布式存儲技術(shù)是互聯(lián)網(wǎng)后端架構(gòu)的神器，掌握了這項(xiàng)技能，以后理解其

18、他技術(shù)的本質(zhì)會變得非常容易。3 、分布式存儲的種類和比較分布式存儲包含的種類繁多，除了傳統(tǒng)意義上的分布式文件系統(tǒng)、分布式塊存儲和分布式對象存儲外，還包括分布式數(shù)據(jù)庫和分布式緩存等，但其中架構(gòu)無外乎于三種A、 中間控制節(jié)點(diǎn)架構(gòu)以 HDFS （ Hadoop Distribution File System ）為代表的架構(gòu)是典型的代表。在這種架構(gòu)中，一部分節(jié)點(diǎn) NameNode 是存放管理數(shù)據(jù)（元數(shù)據(jù)），另一部分節(jié)點(diǎn) DataNode 存放業(yè)務(wù)數(shù)據(jù)，這種類型的服務(wù)器負(fù)責(zé)管理具體數(shù)據(jù)。這種架構(gòu)就像公司的層次組織架構(gòu)， namenode 就如同老板，只管理下屬的經(jīng)理（ datanode ），而下屬的經(jīng)

19、理，而經(jīng)理們來管理節(jié)點(diǎn)下本地盤上的數(shù)據(jù)。在上圖中， 如果客戶端需要從某個(gè)文件讀取數(shù)據(jù)，首先從 NameNode 獲取該文件的位置（具體在哪個(gè) DataNode ），然后從該 NameNode 獲取具體的數(shù)據(jù)。在該架構(gòu)中 NameNode 通常是主備部署（ Secondary NameNode ），而 DataNode 則是由大量節(jié)點(diǎn)構(gòu)成一個(gè)集群。由于元數(shù)據(jù)的訪問頻度和訪問量相對數(shù)據(jù)都要小很多，因此 NameNode 通常不會成為性能瓶頸，而 DataNode 集群中的數(shù)據(jù)可以有副本，既可以保證高可用性，可以分散客戶端的請求。因此，通過這種分布式存儲架構(gòu)可以通過橫向擴(kuò)展 datanode 的數(shù)量

20、來增加承載能力，也即實(shí)現(xiàn)了動(dòng)態(tài)橫向擴(kuò)展的能力。B、 完全無中心架構(gòu) 計(jì)算模式以 Ceph 為代表的架構(gòu)是其典型的代表。在該架構(gòu)中與 HDFS 不同的地方在于該架構(gòu)中沒有中心節(jié)點(diǎn)。客戶端是通過一個(gè)設(shè)備映射關(guān)系 計(jì)算出來 其寫入數(shù)據(jù)的位置，這樣客戶端可以直接與存儲節(jié)點(diǎn)通信，從而避免中心節(jié)點(diǎn)的性能瓶頸。如上圖所示， 在 Ceph 存儲系統(tǒng)架構(gòu)中核心組件有 MON 服務(wù)、 OSD 服務(wù)和 MDS 服務(wù)等。(1) MON 服務(wù)用于維護(hù)存儲系統(tǒng)的硬件邏輯關(guān)系，主要是服務(wù)器和硬盤等在線信息。MON 服務(wù)通過集群的方式保證其服務(wù)的可用性。(2) OSD 服務(wù)用于實(shí)現(xiàn)對磁盤的管理，實(shí)現(xiàn)真正的數(shù)據(jù)讀寫，通常一個(gè)磁

21、盤對應(yīng)一個(gè) OSD 服務(wù)。(3) MDS 只為 CephFS 文件存儲系統(tǒng)跟蹤文件的層次機(jī)構(gòu)和存儲元數(shù)據(jù)。Ceph 塊設(shè)備和 RADOS 并不需要元數(shù)據(jù)，因此也不需要 Ceph MDS 守護(hù)進(jìn)程(4) RADOS ：RADOS 就是包含上述三種服務(wù)的 ceph 存儲集群。在 Ceph 中所有的數(shù)據(jù)都以對象形式存在的，并且無論哪種數(shù)據(jù)類型 RADOS 對象存儲都將負(fù)責(zé)保存這些對象。RADOS 層可以確保數(shù)據(jù)始終保持一致性。要做到這一點(diǎn)必須執(zhí)行數(shù)據(jù)復(fù)制、故障檢測和恢復(fù)，以及數(shù)據(jù)遷移和所在集群節(jié)點(diǎn)實(shí)現(xiàn)在平衡(5) RBD （塊設(shè)備）：原名 RADOS 塊設(shè)備，提供可靠的分布式和高性能塊存儲磁盤給客戶

22、端。(6) CephFS ：Ceph 文件系統(tǒng)提供了一個(gè)使用 Ceph 存儲集群存儲用戶數(shù)據(jù)的與 POSIX 兼容的文件系統(tǒng)(7) Librados ：libRADOS 庫為 PHP 、 RUBY 、 Java 、 Python 、 C+ 等語言提供 了方便的訪問 RADOS 接口的方式(8) RADOS GW ：RGW 提供對象存儲服務(wù)，它允許應(yīng)用程序和 Ceph 對象存儲建立連接， RGW 提供了與 Amazon S3 和 openstack Swift 兼容的 RUSTFUL API客戶端訪問存儲的大致流程是，客戶端在啟動(dòng)后會首先通過 RADOS GW 進(jìn)入，從 MON 服務(wù)拉取存儲資源

23、布局信息，然后根據(jù)該布局信息和寫入數(shù)據(jù)的名稱等信息計(jì)算出期望數(shù)據(jù)的位置（包含具體的物理服務(wù)器信息和磁盤信息），然后和該位置信息對應(yīng)的 CephFS 對應(yīng)的位置直接通信，讀取或者寫入數(shù)據(jù)C、 完全無中心架構(gòu) 一致性哈希以 swift 為代表的架構(gòu)是其典型的代表。與 Ceph 的通過計(jì)算方式獲得數(shù)據(jù)位置的方式不同，另外一種方式是通過一致性哈希的方式獲得數(shù)據(jù)位置。一致性哈希的方式就是將設(shè)備做成一個(gè)哈希環(huán)，然后根據(jù)數(shù)據(jù)名稱計(jì)算出的哈希值映射到哈希環(huán)的某個(gè)位置，從而實(shí)現(xiàn)數(shù)據(jù)的定位。Swift 中存在兩種映射關(guān)系，對于一個(gè)文件，通過哈希算法（ MD5 ）找到對應(yīng)的虛節(jié)點(diǎn)（一對一的映射關(guān)系），虛節(jié)點(diǎn)再通過映

24、射關(guān)系（ ring 文件中二維數(shù)組）找到對應(yīng)的設(shè)備（多對多的映射關(guān)系），這樣就完成了一個(gè)文件存儲在設(shè)備上的映射。D 、分布式存儲的比較那么現(xiàn)在問題來了，如果我們要選擇分布式存儲，選擇哪種好呢？其實(shí)它們各有各的優(yōu)勢和使用場景，具體要看需求。（1）HDFS主要用于大數(shù)據(jù)的存儲場景，是 Hadoop 大數(shù)據(jù)架構(gòu)中的存儲組件。HDFS 在開始設(shè)計(jì)的時(shí)候，就已經(jīng)明確的它的應(yīng)用場景，就是大數(shù)據(jù)服務(wù)。主要的應(yīng)用場景有：a 、對大文件存儲的性能比較高，例如幾百兆，幾個(gè) G 的大文件。因?yàn)?HDFS 采用的是以元數(shù)據(jù)的方式進(jìn)行文件管理，而元數(shù)據(jù)的相關(guān)目錄和塊等信息保存在 NameNode 的內(nèi)存中， 文件數(shù)量的

25、增加會占用大量的 NameNode 內(nèi)存。如果存在大量的小文件，會占用大量內(nèi)存空間，引起整個(gè)分布式存儲性能下降，所以盡量使用 HDFS 存儲大文件比較合適。b 、適合低寫入，多次讀取的業(yè)務(wù)。就大數(shù)據(jù)分析業(yè)務(wù)而言，其處理模式就是一次寫入、多次讀取，然后進(jìn)行數(shù)據(jù)分析工作， HDFS 的數(shù)據(jù)傳輸吞吐量比較高，但是數(shù)據(jù)讀取延時(shí)比較差，不適合頻繁的數(shù)據(jù)寫入。c 、 HDFS 采用多副本數(shù)據(jù)保護(hù)機(jī)制，使用普通的 X86 服務(wù)器就可以保障數(shù)據(jù)的可靠性，不推薦在虛擬化環(huán)境中使用。（ 2 ） Ceph目前應(yīng)用最廣泛的開源分布式存儲系統(tǒng)，已得到眾多廠商的支持，許多超融合系統(tǒng)的分布式存儲都是基于 Ceph 深度定制

26、。而且 Ceph 已經(jīng)成為 LINUX 系統(tǒng)和 OpenStack 的 “ 標(biāo)配 ” ，用于支持各自的存儲系統(tǒng)。Ceph 可以提供對象存儲、塊設(shè)備存儲和文件系統(tǒng)存儲服務(wù)。同時(shí)支持三種不同類型的存儲服務(wù)的特性，在分布式存儲系統(tǒng)中，是很少見的。a、 Ceph 沒有采用 HDFS 的元數(shù)據(jù)尋址的方案，而且采用 CRUSH 算法，數(shù)據(jù)分布均衡，并行度高。而且在支持塊存儲特性上，數(shù)據(jù)可以具有強(qiáng)一致性，可以獲得傳統(tǒng)集中式存儲的使用體驗(yàn)。b、 對象存儲服務(wù)， Ceph 支持 Swift 和 S3 的 API 接口。在塊存儲方面，支持精簡配置、快照、克隆。在文件系統(tǒng)存儲服務(wù)方面，支持 Posix 接口，支持快

27、照。但是目前 Ceph 支持文件的性能相當(dāng)其他分布式存儲系統(tǒng)，部署稍顯復(fù)雜，性能也稍弱，一般都將 Ceph 應(yīng)用于塊和對象存儲。c、 Ceph 是去中心化的分布式解決方案，需要提前做好規(guī)劃設(shè)計(jì)，對技術(shù)團(tuán)隊(duì)的要求能力比較高。特別是在 Ceph 擴(kuò)容時(shí)，由于其數(shù)據(jù)分布均衡的特性，會導(dǎo)致整個(gè)存儲系統(tǒng)性能的下降（ 3 ）Swift主要面向的是對象存儲。和 Ceph 提供的對象存儲服務(wù)類似。主要用于解決非結(jié)構(gòu)化數(shù)據(jù)存儲問題。它和 Ceph 的對象存儲服務(wù)的主要區(qū)別是。a 、客戶端在訪問對象存儲系統(tǒng)服務(wù)時(shí)， Swift 要求客戶端必須訪問 Swift 網(wǎng)關(guān)才能獲得數(shù)據(jù)。而 Ceph 使用一個(gè)運(yùn)行在每個(gè)存儲

28、節(jié)點(diǎn)上的 OSD （對象存儲設(shè)備）獲取數(shù)據(jù)信息，沒有一個(gè)單獨(dú)的入口點(diǎn)，比 Swift 更靈活一些。b 、數(shù)據(jù)一致性方面， Swift 的數(shù)據(jù)是最終一致，在海量數(shù)據(jù)的處理效率上要高一些，但是主要面向?qū)?shù)據(jù)一致性要求不高，但是對數(shù)據(jù)處理效率要求比較高的對象存儲業(yè)務(wù)。而 Ceph 是始終跨集群強(qiáng)一致性。主要的應(yīng)用場景，在 OpenStack 中，對象存儲服務(wù)使用的就是 Swift ，而不是 Ceph 。三、分布式理論淺析1 、一致性和可用性由于異常的存在，分布式存儲系統(tǒng)設(shè)計(jì)時(shí)往往會將數(shù)據(jù)冗余存儲多份，每一份稱為一個(gè)副本）。這樣，當(dāng)某一個(gè)節(jié)點(diǎn)出現(xiàn)故障時(shí)，可以從其他副本上讀到數(shù)據(jù)。可以這么認(rèn)為，副本是分

29、布式存儲系統(tǒng)容錯(cuò)技術(shù)的唯一手段。由于多個(gè)副本的存在，如何保證副本之間的一致性是整個(gè)分布式系統(tǒng)的理論核心。數(shù)據(jù)一致性這個(gè)單詞在平常開發(fā)中，或者各種文章中都能經(jīng)?？匆?，我們常常聽見什么東西數(shù)據(jù)不一致了，造成了一定的損失，趕快修復(fù)一下。那有幾種一致性呢？a、 時(shí)間一致性：要求所有數(shù)據(jù)組件的數(shù)據(jù)在任意時(shí)刻都是完全一致的；b、 事物一致性：事務(wù)一致性只能存在在事務(wù)開始前的和事務(wù)完成之后，在事務(wù)過程中數(shù)據(jù)有可能不一致，比如 A 轉(zhuǎn) 100 元給 B ， A 扣減 100 ， B 加上 100 ，在事務(wù)開始前和事務(wù)完成之后都能保證他們的帳是對上的，那么這就是事務(wù)一致性。但是在事務(wù)過程中有可能會出現(xiàn) A 扣減

30、了 100 元， B 沒有加上 100 元的情況，這就是不一致c、 在應(yīng)用程序中涉及多個(gè)不同的單機(jī)事務(wù)，只有在所有的單機(jī)事務(wù)完成之前和完成之后，數(shù)據(jù)是完全一致的。僅僅靠這三種一致性在實(shí)際的一些復(fù)雜場合是很難描述清楚的，所以，我們引出了一致性模型，這里我們由強(qiáng)到弱簡單的介紹幾種常見的一致性模型。A 、線性一致性又稱強(qiáng)一致性， 可以看做只有一個(gè)單核處理器，或者可以看做只有一個(gè)數(shù)據(jù)副本，并且所有操作都是原子的。如上圖所示，對于事件 e1 和 e2 來說，如果事件 e1 的 response 是在事件 e2 的 invoke 之前，我們就說 e1 happen before e2 。對于同一個(gè)線程來說

31、，前面的事件一定 happen before 后面的事件。但是對于不同線程上的兩個(gè)事件來說，它們之間只有在在時(shí)間線上沒有交叉的情況下，才會存在 happen before 關(guān)系。對于有交叉的那些事件，比如下圖中的 event2 和 event3 ，它們兩個(gè)就不存在 happen before 關(guān)系，對于我們要尋找的合法順序執(zhí)行過程來說，它們兩個(gè)的順序可以是任意的。B 、順序一致性順序一致性弱于嚴(yán)格一致性。對變量的寫操作不一定要在瞬間看到，但是，不同處理器對變量的寫操作必須在所有處理器上以相同的順序看到，這里處理器再分布式系統(tǒng)中可以換成不同的節(jié)點(diǎn)。假設(shè)有兩個(gè)線程 A 和 B 并發(fā)執(zhí)行。其中 A

32、線程由 3 個(gè)操作構(gòu)成，它們在程序中的順序是：A1-A2-A3. B 線程也有 3 個(gè)操作，它們在程序中的順序是：B1-B2-B3. 假設(shè)如果在順序一致的模型中的效果就是如上兩個(gè)圖所示。C 、因果一致性因果一致性是弱于順序一致性的一致性模型，順序一致性要求所有的操作的順序都必須按照某個(gè)單個(gè)處理器 ( 節(jié)點(diǎn) ) 的順序，而因果一致性只需要滿足有因果關(guān)系的操作是順序一致性即可。簡單來說如果有人問你一個(gè)問題，那么你給出答案，這兩個(gè)就是因果關(guān)系，但如果你給出答案再問題之前，那么這個(gè)就違反了因果關(guān)系。舉個(gè)簡單的例子如果節(jié)點(diǎn) 1 更新了數(shù)據(jù) A ，節(jié)點(diǎn) 2 讀取數(shù)據(jù) A ，并更新數(shù)據(jù) B ，這里的數(shù)據(jù) B

33、 有可能是根據(jù)數(shù)據(jù) A 計(jì)算出來的，所有具備因果關(guān)系，但是如果節(jié)點(diǎn) 3 看到的是先更新的 B ，再更新的 A 那么就破壞了因果一致性。D 、最終一致性其實(shí)除了強(qiáng)一致以外，其他的一致性都可以看作為最終一致性，只是根據(jù)一致性不同模型的不同要求又衍生出了很多具體一致性模型。當(dāng)然最簡單的最終一致性，是不需要關(guān)注中間變化的順序，只需要保證在某個(gè)時(shí)間點(diǎn)一致即可。只是這個(gè)某個(gè)時(shí)間點(diǎn)需要根據(jù)不同的系統(tǒng)，不同業(yè)務(wù)再去衡量。再最終一致性完成之前，有可能返回任何的值，不會對這些值做任何順序保證。E 、可用性可用性指“ Reads and writes always succeed” ，即服務(wù)一直可用，而且是正常響應(yīng)

34、時(shí)間。對于一個(gè)可用性的分布式系統(tǒng)，每一個(gè)非故障的節(jié)點(diǎn)必須對每一個(gè)請求作出響應(yīng)。所以，一般我們在衡量一個(gè)系統(tǒng)的可用性的時(shí)候，都是通過停機(jī)時(shí)間來計(jì)算的?？捎眯苑诸惪捎盟剑?）年可容忍停機(jī)時(shí)間容錯(cuò)可用性99.99991 min極高可用性99.9995 min具有故障自動(dòng)恢復(fù)能力的可用性99.9953 min高可用性99.98.8h商品可用性99N ，寫的節(jié)點(diǎn)和讀的節(jié)點(diǎn)重疊，則是強(qiáng)一致性。例如對于典型的一主一備同步復(fù)制的關(guān)系型數(shù)據(jù)庫， N=2,W=2,R=1 ，則不管讀的是主庫還是備庫的數(shù)據(jù)，都是一致的。（2） 如果 W+R=3 。不同的 N,W,R 組合，是在可用性和一致性之間取一個(gè)平衡，以適應(yīng)不

35、同的應(yīng)用場景。那么，實(shí)際生活中，也有一些是AP without C的案例，如 CAP 圖中所示，大部分是 Nosql 、 CoachDB 、 Cassandra 數(shù)據(jù)庫，那場景是哪些呢？其實(shí)就是不要求正確性的場合，如某米的搶購手機(jī)場景或 12306 搶購火車票的場景，可能前幾秒你瀏覽商品的時(shí)候頁面提示是有庫存的，當(dāng)你選擇完商品準(zhǔn)備下單的時(shí)候，系統(tǒng)提示你下單失敗，商品已售完。這其實(shí)就是先在 A（可用性）方面保證系統(tǒng)可以正常的服務(wù)，然后在數(shù)據(jù)的一致性方面做了些犧牲。2 、數(shù)據(jù)分布分布式系統(tǒng)區(qū)別于傳統(tǒng)單機(jī)系統(tǒng)在于能夠?qū)?shù)據(jù)分布到多個(gè)節(jié)點(diǎn)，并在多個(gè)節(jié)點(diǎn)之間實(shí)現(xiàn)負(fù)載均衡。數(shù)據(jù)分布的方式主要有兩種，一種是

36、哈希分布，如一致性哈希，代表系統(tǒng)為Amazon 的 Dynamo 系統(tǒng)， Openstack 的 Swift 系統(tǒng)；另外一種方法是順序分布，即每張表格上的數(shù)據(jù)按照主鍵整體有序，代表系統(tǒng)為 Google 的 Bigtable 系統(tǒng)。Bigtable 將一張大表根據(jù)主鍵切分為有序的范圍，每個(gè)有序范圍是一個(gè)子表。A 、哈希分布（ Swift ）哈希函數(shù)的散列特性很好，哈希方式可以將數(shù)據(jù)比較均勻地分布到集群中去。而且，哈希方式需要記錄的元信息也非常簡單，每個(gè)節(jié)點(diǎn)只需要知道哈希函數(shù)的計(jì)算方式以及模的服務(wù)器的個(gè)數(shù)就可以計(jì)算出處理的數(shù)據(jù)應(yīng)該屬于哪臺機(jī)器。然而，找出一個(gè)散列特性很好的哈希函數(shù)是很難的。這是因?yàn)?/p>

37、，如果按照主鍵散列，那么同一個(gè)用戶 id 下的數(shù)據(jù)可能被分散到多臺服務(wù)器，這會使得一次操作同一個(gè)用戶 id 下的多條記錄變得困難；如果按照用戶 id 散列，容易出現(xiàn) “ 數(shù)據(jù)傾斜 ” （ data skew ）問題，即某些大用戶的數(shù)據(jù)量很大，無論集群的規(guī)模有多大，這些用戶始終由一臺服務(wù)器處理。處理大用戶問題一般有兩種方式，一種方式是手動(dòng)拆分，即線下標(biāo)記系統(tǒng)中的大用戶（例如運(yùn)行一次 MapReduce 作業(yè)），并根據(jù)這些大用戶的數(shù)據(jù)量將其拆分到多臺服務(wù)器上。這就相當(dāng)于在哈希分布的基礎(chǔ)上針對這些大用戶特殊處理；另一種方式是自動(dòng)拆分，即數(shù)據(jù)分布算法能夠動(dòng)態(tài)調(diào)整，自動(dòng)將大用戶的數(shù)據(jù)拆分到多臺服務(wù)器上。

38、其中包含兩種算法。一種是傳統(tǒng)的哈希算法，訪問數(shù)據(jù)時(shí)，首先計(jì)算哈希值，再查詢元數(shù)據(jù)服務(wù)器，獲得該哈希值對應(yīng)的服務(wù)器。在這種算法下，服務(wù)器的上線和下線將導(dǎo)致大量的數(shù)據(jù)遷移，不適合于生產(chǎn)。另一致性哈希（ Distributed Hash Table,DHT ）算法。算法思想如下：給系統(tǒng)中每個(gè)節(jié)點(diǎn)分配一個(gè)隨機(jī) token ，這些 token 構(gòu)成一個(gè)哈希環(huán)。執(zhí)行數(shù)據(jù)存放操作時(shí)，先計(jì)算 Key （主鍵）的哈希值，然后存放到順時(shí)針方向第一個(gè)大于或者等于該哈希值的 token 所在的節(jié)點(diǎn)。一致性哈希的優(yōu)點(diǎn)在于節(jié)點(diǎn)加入 / 刪除時(shí)只會影響到在哈希環(huán)中相鄰的節(jié)點(diǎn)，而對其他節(jié)點(diǎn)沒影響。如上圖所示，算法本身的特性可

39、以使得 磁盤劃分為比較多的較為均勻的虛擬分區(qū)，每個(gè)虛擬分區(qū)是哈希環(huán)上的一個(gè)節(jié)點(diǎn)，整個(gè)環(huán)是從 0 到 32 位最大值的一個(gè)區(qū)間，并且首尾相連，當(dāng)計(jì)算出數(shù)據(jù)（或者數(shù)據(jù)名稱）的哈希值后，必然落到哈希環(huán)的某個(gè)區(qū)間，然后以順時(shí)針，必然能夠找到一個(gè)節(jié)點(diǎn)。那么這個(gè)節(jié)點(diǎn)就是存儲數(shù)據(jù)的位置?？梢娙绻挥幸粋€(gè)節(jié)點(diǎn)，最大到 32 還未找到節(jié)點(diǎn)，那么數(shù)據(jù)就在第一個(gè)唯一節(jié)點(diǎn)上。整個(gè)的數(shù)據(jù)定位就是基于上述的一致算法，實(shí)現(xiàn)將請求重新定向到該設(shè)備進(jìn)行處理（1） 在對象存儲上，通過賬戶名 / 容器名 / 對象名三個(gè)名稱組成一個(gè)位置的標(biāo)識，通過該唯一標(biāo)識可以計(jì)算出一個(gè)整型數(shù)；（2） 存儲設(shè)備方面， Swift 構(gòu)建一個(gè)虛擬分區(qū)表

40、，表的大小在創(chuàng)建集群是確定（通常為幾十萬），這個(gè)表其實(shí)就是一個(gè)數(shù)組；（3） 整數(shù)值和這個(gè)數(shù)組，通過一致性哈希算法就可以確定該整數(shù)在數(shù)組的位置。一致性算法原理上可以保證數(shù)據(jù)的均衡性、單調(diào)性，避免數(shù)據(jù)的分散性，有效的保證數(shù)據(jù)的一致性，使得負(fù)載盡可能的被映射到一個(gè)特定的緩存區(qū)。因?yàn)?一致性哈希算法在服務(wù)節(jié)點(diǎn)太少時(shí)，容易因?yàn)楣?jié)點(diǎn)分部不均勻而造成數(shù)據(jù)傾斜問題。所以在實(shí)際應(yīng)用中，通常將虛擬節(jié)點(diǎn)數(shù)設(shè)置為比 32 更大的值，因此即使很少的服務(wù)節(jié)點(diǎn)也能做到相對均勻的數(shù)據(jù)分布。B 、順序分布（ Bigtable ）哈希散列破壞了數(shù)據(jù)的有序性，只支持隨機(jī)讀取操作，不能夠支持順序掃描。某些系統(tǒng)可以在應(yīng)用層做折衷，比如

41、互聯(lián)網(wǎng)應(yīng)用經(jīng)常按照用戶來進(jìn)行數(shù)據(jù)拆分，并通過哈希方法進(jìn)行數(shù)據(jù)分布，同一個(gè)用戶的數(shù)據(jù)分布到相同的存儲節(jié)點(diǎn)，允許對同一個(gè)用戶的數(shù)據(jù)執(zhí)行順序掃描，由應(yīng)用層解決跨多個(gè)用戶的操作問題。另外，這種方式可能出現(xiàn)某些用戶的數(shù)據(jù)量太大的問題，由于用戶的數(shù)據(jù)限定在一個(gè)存儲節(jié)點(diǎn)，無法發(fā)揮分布式存儲系統(tǒng)的多機(jī)并行處理能力。順序分布在分布式表格系統(tǒng)（ Bigtable ）中比較常見，一般的做法是將大表順序劃分為連續(xù)的范圍，每個(gè)范圍稱為一個(gè)子表，總控服務(wù)器負(fù)責(zé)將這些子表按照一定的策略分配到存儲節(jié)點(diǎn)上。如圖所示，用戶表（ User 表）的主鍵范圍為 1 7000 ，在分布式存儲系統(tǒng)中劃分為多個(gè)子表，分別對應(yīng)數(shù)據(jù)范圍 1 1

42、000 ， 1001 2000 ， 6001 7000 。其中 Meta 表是為了支持更大的集群規(guī)模，它將原來的一層索引結(jié)分成兩層，使用 Meta 表來維護(hù) User 子表所在的節(jié)點(diǎn)，從而減輕 Root 節(jié)點(diǎn)的負(fù)擔(dān)。順序分布與 B+ 樹數(shù)據(jù)結(jié)構(gòu)比較類似，每個(gè)子表相當(dāng)于葉子節(jié)點(diǎn)，隨著數(shù)據(jù)的插入和刪除，某些子表可能變得很大，某些變得很小，數(shù)據(jù)分布不均勻。如果采用順序分布，系統(tǒng)設(shè)計(jì)時(shí)需要考慮子表的分裂與合并，這將極大地增加系統(tǒng)復(fù)雜度。C 、 CRUSH 分布CRUSH 算法，全稱叫 Controlled, Scalable, Decentralized Placement of Replicated

43、 Data. 嚴(yán)格說起來 Crush 算法，其實(shí)也是以 Hash 算法為基礎(chǔ)的。只不過映射的方法和一致性哈希不同。我們用 Ceph 分布的過程來加以說明。Ceph 分布數(shù)據(jù)的過程：首先計(jì)算數(shù)據(jù) x 的 Hash 值并將結(jié)果和 PG 數(shù)目取余，以得到數(shù)據(jù) x 對應(yīng)的 PG 編號。然后，通過 CRUSH 算法將 PG 映射到一組 OSD 中。最后把數(shù)據(jù) x 存放到 PG 對應(yīng)的 OSD 中。注明：PG 全稱是 Placement Group （放置組）。這個(gè)過程中包含了兩次映射，第一次是數(shù)據(jù) x 到 PG 的映射。如果把 PG 當(dāng)作存儲節(jié)點(diǎn)，那么傳統(tǒng) Hash 算法一樣。不同的是， PG 是抽象的

44、存儲節(jié)點(diǎn)，它不會隨著物理節(jié)點(diǎn)的加入或則離開而增加或減少，因此數(shù)據(jù)到 PG 的映射是穩(wěn)定的。以 Dynamo 為例，在這個(gè)過程中， PG 起到了兩個(gè)作用：第一個(gè)作用是劃分?jǐn)?shù)據(jù)分區(qū)。每個(gè) PG 管理的數(shù)據(jù)區(qū)間相同，因而數(shù)據(jù)能夠均勻地分布到 PG 上；第二個(gè)作用是充當(dāng) Dynamo 中 Token 的角色，即決定分區(qū)位置。實(shí)際上，這和 Dynamo 中固定分區(qū)數(shù)目，以及維持分區(qū)數(shù)目和虛擬節(jié)點(diǎn)數(shù)目相等的原則是同一回事。以 Ceph 為例， CRUSH 算法通過兩次映射計(jì)算數(shù)據(jù)存儲位置來確定如何存儲和檢索數(shù)據(jù)。CRUSH 使 Ceph 客戶機(jī)能夠直接與 OSDs 通信，而不是通過集中的服務(wù)器或代理。通過

45、算法確定的數(shù)據(jù)存儲和檢索方法， Ceph 避免了單點(diǎn)故障、性能瓶頸和對其可伸縮性的物理限制。CRUSH 需要集群的映射，并使用 CRUSH 映射在 OSDs 中偽隨機(jī)存儲和檢索數(shù)據(jù)，數(shù)據(jù)在集群中均勻分布。3 、復(fù)制為了保證分布式存儲系統(tǒng)的高可靠和高可用，數(shù)據(jù)在系統(tǒng)中一般存儲多個(gè)副本。當(dāng)某個(gè)副本所在的存儲節(jié)點(diǎn)出現(xiàn)故障時(shí)，分布式存儲系統(tǒng)能夠自動(dòng)將服務(wù)切換到其他的副本，從而實(shí)現(xiàn)自動(dòng)容錯(cuò)。分布式存儲系統(tǒng)通過復(fù)制協(xié)議將數(shù)據(jù)同步到多個(gè)存儲節(jié)點(diǎn)，并確保多個(gè)副本之間的數(shù)據(jù)一致性。A 、強(qiáng)同步復(fù)制客戶端將寫請求發(fā)送給主副本，主副本將寫請求復(fù)制到其他備副本，常見的做法是同步操作日志（ Commit Log ）。主

46、副本首先將操作日志同步到備副本，備副本回放操作日志，完成后通知主副本。接著，主副本修改本機(jī)，等到所有的操作都完成后再通知客戶端寫成功。下圖中的復(fù)制協(xié)議要求主備同步成功才可以返回客戶端寫成功，這種協(xié)議稱為強(qiáng)同步協(xié)議。假設(shè)所有副本的個(gè)數(shù)為 N ，且 N 2 ，即備副本個(gè)數(shù)大于 1 。那么，實(shí)現(xiàn)強(qiáng)同步協(xié)議時(shí)，主副本可以將操作日志并發(fā)地發(fā)給所有備副本并等待回復(fù)，只要至少 1 個(gè)備副本返回成功就可以回復(fù)客戶端操作成功。強(qiáng)同步的好處在于如果主副本出現(xiàn)故障，至少有 1 個(gè)備副本擁有完整的數(shù)據(jù)，分布式存儲系統(tǒng)可以自動(dòng)地將服務(wù)切換到最新的備副本而不用擔(dān)心數(shù)據(jù)丟失的情況。B 、異步復(fù)制與強(qiáng)同步對應(yīng)的復(fù)制方式是異步

47、復(fù)制。在異步模式下，主副本不需要等待備副本的回應(yīng)，只需要本地修改成功就可以告知客戶端寫操作成功。另外，主副本通過異步機(jī)制，比如單獨(dú)的復(fù)制線程將客戶端修改操作推送到其他副本。異步復(fù)制的好處在于系統(tǒng)可用性較好，但是一致性較差，如果主副本發(fā)生不可恢復(fù)故障，可能丟失最后一部分更新操作。C 、 NWR 復(fù)制分布式存儲系統(tǒng)中還可能使用基于寫多個(gè)存儲節(jié)點(diǎn)的復(fù)制協(xié)議（ Replicated-write protocol ）。比如 Dynamo 系統(tǒng)中的 NWR 復(fù)制協(xié)議，其中， N 為副本數(shù)量， W 為寫操作的副本數(shù)， R 為讀操作的副本數(shù)。NWR 協(xié)議中多個(gè)副本不再區(qū)分主和備，客戶端根據(jù)一定的策略往其中的

48、W 個(gè)副本寫入數(shù)據(jù)，讀取其中的 R 個(gè)副本。只要 W+R N ，可以保證讀到的副本中至少有一個(gè)包含了最新的更新。然而，這種協(xié)議的問題在于不同副本的操作順序可能不一致，從多個(gè)副本讀取時(shí)可能出現(xiàn)沖突。這種方式在實(shí)際系統(tǒng)中比較少見，不建議使用。4 、分布式協(xié)議分布式協(xié)議有很多，其中以兩階段提交和 Paxos 協(xié)議最具代表性。兩階段提交協(xié)議（ 2PC ）或三階段提交（ 3PC ）用于保證跨多個(gè)節(jié)點(diǎn)操作的原子性，也就是說，跨多個(gè)節(jié)點(diǎn)的操作要么在所有節(jié)點(diǎn)上全部執(zhí)行成功，要么全部失敗。Paxos 協(xié)議用于確保多個(gè)節(jié)點(diǎn)對某個(gè)投票（例如哪個(gè)節(jié)點(diǎn)為主節(jié)點(diǎn)）達(dá)成一致。A 、兩階段提交二階段提交的算法思路可以概括為

49、: 參與者將操作成敗通知協(xié)調(diào)者，再由協(xié)調(diào)者根據(jù)所有參與者的反饋情報(bào)決定各參與者是否要提交操作還是中止操作。（1）請求階段 ( 表決 ) ：事務(wù)協(xié)調(diào)者協(xié)調(diào)者通知事務(wù)參與者準(zhǔn)備提交或者取消事務(wù)，然后進(jìn)入表決過程。在表決過程中，參與者將告知協(xié)調(diào)者自己的決策：同意（事務(wù)參與者本地執(zhí)行成功）或者取消（事務(wù)參與者本地執(zhí)行失敗）。（2）提交階段 ( 執(zhí)行 ):在該階段，協(xié)調(diào)者將基于第一個(gè)階段的投票結(jié)果進(jìn)行決策 : 提交或取消，當(dāng)且僅當(dāng)所有的參與者同意提交事務(wù)，協(xié)調(diào)者才通知所有的參與者提交事務(wù)，否則協(xié)調(diào)者將通知所有的參與者取消事務(wù)參與者在接收到協(xié)調(diào)者發(fā)來的消息后將執(zhí)行響應(yīng)的操作。（3）兩階段提交無法解決的問題

50、A ）、如果一個(gè)參與者遲遲不投票，那整個(gè)階段都會處于等待狀態(tài)，但這可以通過超時(shí)機(jī)制解決B ）、當(dāng)協(xié)調(diào)者出錯(cuò)，同時(shí)參與者也出錯(cuò)時(shí)，兩階段無法保證事務(wù)執(zhí)行的完整性?？紤]協(xié)調(diào)者在發(fā)出 commit 消息之后宕機(jī)，而唯一接收到這條消息的參與者同時(shí)也宕機(jī)了。那么即使協(xié)調(diào)者通過選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者，這條事務(wù)的狀態(tài)也是不確定的，沒人知道事務(wù)是否被已經(jīng)提交。B 、三階段提交三階段提交擁有 CanCommit 、 PreCommit 、 DoCommit 三個(gè)階段（ 1 ）其中 CanCommit 階段近似等同于兩階段的請求階段；DoCommit 近似等同于兩階段的提交階段。而準(zhǔn)備階段 PreCommit

51、是一個(gè)緩沖，保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。（ 2 ）三階段提交在兩階段提交的第一階段與第二階段之間插入了一個(gè)準(zhǔn)備階段（ PreCommit ），使得原先在兩階段提交中，參與者在投票之后，由于協(xié)調(diào)者發(fā)生崩潰或錯(cuò)誤，而導(dǎo)致參與者處于無法知曉是否提交或者中止的“不確定狀態(tài)”所產(chǎn)生的可能相當(dāng)長的延時(shí)的問題得以解決。（ 3 ）三階段提交無法解決的問題如果進(jìn)入 PreCommit 后，協(xié)調(diào)者發(fā)出的是 commit 請求，假設(shè)只有一個(gè)參與者收到并進(jìn)行了 commit 操作，而其他參與者對于網(wǎng)絡(luò)中斷沒有收到，會根據(jù) 3PC 選擇 abort 操作，此時(shí)系統(tǒng)狀態(tài)發(fā)生不一致性。C 、 Paxo

52、s 協(xié)議要講 Paxos ，先要從拜占庭問題講起，其故事背景是這樣的：拜占庭位于現(xiàn)在土耳其的伊斯坦布爾，是東羅馬帝國的首都。由于當(dāng)時(shí)拜占庭羅馬帝國國土遼闊，為了防御目的，因此每個(gè)軍隊(duì)都分隔很遠(yuǎn)，將軍與將軍之間只能靠信差傳消息。在戰(zhàn)爭的時(shí)候，拜占庭軍隊(duì)內(nèi)所有將軍必需達(dá)成一致的共識，決定是否有贏的機(jī)會才去攻打敵人的陣營。但是，軍隊(duì)可能有叛徒和敵軍間諜，這些叛徒將軍們會擾亂或左右決策的過程。這時(shí)候，在已知有成員謀反的情況下，其余忠誠的將軍在不受叛徒的影響下如何達(dá)成一致的協(xié)議，這就是拜占庭將軍問題。我們否定假設(shè)，給出了非拜占庭模型定義：（ 1 ）一致性模塊的行為可以以任意速度執(zhí)行，允許運(yùn)行失敗，在失敗

53、后也許會重啟并再次運(yùn)行；（ 2 ）一致性模塊之間通過異步方式發(fā)送信息通信，通信時(shí)間可以任意長，信息可能會在傳輸過程中丟失，也允許重復(fù)發(fā)送相同的信息，多重信息的順序可以任意。但是有一點(diǎn)：信息不允許被篡改。由此，我們得出了 Paxos 的基本二階段：Prepare 階段、 Accept 階段，這個(gè)兩個(gè)階段的邏輯非常復(fù)雜，是互信算法的基礎(chǔ)，本文并不打算做過深的解讀。有興趣的讀者可以去參考區(qū)塊鏈算法一書。D 、 Raft 協(xié)議Raft 是 Replicated And Fault Tolerant 的縮寫， Paxos 的簡化版本。在一個(gè)分布式系統(tǒng)中，要提高系統(tǒng)的健壯性，可用性和數(shù)據(jù)的安全性，我們最正

54、確的姿勢是什么？當(dāng)然是靠多備份了，服務(wù)多備份，數(shù)據(jù)多備份，去除單點(diǎn)，確保即使相關(guān)組件掛掉一些，系統(tǒng)還能健康服務(wù)。去除單點(diǎn)，沒有固定不變的權(quán)威，固然好，但是帶來的問題就是，以誰的意見為準(zhǔn)，在信息可能丟失的環(huán)境下，這是一個(gè)相當(dāng)困難的事（可見溝通是多么的重要）！在 1990 年提出來之時(shí)，幾乎沒有人能夠理解。經(jīng)過作者多次簡化，再解釋，包括谷歌等團(tuán)隊(duì)的實(shí)踐再創(chuàng)造，再解釋的過程，十幾年過去了，才漸漸的成為事實(shí)標(biāo)準(zhǔn)并被大家所了解和接受。但直到現(xiàn)在，無比抽象的 Paxos 算法，還是沒有幾個(gè)人能理解。大道至簡！這是永恒不變的真理， Raft 的目標(biāo)問題，是構(gòu)建一個(gè)容易理解和構(gòu)建的分布式一致性協(xié)議，在容易的基

55、礎(chǔ)上，確保理論正確的。Raft 協(xié)議，如果照本宣讀，還是需要點(diǎn)時(shí)間的，本文采用通俗的辦法給大家做解釋Raft 大致的原理，這是一個(gè)選主（ leader selection ）思想的算法，集群總每個(gè)節(jié)點(diǎn)都有三種可能的角色：（ 1 ） leader對客戶端通信的入口，對內(nèi)數(shù)據(jù)同步的發(fā)起者，一個(gè)集群通常只有一個(gè) leader 節(jié)點(diǎn)（ 2 ） follower:非 leader 的節(jié)點(diǎn)，被動(dòng)的接受來自 leader 的數(shù)據(jù)請求（ 3 ） candidate:一種臨時(shí)的角色，只存在于 leader 的選舉階段，某個(gè)節(jié)點(diǎn)想要變成 leader ，那么就發(fā)起投票請求，同時(shí)自己變成 candidate 。如果

56、選舉成功，則變?yōu)?candidate ，否則退回為 follower 。算法包含兩個(gè)過程：leader 選舉和日志復(fù)制：（1） 選舉過程：（假設(shè)有 5 個(gè)節(jié)點(diǎn)， S1S5 ）a、 初始狀態(tài)下，大家都是平等的 follower ，那么 follow 誰呢，總要選個(gè)老大吧。大家都蠢蠢欲動(dòng)，每個(gè) follower 內(nèi)部都維護(hù)了一個(gè)隨機(jī)的 timer ；b、 在 timer 時(shí)間到了的時(shí)候還沒有人主動(dòng)聯(lián)系它的話，那它就要變成 candidate ，同時(shí)發(fā)出投票請求（ RequestVote ）給其他人，假設(shè) S1, S3 成為 candidatec、 對于相同條件的 candidate ， follo

57、wer 們采取先來先投票的策略。如果超過半數(shù)的 follower 都認(rèn)為他是合適做領(lǐng)導(dǎo)的，那么恭喜，新的 leader 產(chǎn)生了，假如 S3 變成了新一屆的大哥 leader ；d、 S1 很不幸，沒有人愿意選這個(gè)悲劇的 candidate ，那它只有老老實(shí)實(shí)的變回小弟的狀態(tài) follower;e、 同樣的，如果在 timer 期間內(nèi)沒有收到大哥的聯(lián)絡(luò)，這時(shí)很可能大哥已經(jīng)跪了，如下圖，所有小弟又開始蠢蠢欲動(dòng)，新的一輪 (term) 選舉開始了。（2） 日志復(fù)制：（假設(shè)有 5 個(gè)節(jié)點(diǎn)， S1S5 ）a、 leader 扮演的是分布式事務(wù)中的協(xié)調(diào)者，每次有數(shù)據(jù)更新的時(shí)候產(chǎn)生二階段提交（ two-ph

58、ase commit ）。在 leader 收到數(shù)據(jù)操作的請求，先不著急更新本地?cái)?shù)據(jù)（數(shù)據(jù)是持久化在磁盤上的），而是生成對應(yīng)的 log ，然后把生成 log 的請求廣播給所有的 follower ；b、 每個(gè) follower 在收到請求之后有兩種選擇：一種是聽從 leader 的命令，也寫入 log ，然后返回 success 回去；另一種情況，在某些條件不滿足的情況下， follower 認(rèn)為不應(yīng)該聽從 leader 的命令，返回 false ；c、 此時(shí)如果超過半數(shù)的 follower 都成功寫了 log ，那么 leader 開始_第二階段_的提交：正式寫入數(shù)據(jù)，然后同樣廣播給 fol

59、lower ， follower 也根據(jù)自身情況選擇寫入或者不寫入并返回結(jié)果給 leader ，最終所有節(jié)點(diǎn)的數(shù)據(jù)達(dá)成一致。d、 這兩階段中如果任意一個(gè)都有超過半數(shù)的 follower 返回 false 或者根本沒有返回，那么這個(gè)分布式事務(wù)是不成功的。此時(shí)雖然不會有回滾的過程，但是由于數(shù)據(jù)不會真正在多數(shù)節(jié)點(diǎn)上提交，所以會在之后的過程中被覆蓋掉Raft 協(xié)議保證_leader_的強(qiáng)領(lǐng)導(dǎo)地位 ,client _讀寫都_通過_leader_，有很高的一致性，但有些同學(xué)會問，那分布式的價(jià)值在什么地方呢？如何才能負(fù)載均衡呢？在實(shí)際中我們采用 Multi Raft 架構(gòu)，結(jié)合應(yīng)用，不同的應(yīng)用選舉不同的 l

60、eader 節(jié)點(diǎn)，在負(fù)載均衡。5、跨機(jī)房部署在分布式系統(tǒng)中，跨機(jī)房問題一直都是老大難問題。機(jī)房之間的網(wǎng)絡(luò)延時(shí)較大，且不穩(wěn)定。跨機(jī)房問題主要包含兩個(gè)方面：數(shù)據(jù)同步以及服務(wù)切換。跨機(jī)房部署方案有三個(gè)：集群整體切換、單個(gè)集群跨機(jī)房、 Paxos 選主副本。下面分別介紹。A 、集群整體切換集群整體切換是最為常見的方案。如圖所示，假設(shè)某系統(tǒng)部署在兩個(gè)機(jī)房：機(jī)房 1 和機(jī)房 2 。兩個(gè)機(jī)房保持獨(dú)立，每個(gè)機(jī)房部署單獨(dú)的總控節(jié)點(diǎn)，且每個(gè)總控節(jié)點(diǎn)各有一個(gè)備份節(jié)點(diǎn)。當(dāng)總控節(jié)點(diǎn)出現(xiàn)故障時(shí)，能夠自動(dòng)將機(jī)房內(nèi)的備份節(jié)點(diǎn)切換為總控節(jié)點(diǎn)繼續(xù)提供服務(wù)。另外，兩個(gè)機(jī)房部署了相同的副本數(shù)，例如數(shù)據(jù)分片 A 在機(jī)房 1 存儲的副本