【RabbitMQ高可用集群架构】

一、保证RabbitMQ服务高可用

1.RabbitMQ如何保证消息安全

之前通过单机环境搭建起来的RabbitMQ服务有一个致命的问题，那就是服务不稳定的问题。如果只是单
机RabbitMQ的服务崩溃了，那还好，大不了重启下服务就是了。但是如果是服务器的磁盘出问题了，那问
题就大了。因为消息都是存储在Queue里的，Queue坏了，意味着消息就丢失了。这在生产环境上肯定是无
法接受的。而RabbitMQ的设计重点就是要保护消息的安全性。
所以RabbitMQ在设计之处其实就采用了集群模式来保护消息的安全。基础的思想就是给每个Queue提供
几个备份。当某一个服务的Queue坏了，至少还可以从其他Queue中获取服务。
其实对于RabbitMQ，一个节点的服务也是作为一个集群来处理的，在web控制台的admin-> cluster 中可
以看到集群的名字，并且可以在页面上修改。

那么RabbitMQ是怎么考虑数据安全这回事的呢？实际上，RabbitMQ考虑了两种集群模式：
默认的普通集群模式：
这种模式使用Erlang语言天生具备的集群方式搭建。这种集群模式下，集群的各个节点之间只会有相同
的元数据，即队列结构，而消息不会进行冗余，只存在一个节点中。消费时，如果消费的不是存有数据
的节点， RabbitMQ会临时在节点之间进行数据传输，将消息从存有数据的节点传输到消费的节点。
很显然，这种集群模式的消息可靠性不是很高。因为如果其中有个节点服务宕机了，那这个节点上的数
据就无法消费了，需要等到这个节点服务恢复后才能消费，而这时，消费者端已经消费过的消息就有可
能给不了服务端正确应答，服务起来后，就会再次消费这些消息，造成这部分消息重复消费。 另外，
如果消息没有做持久化，重启就消息就会丢失。
并且，这种集群模式也不支持高可用，即当某一个节点服务挂了后，需要手动重启服务，才能保证这一
部分消息能正常消费。
所以这种集群模式只适合一些对