如果你公司里的MQ集群崩溃了,你能确保数据绝对不丢失吗?

656 阅读4分钟

上一篇讲消息中间件的文章:《如果公司线上系统突然宕机了,怎么才能确保MQ消息不丢失?》,初步给大家介绍了一个在生产环境中可能遇到的问题,就是你的消费者服务可能会宕机,一旦宕机,你就需要考虑是否会导致没处理完的消息丢失。

这篇文章,给不太熟悉MQ技术的同学,介绍一个生产环境中可能会遇到的问题。

目前为止,你的RabbitMQ部署在线上服务器了,对吧?然后订单服务和仓储服务都可以基于RabbitMQ来收发消息,同时仓储服务宕机,不会导致消息丢失。

1_副本.jpg

好,我们来看下目前为止的架构图。

那如果此时出现一个问题,就是说订单服务投递了订单消息到RabbitMQ里去,RabbitMQ暂时放在了自己的内存中,还没来得及投递给下游的仓储服务呢,此时RabbitMQ突然宕机了,会怎么样?

答案其实很简单,默认情况下,按照我们目前的代码和配置,这个数据就会丢失了。

所以在这里而言,就牵扯到了RabbitMQ的一个较为重要的概念:消息的持久化,用英文来说就是durable机制。

然后这里又有一个引申的概念,如果按照我们之前的代码和配置,默认情况下,RabbitMQ一旦宕机就再次重启,就会丢失我们之前创建的queue。所以首先得先让queue是持久化的。

使用下面的代码,就可以把我们的“warehouse_schedule_delivery”这个queue,也就是仓储调度发货的queue,设置为持久化的。

这样,即使RabbitMQ宕机后重启,也会恢复之前创建好的这个queue。

channel.queueDeclare(

            "warehouse_schedule_delivery",

             true, 

             false,

             false,

             null);

大家看到上面那行定义和创建queue的代码么?核心在于第二个参数,第二个参数是true。

他的意思就是说,这个创建的queue是durable的,也就是支持持久化的。

RabbitMQ会把这queue的相关信息持久化的存储到磁盘上去,这样RabbitMQ重启后,就可以恢复持久化的queue。

2_副本.jpg

OK,现在你的queue的信息可以持久化了,RabbitMQ宕机重启后会自动恢复queue。但是,你的queue里的message数据呢? queue里都是订单服务发送过去的订单消息数据,如果RabbitMQ还没来得及投递queue里的订单消息到仓储服务,结果RabbitMQ就宕机了。

那此时RabbitMQ重启之后,他可以恢复queue的信息,但是queue的message数据是没法恢复了。 所以此时还有一个重要的点,就是在你的订单服务发送消息到RabbitMQ的时候,需要定义这条消息也是durable,即持久化的。

channel.basicPublish(

  "", 

  "warehouse_schedule_delivery",

  MessageProperties.PERSISTENT_TEXT_PLAIN,

  message.getBytes());

通过上面的方式来发送消息,就可以让发送出去的消息是持久化的。

一旦标记了消息是持久化之后,就会让RabbitMQ把消息持久化写入到磁盘上去,此时如果RabbitMQ还没投递数据到仓储服务,结果就突然宕机了。那么再次重启的时候,就会把磁盘上持久化的消息给加载出来。

整个过程,如下图所示:

3_副本.jpg

但是这里要注意一点,RabbitMQ的消息持久化,是不承诺100%的消息不丢失的。

因为有可能RabbitMQ接收到了消息,但是还没来得及持久化到磁盘,他自己就宕机了,这个时候消息还是会丢失的。

如果要完全100%保证写入RabbitMQ的数据必须落地磁盘,不会丢失,需要依靠其他的机制。

图片

图片


另外推荐儒猿课堂的1元系列课程给您,欢迎加入一起学习~

互联网Java工程师面试突击课(1元专享)

SpringCloudAlibaba零基础入门到项目实战(1元专享)

亿级流量下的电商详情页系统实战项目(1元专享)

Kafka消息中间件内核源码精讲(1元专享)

12个实战案例带你玩转Java并发编程(1元专享)

Elasticsearch零基础入门到精通(1元专享)

基于Java手写分布式中间件系统实战(1元专享)

基于ShardingSphere的分库分表实战课(1元专享)