RabbitMQ 消息保证可靠性（存在疑问的笔记）

消息可靠性

• 保证消息不丢失（三步）
  • 开启事务（不推荐）
  • 开启confirm（推荐）【？confirm不理解】
  • 开启rabbitMq持久化（交换机、队列、消息）【rabbit持久化是怎么支持的？】
  • 关闭RabbitMq自动ack（改成手动）【自动ack改成手动，是怎么支持的？为何可以保证消息不丢失】
• 保证消息不重复消费
  • 幂等性（每个消息用一个唯一标识来区分，消费前先判断标识没有被消费过，若已消费过，则直接ACK）【消息是怎么被标识的？】
• rabbitMq如何保证消息的顺序性
  • 将消息放入同一个交换机，交给同一个队列，这个队列只有一个消费者，消费者只允许同时开启一个线程【这个顺序性有点奇葩，有其他方式吗？怎么才能做到】
• rabbitMq的消息重试机制
  • 消费者在消费消息时，如果消费者业务逻辑出现程序异常，这是时候应该如何处理？
    答案：使用消费重试机制（springboot默认3次重试机制）【用哪些类支持的】
  • 如何选择合适的重试机制【具体场景有哪些，比较抽象？】
    • 消费者渠道消息后，调用第三方接口，接口无法访问，需要使用重试机制
    • 消费者取到消息后，抛出数据转换异常，不需要充实机制，需要发布者进行解决
• SpringBoot 消息重试机制
  • 使用@EnableRetry注解：表示启动充实机制（value表示哪些异常需要触发重试，maxAccempts设置最大重试次数，delay表示重试的延迟时间，multiplier表示上一次掩饰时间是这一次的倍数）
    • 代码样例 @Retryable(value = Exception.class, maxAttempts = 3, backoff = @Backoff(delay = 2000, multiplier = 1.5))
• RabbitMq死信队列
  消息被重新投递（publish）到另一个Exchange（死信队列），然后重新消费。说白了就是没有被消费的消息，换个地方重新消费。
  死信队列是当消息再一个队列因为下列原因而变成了“死信队列”：
  • 消息被拒绝（basic.reject或basic.nack）并且requeue=false【这里的几个英文单词的用处现在理解的比较空】
  • 消息TTL过期【啥事TTL，怎么过期的？】
  • 队列达到最大长度（队列满了，数据无法添加到mq钟）【队列有多大；队列为何会满？难道是因为没有人消费？这种情况我们生产出现过，如果规避；死信队列会满吗？】

引用

RabbitMQ如何保证消息的可靠性