一、 從集中式到分佈式
1. 集中式
集中式特點：不用考慮網絡分區，宕機問題，協作問題。但是昂貴。
2. 分佈式
分佈式：由多臺機器通過網絡通信組成，多節點機器，分佈式，故障發生頻率大。
故障原因：網絡問題，多臺機器網絡通信容易超時，中間有可能斷掉造成分區。
網絡分區：俗稱腦裂。
網絡的三態問題：要麼連接成功，要麼失敗，要麼超時。
所以分佈式主要是網絡方面和機器方面的問題，最大問題是網絡問題。
3. ACID
例如數據庫的事務
原子性：要麼成功，要麼失敗；
一致性：如果出現異常數據，還是原來的那份
隔離性：各個會話之間是相互獨立的
持久性：就是提交後的數據永久保存在磁盤上，不丟失。
4. CAP
一致性：多臺機器擁有相同副本
可用性：在適合的時間響應客戶端
分區容錯性：不能出現網絡分區
5. BASE
分佈式主要的問題是網絡，所以我們優先處理分佈式的網絡，然後在一致性和可用性之間權衡。這時提出了BASE就是對CAP的一致性和可用性的權衡結果。
BASE 基本可用，最終一致性
最終一致性：就是你提交一臺機器，其他機器最終會把你提交的那臺機器給同步到自己上。
二、 一致性
主的控制機器就叫協調者，副本機器叫參與者
1. 2PC
兩個階段，提交事務和執行事務。
提交事務
1). 詢問
2).執行初始化（執行提交）
執行事務
2PC的故障情況
單臺機器
1. 協調者故障，那麼有個備用協調者接管，並且查詢參與者當前執行到什麼地步，然後接着執行下去。
2. 參與者故障，那麼協調者會等待它重啓，然後再執行下去。
這兩種情況，都只會阻塞，並不會不一致性。
同時故障：
協調者和參與者同時故障
例如：有機器1，2，3，4。其中4是協調者，1，2，3是參與者
4給1，2發完提交事務後故障了，正好3這個時候也故障了，注意這是3是沒有提交事務數據的。現在備用協調者啓動了，去詢問參與者，用於3死掉了，一直不知道它處於什麼狀態（接受了提交事務，還是反饋了能執行還是不能執行3個狀態）。
面對這種情況，讓1，2迴歸停止事務，3恢復以後，不管是什麼狀態，直接停止事務，回滾，這樣子就保證了一致性。
這是2PC的漏洞，當同時故障了，就全部回滾，效率低下，代價大
缺點
當協調者出錯，同時參與者也出錯時，兩階段無法保證事務執行的完整性。
考慮協調者再發出commit消息之後宕機，而唯一接收到這條消息的參與者同時也宕機了。那麼即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。
2. 3PC
2PC 當時只考慮如果單機故障的情況，並沒有考慮協調者和參與者同時故障的情況。3PC就是對2PC漏洞的補充協議。它把2PC中的提交事務請求一分爲二，添加了一個狀態（準備階段）。做到就算兩個同時故障也不阻塞，並且保證一致性。
事務詢問階段（can階段）
事務準備階段 （pre）（包括執行提交）
執行事務階段 （do commit）（將狀態更改）
下面例子分析：
1. 4是協調者 ，1，2，3 是 參與者，當新聞的節點，協調者4和參與者3同時掛掉了。這時候備用的協調者啓動了，詢問了1和2的狀態，都在can階段，回滾代價下，直接回滾。當3重新啓動了發現自己是can階段，回滾代價下，執行回滾，停止事務。這樣子就擺在了3個節點數據一致性。3PC對應2PC就是減少回滾代價。
-
當3個參與者都進入到per準備階段，說明它們都接受到提交詢問，並且都表決過（意思是都領到了數據），這時協調者4和參與者3突然死掉了。備用協調起來後，詢問其他參與者狀態，一看都到pre階段了，說明都領到了數據包括死掉的3，因爲他表決過才進入到準備階段，所以他讓大家都提交了。當3重啓後，看了日誌，發現自己已經到準備階段時死掉了，可以執行提交，這樣保證了數據一致性。
3. paxos
有個叫paxos小島，他們每項 決定都得通過提議然後半數才能生效，每個決定的提議都有一個唯一的全局編號，這個編號只能自增長，不能後退。
何爲通過：就是提議的id好要大於議員手記錄的最大的id
第一階段：提議者發起提議給每個議員，然後等議員反饋同意或不同意。
第二階段：如果半數以上同意了，則執行事務，否則不執行。
如果半數以上同意了，這個議題就通過，然後提議者就命令剩下的議員同步自己的數據，並修改手上的最大id好。
問題：在分佈式中併發是常見的，例如現在有提議者p1，p2
提議者同時提出一個提議，這個時候他們手上的id就有可能是一樣，p1的id是3，p2的id也是3。當p1提議給議員（假設議員手上的id是2），現在議員先同意了p1，p2來訪問這個議員，議員告訴他已經同意了議題id是3，p2的id是3不同意。然後p2回去加大自己的id重新請求，議員這時同意了他。p1收到半數同意準備去通知他們來更新id同步數據，可是發現議員們的id比自己的大了，然後p1有加大id。這種極端情況，導致死鎖了。
這種解決辦法就是提議者只有一個，也就是paxos裏面說的總統。
三、 zookeeper
1. 什麼是zookeeper
zookeeper是爲了解決分佈式一致性問題的工程應用。
zookeeper並沒有直接用paxos協議，而是在paxos協議的基礎上，提出了符合自己符合實際應用場景的高可用的一致性協議ZAB原子廣播協議。
zookeeper分佈式一致性的特點：
-
順序一致性：客戶端訪問zookeeper的一個節點，發起事務，是排着隊到leader那讓他發起提議，一個一個來；
-
單一視圖：任何節點上的數據都是一樣的，所以客戶端訪問任意節點都看到是相同的數據。
-
可靠性：給了一個客戶端反饋，同意他的請求，那麼就是真的同意了。
-
實時性：zookeeper保證在一定時間內，比如5秒之後你可以訪問到最新數據。這是最終一致性導致的。
2. zookeeper設計目標
-
簡單的數據模型：就是文件夾的樹形結構
-
可以構建集羣：
-
順序訪問：客戶端提出了一個事務請求，會獲得一個唯一的id編號，用於操作的先後順序；
-
高性能：這裏指的是讀取數據
3. zookeeper的幾個角色
zookeeper有幾個角色：leader、follower、observer；其中observer一般不配置，它也不參與投票，observer可以在不影響寫性能的情況下提升集羣的讀性能；
zookeeper中節點有實體機器節點，還有znode數據節點。znode數據節點指的是目錄文件夾。數據節點有永久數據節點和臨時節點。
4. watcher監聽機制
zookeeper有watcher監聽機制，例如一個臨時數據節點，如果客戶session中斷了，臨時節點就刪除了，這時watcher就監聽到了。這點就是hadoop的HA實現機制，zkfc實現了zookeeper的watcher機制來自動切換。
5. zookeeper的權限
zookeeper的數據節點就是一個文件夾目錄，它有自己的權限機制ACL。
實際zookeeper刪除、設置。創建目錄，這些就是執行權限。
四、 zab協議
1. zab 的三種狀態：
-
Looking/election:系統剛啓動時或者Leader崩潰後正處於選舉狀態；
-
Following：Follwoer節點所處的狀態，Follower與Leader處於數據同步階段；
-
Leading：Leader所處狀態，當前集羣中有一個Leader爲主進程。
2. zab宏觀上的三個階段：
-
崩潰恢復
-
快速選舉
-
原子廣播
3. zab的微觀的四個階段：
-
選舉
-
發現
-
同步
-
廣播
客戶端提交一個請求到leader然後leader發起提議floower來投票，這個過程都是原子廣播
4. zab的節點狀態講解
-
ZooKeeper啓動時所有節點初始狀態爲Looking，這時集羣會初始選舉出一個Leader節點，選舉出的Leader節點切換爲Leading狀態；
-
當節點發現集羣中已經選舉出Leader則該節點會切換到Following 狀態，然後和Leader節點保持同步；
-
當Following節點與Leader失去聯繫時Follower節點則會切換到Looking狀態，開始新一輪選舉；
-
在ZooKeeper的整個生命週期中每個節點都會在Looking、Following、Leading狀態間不斷轉換。
當啓動後leader崩潰選舉
選舉出Leader節點後zab進入原子廣播階段，這是Leader爲和自己同步的每個節點Follower只能和一個Leader保持同步Leader節點與Follow節點使用心跳檢測來感知對方的存在；
當Leader節點在超時時間內收到來自Follower的心跳檢測，那Follower節點會一直與該節點保持連接；若超時時間內Leader沒有接收到來自過半Follower節點的心跳檢測或TCP連接斷開，那Leader會結束當前的領導，切換到Looking狀態，所有Follower節點也會放棄該Leader節點切換到Looking狀態，所有Follower節點也會放棄該Leader節點切換到Looking狀態，然後開始新一輪選舉；
5. 詳解zab四個階段：
-
第一階段：準備leader選舉
成爲leader的條件：
選epoch最大的；
epoch相等，選zxid最大的
epoch的zxid都相等，選擇server id最大的（就是配置zoo.cfg中的myid）。
節點在選舉開始讀默認投票給自己，當接收其他節點的選票是，會根據上面的條件更改自己的選票並重新發送選票給其他節點，但一個節點的得到票超過半數，該節點會設置自己的狀態leading，其他節點會設置自己的狀態爲following。
什麼是epoch，什麼是zxid？
首先ZooKeeper一個事務包含兩部分，一個數數據，一個是id；id是全局唯一的id，數據就是具體操作數據，並且是lastid加1；
ZooKeeper每個請求都是順序執行的，強順序性的；
epoch是leader標識，zxid是事務標識。
epoch是指：年代，一個領導掛了，另一個領導上任，現在就是新領導的時代了，當產生新領導，事務編號就從0開始。
zxid是總稱：前32位是leader編號（epoch），後32位是這個leader下事務編號。
-
第二階段：發現階段
發現階段主要是發現最大的epoch和最大的事務編號；
之前說了快速產生準備leader，然後其他節點就是fllower，然後發現階段就是fllower向leader報告，自己的epoch和事務編號，然後leader排序，選擇最大的epoch和最大的事務編號。然後通知fllower去更改它的epoch。 -
第三階段：同步階段
leader利用上一個階段知道最大事務編號，然後通知其他fllower去leader這同步數據。事務編號有可能不一樣，所以要同步。保持數據最終一致性。 -
第四階段：原子廣播階段
這時候leader真正對外提供服務，接受客戶端的請求，生成一個數據，半數以上同意，然後就提交事務。剩下的其他節點直接去leader那同步數據。
原來掛掉的leader的事務？
它啓動起來，發現他的時代已經過時了，就刪除了事務，發現有心的leader，自己就變成fllower，然後就去同步數據。
在選舉上，會選舉擁有最新提議歷史(lastZxid最大)的節點作爲leader，這樣子就省去了發現最新提議的步驟。這是局域擁有最新提議的節點也有最新提交記錄的前提。
6. zab和paxos區別
paxos沒有給出leader選舉協議，只給出一致性協議。
五、 ZooKeeper在大數據中的應用場景
ZooKeeper 目錄有幾個特點，有臨時目錄，永久目錄，順序目錄，強一致性(順序訪問)和watcher機制。
利用這些特點，我們可以實現：
-
發佈訂閱，例如一些配置信息；
-
負載均衡，例如kafka生產，消費均衡；
-
master選舉，例如hbase利用它hmaster選舉；
-
主備切換，例如hdfs的HA利用它進行切換。
1. 發佈訂閱
例如：我們的數據庫配置信息文件就可以放到ZooKeeper上。
利用ZooKeeper的watcher機制實現配置變更，程序在運行中就可以獲取到最新的配置信息，不需要起停。
2. ZooKeeper HA應用（主備切換）
hdfs的HA，它的主備切換用的是ZooKeeper來做Active standby之間切換的。
大致步驟：
1). 多個nodemanager同時向ZooKeeper註冊一個數據節點lock。因爲ZooKeeper是強一致性的，所以只能有一個註冊成功，註冊成功的那個就是active
2). 沒有註冊成功的否成了standby，然後在lock目錄上註冊監聽事件watcher。
注意：註冊的lock節點目錄是臨時節點，如果active掛了，這個目錄也就沒了，並且這個lock目錄是有權限控制的ACL，防止active假死後重新連接出現腦裂。
3). 主備切換：當active掛掉以後，會話結束，臨時目錄自動刪除。其他standby監聽到臨時目錄刪除了，各個standby重新同時進行創建帶權限的臨時目錄。成功的改爲active，沒有成功的還是standby。
4). 如果掛掉的active啓動後，發現沒有權限範圍lock臨時目錄，自動更改成standby狀態。
這是ZooKeeper主備切換應用，利用臨時目錄，ACL，watcher機制實現。
3. master選舉
利用ZooKeeper master選舉其實很簡單，和主備切換一樣。
利用強一致性同時創建同一個目錄，最後只能一個成功。
成功那個節點會返回成功狀態，其他節點返回異常，成功的那個就成爲master，其他節點就改成slave。
4. zookeeper在hbase中應用
hmaster監控regionserver是否掛掉。
首先，rs（regionserver簡稱）在ZooKeeper註冊一個臨時目錄rs/[hostname]目錄，然後hmaster註冊watcher監控rs目錄下面變化就可以發現rs服務器是否掛掉。
元數據存儲（訂閱發佈）：每個region存儲信息位置和狀態，都放在ZooKeeper上存儲，以便大家都能訂閱目前region所處的狀態，比如region是在合併還是在切割，有多少個region分別在哪個regionserver上。所以客戶端訪問先訪問ZooKeeper得到位置信息去讀取數據，不經過hmaster。
5. ZooKeeper在kafka中應用
kafka在ZooKeeper註冊的信息
首先，kafka會把broker創建到ZooKeeper臨時目錄上。
/broker/ids/[1-n]表示broker還活着。然後topic信息創建到ZooKeeper臨時目錄。/brokers/topics/[topicname]/paritiong信息。如果有消費者，消費者也會在ZooKeeper創建自己消費信息的offset信息。等臨時目錄。
kafka註冊broker和topic信息使爲了生產消費時負載均衡，這就利用到ZooKeeper負載均衡。消費生產者監控到broker和topic，topic和partition之間的數量，進行重新排序。
https://blog.csdn.net/wenhui12345/article/details/78603201