目錄
一、 zookeeper 簡介
二、 zookeeper 的作用
1.1 配置管理
1.2 名字服務
1.3 分布式鎖
1.4 集群管理
三、 zookeeper 的儲存結構
3.1 znode
3.2 znode 節點型別
3.2.1 persistent 持久化節點:
3.2.2 persistent_sequential 持久順序節點：
3.3.3 ephemeral 臨時節點：
3.3.4 ephemeral_sequential 臨時自動編號節點：
顧名思義
zookeeper
就是動物園管理員，他是用來管
hadoop
（大象）、
hive(蜜蜂)
、pig(小豬)
的管理員，
apache hbase
和 apache solr
的分布式集群都用到了
zookeeper
；zookeeper:
是乙個分布式的、開源的程式協調服務，是
hadoop
專案下的乙個子專案。他提供的主要功
能包括：配置管理、名字服務、分布式鎖、集群管理。
在我們的應用中除了**外，還有一些就是各種配置。比如資料庫連線等。一般我們都是使用配置檔案的方式，在**中引入這些配置檔案。當我們只有一種配置，只有一台服務
器，並且不經常修改的時候，使用配置檔案是乙個很好的做法，但是如果我配置非常多，
有很多伺服器都需要這個配置，這時使用配置檔案就不是個好主意了。這個時候往往需要尋
找一種集中管理配置的方法，我們在這個集中的地方修改了配置，所有對這個配置感興趣的
都可以獲得變更。
zookeeper
就是這種服務，它使用
zab
這種一致性協議來提供一致性。現
在有很多開源專案使用
zookeeper
來維護配置，比如在
hbase
中，客戶端就是連線乙個
zookeeper
，獲得必要的
hbase
集群的配置資訊，然後才可以進一步操作。還有在開源的消
息佇列
kafka
中，也使用
zookeeper
來維護
broker
的資訊。在
alibaba
開源的
soa
框架 dubbo
中也廣泛的使用
zookeeper
管理一些配置來實現服務治理。
名字服務這個就很好理解了。比如為了通過網路訪問乙個系統，我們得知道對方的
ip位址，但是
ip 位址對人非常不友好，這個時候我們就需要使用網域名稱來訪問。但是計算機是
不能是網域名稱的。怎麼辦呢？如果我們每台機器裡都備有乙份網域名稱到
ip 位址的對映，這個倒
是能解決一部分問題，但是如果網域名稱對應的
ip 發生變化了又該怎麼辦呢？於是我們有了
dns
這個東西。我們只需要訪問乙個大家熟知的
(known)
的點，它就會告訴你這個網域名稱對應
的 ip
是什麼。在我們的應用中也會存在很多這類問題，特別是在我們的服務特別多的時候，
熟知的訪問點，這裡提供統一的入口，那麼維護起來將方便得多了。
其實在第一篇文章中已經介紹了
zookeeper
是乙個分布式協調服務。這樣我們就可以利用
zookeeper
來協調多個分布式程序之間的活動。比如在乙個分布式環境中，為了提高可靠
性，我們的集群的每台伺服器上都部署著同樣的服務。但是，一件事情如果集群中的每個服
務器都進行的話，那相互之間就要協調，程式設計起來將非常複雜。而如果我們只讓乙個服務進
行操作，那又存在單點。通常還有一種做法就是使用分布式鎖，在某個時刻只讓乙個服務去
幹活，當這台服務出問題的時候鎖釋放，立即
fail over
到另外的服務。這在很多分布式系統
中都是這麼做，這種設計有乙個更好聽的名字叫
leader election(leader 選舉)
。比如
hbase 的
master
就是採用這種機制。但要注意的是分布式鎖跟同乙個程序的鎖還是有區別的，所
以使用的時候要比同乙個程序裡的鎖更謹慎的使用。
在分布式的集群中，經常會由於各種原因，比如硬體故障，軟體故障，網路問題，有些節點會進進出出。有新的節點加入進來，也有老的節點退出集群。這個時候，集群中其他機
器需要感知到這種變化，然後根據這種變化做出對應的決策。比如我們是乙個分布式儲存系
統，有乙個**控制節點負責儲存的分配，當有新的儲存進來的時候我們要根據現在集群目
前的狀態來分配儲存節點。這個時候我們就需要動態感知到集群目前的狀態。還有，比如一
個分布式的
soa
架構中，服務是乙個集群提供的，當消費者訪問某個服務時，就需要採用
某種機制發現現在有哪些節點可以提供該服務
(這也稱之為服務發現，比如
alibaba
開源的soa
框架 dubbo
就採用了
zookeeper
作為服務發現的底層機制
)。還有開源的
kafka
佇列就採用了
zookeeper
作為 cosnumer
的上下線管理。
在 zookeeper
中，znode
是乙個跟
unix
檔案系統路徑相似的節點，可以往這個節點儲存
或獲取資料。zookeeper
底層是一套資料結構。這個儲存結構是乙個樹形結構，其上的每乙個節點，
我們稱之為
「znode」
zookeeper
中的資料是按照「樹
」結構進行儲存的。而且
znode
節點還分為
4 中不同的類
型。 每乙個
znode
預設能夠儲存
1mb
的資料（對於記錄狀態性質的資料來說，夠了）
可以使用
zkcli
命令，登入到
zookeeper
上，並通過 ls、
create
、delete
、get
、set
等命令操作這些
znode
節點所謂持久節點，是指在節點建立後，就一直存在，直到有刪除操作來主動清除這個節點。否則不會因為建立該節點的客戶端會話失效而消失。
這類節點的基本特性和上面的節點類
型是一致的。額外的特性是，在
zk 中，每個父節點會為他的第一級子節點維護乙份時序，
會記錄每個子節點建立的先後順序。基於這個特性，在建立子節點的時候，可以設定這個屬
性，那麼在建立節點過程中，
zk 會自動為給定節點名加上乙個數字字尾，作為新的節點名。
這個數字字尾的範圍是整型的最大值。在建立節點的時候只需要傳入節點 「
/test_
」，這樣
之後，zookeeper
自動會給」
test_
」後面補充數字。
和持久節點不同的是，臨時節點的生命週期和客戶端會話繫結。也就是說，如果客戶端會話失效，那麼這個節點就會自動被清除掉。注意，這裡提
到的是會話失效，而非連線斷開。另外，在臨時節點下面不能建立子節點。
這裡還要注意一件事，就是當你客戶端會話失效後，所產生的節點也不是一下子就消失
了，也要過一段時間，大概是
10 秒以內，可以試一下，本機操作生成節點，在伺服器端用
命令來檢視當前的節點數目，你會發現客戶端已經
stop
，但是產生的節點還在。
此節點是屬於臨時節點，不過帶有順序，客戶端會話結束節點就消失。
try，catch和finally的作用結果
1.如果程式是從try 塊或者catch 塊中返回時，finally中的 總會執行。而且finally語句在return語句執行之後return返回之前執行的。2.當finally有返回值 return 時，會直接返回。不會再去返回try或者catch中的返回值。3.如果try和catch的retu...
Kafka在zookeeper中的資料結構
一 brokers節點 brokers brokers topics brokers topics test2 brokers topics test2 partitions brokers topics test2 partitions 0 brokers topics test2 partiti...
棧 順序儲存結
棧是線性表的特例，棧的順序儲存其實也是線性表順序的儲存的簡化，我們簡稱為順序棧。對於這種只能一頭插入，一頭刪除的線性表來說，下標為0的一端作為棧底比較好，因為首元素都存在棧底，變化最小。我們定義乙個top變數來指示棧頂元素在陣列中的位置，這top如同中學的游標卡尺的游標，它可以來回移動，意味著棧頂的...