最后
金三银四马上就到了，希望大家能好好学习一下这些技术点
学习视频：
大厂面试真题：
-
- 1. 两种消费思路
-
2. 确保消费成功两种思路
-
3. 消息拒绝
-
4. 消息确认
-
- 4.1 自动确认
-
4.2 手动确认
-
- 4.2.1 推模式手动确认
-
4.2.2 拉模式手动确认
-
5. 幂等性问题
-
6. 小结
前面一篇文章松哥和大家聊了 MQ 高可用之如何确保消息成功发送，各种配置齐上阵，最终确保了消息的成功发送，甚至在一些极端情况下还可能发生同一条消息重复发送的情况，不管怎么样，消息总算发送出去了，如果小伙伴们还没看过上篇文章，建议先看看，再来学习本文：
今天我们就来聊一聊消息消费的问题，看看如何确保消息消费成功，并且确保幂等性。
RabbitMQ 的消息消费，整体上来说有两种不同的思路：
-
推（push）：MQ 主动将消息推送给消费者，这种方式需要消费者设置一个缓冲区去缓存消息，对于消费者而言，内存中总是有一堆需要处理的消息，所以这种方式的效率比较高，这也是目前大多数应用采用的消费方式。
-
拉（pull）：消费者主动从 MQ 拉取消息，这种方式效率并不是很高，不过有的时候如果服务端需要批量拉取消息，倒是可以采用这种方式。
两种方式我都举个例子看下。
先来看推（push）：
这种方式大家比较常见，就是通过 @RabbitListener 注解去标记消费者，如下：
@Component
public class ConsumerDemo {
@RabbitListener(queues = RabbitConfig.JAVABOY_QUEUE_NAME)
public void handle(String msg) {
System.out.println("msg = " + msg);
}
}
当监听的队列中有消息时，就会触发该方法。
再来看拉（pull）：
@Test
public void test01() throws UnsupportedEncodingException {
Object o = rabbitTemplate.receiveAndConvert(RabbitConfig.JAVABOY_QUEUE_NAME);
System.out.println("o = " + new String(((byte[]) o),“UTF-8”));
}
调用 receiveAndConvert 方法，方法参数为队列名称，方法执行完成后，会从 MQ 上拉取一条消息下来，如果该方法返回值为 null，表示该队列上没有消息了。receiveAndConvert 方法有一个重载方法，可以在重载方法中传入一个等待超时时间，例如 3 秒。此时，假设队列中没有消息了，则 receiveAndConvert 方法会阻塞 3 秒，3 秒内如果队列中有了新消息就返回，3 秒后如果队列中还是没有新消息，就返回 null，这个等待超时时间要是不设置的话，默认为 0。
这是消息两种不同的消费模式。
如果需要从消息队列中持续获得消息，就可以使用推模式；如果只是单纯的消费一条消息，则使用拉模式即可。切忌将拉模式放到一个死循环中，变相的订阅消息，这会严重影响 RabbitMQ 的性能。
在上篇文章中，我们想尽办法确保消息能够发送成功，对于消息消费成功，其实官方提供了相关的机制，我们一起来看下。
为了保证消息能够可靠的到达消息消费者，RabbitMQ 中提供了消息消费确认机制。当消费者去消费消息的时候，可以通过指定 autoAck 参数来表示消息消费的确认方式。
-
当 autoAck 为 false 的时候，此时即使消费者已经收到消息了，RabbitMQ 也不会立马将消息移除，而是等待消费者显式的回复确认信号后，才会将消息打上删除标记，然后再删除。
-
当 autoAck 为 true 的时候，此时消息消费者就会自动把发送出去的消息设置为确认，然后将消息移除（从内存或者磁盘中），即使这些消息并没有到达消费者。
我们来看一张图：
如上图所示，在 RabbitMQ 的 web 管理页面：
-
Ready 表示待消费的消息数量。
-
Unacked 表示已经发送给消费者但是还没收到消费者 ack 的消息数量。
这是我们可以从 UI 层面观察消息的消费情况确认情况。
当我们将 autoAck 设置为 false 的时候，对于 RabbitMQ 而言，消费分成了两个部分：
-
待消费的消息
-
已经投递给消费者，但是还没有被消费者确认的消息
换句话说，当设置 autoAck 为 false 的时候，消费者就变得非常从容了，它将有足够的时间去处理这条消息，当消息正常处理完成后，再手动 ack，此时 RabbitMQ 才会认为这条消息消费成功了。如果 RabbitMQ 一直没有收到客户端的反馈，并且此时客户端也已经断开连接了，那么 RabbitMQ 就会将刚刚的消息重新放回队列中，等待下一次被消费。
综上所述，确保消息被成功消费，无非就是手动 Ack 或者自动 Ack，无他。当然，无论这两种中的哪一种，最终都有可能导致消息被重复消费，所以一般来说我们还需要在处理消息时，解决幂等性问题。
当客户端收到消息时，可以选择消费这条消息，也可以选择拒绝这条消息。我们来看下拒绝的方式：
@Component
public class ConsumerDemo {
@RabbitListener(queues = RabbitConfig.JAVABOY_QUEUE_NAME)
public void handle(Channel channel, Message message) {
//获取消息编号
long deliveryTag = message.getMessageProperties().getDeliveryTag();
try {
//拒绝消息
channel.basicReject(deliveryTag, true);
} catch (IOException e) {
e.printStackTrace();
}
}
}
消费者收到消息之后，可以选择拒绝消费该条消息，拒绝的步骤分两步：
-
获取消息编号 deliveryTag。
-
调用 basicReject 方法拒绝消息。
调用 basicReject 方法时，第二个参数是 requeue，即是否重新入队。如果第二个参数为 true，则这条被拒绝的消息会重新进入到消息队列中，等待下一次被消费；如果第二个参数为 false，则这条被拒绝的消息就会被丢掉，不会有新的消费者去消费它了。
需要注意的是，basicReject 方法一次只能拒绝一条消息。
消息确认分为自动确认和手动确认，我们分别来看。
4.1 自动确认
先来看看自动确认，在 Spring Boot 中，默认情况下，消息消费就是自动确认的。
我们来看如下一个消息消费方法：
@Component
public class ConsumerDemo {
@RabbitListener(queues = RabbitConfig.JAVABOY_QUEUE_NAME)
public void handle2(String msg) {
System.out.println("msg = " + msg);
int i = 1 / 0;
}
}
通过 @Componet 注解将当前类注入到 Spring 容器中，然后通过 @RabbitListener 注解来标记一个消息消费方法，默认情况下，消息消费方法自带事务，即如果该方法在执行过程中抛出异常，那么被消费的消息会重新回到队列中等待下一次被消费，如果该方法正常执行完没有抛出异常，则这条消息就算是被消费了。
4.2 手动确认
手动确认我又把它分为两种：推模式手动确认与拉模式手动确认。
4.2.1 推模式手动确认
最后
做任何事情都要用心，要非常关注细节。看起来不起眼的、繁琐的工作做透了会有意想不到的价值。
当然要想成为一个技术大牛也需要一定的思想格局，思想决定未来你要往哪个方向去走, 建议多看一些人生规划方面的书籍,多学习名人的思想格局，未来你的路会走的更远。
更多的技术点思维导图我已经做了一个整理，涵盖了当下互联网最流行99%的技术点，在这里我将这份导图分享出来，以及为金九银十准备的一整套面试体系，上到集合，下到分布式微服务
…(img-vMiiUMbT-1715646640704)]
[外链图片转存中…(img-tttVTuYO-1715646640704)]
[外链图片转存中…(img-57ZvUjME-1715646640704)]
2246
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
