什麼是單點故障
通常在分佈式系統採用的部署方式是主從模式即一主多從，一個主節點連接着多個從節點，主節點負責分發任務，從節點負責處理任務，當我們主節點出現故障的時候，導致從節點不能繼續提供服務，進而導致整個系統的崩潰，我們把這種故障叫做單點故障
什麼是分佈式協調技術
分佈式協調技術主要用來解決分佈式環境當中多個進程之間的同步控制，讓他們有序的去訪問某種臨界資源，防止造成”髒數據”的後果。分佈式協調技術的核心就是爲了實現分佈式鎖
什麼是分佈式鎖,如何實現分佈式鎖
分佈式鎖是控制分佈式系統之間共同訪問共享資源的一種鎖的實現，如果不同的系統的不同主機之間共享了某個資源時，往往需要分佈式鎖來保證一致性。
2.分佈式鎖要具備以下幾個條件
1.在分佈式系統環境下，同一個方法或者屬性，在同一時間只能被一臺機器的一個線程使用
2. 高可用的獲得鎖和釋放鎖
3. 高性能的獲得鎖和釋放鎖
4. 具備可重入特性
5. 具備防止鎖失效機制，防止死鎖
6. 具備非阻塞特性，如果沒有獲得鎖直接返回獲取鎖失敗
3.分佈式鎖的核心要素 是加鎖 解鎖 鎖超時
要解決三個問題
1.要保證原子性操作 （加鎖和鎖超時）
2. 要防止誤刪鎖
3.再有一個守護線程 爲鎖續命
我們一般是使用zookeeper去實現分佈式鎖
什麼是zookeeper
zookeeper是一個爲分佈式應用提供一致性的的開源組件，它的內部是一個分層的文件目錄樹結構，樹是由節點所組成，Zookeeper 的數據存儲也同樣是基於節點，這種節點叫做 Znode,Znode 的引用方式是路徑引用，類似於文件路徑：Znode裏面包含以下元素
- data 用來存儲數據的信息
- ACL 記錄Znode的訪問權限，即哪些人可以訪問哪些ip
- stat 元數據
- child 當前節點的子節點引用
zookeeper如何實現分佈式鎖
zookeeper的節點類型有4種 分爲臨時節點。臨時順序節點，永久節點，永久順序節點
那麼ZooKeeper如何實現分佈式鎖呢？思路如下：
首先，在 Zookeeper 當中創建一個持久節點 ParentLock。當第一個客戶端想要獲得鎖時，需要在 ParentLock 這個節點下面創建一個臨時順序節點 Lock1。
之後，Client1 查找 ParentLock 下面所有的臨時順序節點並排序，判斷自己所創建的節點 Lock1 是不是順序最靠前的一個。如果是第一個節點，則成功獲得鎖。
這時候，如果再有一個客戶端 Client2 前來獲取鎖，則在 ParentLock 下載再創建一個臨時順序節點 Lock2。
Client2 查找 ParentLock 下面所有的臨時順序節點並排序，判斷自己所創建的節點 Lock2 是不是順序最靠前的一個，結果發現節點 Lock2 並不是最小的。
於是，Client2 向排序僅比它靠前的節點 Lock1 註冊 Watcher，用於監聽 Lock1 節點是否存在。這意味着 Client2 搶鎖失敗，進入了等待狀態。
後面的依次類推，當第一個客戶端使用完鎖之後 ，監聽它的那個客戶端就會知道，它就會再去parentLock下查找所有的節點並判斷自己是不是最前的節點，如果是就拿到鎖，這樣就會形成一個有序的等待隊列，所以說zookeeper可以讓臨界資源有序的被訪問，這就是zookeeper實現分佈式鎖的方式
zookeeper如何解決單點故障問題
爲了解決單點故障問題，我們傳統的方式是採用一個主節點和一個備用主節點的方式，即備用主節點會間斷的給主節點發ping包 主節點也會間斷的給備用主節點回ping包，但是如果由於網絡原因主節回給備用主節點的包 備用主節點沒有收到，它以爲主節點掛了，自己就開始充當主節點了 此時就會出現雙主問題，就會導致數據的紊亂，所以我們zookeeper來解決這個問題，zookeeper也叫服務注與發現中心，就是每個服務在啓動的時候都會到這個中心去註冊，然後這個中心就會去選舉誰來成爲主節點，成爲主節點的就去當主節點，其他備用主節點全部成爲阻塞狀態，當出現相同網絡問題的時候，我們會直接把主節點從服務列表中直接刪掉，然後由這個中心繼續選擇主節點，那個被刪除的主節點會重新向我們的註冊中心註冊成爲備用主節點，然後依次循環這個過程就可以解決單點故障。
zookeeper怎麼實現服務的註冊與發現
zookeeper可以通過watcher通知機制來實現服務的註冊與發現，對於集羣部署的服務在啓動的時候就會向zookeeper的服務端註冊，就是把訪問路徑寫到zookeeper的znode裏面去，當用戶去訪問的時候先通過api網關去請求地址，也就是對應zookeeper服務端的watchTable裏面的key 然後zookeeper會執行getData方法並攜帶watch參數監聽着與key對應的value的那個服務，這個時候用戶就能得到正常的響應，一旦key對應的那個value服務掛了，watcher可以監聽到，所以zookeeper的服務端會第一時間刪除那個服務對應的ip，因爲是集羣模式，zookeeper可以重新選舉一個新的IP，然後在api網關中的zookeeper客戶端也會異步收到服務端的通知 更新列表，這樣就可以達到高可用的指標。
zookeeper是如何實現崩潰恢復的，它是怎麼實現自身高可用
zookeeper本身一般也是主從模式部署的 在寫數據的時候先寫主節點（leader）,在同步到從節點，在讀取數據時，直接讀取任意從節點。假如zookeeper的當前主節點掛點了，集羣就會進行崩潰恢復，分爲以下幾個階段
- 選舉階段，此時集羣中的所有節點都處於looking狀態，它們會各自向其他節點發起投票，投票當中包含自己服務器id和最新事物id,當一個節點獲得一半以上的節點的投票的時候，這個節點就會成爲準leader狀態，其他節點變成follwing。
- 發現階段，用於在從節點當中發現最新的事物日誌，然後leader更新自身的日誌
- 同步階段，最後leader把最新的事物日誌,同步給所有的following,當半數的following同步成功，它才成爲真正的leader
自此集羣崩潰恢復成功
zookeeper如何實現數據同步
zookeeper的數據同步不是強一致性，也不是弱一致性，而是處於2者之間的順序一致性，它依靠事物id和版本號，保證了數據的更新和讀取是有序的
它的執行過程如下
1.客戶端把寫入數據請求發送給任意的follower
2.follwer把寫入數據的請求轉發給leader
3.leader採用2階段提交的方式，先發送propose廣播給follower
4.follower接收到廣播之後，先寫入日誌就是已經執行但是還沒提交，返回一個ack給leader
5.leader 接受到半數以上ack消息，廣播commit請求給follwer， follwer開始提交
