請參考最新文檔 http://zbus.io/guide/ha?menu=hagit
http://git.oschina.net/rushmore/zbus算法
1. ZBUS 高可用設計編程
Zbus高可用採用ZbusServer + TrackServer結合完成,相對於單機版本的zbus,客戶端須要TrackServer的幫助完成實際的zbus動態選擇。Zbus能夠動態的增長到TrackServer組成的高可用羣中,zbus節點之間無狀態。加入高可用羣的ZbusServer向TrackServer上報當前zbus節點的拓撲信息,包括所在節點的IP,隊列分佈,消費者信息等等拓撲信息。TrackServer將全部的zbus上報信息組織路由表,客戶端(生產者、消費者)則訂閱TrackServer的路由信息實時得到zbus節點的全部變化信息,從而根據實際狀況來變換路由算法,作負載均衡等等策略。 服務器
TrackServer與ZbusServer都是能夠任意個實例運行,典型的配置是2個TrackServer共同熱備,2+臺ZbusServer負載均衡。負載均衡
2. ZBUS HA的配置分佈式
ZbusServer與TrackServer各個節點之間都無狀態,節點之間啓動無順序。單機下演示典型的配置:ide
進入zbus的ha目錄下ui
第一步: 啓動兩個TrackServer實例,tracker1.bat 與tracker2.bat分別啓動了16666和16667端口的TrackServer.net
tracker.bat設計
第二步: 啓動兩個ZbusServer實例,zbus1.bat與zbus2.bat,zbus的配置與單機版的惟一區別在於顯示指定了須要上報的TrackServer列表
zbus.bat
啓動結束,整個HA環境便這樣很是簡單的搭建好了。若是是在分佈式環境下搭建,只須要在不一樣的機器上啓動TrackServer,在每臺ZbusServer上的配置中填寫啓動的TrackServer地址列表便可。
3. ZBUS API說明舉例
ZBUS的API對高可用與單機作了模型抽象統一,基本從應用代碼層面感覺不到HA的參與。
ZBUS的編程模型接口遵循了PBC三個角色,即:
P--生產者Producer
B--中介商服務Broker
C--消費者Consumer
另外,RPC是在生產消費者基礎上,讓消費者具有反饋消息回到生產者的能力的一個特列,仍然能夠當作PBC的一個特例。
構建生產者與消費者,咱們都須要指定Broker,Broker中間服務節點,能夠是單機版本SingleBroker也能夠是高可用版本HaBroker。
Broker具體作什麼呢,在zbus體系下的抽象是1)底層到服務器的連接能力,2)更高層對服務器的命令執行能力(invoke),僅此而已。
1)連接能力,主要作鏈接池管理,提供抽象連接概念,應用層不須要關心
2)命令執行,對服務器能完成啥指令的一個抽象,應用層獲得Broker能夠直接向服務發指令。
SingleBroker單機版就是對單個zbus的直接抽象,HaBroker高可用版本是對多個zbus的抽象,連接能力能擴展至多個zbus,invoke一樣,HaBroker經過TrackServer的信息更新得到動態更新鏈接池與動態invoke命令能力。
生產者、消費者的Producer編程模型
1. 構建Broker,選擇SingleBroker或者HaBroker
2. Producer、Consumer 根據Broker建立
3. Producer生產消息,消費者消費消息。
構建SingleBroker只須要配置ServerAddress(直接鏈接的zbus地址),構建HaBroker只須要指定TrackServer列表(間接更新多個zbus的TrackServer列表)
具體代碼參見test目錄下諸多例子。
4. 消費者場景下多Broker配置推薦
Consumer若是使用HaBroker,則具有Failover消費多個zbus的消息,可是消費轉移僅僅發生在Failover以後。Consumer的高可用還有另一種推薦的配置是,在MqConfig中配置多個SingleBroker,咱們稱之爲MultiBroker(不存在這個類)
HaBroker VS MultiBroker
HaBroker:優勢是能解決Consumer,Failover問題,缺點是Consumer可能由於Failover匯聚到某一臺zbus上,沒有作分割,Consumer只能能物理上連接到某一臺zbus。
MultiBroker: Consumer靜態配置指定到多個zbus上,能解決分割問題,配置也方便。缺點是不能解決zbus的徹底動態性。