[转]消息中间件–5消息中间件集群崩溃，如何保证数据不丢失？
“上一篇讲消息中间件的文章《扎心！线上服务宕机时，如何保证数据100%不丢失？》，初步给大家介绍了一个在生产环境中可能遇到的问题，就是你的消费者服务可能会宕机，一旦宕机，你就需要考虑是否会导致没处理完的消息丢失。
这篇文章，再给不太熟悉MQ技术的同学，介绍另外一个生产环境中可能会遇到的问题。
目前为止，你的RabbitMQ部署在线上服务器了，对吧？然后订单服务和仓储服务都可以基于RabbitMQ来收发消息，同时仓储服务宕机，不会导致消息丢失。
好，我们来看下目前为止的架构图。
那如果此时出现一个问题，就是说订单服务投递了订单消息到RabbitMQ里去，RabbitMQ暂时放在了自己的内存中，还没来得及投递给下游的仓储服务呢，此时RabbitMQ突然宕机了，会怎么样？
答案其实很简单，默认情况下，按照我们目前的代码和配置，这个数据就会丢失了。
所以在这里而言，就牵扯到了RabbitMQ的一个较为重要的概念：消息的持久化，用英文来说就是durable机制。
然后这里又有一个引申的概念，如果按照我们之前的代码和配置，默认情况下，RabbitMQ一旦宕机就再次重启，就会丢失我们之前创建的queue。所以首先得先让queue是持久化的。
使用下面的代码，就可以把我们的“warehouse_schedule_delivery”这个queue，也就是仓储调度发货的queue，设置为持久化的。
这样，即使RabbitMQ宕机后重启，也会恢复之前创建好的这个queue。
1 2 3 4 5 6 7 8 9 10 11 |
channel.queueDeclare( "warehouse_schedule_delivery", true, false, false, null); |
大家看到上面那行定义和创建queue的代码么？核心在于第二个参数，第二个参数是true。
他的意思就是说，这个创建的queue是durable的，也就是支持持久化的。
RabbitMQ会把这queue的相关信息持久化的存储到磁盘上去，这样RabbitMQ重启后，就可以恢复持久化的queue。
那此时RabbitMQ重启之后，他可以恢复queue的信息，但是queue的message数据是没法恢复了。
所以此时还有一个重要的点，就是在你的订单服务发送消息到RabbitMQ的时候，需要定义这条消息也是durable，即持久化的。
1 2 3 4 5 6 7 8 9 |
channel.basicPublish( "", "warehouse_schedule_delivery", MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes()); |
通过上面的方式来发送消息，就可以让发送出去的消息是持久化的。
一旦标记了消息是持久化之后，就会让RabbitMQ把消息持久化写入到磁盘上去，此时如果RabbitMQ还没投递数据到仓储服务，结果就突然宕机了。那么再次重启的时候，就会把磁盘上持久化的消息给加载出来。
整个过程，如下图所示：
但是这里要注意一点，RabbitMQ的消息持久化，是不承诺100%的消息不丢失的。
因为有可能RabbitMQ接收到了消息，但是还没来得及持久化到磁盘，他自己就宕机了，这个时候消息还是会丢失的。
如果要完全100%保证写入RabbitMQ的数据必须落地磁盘，不会丢失，需要依靠其他的机制。
下次有机会再继续给不太熟悉MQ技术的同学，来讲解这里的东西。
[source]消息中间件–5消息中间件集群崩溃，如何保证数据不丢失？
![[转]消息中间件–4如何保证数据100%不丢失？](http://www.mobabel.net/wp-content/themes/hueman/assets/front/img/thumb-medium-empty.png)
![[汇总]AI经验](http://www.mobabel.net/wp-content/themes/hueman/assets/front/img/thumb-small-empty.png)
