既生瑜（zookeeper）何生亮（redis）上
zookeeper和redis有很多東西是相通的，為什么zookeeper還能存活？請聽我娓娓道來。
目錄
一， 參考資料
二， ZooKeeper 分布式開源協調服務
三， 設計目標
四， 特性/保證
1，官網解釋
2，分析和使用
五， 安裝驗證，集群搭建
六，根據特性分析可實現功能
（一）前情提要
（二）可實現功能
（三）實際應用
七，Paxos解讀
（一）簡單描述
（二）運作流程
（三）解決沖突
（四）場景
八，ZAB
九，選舉機制
(一)選舉機制（謙讓制）的規則
(二)實際過程解讀
十，WATCH（基于觀察者模式的監控）
? ? ??（一）watch與健康檢測（心跳）
十一， 問題
問題1：單點的，如何維持高可用？
問題2：能做數據庫用么？
問題3：zk實現分布式鎖為什么比redis簡單？
問題4，如何使用observer？
問題5，最終一致性過程中，對外提供服務，腦裂怎么解決？? ??
問題6，zk為什么要分兩階段？
問題7，為什么必須有leader,把提議交給leader發起？
問題8，總統是怎么選出來的？
預知后事如何，且聽下會分解
一， 參考資料
1，官網
zookeeper.apache.org
https://zookeeper.apache.org/doc/current/zookeeperOver.html
2，Zookeeper全解析——Paxos作為靈魂
Zookeeper全解析——Paxos作為靈魂
3，馬xx周老師的視頻
致敬，每當我覺得自己學的很行的時候，總有人打我的臉，不過歡迎，查缺補漏，低調做人。
二， ZooKeeper 分布式開源協調服務
ZooKeeper 的設計目標之一是提供一個非常簡單的編程接口。它公開了一組簡單的原語，分布式應用程序可以基于這些原語來實現更高級別的同步、配置維護以及組和命名服務。它被設計為易于編程，并使用以熟悉的文件系統目錄樹結構為樣式的數據模型。它在 Java 中運行，并且具有 Java 和 C 的綁定。
三， 設計目標
| simple? | 簡單（API簡單） |
| replicated | 可復制（支持集群） |
| ordered | 有序（序列節點） |
| fast | 快速（讀寫分離，且恢復主時間快0.2秒） |
四， 特性/保證
1，官網解釋
- 順序一致性 - 來自客戶端的更新將按發送順序應用。（單點維護順序是簡單的）
- 原子性 - 更新要么成功要么失敗。沒有部分結果。
- 單一系統映像 - 無論連接到哪個服務器，客戶端都將看到相同的服務視圖。（統一視圖）
- 可靠性 - 應用更新后，它將從那時起一直存在，直到客戶端覆蓋更新。（持久化的事務日志和快照）
- 及時性 - 系統的客戶視圖保證在特定時間范圍內是最新的。（最終一致性）
2，分析和使用
快速? ?單機決策速度快，0.2秒恢復leader
擴展性
? ? ? ?角色：leader,follower,observer
? ? ? ? ? ? ? ? ?前兩個是主從，observer 是只讀（讀寫分離），為了平衡選舉的速度和放大查詢能力。
可靠性
? ? ? ?快速恢復leader
? ? ? ?數據的一致性（最終一致性）
? ? ? ? ? ?最終一致性過程中，對外提供服務，腦裂怎么解決？
? ? ? ? ? ?過半通過，一定有部分沒有最新數據，可以通過sync?
時序性
? ? ? ?單點維護順序是簡單的， 有序節點。
五， 安裝驗證，集群搭建
zk集群?
六，根據特性分析可實現功能
（一）前情提要
特性
1，統一配置管理? 存儲1M數據
2，分組管理 path結構
3，統一命名 squential（臨時有序）
4，同步? 臨時節點
（二）可實現功能
分布式鎖（臨時節點）：創建臨時節點，序號最小的獲得
隊列有事務的鎖：同一目錄下，按臨時節點的序列來有序執行。（搶票）
（三）實際應用：
大數據的HA選主依賴zk,通過鎖的方式選出主節點
負載均衡:kafka依賴zk,生產者通過監聽zookeeper上Broker節點感知Broker，Topic的狀態變更，來實現動態負載均衡機制
配置中心：通過監聽實時更新配置
七，Paxos解讀
以下是對Paxos的簡化，作者能力有限，如果我說的不清楚，歡迎查看原帖。
（一）簡單描述
Paxos基于消息傳遞的一致性算法。目前為止唯一的分布式一致性算法，其它算法都是對它的改進或簡化。
1，信任通信環節；算法成立的基本條件
2，一個環境（集群）中，有一群居民（observer）,議員（follower）選擇總統（leader），議員的總數（參與選舉的人越少，選舉的效率越高）是確定的，處理法案的事情；
3，法案的編號是唯一的(操作的事務id)，需要半數議員通過才能生效（過半通過）；
4，每個議員只會同意大于當前編號的提議，包括已生效和為生效的；（分布式，可能會延遲收到信息）
5，收到小于等于當前編號的提議，會拒絕，并告知通知者；每個議員有自己的記事本，會不斷更新這個編號（每個zk都有日志文件記錄事務id）；
6，只有總統能發起提議。
（二）運作流程
所有議員記事本初始編號都是0；
現在開始發起提議：自身編號+1，把1號提議發給所有議員；
當前編號是0，這個提議可以接收，記錄提議并 回復同意；
當提出者收到半數以上回復后，立即發通知給所有人，1號提議提議成立。
（三）解決沖突
s1,s2,s3初始? ? ?： 編號都是0；
s1,s2 發起提議 ?：1號提議，s1房租+1，s2房租+2；
s3 收到回復? ? ? ?：先收到s1的提議；緊接著又收到s2的提議，但是s2的提議號等于它自己當前的提議號，拒絕；
結果? ? ? ? ? ? ? ? ? ?：s1提議生效，s2提議失敗。
s2 如果想實現自己的提議怎么辦? :向s1或者s3打聽（sync?）最新法令內容（ZNode及數據），然后發起2號提議。
（四）場景
情況一：（讀和同步操作）
屁民甲(Client)到某個議員(ZK Server)那里詢問(Get)某條法令的情況(ZNode的數據)，議員毫不猶豫的拿出他的記事本(local storage)，查閱法令并告訴他結果，同時聲明：我的數據不一定是最新的。你想要最新的數據？沒問題，等著，等我找總統Sync一下再告訴你。
情況二：（觸發寫操作）
屁民乙(Client)到某個議員(ZK Server)那里要求政府歸還欠他的一萬元錢，議員讓他在辦公室等著，自己將問題反映給了總統，總統詢問所有議員的意見，多數議員表示欠屁民的錢一定要還，于是總統發表聲明，從國庫中拿出一萬元還債，國庫總資產由100萬變成99萬。屁民乙拿到錢回去了(Client函數返回)。
情況三：（三臺的集群，leader掛了，只有兩臺機器，選不出leader，集群無法使用）
總統（leader）突然掛了，議員(ZK Server)接二連三的發現聯系不上總統，于是各自發表聲明，推選新的總統，總統大選期間政府停業，拒絕屁民的請求。
八，ZAB
? ?Zab借鑒了Paxos算法，是特別為Zookeeper設計的支持崩潰恢復的原子廣播協議。基于該協議，zk實現了一種主備模型（即Leader和Follower模型）的系統架構來保證集群中各個副本之間數據的一致性。這里的主備系統架構模型，就是指只有一臺客戶端（Leader）負責處理外部的寫事務請求，然后Leader客戶端將數據同步到其他Follower節點。
? ? ? ? zk原子廣播協議，是Paxos的精簡版。
? ? ? ? 原子：成功；失敗。沒有中間態
? ? ? ? 廣播：分布式多節點，不代表全部知道。（UTP：不確定每人能收到）
? ? ? ? 隊列：FIFO，先進先出，順序性
? ? ? ? 內存：存放數據狀態
? ? ? ? 磁盤：存放日志
九，選舉機制
(一)選舉機制（謙讓制）的規則
? ?1，3888兩兩通訊（任何模型可以和其他任何節點通訊）；
? ?2，任何人都會給自己投1票；
? ?3，推舉制：先比較zxid，再比較myid;
? ?4，過半通過的數據才是真實數據，zxid只要存在就是真實存在的（可能會不是最新的）；
? ?5，發起投票的通訊會觸發接收者發起投票；
? 6，過半通過超過n/2+1。
(二)實際過程解讀
?
? ?在上述圖上加入節點node04，且這時node03掛掉，那么推舉有兩種情況，結果如下：
? ? ? ? 1，如果zxzid事務id沒有變化，主掛掉之后，永遠是myid最大的node04是leader。
? ? ? ? 2，如果原集群有事務操作，那么選舉的結果是node02。
? ? ? ?描述上述第二個過程
第一次通訊：node04先給自己投一票，node04 連接node01:對比（zxid，myid）后node01后，回執的觸發node01發起node04的投票，node04給node01投1票，
| node01 | node02 | node04 | |
| node01 | 1 | 0 | 1 |
| node02 | 0 | 0 | 0 |
| node04 | 0 | 0 | 1 |
? ? ? ? ? ? ? ? ?node01：2票 ；node02：0票 ；? ?node04：1票
第二次通訊：node04 連接node02:對比（zxid，myid）后node01后，回執的觸發node01發起node04的投票，node04給node02投1票，
| node01 | node02 | node04 | |
| node01 | 1 | 0 | 1 |
| node02 | 1 | 0 | 1 |
| node04 | 0 | 0 | 1 |
? ? ? ? ? ? ? ? ? ? ?node01：2票 ；node02：2票 ；? ?node04：1票 ? ?
第三次通訊：node02連接node01:對比（zxid，myid）后node01后，回執的同時觸發node01發起node02的投票，node01給node02投1票，這時*node02記錄的是自己3票，過半（超過n/2+1）,隨機開啟2888端口并發起廣播，新的紀元開始了。
| node01 | node02 | node04 | |
| node01 | 1 | 0 | 1 |
| node02 | 1 | 1 | 1 |
| node04 | 0 | 0 | 1 |
? ? ? ? ? ? ? ? ? ? ?node01：2票 ；node02：3票 ；? ?node04：1票 ? ?
有人問，每次一定是node02么，不一定的，這個是根據先zxid后myid比較大小決定的，myid就像人為指定的序列：就像公司里，職員A比職員B來的早，但是職員B經歷的項目多經驗更豐富（zxid），就可以更好的擔任領導職務。
十，WATCH（基于觀察者模式的監控）
（一）watch與健康檢測（心跳）
? ? 健康檢測：需要心跳驗證，頻繁的去按指定的時間去查看對方是否存活；且雙方都需實現心跳驗證。
? ? watch：通過臨時節點+session，當目標宕機后，會觸發回調函數，立即通知觀察者；
? ? watch的失效性更高（心跳有時間間隔，延遲，如果是多臺呢？成本是巨大的），并且沒有方向性（心跳是單向的）
十一， 問題
問題1：單點的，如何維持高可用？
leader單點故障-->服務不可用-->不可靠
但是zk說它自己是可靠且高可用的。那么一定有一種方式可以快速回復出一個leader來維持其高可用。
以下是官網提供：
1，性能
運行一個由 7 臺機器組成的 ZooKeeper 服務。我們運行了與之前相同的飽和基準測試，但這次我們將寫入百分比保持在 30% 不變，這是我們預期工作負載的保守比例。
3臺的集群服務能支撐8萬的并發
2，可靠性
響應各種故障
?每秒4-5W的并發
首先，ZooKeeper 能夠維持高吞吐量。
其次，花費不到 200 毫秒恢復leader。
最后，恢復就能夠再次提高吞吐量。
ZooKeeper 的性能方面意味著它可以用于大型分布式系統。可靠性方面使其不會成為單點故障。嚴格的排序意味著可以在客戶端實現復雜的同步原語。
問題2：能做數據庫用么？
ZooKeeper 旨在存儲協調數據：狀態信息、配置、位置信息等，因此每個節點存儲的數據通常很小，在字節到千字節范圍內。
ZooKeeper 應用程序在數千臺機器上運行，它在讀取比寫入更常見的情況下表現最佳，比率約為 10:1。
它支持，但不要，例如：一個資深的架構師可以勝任測試，運維，開發的工作，但這樣不會發揮他最大的作用。
節點建議是1M以內，并不是說它只能存這么多數據；
最佳讀寫比例10:1。
問題3：zk實現分布式鎖為什么比redis簡單？
zk 的session? =?redis??nx + 過期時間+client多線程過期時間
redis ： nx + 過期時間+多線程，客戶端會引出多線程，提高復雜度，更新過期時間。
zk ： 當client連接到zk會產生一個session（會話）來代表client，session有創建和消亡的概念，臨時節點Client存活則session存在，client掛了session也會消失。可以使用順序節點，通過監聽回調方法來逐個實現功能。
zk實現分布式鎖比redis實現更簡單，可用性更高，代價更小。稍微改動下還能實現有事務的分布式隊列。
問題4，如何使用observer？
? ? ? ? 配置zoo.cfg中添加observer
server.x=node0x:2888:3888 observer問題5，最終一致性過程中，對外提供服務，腦裂怎么解決？? ??
? ? ? ? ?? ? ?? 過半通過，一定有部分沒有最新數據，可以通過sync
問題6，zk為什么要分兩階段？
? ? ? ?(1),寫日志，過半通過；(2),提議成立。為了解決分布式通信中比較麻煩的事情，確保過半通過后，提議成交。
問題7，為什么必須有leader,把提議交給leader發起？
? ? ? 如果s1,s2,s3 都同時發起提議，票數都一致為1，那么都通過不了（大于自身編號的提議生效），永不過半。
問題8，總統是怎么選出來的？
? ? ? 選舉機制，zk的ZAB協議
預知后事如何，且聽下會分解
用API分別展示watch，CALLBACK，zk實現的一些功能，包括：分布式鎖，多進程下隊列有事務的鎖，注冊與發現。
總結：分別說下zookeeper和redis的一些共性和側重點。
總結
以上是生活随笔為你收集整理的既生瑜（zookeeper）何生亮（redis）上的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： R语言文本挖掘tm包详解（附代码实现）
- 下一篇： 2021年第八届大唐杯全国大学生移动通信