前几章讲到RabbitMQ单主机模式的搭建和使用,我们在实际生产环境中出于对性能还有可用性的考虑会采用集群的模式来部署RabbitMQ。
RabbitMQ集群基本概念
Rabbit模式大概分为以下三种:单主机模式、普通集群模式、镜像集群模式。
单主机模式:
- RabbitMQ服务运行在单独的一台主机中,通常生产环境不使用该模式,性能有限,并且如果服务器宕机服务将完全不可用。
普通集群模式
一说到集群问题瞬间变得复杂多了。首先对于Queue来说消息实体只存在于其中一个节点,集群中其他节点仅有相同的元数据,即队列结构。
当消息进入A节点的Queue中后,Consumer从B节点拉取消息时,RabbitMQ会临时在两个节点间进行消息传输,把A中的消息实体取出并经过B发送给Consumer。所以Consumer应尽量连接每一个节点,从中取消息。即对于同一个逻辑队列,要在多个节点建立Queue。否则Consumer如果只连接一个节点区消息会造成该节点的性能瓶颈。
该模式存在一个问题就是当其中一个节点故障后,其他节点无法取到故障节点中还未消费的消息。如果做了消息持久化,那么得等A节点恢复,然后才可被消费;如果没有持久化的话,那就杯具了!
镜像集群模式
- 前面讲到RabbitMQ的普通集群模式不同节点间只同步队列结构不同步消息。镜像模式会把队列结构和消息都存在于多个节点,属于RabbitMQ的HA方案。其实质和普通模式不同之处在于,消息实体会主动在镜像节点间同步。该模式带来的副作用也很明显,除了降低系统性能外,如果镜像队列数量过多,加之大量的消息进入,集群内部的网络带宽将会被这种同步通讯大量消耗。所以这种模式应用于可靠性要求较高的场合中。
内存节点与磁盘节点
- RabbitMQ的集群节点包括内存节点、磁盘节点。顾名思义内存节点就是将所有数据放在内存,磁盘节点将数据放在磁盘。不过,如前文所述,如果在投递消息时,打开了消息的持久化,那么即使是内存节点,数据还是会放在磁盘。原则上一个集群至少有一个磁盘节点。在实际使用中会发现所谓的磁盘节点是只用来存储集群的配置信息,也就是说如果集群中没有磁盘节点,当所有节点关机后集群的配置信息就会丢失。在进行性能测试时两个模式的节点订阅发布消息的性能没有太大差距。
多节点负载分发
RabbitMQ集群模式是没有中心节点的,并且在连接集群的时候实际上Consumer是连接其中某一台节点,连接方法和单主机模式一致。那就遇到一个尴尬的问题,怎么保证Consumer均匀的连接到多个节点。以下是我的一些思考,提供了两个思路。
- 1、通过负载均衡设备来实现流量分发。可以使用F5硬件负载均衡,如果没有F5的硬件负载均衡设备也可以使用想LVS等服务,当Consumer连接集群时实际是先经过负载均衡。
- 2、虽然负载均衡设备通常都很稳定,但这样一来RabbitMQ的集群就有了中心节点。我们在使用的时候是这样的,首先将集群中所以节点的IP放在一个数组中,app在连接RabbitMQ的时候会从数组中随机选择一个IP来连接,然后把连接的节点的IP缓存到服务器,如果连接超时则重新随机选择其他节点来连接。通过这种方式来实现app流量的分发。