【原創】大數據基礎之Zookeeper（4）應用場景

1 集羣配置管理

應用服務器的配置一般會放到properties文件中，格式爲：

system1.module2.prop3=value4

而後啓動的時候加載，這樣帶來的問題是啓動後沒法修改，想修改必需要重啓應用服務器；

• 一個簡單的替代方式是存放到數據庫中，應用服務器每次從數據庫中加載配置，這樣帶來的問題是因爲數據庫是一種昂貴的資源從而下降性能；
• 一個簡單的改進方式是存放到數據庫中後再存放到緩存中，應用服務器每次從緩存中加載配置，這時要解決的問題是數據庫和緩存的數據一致性問題，緩存的可靠性問題，並且會增長至關多的網絡IO（緩存讀操做）；
• 一個簡單的改進方式是應用服務器在本地也存一份配置，每次從緩存中加載配置或者定時從緩存中加載配置，緩存讀超時則使用本地配置；

回過頭來看，配置的名字是一個標準的樹形結構，能夠直接將全部配置以及值放到zookeeper中，

/config/system1/module2/prop3=value4

因爲zookeeper將全部的數據存放在內存中，因此讀操做很是快，應用服務器啓動以後從zookeeper中將全部配置存儲到本地一份，另外利用zookeeper的watcher，當配置修改以後全部的應用服務器均可以收到通知，同步修改本地配置便可，這樣達到的效果是若是配置沒有更新（極大機率事件），則全部的配置讀取都是本地操做（沒有網絡io）；若是配置有更新（極小機率事件），全部的應用服務器均可以及時收到通知並更新本地；

2 服務器分組及動態更新

在大規模集羣中一般有不少類型角色的服務器，這時會將服務器按照類型角色進行分組，而後能夠動態監控組內服務器的變動，而後作進一步處理；

好比在Dubbo中會將producer服務器分組，當producer服務器有變動時consumer端會及時收到更新方便作balance，這樣實現producer服務器動態增減以及自動發現；

好比在Kafka中會將consumer服務器分組，當consumer服務器有變動時也會觸發rebalance；

另外還能夠用來對組內服務器的存活進行監控報警；

3 Master主備

衆多的開源軟件中好比Hadoop（HDFS、YARN）、HBase、Spark Standalone、Oozie等，都是經過zookeeper來實現master的HA，實現主從切換；

好比：

/hadoop-ha/$hdfs_name/ActiveStandbyElectorLock

/yarn-leader-election/$yarn_name/ActiveStandbyElectorLock

/hbase/master

4 分佈式鎖

分佈式環境中有時須要在服務器之間進行協調，好比一個任務只容許在集羣中的一臺服務器運行等，經常使用的方法是利用數據庫鎖，這裏分爲樂觀鎖和悲觀鎖兩種實現；

好比Quartz的分佈式部署，就是利用數據庫鎖；

使用數據庫鎖有一些問題，1 數據庫資源昂貴，並且有併發數限制，悲觀鎖會直接佔用鏈接數，樂觀鎖可能因爲數據庫鏈接池滿致使鎖釋放，悲觀鎖可能因爲數據庫鏈接池滿致使卡住；2 數據庫鏈接有超時時間限制；

利用zookeeper的Ephemeral Node+Sequence Node+watch能夠很方便的實現分佈式鎖，Sequence Node能夠保證只有一個節點能拿到鎖，Ephemeral Node+watch能夠保證一旦鎖的持有者掛掉，其餘等待鎖的節點能夠立刻收到通知，同時再利用Sequence Node保證下一個節點能拿到鎖；