90%的Java程序员，都扛不住这波消息中间件的面试四连炮！(2)

设置持久化有两个步骤：

• 第一个是创建queue的时候将其设置为持久化的，这样就可以保证rabbitmq持久化queue的元数据，但是不会持久化queue里的数据
• 第二个是发送消息的时候将消息的deliveryMode设置为2，就是将消息设置为持久化的，此时rabbitmq就会将消息持久化到磁盘上去。

但是这样一来可能会有人说：万一消息发送到RabbitMQ之后，还没来得及持久化到磁盘就挂掉了，数据也丢失了，怎么办?

对于这个问题，其实是配合上面的confirm机制一起来保证的，就是在消息持久化到磁盘之后才会给生产者发送ack消息。

万一真的遇到了那种极端的情况，生产者是可以感知到的，此时生产者可以通过重试发送消息给别的RabbitMQ节点

消费端弄丢了数据

RabbitMQ消费端弄丢了数据的情况是这样的：在消费消息的时候，刚拿到消息，结果进程挂了，这个时候RabbitMQ就会认为你已经消费成功了，这条数据就丢了。

对于这个问题，要先说明一下RabbitMQ消费消息的机制：在消费者收到消息的时候，会发送一个ack给RabbitMQ，告诉RabbitMQ这条消息被消费到了，这样RabbitMQ就会把消息删除。

但是默认情况下这个发送ack的操作是自动提交的，也就是说消费者一收到这个消息就会自动返回ack给RabbitMQ，所以会出现丢消息的问题。

所以针对这个问题的解决方案就是：关闭RabbitMQ消费者的自动提交ack,在消费者处理完这条消息之后再手动提交ack。

这样即使遇到了上面的情况，RabbitMQ也不会把这条消息删除，会在你程序重启之后，重新下发这条消息过来。

怎么保证MQ的高可用性性?

使用了MQ之后，我们肯定是希望MQ有高可用特性，因为不可能接受机器宕机了，就无法收发消息的情况。

这一块我们也是基于RabbitMQ这种经典的MQ来说明一下：

RabbitMQ是比较有代表性的，因为是基于主从做高可用性的，我们就以他为例子讲解第一种MQ的高可用性怎么实现。

rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式

单机模式

单机模式就是demo级别的，就是说只有一台机器部署了一个RabbitMQ程序。

这个会存在单点问题，宕机就玩完了，没什么高可用性可言。一般就是你本地启动了玩玩儿的，没人生产用单机模式。

普通集群模式

这个模式的意思就是在多台机器上启动多个rabbitmq实例。类似的master-slave模式一样。

但是创建的queue，只会放在一个master rabbtimq实例上，其他实例都同步那个接收消息的RabbitMQ元数据。

在消费消息的时候，如果你连接到的RabbitMQ实例不是存放Queue数据的实例，这个时候RabbitMQ就会从存放Queue数据的实例上拉去数据，然后返回给客户端。

总的来说，这种方式有点麻烦，没有做到真正的分布式，每次消费者连接一个实例后拉取数据，如果连接到不是存放queue数据的实例，这个时候会造成额外的性能开销。如果从放Queue的实例拉取，会导致单实例性能瓶颈。

如果放queue的实例宕机了，会导致其他实例无法拉取数据，这个集群都无法消费消息了，没有做到真正的高可用。

所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性可言了，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。

镜像集群模式

镜像集群模式才是真正的rabbitmq的高可用模式，跟普通集群模式不一样的是：创建的queue无论元数据还是queue里的消息都会存在于多个实例上，

每次写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。

这样的话任何一个机器宕机了别的实例都可以用提供服务，这样就做到了真正的高可用了。

（编辑：ASP站长网）