rabbitMQ的五种模型及消息确认机制

rabbitMQ的五种模型及消息确认机制

队列、交换机、生产者、消费者、虚拟主机之间的关系；不同的服务可以定义在不同的虚拟主机之中，不同的虚拟主机之间互不通信

1.HelloWorld 模型

• 生产者向队列中发送消息，消费者监听队列，消费消息；
• 当队列中的消息被拿走后，就会自动从队列中被删除；
• 存在的问题是：当消息被消费者拿走但并未被正常消费，但队列中的消息已被删除，此时可能会出现消息丢失现象。

2. work模型

• 当生产者生产消息的速度大于消费者消费消息的速度的时候
• 生产者向队列中发送消息
• 存在多个消费者平均消费消息
• 消息一旦被消费，即被从队列中删除，因此不会存在重复消费消息
• 存在隐患：消息被发送给消费者后会自动从队列中删除，若消费者在消费的过程中出现进程阻塞、宕机，网络不稳定、服务器异常等现象，则会导致未被消费的消息丢失，为了解决这一问题可以使用RabbitMQ提供的 消息确认机制（Ack）实现能者多劳，见下文
• 有看到别的博客中说work模式的多个消费者之间是竞争关系，但本文使用的rabbitMQ版本为3.7.18，创建多个消费者的时候，不同消费者之间则是平均消费消息，这种平均消费的方式有明显的不足（消息处理快的消费者完成消费后仍处于等待状态，而处理慢的消费者却出现消息阻塞的情况），会造成一定的资源浪费。
• 补充：对于work的平均分发机制，可以通过设置消费者的channel.basicQos(1)将消息分发设置为不公平，从而实现能者多劳

3. Fanout模型

• 可以有多个消费者，每个消费者都有自己单独的队列（queue）
• 每个queue都要绑定到交换机（X）上
• 生产者只能将消息发送到交换机上，交换机来决定将消息发送到绑定的所有队列上，生产者无法决定
• 若有多个队列绑定到同一个交换机上，则能实现将一个消息发送给多个消费者

4.Direct模型（Routing）

• 队列和交换机之间的绑定关系需要依赖于Routing key(路由key)
• 生产者在向交换机发送消息的时候也需要指定一个Routing key
• 消费者根据Routing key判断，只有当队列绑定交换机的Routing key与生产者和交换机之间的Routing key一致时，才能收到消息
• 目的是使得不同的队列绑定到同一交换机上时，可以收到不同的消息

5. Topic模型

• 星号井号代表通配符
• 星号代表多个单词,井号代表一个单词
• 路由功能添加模糊匹配
• 消息产生者产生消息,把消息交给交换机
• 交换机根据key的规则模糊匹配到对应的队列,由队列的监听消费者接收消息消费

消息确认机制实现能者多劳

• 为什么有消息确认？
  消息的自动确认机制会在消息被发送给消费者后，将消息从队列中删除，若在处理消息的过程中，消费者在消费的时候发生了异常，则会导致消息丢失，为了确保消息不会被丢失，引入了ACK机制。
• ACK具体？
  取消消息的自动确认机制，只有当消费者完成消息消费后才向rabbitMQ发送确认，rabbitMQ在收到确认后才将队列中的消息删除，否则会认为消费未被消费者成功消费，而重复向消费者发送消息
• 注意事项？

1. RabbitMQ的确认机制默认是打开的
2. 在集群环境中，RabbitMQ会将未成功消费的消息推送给在线的其他消费者
3. 消费者务必在成功消费消息后向rabbitMQ确认，否则rabbitMQ会一直向队列中重发消息，而这将造成严重的内存泄漏。