仿大众点评——秒杀系统部分03——RabbitMq措施

本文链接：https://blog.youkuaiyun.com/mao____mao/article/details/127940966

本文探讨了如何使用RabbitMQ确保消息不丢失，包括使用confirm机制、消息持久化、消息入库和消息延迟投递。此外，还讨论了如何处理消息幂等性，防止重复消费，如设计幂等性接口、使用防重表和唯一键策略。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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);