1 zookeeper如何實現高可用
1 zookeeper 多臺構成集羣實現高可用，有三種角色羣首（leader），追隨者（follower），觀察者（observer）。
Leader作爲整個ZooKeeper集羣的主節點，負責響應所有對ZooKeeper狀態變更的請求。它會將每個狀態更新請求進行排序和編號，以便保證整個集羣內部消息處理的FIFO
Follower的邏輯就比較簡單了。除了響應本服務器上的讀請求外，follower還要處理leader的提議，並在leader提交該提議時在本地也進行提交。，leader和follower構成ZooKeeper集羣的法定人數，也就是說，只有他們才參與新leader的選舉、響應leader的提議。
如果ZooKeeper集羣的讀取負載很高，或者客戶端多到跨機房，可以設置一些observer服務器，以提高讀取的吞吐量。Observer和Follower比較相似，只有一些小區別：首先observer不屬於法定人數，即不參加選舉也不響應提議；其次是observer不需要將事務持久化到磁盤，一旦observer被重啓，需要從leader重新同步整個名字空間。
2 zookeeper如何實現負載均衡？
以前接觸的負載均衡是通過VIP調度到各個節點。如：nginx+keepalived實現負載均衡和高可用。這個是直接在nginx配置文件中配置好了下面節點的IP：PORT，由nginx實現轉發
zookeeper不是這樣的，如三臺服務構成zookeeper集羣，是在服務生產者和服務消費的服務器上，
基本流程:
1) 服務提供者B啓動到Zookeeper服務器處進行註冊;
2) 服務消費者A啓動時，請求Zookeeper服務器獲取最新的B服務存活列表，並保存到本地緩存中;
3)A請求B服務器時，根據緩存中的B服務器列表，隨機選取一個進行請求。
服務變動:
1) 當B出現異常或人工關閉不能提供服務時，Zookeeper服務器某個節點會探測到B節點的變化，更新本節點B服務器列表；
2) Zookeeper內部節點進行數據同步；
3) 服務消費者A監聽到B服務列表的變化，更新本地緩存。
自動重發機制:
B服務掛掉到A緩存更新大約需要3-5s的時間（根據網絡環境不同還需仔細測試）。爲了保證服務的實時可用，A請求B發生異常時，需要根據服務消費報錯信息，處理特定異常進行自動重發。
存在風險和問題
1) 服務發現速度慢的問題，上述描述服務延遲問題。
2) Zookeeper 作爲服務發現存在的問題
在分佈式系統領域有個著名的CAP定理（C-數據一致性；A-服務可用性；P-服務對網絡分區故障的容錯性，這三個特性在任何分佈式系統中不能同時滿足，最多同時滿足兩個）。
ZooKeeper是個CP的，即任何時刻對ZooKeeper的訪問請求能得到一致的數據結果，同時系統對網絡分割具備容錯性；但是它不能保證每次服務請求的可用性（注：也就是在極端環境下，ZooKeeper可能會丟棄一些請求，消費者程序需要重新請求才能獲得結果）。但是別忘了，ZooKeeper是分佈式協調服務，它的職責是保證數據（注：配置數據，狀態數據）在其管轄下的所有服務之間保持同步、一致；所以就不難理解爲什麼ZooKeeper被設計成CP而不是AP特性的了，如果是AP的，那麼將會帶來恐怖的後果（注：ZooKeeper就像交叉路口的信號燈一樣，你能想象在交通要道突然信號燈失靈的情況嗎？）。而且，作爲ZooKeeper的核心實現算法Zab，就是解決了分佈式系統下數據如何在多個服務之間保持同步問題的。
保存草稿
3 dubbo
Dubbo 是阿里巴巴公司開源的一個Java高性能優秀的服務框架，使得應用可通過高性能的 RPC 實現服務的輸出和輸入功能，可以和 Spring框架無縫集成。
dubbo能做什麼？
1.透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。
2.軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，降低成本，減少單點。
- 服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，並且能夠平滑添加或刪除服務提供者。
4 dubbo與zookeeper的關係
Dubbo建議使用Zookeeper作爲服務的註冊中心。
Dbbo是一個框架，用於服務間的調度，服務程序編寫使用dubbo做接口，利用dubbo是實現服務服務之間還有zookeeper之間的通訊。
1） Zookeeper的作用：
zookeeper用來註冊服務和進行負載均衡，哪一個服務由哪一個機器來提供必需讓調用者知道，簡單來說就是ip地址和服務名稱的對應關係。當然也可以 通過硬編碼的方式把這種對應關係在調用方業務代碼中實現，但是如果提供服務的機器掛掉調用者無法知曉，如果不更改代碼會繼續請求掛掉的機器提供服務。 zookeeper通過心跳機制可以檢測掛掉的機器並將掛掉機器的ip和服務對應關係從列表中刪除。至於支持高併發，簡單來說就是橫向擴展，在不更改代碼 的情況通過添加機器來提高運算能力。通過添加新的機器向zookeeper註冊服務，服務的提供者多了能服務的客戶就多了。2） dubbo：
是管理中間層的工具，在業務層到數據倉庫間有非常多服務的接入和服務提供者需要調度，dubbo提供一個框架解決這個問題。
注意這裏的dubbo只是一個框架，至於你架子上放什麼是完全取決於你的，就像一個汽車骨架，你需要配你的輪子引擎。這個框架中要完成調度必須要有一個分佈式的註冊中心，儲存所有服務的元數據，你可以用zk，也可以用別的，只是大家都用zk。3）zookeeper和dubbo的關係：
Dubbo的將註冊中心進行抽象，是得它可以外接不同的存儲媒介給註冊中心提供服務，有ZooKeeper，Memcached，Redis等。
引入了ZooKeeper作爲存儲媒介，也就把ZooKeeper的特性引進來。首先是負載均衡，單註冊中心的承載能力是有限的，在流量達到一定程度的時 候就需要分流，負載均衡就是爲了分流而存在的，一個ZooKeeper羣配合相應的Web應用就可以很容易達到負載均衡；資源同步，單單有負載均衡還不 夠，節點之間的數據和資源需要同步，ZooKeeper集羣就天然具備有這樣的功能；命名服務，將樹狀結構用於維護全局的服務地址列表，服務提供者在啓動 的時候，向ZK上的指定節點/dubbo/${serviceName}/providers目錄下寫入自己的URL地址，這個操作就完成了服務的發佈。 其他特性還有Mast選舉，分佈式鎖等。
5 kafka與zookeeper
1）Kafka把它的meta數據都存儲在ZK上，所以說ZK是必要存在的，沒有ZK沒法運行Kafka；在老版本（0.8.1以前）裏面消費段（consumer）也是依賴ZK的，在新版本中移除了客戶端對ZK的依賴，但是broker依然依賴於ZK。
2）kafka是消息隊列，zookeeper是服務的控制中心；消費者要訪問服務，需要知道現在哪些生產者（對於消費者而言，kafka就是生產者）是可用的，就需要zk的調度。
https://www.cnblogs.com/xiaofei1208/p/7077733.html
http://colobu.com/2016/09/05/benchmarks-of-popular-rpc-frameworks/
https://blog.csdn.net/houshaolin/article/details/76408399