怎么實(shí)現(xiàn)zookeeper技術(shù)淺析

怎么實(shí)現(xiàn)zookeeper技術(shù)淺析 ，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

　Zookeeper是hadoop的一個子項目，雖然源自hadoop，但是我發(fā)現(xiàn)zookeeper脫離hadoop的范疇開發(fā)分布式框架的運(yùn)用越來越多。今天我想談?wù)剒ookeeper，下面不談如何使用zookeeper，而是zookeeper到底有哪些實(shí)際的運(yùn)用，哪些類型的應(yīng)用能發(fā)揮zookeeper的優(yōu)勢，最后談?wù)剒ookeeper對分布式網(wǎng)站架構(gòu)能產(chǎn)生怎樣的作用。

　　Zookeeper是針對大型分布式系統(tǒng)的高可靠的協(xié)調(diào)系統(tǒng)。由這個定義我們知道zookeeper是個協(xié)調(diào)系統(tǒng)，作用的對象是分布式系統(tǒng)。為什么分布式系統(tǒng)需要一個協(xié)調(diào)系統(tǒng)了？理由如下：

　　開發(fā)分布式系統(tǒng)是件很困難的事情，其中的困難主要體現(xiàn)在分布式系統(tǒng)的“部分失敗”?！安糠质　笔侵感畔⒃诰W(wǎng)絡(luò)的兩個節(jié)點(diǎn)之間傳送時候，如果網(wǎng)絡(luò)出了故障，發(fā)送者無法知道接收者是否收到了這個信息，而且這種故障的原因很復(fù)雜，接收者可能在出現(xiàn)網(wǎng)絡(luò)錯誤之前已經(jīng)收到了信息，也可能沒有收到，又或接收者的進(jìn)程死掉了。發(fā)送者能夠獲得真實(shí)情況的唯一辦法就是重新連接到接收者，詢問接收者錯誤的原因，這就是分布式系統(tǒng)開發(fā)里的“部分失敗”問題。

　　Zookeeper就是解決分布式系統(tǒng)“部分失敗”的框架。Zookeeper不是讓分布式系統(tǒng)避免“部分失敗”問題，而是讓分布式系統(tǒng)當(dāng)碰到部分失敗時候，可以正確的處理此類的問題，讓分布式系統(tǒng)能正常的運(yùn)行。

　　下面我要講講zookeeper的實(shí)際運(yùn)用場景：

　　場景一：有一組服務(wù)器向客戶端提供某種服務(wù)（例如：我前面做的分布式網(wǎng)站的服務(wù)端，就是由四臺服務(wù)器組成的集群，向前端集群提供服務(wù)），我們希望客戶端每次請求服務(wù)端都可以找到服務(wù)端集群中某一臺服務(wù)器，這樣服務(wù)端就可以向客戶端提供客戶端所需的服務(wù)。對于這種場景，我們的程序中一定有一份這組服務(wù)器的列表，每次客戶端請求時候，都是從這份列表里讀取這份服務(wù)器列表。那么這分列表顯然不能存儲在一臺單節(jié)點(diǎn)的服務(wù)器上，否則這個節(jié)點(diǎn)掛掉了，整個集群都會發(fā)生故障，我們希望這份列表時高可用的。高可用的解決方案是：這份列表是分布式存儲的，它是由存儲這份列表的服務(wù)器共同管理的，如果存儲列表里的某臺服務(wù)器壞掉了，其他服務(wù)器馬上可以替代壞掉的服務(wù)器，并且可以把壞掉的服務(wù)器從列表里刪除掉，讓故障服務(wù)器退出整個集群的運(yùn)行，而這一切的操作又不會由故障的服務(wù)器來操作，而是集群里正常的服務(wù)器來完成。這是一種主動的分布式數(shù)據(jù)結(jié)構(gòu)，能夠在外部情況發(fā)生變化時候主動修改數(shù)據(jù)項狀態(tài)的數(shù)據(jù)機(jī)構(gòu)。Zookeeper框架提供了這種服務(wù)。這種服務(wù)名字就是：統(tǒng)一命名服務(wù)，它和javaEE里的JNDI服務(wù)很像。

　　場景二：分布式鎖服務(wù)。當(dāng)分布式系統(tǒng)操作數(shù)據(jù)，例如：讀取數(shù)據(jù)、分析數(shù)據(jù)、最后修改數(shù)據(jù)。在分布式系統(tǒng)里這些操作可能會分散到集群里不同的節(jié)點(diǎn)上，那么這時候就存在數(shù)據(jù)操作過程中一致性的問題，如果不一致，我們將會得到一個錯誤的運(yùn)算結(jié)果，在單一進(jìn)程的程序里，一致性的問題很好解決，但是到了分布式系統(tǒng)就比較困難，因為分布式系統(tǒng)里不同服務(wù)器的運(yùn)算都是在獨(dú)立的進(jìn)程里，運(yùn)算的中間結(jié)果和過程還要通過網(wǎng)絡(luò)進(jìn)行傳遞，那么想做到數(shù)據(jù)操作一致性要困難的多。Zookeeper提供了一個鎖服務(wù)解決了這樣的問題，能讓我們在做分布式數(shù)據(jù)運(yùn)算時候，保證數(shù)據(jù)操作的一致性。

　　場景三：配置管理。在分布式系統(tǒng)里，我們會把一個服務(wù)應(yīng)用分別部署到n臺服務(wù)器上，這些服務(wù)器的配置文件是相同的（例如：我設(shè)計的分布式網(wǎng)站框架里，服務(wù)端就有4臺服務(wù)器，4臺服務(wù)器上的程序都是一樣，配置文件都是一樣），如果配置文件的配置選項發(fā)生變化，那么我們就得一個個去改這些配置文件，如果我們需要改的服務(wù)器比較少，這些操作還不是太麻煩，如果我們分布式的服務(wù)器特別多，比如某些大型互聯(lián)網(wǎng)公司的hadoop集群有數(shù)千臺服務(wù)器，那么更改配置選項就是一件麻煩而且危險的事情。這時候zookeeper就可以派上用場了，我們可以把zookeeper當(dāng)成一個高可用的配置存儲器，把這樣的事情交給zookeeper進(jìn)行管理，我們將集群的配置文件拷貝到zookeeper的文件系統(tǒng)的某個節(jié)點(diǎn)上，然后用zookeeper監(jiān)控所有分布式系統(tǒng)里配置文件的狀態(tài)，一旦發(fā)現(xiàn)有配置文件發(fā)生了變化，每臺服務(wù)器都會收到zookeeper的通知，讓每臺服務(wù)器同步zookeeper里的配置文件，zookeeper服務(wù)也會保證同步操作原子性，確保每個服務(wù)器的配置文件都能被正確的更新。

　　場景四：為分布式系統(tǒng)提供故障修復(fù)的功能。集群管理是很困難的，在分布式系統(tǒng)里加入了zookeeper服務(wù)，能讓我們很容易的對集群進(jìn)行管理。集群管理最麻煩的事情就是節(jié)點(diǎn)故障管理，zookeeper可以讓集群選出一個健康的節(jié)點(diǎn)作為master，master節(jié)點(diǎn)會知道當(dāng)前集群的每臺服務(wù)器的運(yùn)行狀況，一旦某個節(jié)點(diǎn)發(fā)生故障，master會把這個情況通知給集群其他服務(wù)器，從而重新分配不同節(jié)點(diǎn)的計算任務(wù)。Zookeeper不僅可以發(fā)現(xiàn)故障，也會對有故障的服務(wù)器進(jìn)行甄別，看故障服務(wù)器是什么樣的故障，如果該故障可以修復(fù)，zookeeper可以自動修復(fù)或者告訴系統(tǒng)管理員錯誤的原因讓管理員迅速定位問題，修復(fù)節(jié)點(diǎn)的故障。大家也許還會有個疑問，master故障了，那怎么辦了？zookeeper也考慮到了這點(diǎn)，zookeeper內(nèi)部有一個“選舉領(lǐng)導(dǎo)者的算法”，master可以動態(tài)選擇，當(dāng)master故障時候，zookeeper能馬上選出新的master對集群進(jìn)行管理。

　　下面我要講講zookeeper的特點(diǎn)：

1. zookeeper是一個精簡的文件系統(tǒng)。這點(diǎn)它和hadoop有點(diǎn)像，但是zookeeper這個文件系統(tǒng)是管理小文件的，而hadoop是管理超大文件的。

2. zookeeper提供了豐富的“構(gòu)件”，這些構(gòu)件可以實(shí)現(xiàn)很多協(xié)調(diào)數(shù)據(jù)結(jié)構(gòu)和協(xié)議的操作。例如：分布式隊列、分布式鎖以及一組同級節(jié)點(diǎn)的“領(lǐng)導(dǎo)者選舉”算法。

3. zookeeper是高可用的，它本身的穩(wěn)定性是相當(dāng)之好，分布式集群完全可以依賴zookeeper集群的管理，利用zookeeper避免分布式系統(tǒng)的單點(diǎn)故障的問題。

4. zookeeper采用了松耦合的交互模式。這點(diǎn)在zookeeper提供分布式鎖上表現(xiàn)最為明顯，zookeeper可以被用作一個約會機(jī)制，讓參入的進(jìn)程不在了解其他進(jìn)程的（或網(wǎng)絡(luò)）的情況下能夠彼此發(fā)現(xiàn)并進(jìn)行交互，參入的各方甚至不必同時存在，只要在zookeeper留下一條消息，在該進(jìn)程結(jié)束后，另外一個進(jìn)程還可以讀取這條信息，從而解耦了各個節(jié)點(diǎn)之間的關(guān)系。

5. zookeeper為集群提供了一個共享存儲庫，集群可以從這里集中讀寫共享的信息，避免了每個節(jié)點(diǎn)的共享操作編程，減輕了分布式系統(tǒng)的開發(fā)難度。

6. zookeeper的設(shè)計采用的是觀察者的設(shè)計模式，zookeeper主要是負(fù)責(zé)存儲和管理大家關(guān)心的數(shù)據(jù)，然后接受觀察者的注冊，一旦這些數(shù)據(jù)的狀態(tài)發(fā)生變化，Zookeeper 就將負(fù)責(zé)通知已經(jīng)在 Zookeeper 上注冊的那些觀察者做出相應(yīng)的反應(yīng)，從而實(shí)現(xiàn)集群中類似 Master/Slave 管理模式。

　　由此可見zookeeper很利于分布式系統(tǒng)開發(fā)，它能讓分布式系統(tǒng)更加健壯和高效。

　　前不久我參加了部門的hadoop興趣小組，測試環(huán)境的hadoop、mapreduce、hive及hbase都是我來安裝的，安裝hbase時候安裝要預(yù)先安裝zookeeper，最早我是在四臺服務(wù)器上都安裝了zookeeper，但是同事說安裝四臺和安裝三臺是一回事，這是因為zookeeper要求半數(shù)以上的機(jī)器可用，zookeeper才能提供服務(wù)，所以3臺的半數(shù)以上就是2臺了，4臺的半數(shù)以上也是兩臺，因此裝了三臺服務(wù)器完全可以達(dá)到4臺服務(wù)器的效果，這個問題說明zookeeper進(jìn)行安裝的時候通常選擇奇數(shù)臺服務(wù)器。在學(xué)習(xí)hadoop的過程中，我感覺zookeeper是最難理解的一個子項目，原因倒不是它技術(shù)負(fù)責(zé)，而是它的應(yīng)用方向很讓我困惑，所以我有關(guān)hadoop技術(shù)第一篇文章就從zookeeper開始，也不講具體技術(shù)實(shí)現(xiàn)，而從zookeeper的應(yīng)用場景講起，理解了zookeeper應(yīng)用的領(lǐng)域，我想再學(xué)習(xí)zookeeper就會更加事半功倍。

　　之所以今天要談?wù)剒ookeeper，也是為我上一篇文章分布式網(wǎng)站框架的補(bǔ)充。雖然我設(shè)計網(wǎng)站架構(gòu)是分布式結(jié)構(gòu)，也做了簡單的故障處理機(jī)制，比如：心跳機(jī)制，但是對集群的單點(diǎn)故障還是沒有辦法的，如果某一臺服務(wù)器壞掉了，客戶端任然會嘗試連接這個服務(wù)器，導(dǎo)致部分請求的阻塞，也會導(dǎo)致服務(wù)器資源的浪費(fèi)。不過我目前也不想去修改自己的框架，因為我總覺得在現(xiàn)有的服務(wù)上添加zookeeper服務(wù)會影響網(wǎng)站的效率，如果有獨(dú)立的服務(wù)器集群部署zookeeper還是值得考慮的，但是服務(wù)器資源太寶貴了，這個可能性不大。幸好我們部門也發(fā)現(xiàn)了這樣的問題，我們部門將開發(fā)一個強(qiáng)大的遠(yuǎn)程調(diào)用框架，將集群管理和通訊管理這塊剝離出來，集中式提供高效可用的服務(wù)，等部門的遠(yuǎn)程框架開發(fā)完畢，我們的網(wǎng)站加入新的服務(wù)，我想我們的網(wǎng)站將會更加穩(wěn)定和高效。

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注億速云行業(yè)資訊頻道，感謝您對億速云的支持。