RabbitMQ常见问题

一、什么是死信队列

 Queue 中的某些消息无法被消费，这类消费异常的数据将会保存在死信队列中防止消息丢失，
死信队列只不过是绑定在死信交换机上的队列。死信交换机只不过是用来接受死信的交换机，可以为任何类型【Direct、Fanout、Topic】。一般来说，会为每个业务队列分配一个独有的路由key，并对应的配置一个死信队列进行监听，也就是说，一般会为每个重要的业务队列配置一个死信队列。
（1）消息的存活时间到了，ttl过期
（2）队列积压的消息达到最大长度（在队列中等待时间最久的消息会成为死信）
（3）消息被拒（消费方返回nack进行否定应答）且不重新加入队列（requeue=false)

二、RabbitMQ-如何保证消息不丢失

confirm机制，手动应答机制，消息及队列持久化

• 生产者把消息发送到 RabbitMQ Server 的过程中丢失

  • 从生产者发送消息的角度来说，RabbitMQ 提供了一个 Confirm（消息确认）机制，生产者发送消息到 Server 端以后，如果消息处理成功，Server 端会返回一个 ack 消息。客户端可以根据消息的处理结果来决定是否要做消息的重新发送，从而确保消息一定到达 RabbitMQ Server 上。

• RabbitMQ Server 收到消息后在持久化之前宕机，数据未到达队列导致数据丢失

  • 在发布消息时，你可以设置消息的持久化属性，使其在 RabbitMQ 服务器宕机后仍然保存在磁盘上。这样即使服务器宕机，消息仍然会被保存，并在服务器重新启动后恢复。使用事务来确保消息的持久化和发送的原子性。在开启事务模式后，RabbitMQ 会等待消息被完全写入磁盘后才确认发布成功

• 队列中的数据还未被消费就宕机，队列中的数据消息丢失

  • 在创建队列时，可以将队列设置为持久化，这样在 RabbitMQ 服务宕机时，所有未被消费的消息也将被持久化保存在磁盘中，并在服务恢复时重新加载到队列中。

• 消费端收到消息还没来得及处理宕机，导致 RabbitMQ Server 认为这个消息已签收

  • 把消息的自动确认机制修改成手动确认，也就是说消费端只有手动调用消息确认方法才表示消息已经被签收。确保消息被成功的业务调用后才发起确认信号来删除队列中的消息。

三、MQ百万消息持续积压问题

        消息积压的原因是生产者的消息生产速度大于消费者的消费速度，遇到这个问题的时候，需要排查具体的原因再提出解决方案

1. 增加消费者数量
如果消息消费者的处理速度无法满足消息产生的速度，可以通过增加消费者的数量来提高消费能力。这样可以将负载分散到多个消费者上，加快消息处理速度，减少积压。

2. 增加消息队列的容量
如果消息队列的容量设置过小，可能会导致消息积压。可以通过增加消息队列的容量来缓解积压问题。但需要注意，过大的消息队列容量可能会增加消息处理的延迟。

3 设置消息消费失败的处理机制
当消息消费失败时，可以根据业务需求选择合适的处理方式。可以将失败的消息记录下来，后续再次消费；或者将失败的消息发送到死信队列进行处理。

4. 监控和报警机制
建立监控和报警机制，及时发现消息积压的情况并采取相应的措施。可以通过监控指标、日志或者专业的监控工具来实现。
 

四、RabbitMQ消息的重复消费问题

消息去重：在消费者端对接收到的消息进行去重操作，可以通过维护一个消息ID的集合（去重表）或者使用唯一标识（查数据库）来判断是否已经消费过该消息。如果已经消费过，则不进行处理，避免重复消费。

消息确认机制：RabbitMQ提供了消息确认机制，可以确保消息被正确地消费。消费者在消费完消息之后，可以手动向RabbitMQ发送确认消息，告知RabbitMQ该消息已经成功消费，RabbitMQ会将该消息标记为已确认，然后删除消息队列中的该消息。

五、RabbitMQ消息的消费顺序性问题

        业务中可能会存在多个消息需要顺序处理的情况，比如生成订单和扣减库存消息，那肯定先执行生成订单的操作，再执行扣减库存操作。

        但我们的项目一般都是集群部署的，一个队列就会有多个消费者，怎么实现一个队列中所有顺序消息只能有一个消费者消费呢？

        RabbitMQ本身并不能直接保证消息的消费顺序，因为其是基于 AMQP 协议 的，它使用多个消费者在多个线程上并行地消费消息。但是可以采取以下方法间接实现消息的有序消费：

1. 单消费者对单队列：可以给 RabbitMQ 创建多个queue， 每个消费者只消费一个queue， 生产者根据订单号，把订单号相同的消息放入一个同一个queue。这样同一个订单号的消息就只会被同一个消费者顺序消费。

2. 分区顺序消息：某些消息队列（如 Kafka）支持分区概念，不同分区之间的消息是并行处理的，但在同一个分区内的消息是有序的。如果业务允许，可以将需要保持顺序的消息发送到同一个分区中。

3. 消费者内部排序：为了减少网络延迟、消费者运行速度等影响，在消费者端，可以对接收到的消息进行排序，以确保按照特定的顺序进行处理。消费者可以在内部维护一个消息缓冲区，按照某个属性或序列号对消息进行排序后再进行处理。消息排序字段：在消息中添加一个排序字段，消费者在处理消息时根据该字段进行排序，保证消息的顺序性