赞
踩
一、RabbitMQ如何保证消息的发送和接收
1.ConfirmCallback方法
ConfirmCallback是一个回调接口,消息发送到broker后触发回调,确认消息是否到达broker服务器,也就是只确认消息是否正确到达Exchange交换机中。
2.ReturnCallback方法
通过实现ReturnCallback接口,启动消息失败返回,此接口是在交换机路由不到队列时触发回调,该方法可以不使用,因为交换机和队列是在代码里绑定的,如果消息投递到broker后几乎几乎不存在绑定队列失败,除非你代码写错了。
3.消息确认接收
RabbitMQ消息确认机制ack是默认自动确认的,自动确认会在消息发送给消费者后立即确认,但存在消息丢失的可能,如果消费逻辑出现异常,假如回滚了,也只是保证了数据一致性,但是消息还是丢了,也就是消费端没有成功处理这个消息,相当于消息丢失。
消费者收到消息后,手动调用Basic.ack或Basic.Nack或Basic.Reject后,RabbitMQ收到这些消息后,才认为本次投递完成。
Basic.ack 用于确认当前消息,Basic.Nack 用于否定当前消息 ,Basic.Reject 用于拒绝当前消息
Nack ,Reject 后有能力要求是否requeue消息或进入死信队列。
1.1 生产时消息重复
由于生产者发送消息给MQ,在MQ确认的时候出现了网络波动,生产者没有收到确认,实际上MQ已经接收到了消息。这时候生产者就会重新发送一遍这条消息。
生产者中如果消息未被确认,或确认失败,我们可以使用定时任务+(redis/db)来进行消息重试。
1.2消费时消息重复
消费者消费成功后,再给MQ确认的时候出现了网络波动,MQ没有接收到确认,为了保证消息被消费,MQ就会继续给消费者投递之前的消息。这时候消费者就接收到了两条一样的消息。
让每个消息携带一个全局的唯一ID,即可保证消息的幂等性,具体消费过程为:
消费者获取到消息后先根据id去查询redis/db是否存在该消息
如果不存在,则正常消费,消费完毕后写入redis/db
如果存在,则证明消息被消费过,直接丢弃。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。