https://taozj.org/201701/learn-note-of-distributed-system-%286%29-application.html
至此，Paxos、Raft、ZAB代表著分布式系統中最常見的一致性協議都有所了解，但是除了PaxSql之外，對于分布式系統一致性原理的實際應用還處于一臉懵逼的狀態中。此處于是主要借著《從Paxos到Zookeeper:分布式一致性原理與實踐》中的案例，依靠ZooKeeper分布式系統組建，對分布式系統的使用情境做一個簡單的了解。畢竟嘛，我又不是做學術的，了解原理后不知道現實有什么用處又有啥意義…
ZooKeeper扮演者分布式系統的管理和協調框架的作用，通過前面對ZAB和ZooKeeper的了解，ZooKeeper通過ZNode數據模型和序列號、持久和臨時節點分類，以及Watcher事件通知機制，可以快速構建分布式應用的核心功能，看看Apache旗下那么多基于ZooKeeper的分布式項目就可曉而知了。ZooKeeper的集群達到3臺就可以正常工作了，但是工業上通常認為至少達到5臺才是合適的，一方面機器增多集群的可靠性增加了，再次集群工作過程中常常會有機器下線維護的情況，這樣在一臺機器下線的時候集群還可以容易一臺機器宕機而不停止服務。
再次說明，個人沒什么分布式系統的經驗，這些都是查閱資料摘抄得來，如果錯誤盡請指正，被我誤導概不負責！
一、數據發布/訂閱(配置中心) - Publish/Subscribe
發布/訂閱模式不僅僅會出現在這里，通常消息隊列的設計中會更加常用到這種模式。發布/訂閱模式功能可以分為這幾種模式：
(1). Push模式是服務器主動將數據更新發送給所有訂閱的客戶端，優點是實時性好，但是服務端的工作比較繁重，常常需要記錄各個客戶端的狀態信息，甚至要考慮消費者的消費能力實現流量控制工作；
(2). Pull模式則是由客戶端主動發起請求來獲取最新數據，通常采用定時機制輪訓拉取的方式進行，所以實時性較差，但好處是實現簡單；
(3). 還有就是結合兩者進行推拉相結合的方式，客戶端向服務端注冊自己關心的主題，一旦主題數據有所更新，服務端會向對應訂閱的客戶端發送事件通知，客戶端接收到事件通知后主動向服務器拉取最新的數據。
在系統開發中通常會遇到機器列表信息、運行時開關配置、數據庫配置等信息，這些數據的特點是數據規模比較小、數據內容在運行時候常常發生動態變更、相同的數據在多個機器中共享。在單機的情況下，可以通過共享內存，或者統一配置文件(可以使用文件系統的特性監測文件變更iNotify)來滿足這個需求，但是如果配置需要跨主機，尤其機器規模大且成員會發生變動的情況下共享這些動態信息就較為困難。
基于ZooKeeper的配置中心方案可以這樣設計：首先運行一個ZooKeeper服務器集群，然后在其上面創建周知路徑的ZNode；專用的配置管理程序可以修改ZNode上的配置信息，作為用戶更新配置的操作接口；關心這些配置的分布式應用啟動時候主動獲取配置信息一次，然后對ZNode注冊Watcher監聽，那么當ZNode的數據內容發生變化后，ZooKeeper就可以將這個變更通知發送給所有的客戶端，客戶端得知這個變更通知后就可以請求獲取最新數據。通過這種手段，就可以實現配置信息的集中式管理和動態更新部署的功能了。
二、負載均衡 - Load Balance
負載均衡在前面的Nginx中也介紹過了，Nginx支持3層和7層軟件負載均衡，對用戶看來這實際上是實現的基于服務端的負載均衡操作。其實負載均衡還可以在客戶端實現，之前介紹的memcached的負載均衡基本都是在客戶端通過一致性hash原理實現的。
通過ZooKeeper實現的負載均衡也是通過客戶端來實現的：ZooKeeper創建一個周知路徑的ZNode，其數據內容包含了可以提供服務的服務器地址信息，接收服務的客戶端在該ZNode上注冊Watcher以偵聽它的改變。在工作的時候客戶端獲取提供服務的服務器列表，在接收到修改事前之前可以緩存該列表提高性能，然后服務調用者可以采用自己某種特定負載均衡算法(比如Round Robin、HASH、響應時間、最少連接等算法)選取機器獲取服務。
為了使用方便，服務機器列表的配置可以采用全自動的方式，這也涉及到機器健康度檢測問題。可以設計一個健康度探測服務端，并負責更新ZNode中的機器列表：健康度探測服務端可以同機器中的列表建立TCP長連接，健康度探測服務端采用Ping-Pong心跳監測的方式進行健康度監測；也可以機器每隔一定的時間向這個健康度探測服務端發送數據包，如果健康度探測在某個超時時間后仍未收到某機器的數據包，就認定其不可用而將其從機器列表中進行刪除。(呃，后面想想，每個服務端機器把自己作為臨時ZNode創建在某個路徑下，這樣的偵測操作不是更加的方便？和集群管理重了)
三、命名服務 - Name Service
命名服務其實是指明了一種映射關系，在分布式開發中有很多的資源需要命名，比如主機地址，RPC服務列表等，客戶端根據名字可以獲取資源的實體、服務地址和提供者等信息。
ZooKeeper提供了方便的API，可以輕松的創建全局唯一的path，這個path就可以作為名稱使用，所以ZooKeeper的Name Service是開箱即用的。而且ZNode支持SEQUENTIAL屬性，通過創建順序節點的手法就可以創建具有相同名字但帶順序后綴的這樣很具有規則性的名字，這樣的命名服務顯然在保證命名唯一性的同時更具有解釋意義。
四、分布式協調/通知 - Coordinator
得益于ZooKeeper特有的Watcher注冊和異步通知的機制，可以實現分布式環境下不同機器，甚至是不同系統之間的通知和協調工作，以應對于數據變更的實時快速處理，這是和觀察者類似的工作模式。而且通過ZooKeepr作為一個事件的中介者，也起到了業務之間解除耦合的效果。
五、集群管理 - Management
用于對集群中的機器進行監控的情況，主要包括對集群運行狀態的收集，以及對集群和集群成員進行操作和控制。
傳統的運維都是基于Agent的分布式集群管理模式，通過在集群成員上部署該類服務軟件，該軟件負責主動向集群控制中心匯報機器的狀態信息。這種方式雖然直接，但是具有著固有的缺陷：很難實現跟業務相關的細化監控，通常都是對CPU、負載等通用信息進行監測；如果整個集群環境一致還可以，否則就必須面對集群中的異構成員進行兼容和適配的問題。
如果運行一個ZooKeeper集群，不僅通過臨時節點在會話結束后會自動消失的特性，可以快速偵測機器的上下線，而且可以通過創建特定的ZNode，集群中的機器就可以向控制中心報告更多主機相關甚至業務相關的信息，而且這一切操作都極為便利，只需要在業務端和控制中心進行適配就可以了。
六、Master選舉 - Election
可以應用于那些只需要一個主節點做特殊的工作，其他節點做普通的工作或者候命作為冗余節點的情況，比如數據庫的讀寫分離可以讓Master處理所有的寫任務，而剩余的讀請求由其他機器負載均衡完成，借此提供整個數據庫性能；類似的Master可以單獨處理一些復雜的邏輯或者計算，而將計算結果同步共享給集群中的其他主機使用，以此減少重復勞動提高資源利用率。
傳統情況下的選主可以使用數據庫唯一性索引簡單實現，在此約束下所有的機器創建同一條記錄時候只能有一個機器成功，那么可以讓這個獨一無二的機器作為Master，但是這種方法只是解決了競爭沖突問題，無法解決Master單點故障后整個系統不可用的問題，即不能實現高效快速的動態Master選舉功能。
對此，ZooKeeper的強一致性可以天然解決Master選舉的問題(注意這里的選主是客戶端的Master，和ZAB協議中的Leader沒有關系)：首先ZooKeeper保證在多個客戶端請求創建同一路徑描述的ZNode的情況下，只會有一個客戶端的請求成功；其次創建ZNode可以是臨時ZNode，那么一旦創建這個臨時ZNode的Master掛掉后會導致會話結束，這個臨時ZNode就會自動消失；在之前競爭Master失敗的客戶端，可以注冊該ZNode的Watcher偵聽，一旦接收到節點的變更事件，就表示Master不可用了，此時大家就可以即刻再次發起Master選舉操作了，以實現了一種高可用的automatic fail-over機制，滿足了機器在線率有較高要求的應用場景。
除了上面的方式，各個主機還可以通過創建臨時順序ZNode的方式，每個主機會具有不同的后綴，一旦當前的Master宕機之后自動輪訓下一個可用機器，而下線的機器也可以隨時再次上線創建新序列號的臨時順序節點。
七、分布式鎖 - Lock
主要用來進行分布式系統之間的訪問資源的同步手段。在使用中分布式鎖可以支持這些服務：保持獨占、共享使用和時序訪問。雖然關系數據庫在更新的時候，數據庫系統會根據隔離等級自動使用行鎖、表鎖機制保證數據的完整性，但是數據庫通常都是大型系統的性能瓶頸之所在，所以如果使用分布式鎖可以起到一定的協調作用，那么可以期待增加系統的運行效率。
保持獨占，就是當多個客戶端試圖獲取這把鎖的時候，只能有一個可以成功獲得該鎖，跟上面的Master選舉比較類似，當多個競爭者同時嘗試創建某個path(例如”_locknode_/guid-lock-“)的ZNode時候，ZooKeeper的一致性能夠保證只有一個客戶端成功，創建成功的客戶端也就擁有了這把互斥鎖，此時其他客戶端可以在這個ZNode上面注冊Watcher偵聽，以便得到鎖變更(如持鎖客戶端宕機、主動解鎖)的情況采取接下來的操作。
共享使用類似于讀寫鎖的功能，多個讀鎖可以同時對一個事務可見，但是讀鎖和寫鎖以及寫鎖和寫鎖之間是互斥的。鎖的名字按照類似”/share_lock/[Host]-R/W-SN”的形式創建臨時順序節點，在創建鎖的同時讀取/share_lock節點下的所有子節點，并注冊對/share_lock/節點的Watcher偵聽，然后依據讀寫所的兼容法則檢查比自己序號小的節點看是否可以滿足當前操作請求，如果不滿足就執行等待。當持有鎖的節點崩潰或者釋放鎖之后，所有處于等待狀態的節點就都得到了通知，實際中這會產生一個“驚群效應”，所以可以在上面注冊/share_lock/的Watcher事件進行細化，只注冊比自己小的那個子節點的Watcher偵聽就可以了，以避免不必要的喚醒。
時序訪問的方式，則是在這個時候每個請求鎖的客戶端都可以創建臨時順序ZNode的子節點，他們維系著一個帶有序列號的后綴，同時添加對鎖節點(或者像上面類似優化，只注冊序列號比自己小的那個子節點)的Watcher偵聽，這樣前面的客戶端釋放鎖之后，后面的客戶端會得到事件通知，然后按照一定順序接下來的一個客戶端獲得鎖。該模式能夠保證每個客戶端都具有訪問的機會，但是其是按照創建臨時順序子節點的順序按次序依次訪問的。
八、分布式隊列 - Queue
說到分布式隊列，目前已有相當多的成熟消息中間件了。在ZooKeeper的基礎上，可以方便地創建先進先出隊列，以及對數據進行聚集之后再統一安排處理的Barrier的工作模式。
先入先出之FIFO隊列算是最常見使用的數據模型了，類似于一個生產者-消費者的工作模型。生產者會創建順序ZNode，這些順序ZNode的后綴表明了創建的順序，消費者獲得這些順序ZNode后挑出序列號最小的進行消費，就簡單的實現了FIFO的數據類型。
對于另外一種Barrier(叫做屏障)工作模式，是需要把數據集聚之后再做統一處理，通常在大規模并行計算的場景上會使用到。這種隊列實現也很簡單，就是在創建順序ZNode的時候記錄隊列當前已經擁有的事務數目，如果達到了Barrier的數目，就表示條件就緒了于是創建類似“/synchronizing/start”的ZNode，而等待處理的消費者之前就偵聽該ZNode是否被創建，如果偵測到一旦創建了就表明事務的數目滿足需求了，于是可以啟動處理工作。
小結
其實，通過上面的查看，基于ZooKeeper實現特定需要的分布式應用是比較方便的，而且更可貴的是，上面的應用都是反反復復基于ZooKeeper的那幾條性質實現的！ZooKeeper真是個好東西！
本文完！
參考