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的完全动态性。