資料內(nèi)容：

1. Zookeeper是什么？ Zookeeper是一個開放源碼的 分布式協(xié)調(diào)服務(wù) ，它是集群的管理者，監(jiān)視著集群中各個節(jié)點(diǎn)的狀態(tài)根據(jù)節(jié)點(diǎn) 提交的反饋進(jìn)行下一步合理操作。最終，將簡單易用的接口和性能高效、功能穩(wěn)定的系統(tǒng)提供給用戶。 分布式應(yīng)用程序可以基于Zookeeper實(shí)現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱、負(fù)載均衡、命名服務(wù)、分布式協(xié)調(diào)/通知、集 群管理、Master選舉、分布式鎖和分布式隊(duì)列等功能。 Zookeeper保證了如下分布式一致性特性： 順序一致性 原子性 單一視圖 可靠性 實(shí)時性（最終一致性） 客戶端的讀請求可以被集群中的任意一臺機(jī)器處理，如果讀請求在節(jié)點(diǎn)上注冊了監(jiān)聽器，這個監(jiān)聽器也是由 所連接的Zookeeper機(jī)器來處理。對于寫請求，這些請求會同時發(fā)給其他Zookeeper機(jī)器并且達(dá)成一致后， 請求才會返回成功。因此，隨著Zookeeper的集群機(jī)器增多，讀請求的吞吐會提高但是寫請求的吞吐會下 降。有序性是Zookeeper中非常重要的一個特性，所有的更新都是全局有序的，每個更新都有一個唯一的時 間戳，這個時間戳稱為 zxid（Zookeeper Transaction Id）。而讀請求只會相對于更新有序，也就是讀請求 的返回結(jié)果中會帶有這個Zookeeper最新的zxid。 2. Zookeeper和dubbo的區(qū)別？ Zookeeper： Zookeeper用來注冊服務(wù)和進(jìn)行負(fù)載均衡，哪一個服務(wù)由哪一個機(jī)器來提供必需讓調(diào)用者知 道， 簡單來說就是ip地址和服務(wù)名稱的對應(yīng)關(guān)系。當(dāng)然也可以通過硬編碼的方式把這種對應(yīng)關(guān)系在調(diào)用方業(yè) 務(wù)代碼中實(shí)現(xiàn)，但是如果提供服務(wù)的機(jī)器掛掉，調(diào)用者無法知曉，如果不更改代碼會繼續(xù)請求掛掉的機(jī)器提 供服務(wù)。 Zookeeper通過 心跳機(jī)制 可以檢測掛掉的機(jī)器并將掛掉機(jī)器的ip和服務(wù)對應(yīng)關(guān)系從列表中刪除。 至于支持高并發(fā)，簡單來說就是橫向擴(kuò)展，在不更改代碼的情況通過添加機(jī)器來提高運(yùn)算能力。通過添加新 的機(jī)器向 Zookeeper注冊服務(wù)，服務(wù)的提供者多了能服務(wù)的客戶就多了。 Dubbo: 是管理中間層的工具，在業(yè)務(wù)層到數(shù)據(jù)倉庫間有非常多服務(wù)的接入和服務(wù)提供者需要調(diào)度，dubbo 提供一個框架解決這個問題。 Zookeeper和 Dubbo的關(guān)系： Dubbo將注冊中心進(jìn)行抽象，它可以外接不同的存儲媒介給注冊中心提供服 務(wù)，有 Zookeeper， Memcached， Redis等。注意這里的 dubbo只是一個框架，這個框架中要完成調(diào)度必 須要有一個分布式的注冊中心，儲存所有服務(wù)的元數(shù)據(jù)，可以用Zookeeper，也可以用別的。 3. Zookeeper的java客戶端都有哪些? Zookeeper自帶的 Zookeeperclient Apache開源的 Curator 4. Zookeeper提供了什么？ 文件系統(tǒng) 通知機(jī)制 5. 說說Zookeeper文件系統(tǒng) Zookeeper提供一個多層級的節(jié)點(diǎn)命名空間(節(jié)點(diǎn)稱為 znode)。與文件系統(tǒng)不同的是，這些節(jié)點(diǎn)都可以設(shè)置 關(guān)聯(lián)的數(shù)據(jù)，而文件系統(tǒng)中只有文件節(jié)點(diǎn)可以存放數(shù)據(jù)而目錄節(jié)點(diǎn)不行。Zookeeper為了保證高吞吐和低延 遲，在內(nèi)存中維護(hù)了這個樹狀的目錄結(jié)構(gòu)，這種特性使得 Zookeeper不能用于存放大量的數(shù)據(jù),每個節(jié)點(diǎn)的存 放數(shù)據(jù)上限為1M。 6. 說說ZAB協(xié)議？ ZAB協(xié)議是為分布式協(xié)調(diào)服務(wù)Zookeeper專門設(shè)計(jì)的一種支持 崩潰恢復(fù)的原子廣播協(xié)議 。 ZAB協(xié)議包括兩種基本的模式： 崩潰恢復(fù) 和 消息廣播 。 當(dāng)整個Zookeeper集群剛剛啟動或者Leader服務(wù)器宕機(jī)、重啟或者網(wǎng)絡(luò)故障導(dǎo)致不存在過半的服務(wù)器與 Leader服務(wù)器保持正常通信時，所有進(jìn)程（服務(wù)器）進(jìn)入崩潰恢復(fù)模式，首先選舉產(chǎn)生新的Leader服務(wù)器， 然后集群中Follower服務(wù)器開始與新的Leader服務(wù)器進(jìn)行數(shù)據(jù)同步，當(dāng)集群中超過半數(shù)機(jī)器與該Leader服務(wù) 器完成數(shù)據(jù)同步之后，退出恢復(fù)模式進(jìn)入消息廣播模式，Leader服務(wù)器開始接收客戶端的事務(wù)請求生成事物 提案來進(jìn)行事務(wù)請求處理。 7. Znode有哪些類型 PERSISTENT：持久節(jié)點(diǎn) 除非手動刪除，否則節(jié)點(diǎn)一直存在于Zookeeper上 EPHEMERAL：臨時節(jié)點(diǎn) 臨時節(jié)點(diǎn)的生命周期與客戶端會話綁定，一旦客戶端會話失效（客戶端與 Zookeeper連接斷開不一定會話失效），那么這個客戶端創(chuàng)建的所有臨時節(jié)點(diǎn)都會被移除。 PERSISTENT_SEQUENTIAL：持久順序節(jié)點(diǎn) 基本特性同持久節(jié)點(diǎn)，只是增加了順序?qū)傩?，?jié)點(diǎn)名后邊會 追加一個由父節(jié)點(diǎn)維護(hù)的自增整型數(shù)字。 EPHEMERAL_SEQUENTIAL：臨時順序節(jié)點(diǎn) 基本特性同臨時節(jié)點(diǎn)，增加了順序?qū)傩裕?jié)點(diǎn)名后邊會追 加一個由父節(jié)點(diǎn)維護(hù)的自增整型數(shù)字。 8. Zookeeper節(jié)點(diǎn)宕機(jī)如何處理？ Zookeeper本身也是集群，推薦配置 不少于3個服務(wù)器 。Zookeeper自身也要保證當(dāng)一個節(jié)點(diǎn)宕機(jī)時，其他 節(jié)點(diǎn)會繼續(xù)提供服務(wù)。 如果是一個Follower宕機(jī)，還有2臺服務(wù)器提供訪問，因?yàn)閆ookeeper上的數(shù)據(jù)是有 多個副本的，數(shù)據(jù)并不會丟失； 如果是一個Leader宕機(jī)，Zookeeper會選舉出新的Leader。 Zookeeper集群的機(jī)制是只要超過半數(shù)的節(jié)點(diǎn)正常，集群就能正常提供服務(wù)。 只有在Zookeeper節(jié)點(diǎn)掛得太 多，只剩一半或不到一半節(jié)點(diǎn)能工作，集群才失效。 所以： 3個節(jié)點(diǎn)的cluster可以掛掉1個節(jié)點(diǎn)(leader可以得到2票>1.5) 2個節(jié)點(diǎn)的cluster不能掛掉任何1個節(jié)點(diǎn)(leader可以得到1票<=1)