目录
高可用
rabbitMQ对于高可用是基于主从的方式进行实现. 其有三种工作模式: 单机模式、普通集群模式、镜像集群模式
单机模式
单机模式，就是我们平常玩的demo，生产上肯定不能用。：
普通集群模式
即在多个服务器上部署多个MQ实例, 每台机器一个实例. 创建的每一个queue,只会存在一个MQ实例上. 但是每一个实例都会同步queue的元数据(即queue的标识信息). 当在进行消费的时候, 就算 连接到了其他的MQ实例上, 其也会根据内部的queue的元数据,从该queue所在实例上拉取数据过来.
这种方式只是一个简单的集群,并没有考虑高可用. 并且性能开销巨大.容易造成单实例的性能瓶颈. 并且如果真正有数据的那个queue的实例宕机了. 那么其他的实例就无法进行数据的拉取.
这种方式只是通过集群部署的方式提高了消息的吞吐量,但是并没有考虑到高可用.
镜像集群模式
这种模式才是高可用模式. 与普通集群模式的主要区别在于. 无论queue的元数据还是queue中的消息都会同时存在与多个实例上.
要开启镜像集群模式,需要在后台新增镜像集群模式策略. 即要求数据同步到所有的节点.也可以指定同步到指定数量的节点.
这种方式的好处就在于, 任何一个服务宕机了,都不会影响整个集群数据的完整性, 因为其他服务中都有queue的完整数据, 当进行消息消费的时候,连接其他的服务器节点一样也能获取到数据.
缺点:
1: 性能开销大: 因为需要进行整个集群内部所有实例的数据同步
2:无法线性扩容: 因为每一个服务器中都包含整个集群服务节点中的所有数据。
高吞吐
与其他中间件产品类似，RabbitMQ也是通过集群的方式来解决单节点在处理海量消息时的性能瓶颈，通过集群的方式来实现高吞吐量，如单个RabbitMQ节点每秒只能处理1000个消息，而通过集群方式拓展，则可以进一步达到每秒10万个消息的处理或者更高的吞吐量。
不过RabbitMQ的集群在处理海量消息时，是通过在集群的多个节点建立多个不同的队列来分散消息到多个不同节点的，所以在业务层需要对消息进行细分类别来放到不同队列中。
RabbitMQ的集群不是一个主从模式的集群，而是一个对等集群，即节点之间是对等，不存在主从关系，每个节点存放的是不同的队列，所以存放的是不同的消息，由集群内所有节点的所有队列的消息共同组成该集群的所有消息。
不过如果使用了镜像队列，则集群中的某些节点作为该队列的主master节点的mirror节点或者说是slave节，存在主从关系，这个主从主要用于实现队列消息的冗余存储，实现队列和队列内部消息的高可用，不是用于读写分离实现高并发。
高并发
与大部分中间件的集群，如Redis，MySQL，zookeeper等，采用读写分离的方式来应对高并发数据请求不同的是，RabbitMQ集群是一个对等集群，集群内部每个节点存放不同队列（所以也就存放着不同的数据），集群内部每个节点在应对客户端的数据请求方面不存在主从关系，对于某个消息的请求，如生产者写入该消息或者消费者消费该消息，都需要首先定位到该消息所在队列的节点，然后交给该节点来处理，其他节点由于不存在这个队列，或者是镜像队列的mirror节点，故不能处理这个消息的请求。
不过从客户端的角度来看，RabbitMQ集群其实就是一个逻辑上的单节点，即客户端可以连接RabbitMQ集群的任何一个节点，而不需要约束为只能连接该客户端所要请求的消息对应的队列所在的节点。任何一个节点接收到客户端的请求后，如果该请求对应的消息属于自身节点的队列，则由该节点处理，否则将该请求转发给该消息所属队列所在的节点处理，这个过程对客户端来说是透明的。所以通过这种方式RabbitMQ集群可以通过增加节点个数来应对高并发请求，因为客户端可以连接任意一个节点。
所以出于性能考虑，RabbitMQ集群一般需要部署在一个局域网LAN内部，这样才能保证不同节点之间的请求转发的高性能。
