当一个应用被部署于生产环境,灾备计划是非常重要的,以便从网络故障,硬件故障,软件故障或者电源故障中恢复。通过合理的配置ActiveMQ,可以解决上诉问题。最典型的配置方法是运行多个Broker,一旦某台机器或者某个broker失效,其他broker能够顶上去。这种方式叫做Master/Slave,一个broker作为Master提供服务,而其他broker则作为slave等待master失效从而顶上。 目前activemq提供2种master/slave配置方式:
* Sharing nothing
broker拥有自己唯一的消息存储
* Sharing storage
broker之间共享一个消息存储设备,比如关系数据库,共享文件系统等。但是一个时间段内只能有一个broker占据他们。
1. 不共享式Master/Slave
该模式下,Master与Slave拥有各自独立的消息存储设备。他是最简单的提供高可用性的消息Broker。Slave需要额外的配置,而Master不需要。
所有的消息命令如消息、反馈、订阅、事务等会被从master复制到slave,如图所示,她发生在master收到这些消息之前。
slave启动后会连接到master,所以master要先启动起来。slave只有在master失效后才会建立通信连接以顶替master。
客户端给master发送消息后,master会首先将他转发到slave,等待slave反馈存储完毕后,master才开始处理这个消息。
当master失效后,slave有2个选择
关闭slave
管理员重新配置这个slave作为master,然后再配置一个slave作为替补,并将之前存储的消息数据复制一份给slave,以同步。
开启通信端口并初始化网络连接
slave自动升级为master
缺点:
master只会把slave连接后的消息传给他,而连接master之前的消息,不会被复制过去。不过你可以通过配置waitForSlave属性来让master一直等待slave启动才开始工作。
master只允许一个slave,而slave不能再有slave
何时使用:
当master失效后,可接受服务器维护时间,以及管理手工部署新的master和slave
2. 共享存储式Master/Slave
不共享式的Master Slave让各个broker保持了相对独立性,而共享式则是让所有broker共享同一个存储器,这个存储器一定时间内只能被一个broker占有。相比非共享式,优点是一旦master失效,无需手工恢复,而且也不限制slave broker数量。
共享式目前分为2种,共享数据库和共享文件系统。 值得一提的是,另外新的一种是基于zookeeper的,将会在5.9版中发布,详情查看 http://www.cnblogs.com/dycg/p/3177450.html
基于数据库的共享
原理是把消息命令都存储在数据库中,并且在数据库中加锁,一旦master失效后,slave获得该锁后继续服务。
只要你拥有数据库,并且不在意使用数据库而造成的性能相对其他方式有所降低的话,可以考虑。
基于共享文件系统的方式
其实就是把数据库换成了一个共享文件系统如SAN等。
转载于:https://www.cnblogs.com/dycg/p/3179679.html