RabbitMQ是实现了高级消息队列协议(AMQP)的开源消息代理软件(亦称面向消息的中间件)。RabbitMQ服务器是用Erlang语言编写的。
常用消息策略:发布订阅模式 fanout、路由模式 route、主题模式 topic等
特性
1、消息如何保障100%的投递成功
2、幂等性概念
3、在海量订单产生的业务高峰期,如何避免消息的重复消费问题
4、Confirm确认消息,Return返回消息
5、消息的ACK与重回队列
6、消息的限流
7、TTL消息
8、死信队列
一、什么是生产端的可靠性投递?
保障消息的成功发出、MQ节点的成功接收、发送端收到MQ节点(Broker)确认应答、完善的消息进行补偿机制
解决方案:消息落库,对消息状态进行打标;幂等性借鉴数据库的乐观锁机制实现(数据库主键去重)。
二、Confirm确认消息、Return消息
Confirm消息的确认,是指生产者投递消息后,如果Broker收到消息,则会给我们生产者一个应答;生产者进行接收应答,用来确定这条消息是否正常的发送到Broker,这种方式也是消息的可靠性投递的核心保障。
如何实现Confirm确认消息
1.在channel上开启确认模式:channel.confirmSelect()
2.在channel上添加监听,addConfirmListener,监听成功和失败的返回结果,根据具体的结果对消息进行重新发送,或记录日志等后续处理。
Reruen消息机制,Return Listener用于处理一些不可路由的消息;我们的消息生产者,通过指定一个Exchange和Routingkey,把消息送达到某一个队列中去,然后我们的消费者监听队列,进行消费处理操作;当exchange不存在或者指定的路由key路由不到,监听这种不可达的消息,就要使用ReturnListener!
如何实现Return消息机制
1.在基础API中找到配置项:Mandatory,设置为true,则监听器会接收到路由不可达的消息,进行后续的处理,为false,则broker端自动删除该消息。
三、消费端限流
RabbitMq提供了一种qos(服务质量保证)功能,即在非自动确认消息的前提下,如果一定数目的消息(通过基于consume或者channel设置Qos的值)未被确认前,不进行消费新的消息。
四、消息的ACK与重回队列
(基本使用手动ACK)
消费端的手工ACK和NACK,消费端进行消费时由于业务异常进行日志的记录,然后进行补偿;由于服务器宕机等严重问题,则需要手工进行ACK保障消费端消费成功!
(重回队列一般不开启,容易卡死)
消费端重回队列是为了对没有处理成功的消息,把消息重新会传递给Broker!
五、TTL队列/消息
TTL:Time To Live 生存时间
RabbitMq支持消息的过期时间,在消息发送时可以进行指定;同时支持队列的过期时间,从消息入队列开始计算,只要超过了队列的超时时间配置,那么消息会自动的清除。
死信队列(一个特殊的Exchange):DLX,当消息在一个队列中变成死信,可以publish到另一个Exchange,就是DLX。
消息变为死信队列的几种情况:1.消息被拒绝并且不重回队列 2.消息TTL过期 3.队列达到最大长度
死信队列设置(交换机,队列,路由key):
Exchange:dlx.exchange
Queue:dlx.queue
RoutingKey:#
正常队列设置:
同上,增加一个参数即可将问题消息放置指定的死信队列
arguments.put("x-dead-letter-exchange","dlx.exchange");
这样在消息过期、队列超长等情况下就会被路由到死信队列进行再处理,避免消息丢失。