请参考最新文档 http://zbus.io/guide/ha?menu=ha
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各个节点之间都无状态,节点之间启动无顺序。单机下演示典型的配置:
进入zbus的ha目录下
第一步: 启动两个TrackServer实例,tracker1.bat 与tracker2.bat分别启动了16666和16667端口的TrackServer
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的完全动态性。