面试宝典之消息队列如何保证高可用？

既然用了MQ，那么面试官肯定会问你如何来保证可用性？

面试官心理剖析：
主要是看你了不了解MQ的高可用，如果你只是简单的用用，不考虑高可用，那么面试官会觉得你是挖坑的。

回答：

这里分两种类型的MQ来讲，一种是分布式的；还有一种是主从架构的；

（1）RabbitMQ的高可用性

rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式
1、单机模式
这个是你自己玩玩的，如果线上你使用了这个，那么面试你基本没戏

2、普通集群模式
MQ1里面保存queue的元数据和实际数据，MQ2里面保存了queue的元数据。如果客户端消费数据连到MQ2，但是实际数据在MQ1里面，那么MQ2会从MQ1中获取到数据，在返回给客户端。其实这种模式也是单机的，如果MQ1挂了，那么系统就不可用了

缺点：
1）会产生大量数据传输；
2）queue所在的节点宕机了，导致数据丢失，那么可用性就不能保证；
这个方案是不能保证可用性的。

3、镜像集群模式
生产者调用MQ1，MQ1会把queue的元数据和实际数据同步给MQ2，消费者不管消费哪个MQ，都可以获取到数据。就是其中一个宕机也不影响使用。

这个方案是RabbitMQ真正的高可用方案；
注意：你可以只说这个方案，也可以说上面几个方案，进行比较就可以了。
缺点：
1）因为不是分布式的，数据量很大很大的时候，超出机器的容纳时，就会变成不可用了。

（2）kafka高可用

kafka把数据分布在不同的机器上，可以支持1T+的数据，kafka8.0以后支持HA机制，就是replica副本机制，这个机制支持kafka的高可用。

如果其中一个机器宕机了，没关系，这个机器有副本，kafka会自动把follower变为leader，这样就保证了高可用。

（3）RocketMq高可用

Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server。