為什么需要分布式系統(tǒng)

l?單機系統(tǒng)已經無法滿足業(yè)務需要

l?高性能硬件價格昂貴

分布式系統(tǒng)帶來哪些問題

l?集群中節(jié)點數(shù)據(jù)一致性問題

l?集群產生分區(qū)

l?負載問題

l?冪等性問題

l?可用性問題

l?Session問題

分布式PAC設計原則

一個經典的分布式系統(tǒng)理論。CAP理論告訴我們：一個分布式系統(tǒng)不可能同時滿足一致性（C：Consistency）、可用性（A：Availability）和分區(qū)容錯性（P：Partition tolerance）這三個基本需求，最多只能同時滿足其中兩項。

1、一致性

在分布式環(huán)境下，一致性是指數(shù)據(jù)在多個副本之間能否保持一致的特性。在一致性的需求下，當一個系統(tǒng)在數(shù)據(jù)一致的狀態(tài)下執(zhí)行更新操作后，應該保證系統(tǒng)的數(shù)據(jù)仍然處于一致的狀態(tài)。

對于一個將數(shù)據(jù)副本分布在不同分布式節(jié)點上的系統(tǒng)來說，如果對第一個節(jié)點的數(shù)據(jù)進?行了更新操作并且更新成功后，卻沒有使得第二個節(jié)點上的數(shù)據(jù)得到相應的更新，于是在對第二個節(jié)點的數(shù)據(jù)進行讀取操作時，獲取的依然是老數(shù)據(jù)（或稱為臟數(shù)?據(jù)），這就是典型的分布式數(shù)據(jù)不一致的情況。在分布式系統(tǒng)中，如果能夠做到針對一個數(shù)據(jù)項的更新操作執(zhí)行成功后，所有的用戶都可以讀取到其最新的值，那么?這樣的系統(tǒng)就被認為具有強一致性

2、可用性

可用性是指系統(tǒng)提供的服務必須一直處于可用的狀態(tài)，對于用戶的每一個操作請求總是能夠在有限的時間內返回結果。這里的重點是"有限時間內"和"返回結果"。

"有限時間內"是指，對于用戶的一個操作請求，系統(tǒng)必須能夠在指定的時間內返回對 應的處理結果，如果超過了這個時間范圍，那么系統(tǒng)就被認為是不可用的。另外，"有限的時間內"是指系統(tǒng)設計之初就設計好的運行指標，通常不同系統(tǒng)之間有很 大的不同，無論如何，對于用戶請求，系統(tǒng)必須存在一個合理的響應時間，否則用戶便會對系統(tǒng)感到失望。

"返回結果"是可用性的另一個非常重要的指標，它要求系統(tǒng)在完成對用戶請求的處理后，返回一個正常的響應結果。正常的響應結果通常能夠明確地反映出隊請求的處理結果，即成功或失敗，而不是一個讓用戶感到困惑的返回結果。

3、分區(qū)容錯性

分區(qū)容錯性約束了一個分布式系統(tǒng)具有如下特性：分布式系統(tǒng)在遇到任何網絡分區(qū)故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務，除非是整個網絡環(huán)境都發(fā)生了故障。

網絡分區(qū)是指在分布式系統(tǒng)中，不同的節(jié)點分布在不同的子網絡（機房或異地網絡）?中，由于一些特殊的原因導致這些子網絡出現(xiàn)網絡不連通的狀況，但各個子網絡的內部網絡是正常的，從而導致整個系統(tǒng)的網絡環(huán)境被切分成了若干個孤立的區(qū)域。?需要注意的是，組成一個分布式系統(tǒng)的每個節(jié)點的加入與退出都可以看作是一個特殊的網絡分區(qū)。

既然一個分布式系統(tǒng)無法同時滿足一致性、可用性、分區(qū)容錯性三個特點，所以我們就需要拋棄一樣：

Paxos如何解決分布式一致問題

??Paxos的基本思路：

假設有一個社團，其中有團員、議員（決議小組成員）兩個角色

團員可以向議員申請?zhí)岚竵硇薷纳鐖F制度

議員坐在一起，拿出自己收到的提案，對每個提案進行投票表決，超過半數(shù)通過即可生效

為了秩序，規(guī)定每個提案都有編號ID，按順序自增

每個議員都有一個社團制度筆記本，上面記著所有社團制度，和最近處理的提案編號，初始為0

投票通過的規(guī)則：

新提案ID?是否大于 議員本中的ID，是議員舉手贊同

如果舉手人數(shù)大于議員人數(shù)的半數(shù)，即讓新提案生效

例如：

剛開始，每個議員本子上的ID都為0，現(xiàn)在有一個議員拿出一個提案：團費降為100元，這個提案的ID自增為1

每個議員都和自己ID對比，一看?1>0，舉手贊同，同時修改自己本中的ID為1

發(fā)出提案的議員一看超過半數(shù)同意，就宣布：1號提案生效

然后所有議員都修改自己筆記本中的團費為100元

以后任何一個團員咨詢任何一個議員："團費是多少？"，議員可以直接打開筆記本查看，并回答：團費為100元

可能會有極端的情況，就是多個議員一起發(fā)出了提案，就是并發(fā)的情況

例如

剛開始，每個議員本子上的編號都為0，現(xiàn)在有兩個議員（A和B）同時發(fā)出了提案，那么根據(jù)自增規(guī)則，這兩個提案的編號都為1，但只會有一個被先處理

假設A的提案在B的上面，議員們先處理A提案并通過了，這時，議員們的本子上的ID已經變?yōu)榱?/span>1，接下來處理B的提案，由于它的ID是1，不大于議員本子上的ID，B提案就被拒絕了，B議員需要重新發(fā)起提案

上面就是Paxos的基本思路，對照ZooKeeper，對應關系就是：

團員?-client

議員?-server

議員的筆記本?-server中的數(shù)據(jù)

提案?-變更數(shù)據(jù)的請求

提案編號?-zxid（ZooKeeper Transaction Id）

提案生效?-執(zhí)行變更數(shù)據(jù)的操作

ZooKeeper中還有一個leader的概念，就是把發(fā)起提案的權利收緊了，以前是每個議員都可以發(fā)起提案，現(xiàn)在有了leader，大家就不要七嘴八舌了，先把提案都交給leader，由leader一個個發(fā)起提案

Paxos算法就是通過投票、全局編號機制，使同一時刻只有一個寫操作被批準，同時并發(fā)的寫操作要去爭取選票，只有獲得過半數(shù)選票的寫操作才會被批準，所以永遠只會有一個寫操作得到批準，其他的寫操作競爭失敗只好再發(fā)起一輪投票

zookeeper特性介紹

一致性保證:

更新請求順序進行，來自同一個client的更新請求按其發(fā)送順序依次執(zhí)行

數(shù)據(jù)更新原子性，一次數(shù)據(jù)更新要么成功，要么失敗

全局唯一數(shù)據(jù)視圖，client無論連接到哪個server，數(shù)據(jù)視圖都是一致的

實時性，在一定事件范圍內，client能讀到最新數(shù)據(jù)

zookeeper選舉流程

1.選舉線程由當前Server發(fā)起選舉的線程擔任，其主要功能是對投票結果進行統(tǒng)計，并選出推薦的Server；

2.選舉線程首先向所有Server發(fā)起一次詢問(包括自己)；

3.選舉線程收到回復后，驗證是否是自己發(fā)起的詢問(驗證zxid是否一致)，然后獲取對方的id(myid)，并存儲到當前詢問對象列表中，最后獲取對方提議的leader相關信息(id,zxid)，并將這些信息存儲到當次選舉的投票記錄表中；

4.收到所有Server回復以后，就計算出zxid最大的那個Server，并將這個Server相關信息設置成下一次要投票的Server；

5.線程將當前zxid最大的Server設置為當前Server要推薦的Leader，如果此時獲勝的Server獲得n/2 + 1的Server票數(shù)，設置當前推薦的leader為獲勝的Server，將根據(jù)獲勝的Server相關信息設置自己的狀態(tài)，否則，繼續(xù)這個過程，直到leader被選舉出來

zookeeper讀寫流程

寫流程

客戶端連接到集群中某一個節(jié)點

客戶端發(fā)送寫請求

服務端連接節(jié)點，把該寫請求轉發(fā)給leader

leader處理寫請求，一半以上的從節(jié)點也寫成功，返回給客戶端成功。

讀流程

客戶端連接到集群中某一節(jié)點

讀請求，直接返回。

zookeeper存儲策略

????持久化存儲是基于內存快照(snapshot)和事務日志（txlog）來存儲。

snapshot和txlog的存儲目錄定義在zoo.cfg中，txlog存儲磁盤和snapshot存儲磁盤分開，避免io爭奪。

txlog的刷盤閾值是1000。txlog是生成snapshot之后生成。

snapshot的保存數(shù)量和清理時間間隔配置在zoo.cfg中。

zookeeper?使用concurrenthashmap進行存儲。鎖的粒度是segment，減少鎖競爭，segment里對應一個hashtable?的若干桶.

所以時間復雜度都是?O(1)

zookeeper應用場景

數(shù)據(jù)發(fā)布與訂閱

發(fā)布與訂閱即所謂的配置管理，顧名思義就是將數(shù)據(jù)發(fā)布到zk節(jié)點上，供訂閱者動態(tài)獲取數(shù)據(jù)，實現(xiàn)配置信息的集中式管理和動態(tài)更新。例如全局的配置信息，地址列表等就非常適合使用。

1.?索引信息和集群中機器節(jié)點狀態(tài)存放在zk的一些指定節(jié)點，供各個客戶端訂閱使用。

2.?系統(tǒng)日志（經過處理后的）存儲，這些日志通常2-3天后被清除。

3.?應用中用到的一些配置信息集中管理，在應用啟動的時候主動來獲取一次，并且在節(jié)點上注冊一個Watcher，以后每次配置有更新，實時通知到應用，獲取最新配置信息。

4.?業(yè)務邏輯中需要用到的一些全局變量，比如一些消息中間件的消息隊列通常有個offset，這個offset存放在zk上，這樣集群中每個發(fā)送者都能知道當前的發(fā)送進度。

5.?系統(tǒng)中有些信息需要動態(tài)獲取，并且還會存在人工手動去修改這個信息。以前通常是暴露出接口，例如JMX接口，有了zk后，只要將這些信息存放到zk節(jié)點上即可。

分布通知/協(xié)調

ZooKeeper?中特有watcher注冊與異步通知機制，能夠很好的實現(xiàn)分布式環(huán)境下不同系統(tǒng)之間的通知與協(xié)調，實現(xiàn)對數(shù)據(jù)變更的實時處理。使用方法通常是不同系統(tǒng)都對?ZK上同一個znode進行注冊，監(jiān)聽znode的變化（包括znode本身內容及子節(jié)點的），其中一個系統(tǒng)update了znode，那么另一個系統(tǒng)能 夠收到通知，并作出相應處理。

1.?另一種心跳檢測機制：檢測系統(tǒng)和被檢測系統(tǒng)之間并不直接關聯(lián)起來，而是通過zk上某個節(jié)點關聯(lián)，大大減少系統(tǒng)耦合。

2.?另一種系統(tǒng)調度模式：某系統(tǒng)有控制臺和推送系統(tǒng)兩部分組成，控制臺的職責是控制推送系統(tǒng)進行相應的推送工作。管理人員在控制臺作的一些操作，實際上是修改 了ZK上某些節(jié)點的狀態(tài)，而zk就把這些變化通知給他們注冊Watcher的客戶端，即推送系統(tǒng)，于是，作出相應的推送任務。

3.?另一種工作匯報模式：一些類似于任務分發(fā)系統(tǒng)，子任務啟動后，到zk來注冊一個臨時節(jié)點，并且定時將自己的進度進行匯報（將進度寫回這個臨時節(jié)點），這樣任務管理者就能夠實時知道任務進度。

總之，使用zookeeper來進行分布式通知和協(xié)調能夠大大降低系統(tǒng)之間的耦合。

分布式鎖

分布式鎖，這個主要得益于ZooKeeper為我們保證了數(shù)據(jù)的強一致性，即用戶只要完全相信每時每刻，zk集群中任意節(jié)點（一個zk server）上的相同znode的數(shù)據(jù)是一定是相同的。鎖服務可以分為兩類，一個是保持獨占，另一個是控制時序。

保持獨占，就是所有試圖來獲取這個鎖的客戶端，最終只有一個可以成功獲得這把鎖。通常的做法是把zk上的一個znode看作是一把鎖，通過create znode的方式來實現(xiàn)。所有客戶端都去創(chuàng)建?/distribute_lock?節(jié)點，最終成功創(chuàng)建的那個客戶端也即擁有了這把鎖。

控制時序，就是所有視圖來獲取這個鎖的客戶端，最終都是會被安排執(zhí)行，只是有個全局時序了。做法和上面基本類似，只是這里?/distribute_lock?已經預先存在，客戶端在它下面創(chuàng)建臨時有序節(jié)點（這個可以通過節(jié)點的屬性控制：CreateMode.EPHEMERAL_SEQUENTIAL來指定）。Zk的父節(jié)點（/distribute_lock）維持一份sequence,保證子節(jié)點創(chuàng)建的時序性，從而也形成了每個客戶端的全局時序。

集群管理

1.?集群機器監(jiān)控：這通常用于那種對集群中機器狀態(tài)，機器在線率有較高要求的場景，能夠快速對集群中機器變化作出響應。這樣的場景中，往往有一個監(jiān)控系統(tǒng)，實時檢測集群機器是否存活。過去的做法通常是：監(jiān)控系統(tǒng)通過某種手段（比如ping）定時檢測每個機器，或者每個機器自己定時向監(jiān)控系統(tǒng)匯報“我還活著”。 這種做法可行，但是存在兩個比較明顯的問題：1.?集群中機器有變動的時候，牽連修改的東西比較多。2.?有一定的延時。

利用ZooKeeper有兩個特性，就可以實時另一種集群機器存活性監(jiān)控系統(tǒng)：a.?客戶端在節(jié)點?x?上注冊一個Watcher，那么如果?x?的子節(jié)點變化了，會通知該客戶端。b.?創(chuàng)建EPHEMERAL類型的節(jié)點，一旦客戶端和服務器的會話結束或過期，那么該節(jié)點就會消失。

2. Master選舉則是zookeeper中最為經典的使用場景了。

在分布式環(huán)境中，相同的業(yè)務應用分布在不同的機器上，有些業(yè)務邏輯（例如一些耗時的計算，網絡I/O處理），往往只需要讓整個集群中的某一臺機器進行執(zhí)行， 其余機器可以共享這個結果，這樣可以大大減少重復勞動，提高性能，于是這個master選舉便是這種場景下的碰到的主要問題。

利用ZooKeeper的強一致性，能夠保證在分布式高并發(fā)情況下節(jié)點創(chuàng)建的全局唯一性，即：同時有多個客戶端請求創(chuàng)建?/currentMaster?節(jié)點，最終一定只有一個客戶端請求能夠創(chuàng)建成功。

zookeeper虛擬機安裝

略

原文地址：https://mp.weixin.qq.com/s?__biz=MzU0NTk2MjQyOA==&mid=2247483654&idx=1&sn=6909d8ec8b96cf6297e5fa1afcd86129&chksm=fb65a1d5cc1228c3b0898a05773e4396457e30a5567c4f0cb8bc6e652383bfd6bfce4537e21d&mpshare=1&scene=23&srcid=1112wZgWIS4QYtpGfvjHSJN5#rd

總結

以上是生活随笔為你收集整理的面试无忧之Zookeeper总结心得的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。