zookeeper、dubbo、kafka隨筆
1 zookeeper 多臺構成集群實現高可用，有三種角色群首（leader），追隨者（follower），觀察者（observer）。
Leader作為整個ZooKeeper集群的主節點，負責響應所有對ZooKeeper狀態變更的請求。它會將每個狀態更新請求進行排序和編號，以便保證整個集群內部消息處理的FIFO
Follower的邏輯就比較簡單了。除了響應本服務器上的讀請求外，follower還要處理leader的提議，並在leader提交該提議時在本地也進行提交。，leader和follower構成ZooKeeper集群的法定人數，也就是說，只有他們才參與新leader的選舉、響應leader的提議。
2 zookeeper如何實現負載均衡？
以前接觸的負載均衡是通過VIP調度到各個節點。如：nginx+keepalived實現負載均衡和高可用。這個是直接在nginx配置文件中配置好了下面節點的IP：PORT，由nginx實現轉發
基本流程:
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作為服務的註冊中心。
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
https://blog.csdn.net/oMaverick1/article/details/50767166
https://blog.csdn.net/mayp1/article/details/52026797
zookeeper、dubbo、kafka隨筆