rabbitmq持久化（RabbitMQ的持久化设置）

本文目录

• RabbitMQ的持久化设置
• 如何保证消息队列的可靠性传输
• rabbitmq保证消息不丢失
• rabbitmq的特点
• 10.RabbitMQ持久化
• rabbitmq中持久化数据什么时候会删除

RabbitMQ的持久化设置

“持久化”可以提高RabbitMQ的可靠性，以防在异常情况（重启、关闭、宕机等）下的数据丢失。RabbitMQ的持久化分为三个部分：交换器的持久化、队列的持久化和消息的持久化。

交换器的持久化是通过在声明队列是将durable参数设置为true实现的。如果交换器不设置持久化，那么在RabbitMQ服务器重启之后，相关的交换器元数据会丢失，不过消息不会丢失，只是不能将消息发送到这个交换器中了。对于一个长期使用的交换器来说，建议将其设置为持久化的。

队列的持久化是通过在声明队列时将durable参数设置为true实现的。如果队列不设置持久化，那么在RabbitMQ服务重启之后，相关队列的元数据会丢失，此时数据也会丢失。争所谓“皮之不存，毛将焉附”，队列都没有了，消息有能存在哪里呢？

队列的持久化能保证其本身的元数据不会因异常情况而丢失，但是不能保证内部所存储的消息不会丢失。要确保消息不会丢失，需要将其设置为持久化。通过将消息的投递模式（BasicProperties中的deliveryMode属性）设置为2即可实现消息的持久化。

设置了队列和消息的持久化，当RabbitMQ服务重启之后，消息依旧存在。单单只设置队列持久化，重启之后消息会丢失，单单只设置了消息的持久化，重启之后队列消失，继而消息也丢失。单单设置消息持久化而不设置队列的持久化显得毫无意义。

将交换器、队列、消息都设置了持久化之后就能百分之百保证数据不丢失了吗？答案是否定的。

首先从消费者来说，如果在订阅消费队列时将autoAck参数设置为true，那么当消费者接收到相关消息之后，还没来得及处理就宕机了，这样也算数据丢失。这种情况很好解决，将autoAck参数设置为false，并进行手动确认。

其次，在持久化的消息正确存入RabbitMQ之后，还需要一段时间（虽然很短，但是不可忽视）才能存入磁盘之中。RabbitMQ并不会为每条消息都进行同步存盘（调用内核的fsync方法）的处理，可能仅仅保存在操作系统缓存之中而不是物理磁盘之中。如果在这段时间内RabbitMQ服务节点发生了宕机、重启等异常情况，消息保存还没来得及落盘，那么这些消息将会丢失。

这个问题怎么解决呢？这里可以引入RabbitMQ的镜像队列机制，相当于配置了副本，如果主节点（master）在此特殊时间内挂掉，可以自动切换到从节点（slave），这样有效地保证了高可用性，除非整个集群都挂掉。虽然这样也不能完全保证RabbitMQ消息不丢失，但是配置了镜像队列要比没有配置镜像队列的可靠性要高很多，在实际生产环境中的关键业务队列一般都会设置镜像队列。

还可以在发送端引入事务机制或者发送方确认机制来保证消息已经正确地发送并存储至RabbitMQ中，前提还要保证在调用channel.basicPublish方法的时候交换器能够将消息正确路由到相应的队列之中。

如何保证消息队列的可靠性传输

消息丢失分成三种情况，可能出现生产者、RabbitMQ、消费者。

首先要确保写入 RabbitMQ 的消息别丢，消息队列通过 请求确认机制 ，保证消息的可靠传输。生产开启 comfirm 模式，在生产者开启 comfirm 模式之后，每次发送消息都会分配一个唯一的id。

RabbitMQ 丢失数据，需要开启 RabbitMQ 持久化，开启持久化之后，生产者发送的消息会持久化到磁盘，RabbitMQ 就算是挂了，恢复启动后也会读取之前存储的数据。
还有一种少见的情况，就是RabbitMQ还没将消息持久化，自己就挂了。这种情况需要生产者那边的确认机制结合起来。只有消息被持久化到磁盘以后，才会回传 ack 消息。生产者没有接收到 ack，也可以自己重发。

消费丢失数据，刚消费到 RabbitMQ 发送的数据，消费进程就挂了，重启进程后，RabbitMQ 也不会重新发送消息。
这个时候需要关闭 RabbitMQ 关闭自动的 ack 机制。每次在消费端处理后，再在程序里做 ack 确认，这样的话，如果没有处理完，就没有 ack 确认，那 RabbitMQ 就认为你还没有处理完，这个时候 RabbitMQ 会重新发送消息给消费者。

如果觉得文章对你有帮助的话，请点个赞吧!

rabbitmq保证消息不丢失

1. 我是在网上粘贴复制的。

2. mq原则

数据不能多，也不能少，不能多是说消息不能重复消费，这个我们上一节已解决；不能少，就是说不能丢失数据。如果mq传递的是非常核心的消息，支撑核心的业务，那么这种场景是一定不能丢失数据的。

2.丢失数据场景

丢数据一般分为两种，一种是mq把消息丢了，一种就是消费时将消息丢了。下面从rabbitmq和kafka分别说一下，丢失数据的场景，
（1）rabbitmq
A:生产者弄丢了数据 生产者将数据发送到rabbitmq的时候，可能在传输过程中因为网络等问题而将数据弄丢了。
B:rabbitmq自己丢了数据 如果没有开启rabbitmq的持久化，那么rabbitmq一旦重启，那么数据就丢了。所依必须开启持久化将消息持久化到磁盘，这样就算rabbitmq挂了，恢复之后会自动读取之前存储的数据，一般数据不会丢失。除非极其罕见的情况，rabbitmq还没来得及持久化自己就挂了，这样可能导致一部分数据丢失。
C：消费端弄丢了数据 主要是因为消费者消费时，刚消费到，还没有处理，结果消费者就挂了，这样你重启之后，rabbitmq就认为你已经消费过了，然后就丢了数据。

3.如何防止消息丢失

（1）rabbitmq
A:生产者丢失消息
①：可以选择使用rabbitmq提供是事物功能，就是生产者在发送数据之前开启事物，然后发送消息，如果消息没有成功被rabbitmq接收到，那么生产者会受到异常报错，这时就可以回滚事物，然后尝试重新发送；如果收到了消息，那么就可以提交事物

channel.txSelect();//开启事物try{//发送消息}catch(Exection e){channel.txRollback()；//回滚事物//重新提交}复制代码

缺点： rabbitmq事物已开启，就会变为同步阻塞操作，生产者会阻塞等待是否发送成功，太耗性能会造成吞吐量的下降。

②：可以开启confirm模式。在生产者哪里设置开启了confirm模式之后，每次写的消息都会分配一个唯一的id，然后如何写入了rabbitmq之中，rabbitmq会给你回传一个ack消息，告诉你这个消息发送OK了；如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息失败了，你可以进行重试。而且你可以结合这个机制知道自己在内存里维护每个消息的id，如果超过一定时间还没接收到这个消息的回调，那么你可以进行重发。

//开启confirmchannel.confirm();//发送成功回调public void ack(String messageId){}// 发送失败回调public void nack(String messageId){//重发该消息}复制代码

二者不同 事务机制是同步的，你提交了一个事物之后会阻塞住，但是confirm机制是异步的，发送消息之后可以接着发送下一个消息，然后rabbitmq会回调告知成功与否。 一般在生产者这块避免丢失，都是用confirm机制。
B:rabbitmq自己弄丢了数据 设置消息持久化到磁盘。设置持久化有两个步骤：
①创建queue的时候将其设置为持久化的，这样就可以保证rabbitmq持久化queue的元数据，但是不会持久化queue里面的数据。
②发送消息的时候讲消息的deliveryMode设置为2，这样消息就会被设为持久化方式，此时rabbitmq就会将消息持久化到磁盘上。 必须要同时开启这两个才可以。

而且持久化可以跟生产的confirm机制配合起来，只有消息持久化到了磁盘之后，才会通知生产者ack，这样就算是在持久化之前rabbitmq挂了，数据丢了，生产者收不到ack回调也会进行消息重发。
C:消费者弄丢了数据 使用rabbitmq提供的ack机制，首先关闭rabbitmq的自动ack，然后每次在确保处理完这个消息之后，在代码里手动调用ack。这样就可以避免消息还没有处理完就ack。

rabbitmq的特点

可靠性 ∶RabbitMQ使用一些机制来保证可靠性，如持久化、传输确认及发布确认等。

灵活的路由 ∶在消息进入队列之前，通过交换器来路由消息。对于典型的路由功能，RabbitMQ已经提供了一些内置的交换器来实现。针对更复杂的路由功能，可以将多个交换器绑定在一起，也可以通过插件机制来实现自己的交换器。

扩展性 ∶多个RabbitMQ节点可以组成一个集群，也可以根据实际业务情况动态地扩展集群中节点。

高可用性 ∶ 队列可以在集群中的机器上设置镜像，使得在部分节点出现问题的情况下队列仍然可用。

多种协议 ∶ RabbitMQ除了原生支持AMQP协议，还支持STOMP、MQTT等多种消息中间件协议

多语言客户端 ∶ RabbitMQ几乎支持所有常用语言，比如 Java、Python、Ruby、PHP、C#、JavaScript 等。

管理界面 ∶RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息、集群中的节点等。

插件机制 ∶RabiMQ提供了许多插件，以实现从多方面进行扩展，当然也可以编写自己的插件。

10.RabbitMQ持久化

持久化可以提高RabbitMQ的可靠性，以防在RabbitMQ重启、关闭、宕机下的数据丢失。

交换器的持久化是在声明交换器的时候，将durable设置为true。如果交换器不设置持久化，那么在RabbitMQ交换器服务重启之后，相关的交换器信息会丢失，不过消息不会丢失，但是不能将消息发送到这个交换器。

队列的持久化在声明队列的时候，将durable设置为true。如果队列不设置持久化，那么RabbitMQ交换器服务重启之后，相关的队列信息会丢失，同时队列中的消息也会丢失。

消息的持久化是在BasicProperties中设置deliveryMode设置为2。队列的持久化能保证本身的元数据不会因为异常而丢失，但是不能保证内部所存在的消息不会丢失。要确保消息不丢失，需要将消息持久化。
如果将所有的消息都进行持久化操作，这样会严重影响RabbitMQ的性能。写入磁盘的速度比写入内存的速度慢很多。所以要在可靠性和吞吐量之间做权衡。

将交换器、队列和消息都进行持久化操作后，也并不能保证消息一定不会丢失。
1.对于消费者来说，如果在订阅消息的时候，将autoAck设置为true，那么消费者接收到消息后，还没有处理，就出现了异常挂掉了，此时，队列中已经将消息删除，消费者不能够在收到消息。这种情况可以将autoAck设置为false，进行手动确认。
2.在持久化后的消息存入Rabbit’MQ之后，还需要一段时间才能存入磁盘。RabbitMQ并不会为每条消息都进行同步存盘，可能仅仅是保存到操作系统缓存之中而不是物理磁盘。如果在这段时间，服务器宕机或者重启，消息还没来得及保存到磁盘当中，从而丢失。对于这种情况，可以引入RabiitMQ镜像队列机制。

rabbitmq中持久化数据什么时候会删除

rabbitmq重启。
创建的队列都是非持久化的，rabbitmq如果重启的话，该队列就会被删除掉，如果要队列实现持久化，需要在声明队列的时候把，durabl参数设置为持久化。
当所有消费客户端断开连接时，而我们对RabbitMQ消息进行了持久化。