RabbitMq保证消息不丢失
RabbitMQ如何保证消息的可靠性:
1.从生产者到消息队列,congfirm模式(与事务相比confirm模式最大的优势是异步)通过消息确认机制来保证,通过给每个指派唯一标志,完成消费后返回ack确认, 2 消息队列 消息队列的持久化,包括交换机持久化,消息队列持久化以及消息持久化 3.消费者 消费完返回完后手动ack确认,开启RabbitMQ会等待消费者显式发回ack信号后才从内存(和磁盘,如果是持久化消息的话)中移去消息。否则,RabbitMQ会在队列中消息被消费后立即删除它。 若长时间没有ack确认会像下一个消费者发送任务,同时需要做等幂性处理。
RabbitMQ消息丢失的情况
RabbitMQ 消息丢失的源头主要有以下三个:
- 生产者丢失消息
- RabbitMQ 丢失消息
- 消费者丢失消息
生产者丢失消息解决方案
事务消息机制:在生产者发送消息之前,通过 channel.txSelect 开启一个事务,接着发送消息,如果消息没有成功被 RabbitMQ 接收到,生产者会收到异常,此时就可以进行事务回滚 channel.txRollback 然后重新发送;假如 RabbitMQ 收到了这个消息,就可以提交事务channel.txCommit;但是这样一来,生产者的吞吐量和性能都会降低很多,现在一般不这么干。
// 开启事务
channel.txSelect
try {
// 这里发送消息
} catch (Exception e) {
channel.txRollback
// 这里再次重发这条消息
}
// 提交事务
channel.txCommit
confirm 机制:就是生产端投递的消息一旦投递到RabbitMQ后,RabbitMQ就会发送一个确认消息给生产端,让生产端知道我已经收到消息了,否则这条消息就可能已经丢失了,需要生产端重新发送消息了。
一般采用异步confirm,所以发送消息之前,需要把消息存起来。所以我们需要为消息分配全局唯一的Id,与消息内容一一对应。
生产者也需要监听Broker发送的通知,根据ack / nack 进行确认。
而具体实现时,需要注意:
- 限制重发次数:超限应标志为任务异常,通过人工处理,避免一直重发浪费资源
- 定时扫描未确认消息,因为broker的响应可能会丢失
rabbitmq:
# 开启发送确认
publisher-confirm-type: correlated
@Service
@Slf4j
public class MqSender {
@Autowired
private RabbitTemplate rabbitTemplate;
//发送秒杀信息
public void sendSeckillMessage(String msg){
log.info("发送消息:" + msg);
rabbitTemplate.convertAndSend("seckillExchange", "seckill.message", msg);