除了内置的RabbitMQ集群方案,还可以通过其它一些软件或者插件来构建RabbitMQ集群.这些方案可以解决一些让我们头痛不已的问题,当然它们也不是银弹,也有使用场景的限制.事实上,对于各种集群方案我们都不能假设太多,每当连入一个节点,我们都要把这个节点当成一个全新的节点来处理,首先要完成各种声明工作.
下面的方式都没有实践过,暂且记录一笔,留点印象,后面实践之后丰富.下面的截图来自"RabbitMQ in Action"
HAProxy
开源项目HAProxy 的定位是:The Reliable, High Performance TCP/HTTP Load Balancer.官网地址 http://haproxy.1wt.eu/我们可以把独立的RabbitMQ节点隐藏在HAProxy后面,HAProxy完成了下面的职责:
[1] 负载均衡 帮助我们进行节点选择 HAProxy 实现了一些经典的负载均衡算法 比如:roundrobin leastconn 完整的列表请查看 http://cbonte.github.com/haproxy-dconv/configuration-1.5.html#4-balance
[2] 异常节点检测
使用HAProxy可以不同策略来构建RabbitMQ集群,最典型的用法是:在一组Rabbit节点前端放置HAProxy做负载均衡,看下面的图:
使用这种方式构建集群,和我们做WebServer集群一样,把一批功能相同的Web Server隐藏在HAProxy后面.如果节点宕掉如何处理?这种情况,应用程序并不知道自己实际连接的是哪个节点, cancellation notification消息可以显示得到连接到的节点已经宕掉.
Warrens 替补队员
之前提到过使用built-in方式构建集群环境durable queue的问题:队列只有元数据会在集群的所有节点同步,但是队列中的数据只会存在于一个节点;这不免让人失望:数据没有冗余容易丢数据甚至在durable的情况下,如果所在的节点当掉就要等待节点恢复.
使用HAProxy添加backup节点的方式可以在当前活跃节点宕掉之后尽快启用备用节点,恢复正常服务.
backup节点在没有投入使用的时候都处于静默状态,并不从活跃节点同步消息.活跃节点在崩溃之前积压没有处理的消息只有等待其重启恢复之后才能启用.还有一个方法是让active和backup节点共享存储文件,这里有两个问题:1.共享存储 之前造成active node崩掉的数据可能继续让backup崩掉 2.要共享存储要求节点名完全一致,换句话说两个节点不可能同时启动,这就达不到我们的目的了
Shovel:WAN环境使用Cluster
Erlang OTP对网络延迟敏感,所以RabbitMQ一样不建议在WAN环境使用集群.在WAN环境可以使用Shovel 实现跨地域数据同步.
最后小图一张:
