1. 程式人生 > >zookeeper、dubbo、kafka隨筆

zookeeper、dubbo、kafka隨筆

樹狀結構 程序 業務層 alived 設計 機房 vip ast 比較

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作為服務的註冊中心。

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隨筆