关于java:如何保证消息队列的可靠性传输

3次阅读

共计 677 个字符,预计需要花费 2 分钟才能阅读完成。

音讯失落分成三种状况,可能呈现生产者、RabbitMQ、消费者。

生产者失落数据

首先要确保写入 RabbitMQ 的音讯别丢,音讯队列通过 申请确认机制,保障音讯的牢靠传输。生产开启 comfirm 模式,在生产者开启 comfirm 模式之后,每次发送音讯都会调配一个惟一的 id。

  • 如果写入了 RabbitMQ 中,RabbitMQ 会回传一个 ack 音讯
  • 如果没能写入 RabbitMQ,会回调一个 nack 接口,能够从新发送音讯

个别在生产者这块防止数据失落,都是用 confirm 机制的

RabbitMQ 失落数据

RabbitMQ 失落数据,须要开启 RabbitMQ 长久化,开启长久化之后,生产者发送的音讯会长久化到磁盘,RabbitMQ 就算是挂了,复原启动后也会读取之前存储的数据。
还有一种少见的状况,就是 RabbitMQ 还没将音讯长久化,本人就挂了。这种状况须要生产者那边的确认机制联合起来。只有音讯被长久化到磁盘当前,才会回传 ack 音讯。生产者没有接管到 ack,也能够本人重发。

消费者失落数据

生产失落数据,刚生产到 RabbitMQ 发送的数据,生产过程就挂了,重启过程后,RabbitMQ 也不会从新发送音讯。
这个时候须要敞开 RabbitMQ 敞开主动的 ack 机制。每次在生产端解决后,再在程序里做 ack 确认,这样的话,如果没有解决完,就没有 ack 确认,那 RabbitMQ 就认为你还没有解决完,这个时候 RabbitMQ 会从新发送音讯给消费者。

总结

  • 生产者

    • 开启确认 comfirm 机制
  • MQ

    • 开启 RabbitMQ 长久化
  • 消费者

    • 敞开 RabbitMQ 主动 ack 确认

如果感觉文章对你有帮忙的话,请点个赞吧!

正文完
 0