zookeeper、dubbo、kafka

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等硬體負載均衡器，降低成本，減少單點。

1. 服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於介面名查詢服務提供者的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

https://blog.csdn.net/oMaverick1/article/details/50767166

https://blog.csdn.net/mayp1/article/details/52026797