zookeeper的產生背景和概念
zookeeper:
背景
集中式管理
集中式的一致性問題
mysql---事務
分散式概念
分散式如何保證資料一致性問題?
多個節點之間如何做到各個節點的資料或狀態的一致性
1)hadoop的ha 兩個namenode 兩個namenode
實時的資料同步 資料一致
2)hadoop的ha 兩個namenode 一個active 一個standby的
狀態一致 standby實時的獲取 active的狀態資訊
3)hadoop的節點3個節點 3個節點配置檔案同步的
遠端傳送 叢集500個 延時性太長
zookeeper就是解決分散式一致性問題 分散式協調(一致)服務
目前zookeeper是沒有取代方案的 目前解決分散式一致性問題的
最完美的解決方案
分散式一致性的發展:
CAP理論:
絕對完美的一致性理論
C:Consistency,一致性: 多個副本保持一致 強一致性 實時一致性
一致性:
強一致性:寫入什麼 就能讀取什麼 寫操作完成
從其他任意備份立即可以讀取
弱一致性:儘量保證寫什麼 讀什麼 保證絕大部分
最終一致性:弱一致性的一個特殊情況
在一定的時間延遲內 寫資料的 所有的副本可以達到資料一致
最終肯定所有的副本保證資料一致的
一致性最高:只有一個副本
副本數量越多 一致性越難保證
A:Availability,可用性: 高可用
系統提供的服務必須一直處於可用,
對於使用者的每一個操作請求總是能在有限時間內返回結果
系統實時對外提供服務 即使存在節點宕機
可用性最高的時候:所有節點儲存的都有副本
副本越多 可用性越高
P:Partition Tolerance分割槽容錯性:
分散式系統在遇到任何網路分割槽故障時,
仍然需要能夠保證對外提供滿足一致性和可用性的服務
hdfs的副本策略
C和A 是衝突的 不可同時滿足的 實踐上不能達到的
要想實現CAP理論 在C 和A 之間平衡
BASE理論:
將c a做了平衡
c----最終一致性
a----基本可用性
Basically Available:基本可用
相應時間的損失
功能上的損失
Soft State:軟狀態
允許存在不同節點同步資料時出現延遲,
且出現數據同步延遲時存在的中間狀態也不會
影響系統的整體效能。
允許時間延遲
Eventually Consistent:最終一致性
系統中所有資料副本,在經過一段時間後,
都可以達到同步:要求最終達到一致,而不是實時一致
Quorum NRW:保證資料安全的演算法
quorum機制是分散式場景中常用的,
用來保證資料安全,
並且在分散式環境中實現最終一致性的投票演算法
N: 複製的節點數,即一份資料被儲存的份數。
R: Read 成功讀操作的最小節點數,即每次讀取成功需要的份數。
W: Write 成功寫操作的最小節點數 ,即每次寫成功需要的份數。
R+W>N
1)W=1 R=N
2)R=1 W=N
R W 權衡:
N=10
W=5
R=6
W=6
R=5
W=N/2+1
R=N/2
過半寫入
paxos演算法:選舉演算法
來源希臘的幫主選舉
一半以上的選民投票
過半選舉的機制
這個演算法的一個最完美的實現就是zookeeper
其他的實現都是不完美的實現
zookeeper是什麼
分散式一致性演算法的
ZooKeeper Google 的 Chubby
一個開源的實現。它提供了簡單原始的功能,分是一個分散式的,開放原始碼的分散式應用程式協調服務,是布式應用可以基於它實現更高階的服務,比
如分散式同步,配置管理,叢集管理,命名管理,佇列管理。