请参考最新文档 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的彻底动态性。