消息确认机制
为了保证消息成功被消费,rabbitMQ提供了消息确认机制。当消费者接收到消息后,要给一个反馈:
- ack:消费成功
- nack:消费失败
- reject:拒接
如果消费成功,告诉rabbitmq消费成功,才会放心地移除消息
1、支持配置autoack,会自动执行ack命令,接受到的消息就成功了
channel.basicConsume(TASK_QUEUE_NAME, false, deliverCallback, consumerTag -> { });
但是建议autoack改为false,进行手动确认消息
2、指定确认某条消息
第二个参数multiple进行批量处理,即此消费者之前积压了消息没有处理,参数设置为true则之前的消息一并处理了。
channel.basicAck(delivery.getEnvelope().getDeliveryTag(),false);
3、指定性拒绝某条消息
第三个参数requeue,表示拒绝的消息是否重新入队。
channel.basicNack(delivery.getEnvelope().getDeliveryTag(),false,false);
消息过期机制(TTL)
可以给每条消息指定一个有效期,一段时间未被消费,就过期了。
示例场景:消费者(库存系统)挂了,一个订单15分钟没有被库存系统处理,这个订单就已经失效了,哪怕库存系统再恢复,也不用扣减库存。
使用场景:请理过期数据,模拟延迟队列(创建两个队列,第一个队列设定一个过期时间,过期后放入第二个队列,第二个队列就是延迟队列。不开会员就慢速),专门让某个程序处理延迟消息
- 给某条队列设置过期时间
如果再过期时间内,还没有消费者取消息,消息才会过期
如果已经接收,但是没有确认,是不会过期的。
- 给某个消息设置过期时间
死信队列(容错机制)
1、为了保证消息的可靠性,比如每条消息都成功消费,需要提供一个容错机制,即:失败的消息怎么处理?
2、死信:过期的消息、拒收的消息、处理失败的消息、消息队列满了的信息的统称
3、死信队列:专门处理死信的队列(一个普通的队列)
4、死信交换机:专门给死信队列转发消息的交换机。也存在路由绑定关系
场景示例:
实现:
1、创建死信交换机和死信队列
2、给失败后需要容错处理的队列绑定死信交换机
3、可以给要容错的队列指定死信之后的转发规则,死信应该再转发到哪个死信队列
交换机
1、作用:提供消息转发的功能,类似于网络路由器
2、 一个生产者给多个队列发消息,1个队列对应多个消费者
3、绑定:交换机和队列关联起来,也可以叫路由,算是一个算法或者转发策略
fanout交换机:扇出、广播
1、特点:很适用于转发到所有绑定到该交换机的队列
2、场景:很适用于发布订阅场景。比如写日志,可以多个系统之间共享
Direct交换机:
1、绑定:指定交换机与哪个队列关联。让交换机把什么样的消息发给哪个队列(类似于计算机网络中的两个路由,或者是网线)
2、关键的参数:路由键(routinKey),控制消息要转发给哪个队列
3、特点:消息会根据路由键转发到指定的队列
4、场景:特定的消息只分配给特定的系统执行
日志信息分类:
场景:
topic交换机:
1、特点:消息会根据一个模糊的路由键转发到指定的队列
2、场景:特定的一类消息可以交给特定的一类系统(程序)来处理
3、绑定关系:可以,模糊匹配多个绑定,类似于数据库中的模糊查询
* :匹配一个单词
#:匹配0个或者多个单词
注意:这里的匹配和数据库中的Like 的%不一样,只能按照单个单词来匹配,每个’.‘分隔单词,如果是’#.‘,其实可以忽略,匹配0个词也ok。
应用场景:
老板要发送一个任务,让多个组处理。
面试重点:
- 消息队列的概念、模型、应用场景
- 交换机的类别、路由绑定的关系
- 消息可靠性
a.消息确认机制(ack、nack、reject)
b.消息持久化(durable)
c.消息过期机制
d.死信队列
4.延迟队列(类似于死信队列)