RabbitMQ知识梳理

保证消息幂等性

批量发布确认

应用场景：1. 订单在十分钟之内未支付则自动取消2. 新创建的店铺，如果在十天内都没有上传过商品，则自动发送消息提醒。3. 用户注册成功后，如果三天内没有登陆则进行短信提醒。4. 用户发起退款，如果三天内没有得到处理则通知相关运营人员。5. 预定会议后，需要在预定的时间点前十分钟通知各个与会人员参加会议

没有接收到ACK消息应答的消息会自动重新进入队列，以便其他消费者进行消费

直接（direct）

消息

队列2

手动应答

生产者将信道设置成 confirm 模式，一旦信道进入 confirm 模式， 所有在该信道上面发布的消息都将会被指派一个唯一的 ID (从 1 开始)，一旦消息被投递到所有匹配的队列之后，broker  就会发送一个确认给生产者(包含消息的唯一 ID)，这就使得生产者知道消息已经正确到达目的队列了，如果消息和队列是可持久化的，那么确认消息会在将消息写入磁盘之后发出，broker 回传给生产者的确认消息中 delivery-tag 域包含了确认消息的序列号，此外 broker 也可以设置 basic.ack 的multiple 域，表示到这个序列号之前的所有消息都已经得到了处理。

可靠性

扇出，发布订阅(fanout)

dead-exchange

confirm模式

一般来说，producer 将消息投递到 broker 或者直接到queue 里了，consumer 从 queue 取出消息进行消费，但某些时候由于特定的原因导致 queue 中的某些消息无法被消费，这样的消息如果没有后续的处理，就变成了死信，有死信自然就有了死信队列。

消息TTL过期

基于插件的延时队列可以避免该情况

消息被拒并且requeue=false（不放到队列中）

惰性队列

队列达到最大长度

死信的来源

为了保证消息在发送过程中不丢失，rabbitmq 引入消息应答机制，消息应答就是: 消费者在接收到消息并且处理该消息之后，告诉 rabbitmq 它已经处理了， rabbitmq 可以把该消息删除了。

生产者

消息自动重新入队

交换机（Exchange）

normal-exchange

应用场景为了保证订单业务的消息数据不丢失，需要使用到 RabbitMQ 的死信队列机制，当消息消费发生异常时，将消息投入死信队列中.还有比如说: 用户在商城下单成功并点击去支付后在指定时间未支付时自动失效

异步发布确认

优先级队列

持久化

P

标题（headers）

消息应答

肯定确认

将队列持久化到磁盘

将消息持久化到磁盘

否定确认

种种原因成为死信

事务transaction

队列1

自动应答

normal-queue

这是主线

发布确认

之前这种业务好多情况下使用的都是定时器轮询查询，对于数据量较大的场景，这种情况不适用

binding

C1

消费者1

概念

dead-queue

主题（topic）

死信队列

单个发布确认

类型

C2

RabbitMQ 消息传递模型的核心思想是: 生产者生产的消息从不会直接发送到队列。实际上，通常生产者甚至都不知道这些消息传递传递到了哪些队列中。相反，生产者只能将消息发送到交换机(exchange)，交换机工作的内容非常简单，一方面它接收来自生产者的消息，另一方面将它们推入队列。交换机必须确切知道如何处理收到的消息。是应该把这些消息放到特定队列还是说把他们到许多队列中还是说应该丢弃它们。这就的由交换机的类型来决定

否定确认可以选择是否将消息直接丢弃

示意图

延迟队列

消费者2

基于死信队列的延时队列会出现消息过期但是还没有被放入延时队列的情况