目錄：

1.解決的問題

2.基本概念

3.實現手段

4.CAP理論

5.節點和數據

1.解決的問題

本質上是解決單台機器無法解決的問題，核心是計算、存儲。

方向是使用多台機器協同解決。

要解決的問題集中在分片、存儲、單點故障

2.基本概念

分片、存儲：這兩個概念其實是無法分割處理的，分片的結果就是落地到數據存儲上。

分片指以一種規則將數據合理地分配到多台機器上；該規則應着重解決：數據分佈均衡、節點動態增加、節點故障問題。

存儲指數據落地，比如內存、硬盤（包括文件、數據庫）；其中要解決單節點數據故障問題、數據同步問題、中心化副本控制協議中的主節點選舉

3.實現手段

分片方式有四種：hash方式、一致性hash、range Based、number Based

這四種方式，可單獨使用，亦可配合使用。它們都不同程度上解決了數據均衡分佈、節點動態增加、單點故障問題。

存儲可將數據集中、分散存儲，採用主從備份；亦可從中心化複製、去中心化來實現。數據可同步可異步

中心化複製集，涉及到主節點選舉，主流的算法是paxos算法、Raft算法。

Raft算法：節點有三個狀態：選民、候選者、當選者。一開始時指定節點為主節點；當主節點掛掉或者出現網絡分區，餘下節點選舉推出主節點；節點向能訪問到的節點發送投票消息，獲票數大於一半時當選；若存在票數相同，所有節點重新投票。投票時節點存在隨機等待時間，且節點在特定時間內僅允許投一次票。

數據同步：主流是從主節點流向從節點，可鏈式，可從節點都從主節點同步。

4.CAP理論

c: 一致性(consistency)，A：可用性(availability)，P 分區容錯(partition tolerance). 對於分佈式數據存儲，至多隻能滿足其中的兩種，需注意的是A和C都是一個度的問題，並不是非0即1兩個極端。

一致性：複製多個節點的更新，本質上是分佈式事務問題，理論上應該保證原子性：要麼更新成功，要麼都不更新，而不會出現部分節點更新成功的情況。經典解決方案：一階段提交、二階段提交。

可用性：一種是採用集羣或主從備份處理，多個節點處理或者一個節點出現故障後，備份節點提供服務。第二種是數據或計算分攤，確保至少一處可用，多處計算可得結果

分區容錯：採用數據備份解決，可按機器備份、按數據塊備份

5.節點和數據

數據分佈到各個節點上，數據和節點的關係存儲到特定集羣節點上，這個關係稱為元數據。

每次對數據請求都經過元數據服務器的話，元數據服務器壓力會很大。通常元數據的變化並不頻繁，因此通常在訪問節點上做緩存，利用緩存進行讀寫操作，減輕元數據服務壓力。

如何解決緩存的強一致性？問題是通信有延時，不可靠

一種思路是版本號，基本思路是請求的時候帶上緩存的版本號，路由到具體節點後，比較實際數據的版本號，如果不一致，則表示緩存信息過舊，此時拉取元數據並緩存。

第二種是lease機制。Lease機制提出的時候是為了解決分佈式存儲系統中緩存一致性的問題

lease機制要點:

服務器向所有客户端發送魂村數據的同時，頒發一個lease，lease包含一個有限期（即過期時間）

lease的含義是：在這個有效期內，服務器保證元數據不會發生變化

因此客户端在這個有效期內可以放心大膽的使用緩存的數據，如果超過這個期限，就不能使用數據了，就得去服務器請求。

如果外部請求修改服務器的元數據，那麼服務器會阻塞修改請求，直到所有已頒發的lease過期，然後修改元數據，並將新的元數據和新的lease發送到客户端。

如果元數據沒有發生變化，那麼服務器也需要咋之前已頒發的lease過期前，重新給客户端頒發新的lease（只有lease，沒有數據）

　　在Lease論文的標題中，提到了“Fault-Tolerant”，那麼lease是怎麼做到容錯的呢。關鍵在於，只要服務器一旦發出數據和lease，不關心客户端是否收到數據，只要等待lease過期，就可以修改元數據；另外，lease的有效期通過過期時間（一個時間戳）來標識，因此即使從服務器到客户端的消息延時到達、或者重複發送都是沒有關係的。

zookeeper社區對腦裂的解決辦法叫做fencing, 中文翻譯為隔離，就是想辦法把舊的name node 隔離起來，使它不能正常對外提供服務。