1. 程式人生 > >對Zookeeper的簡單理解

對Zookeeper的簡單理解

           zookeeper,有些聽說過,有些人沒有,本人也是因為自己在做一個分散式的系統,由dubbo+zookeeper整合,所以接觸一下。到底是什麼東西?關於這個問題我首先到其官網和百度百科。其大致就是zookepper是hadoop的一個子專案,Apache軟體基金會下的一個專案,作為分散式協調作用的,作用型別與我們的大腦。而至於hadoop是什麼的話,我只能告訴你,是一個大資料的框架,具體是什麼,小的不清楚,哈哈。其實zookeeper在hadoop的作用,我可以再打個比喻。不管是hadoop還是其它分散式系統,就好比我們人的身體,有心臟,胃,有呼吸道系統。腿,手。。。。。等等。這麼多的子系統處於分散式環境,怎麼協調呢?那就是我們大腦(zookeeper),大家可以把zookeepr想成大腦,本身沒有其它功能,只有負責協調,聯絡子系統的功能,具體有哪些協調功能,往下看

         回到主題,zookeeper官網是這麼介紹它的

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them ,which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.

中文翻譯

ZooKeeper是一個集中式服務,用於維護配置資訊命名,提供分散式同步提供組服務所有這些型別的服務以分散式應用程式的某種形式或另一種形式使用。每次他們被實現,有很多工作,以修復錯誤和競爭條件是不可避免的。由於實現這些服務的難度,應用程式最初通常嘲弄它們,這使得它們在變化的存在下變得脆弱並且難以管理。即使正確地完成,這些服務的不同實施導致在應用被部署時的管理複雜性。

其實zookeeper怎麼協調hadoop以及其它的分散式系統的,我們可以從其介紹看出(標紅色部分),下面針對以上4個,我們簡單講一下,目的就是大家能簡單知道,瞭解zookeeper。

1、維護配置資訊

        這個的應用場景:

       比方說你有20多個,甚至更多的專案,共同使用很多配置檔案。當你要修改配置檔案時,你是不是要一個個去複製一遍,這樣很耗時間,精力,而且也不利於管理。而且現在專案都是分散式專案,在加上如果專案已經上線,那你如果一個個去改,然後重啟服務,那不是麻煩死了。

zookeeper提供的這個配置管理,就是把這公用的配置檔案提取出來放到一個地方,對這個地方(目錄節點)進行監聽,一旦配置資訊發生變化,每個應用程式就會收到 Zookeeper 的通知,然後從 Zookeeper 獲取新的配置資訊應用到系統中就好,專案不需要重啟,這樣上面一開始講的問題就解決了.
參考文章:http://www.jianshu.com/p/01388f06e75d

2、命名

   命名功能其實在dubbo上體現的,相信大家都知道jndi吧,如果不知道的話那我也沒有辦法了。zookeeper的命名服務跟jndi功能幾乎差不多,這樣說大家應該大致應該知道zookeeper的命名功能了。如果用過duboo+zookeeper整合的系統的人也能知道,正是因為這個命名服務,才方便了分散式個個專案之間的聯絡.在SOA框架裡面,RMI框架就是通過很簡單的你要某個伺服器上的URL來獲取遠方伺服器上的物件來呼叫服務,但到叢集,和分散式環境下,如何做到子專案之間呼叫的關係不會很複雜,不會到時候出現問題都不知道哪個服務呼叫的哪個,所以這裡就需要一個伺服器專門替我們管理這裡服務的資訊和調節,管理這些服務,讓我們可以把集中與專案的業務,zookeeper的命名功能就是這麼一個伺服器。當叢集的時候,相同的一個服務有很多個提供者,這些提供者啟動時,提供者伺服器的相關資訊,包括服務介面,地址,埠等一下連線提供者的資訊註冊到zookper中,當消費者要消費某服務的時候,從zookeeper中拿改服務的所有提供者資訊目錄,再根據dubbo的負載均衡機制從地圖中選擇一個提供者。其實從作用1,2可以看出,zookeeper大家可以看出是一個檔案系統(類似與linux檔案系統),還是那句話,zookeeper就是分散式中充當大腦。

3、分散式同步

     分散式的同步,又叫分散式鎖。相信對於鎖這個概念,大家都應該知道吧。對於單伺服器的鎖,大家都知道怎麼做。在分散式上,如果A要呼叫B的方法C,C方法也要加鎖,但這個鎖不能想單伺服器那樣加,因為這個是分散式呼叫的方法,不一樣。就像事務一樣,單伺服器上的事務和分散式事務不一樣。zookeeper提供了一個分散式同步(鎖)的方法,使用其提供的,客戶可以省了很多事。

zookeeper分散式鎖的思路

程序需要訪問共享資料時, 就在”/locks”節點下建立一個sequence型別的子節點, 稱為thisPath. 當thisPath在所有子節點中最小時, 說明該程序獲得了鎖. 程序獲得鎖之後, 就可以訪問共享資源了. 訪問完成後, 需要將thisPath刪除. 鎖由新的最小的子節點獲得.
有了清晰的思路之後, 還需要補充一些細節. 程序如何知道thisPath是所有子節點中最小的呢? 可以在建立的時候, 通過getChildren方法獲取子節點列表, 然後在列表中找到排名比thisPath前1位的節點, 稱為waitPath, 然後在waitPath上註冊監聽, 當waitPath被刪除後, 程序獲得通知, 此時說明該程序獲得了鎖.

大致流程圖


參考文獻

四、提供組服務

           其實這個組服務也就是叢集管理了,就像dubbo+zookeeer。伺服器上的服務註冊,或者獲取服務,都是在zookeeper上操作的,所以所謂的提供組服務也就包括建立組、加入組成員、列出組成員和刪除組成員。對於這些服務,主要通過zookeeper心跳機制,它會去檢測與其連線的一些伺服器的數量,以及資訊。什麼時候連上zookeeper,或什麼時候斷開都有其心跳機制完成。