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