RabbitMQ
一、高级特性
消息的可靠性
- exchange confirm
- 回退
- consumer ack
消费端限流
- 自动确认设置为手动,设置每次消费10的步长
TTL(TimeToLive)
-
RabbitMQ过期队列和过期消息处理机制:
-
1.当队列和队列当中的消息(1条消息)都设置了过期时间,以时间短的为准
-
2.当队列存在多条消息时,且存在设置了过期时间的消息,RabbitMQ是怎么处理的呢?
- 1.并不是以时间短的消息为准删除所有消息❎
- 2.RabbitMQ是将该队列中的消息逐个进行消费,当发现过期的消息,将其删除✅,节省ARM
-
-
在queue定义中添加实例:
死信队列DLX
-
什么是死信队列
- 消息成为Dead message后被重新发送到另一个交换,这个交换机被就是DLX
-
死信队列图解
-
成为死信队列的条件有哪些
- 超时未被消费:x-message-ttl
- 超长:x-max-length;x-max-length-bytes
- 被消费者拒绝签收basicNack,并且requeue=”false“
延迟队列(TTL+DLX)
-
延迟队列图解:
-
延迟队列应用场景
- 1、下单成功在规定时间内未进行付款取消订单
- 2、成功注册账号在七天之后发短信问候
-
延迟队列的使用
- 1.定义正常队列,交换机并绑定
- 2.定义死信队列、死信交换机并绑定
- 3.设置正常队列的x-message-ttl,x-dead-letter-exchange,也可以设置x-dead-letter-routing-key
- 4.consumer编写Listener类(implements ChannelAwareMessageListener) 重写onMessage(Message message,Channel channel)方法,在xml文件中设置rabbitMQ监听类,监听的对列是死信队列
- 4.启动consumer测试,producer测试向正常队列发送message
二、日志监控
RabbitMQ默认日志存放路径:/var/log/rabbitmq/rabbit@xxx.log
日志包含的内容:日志包含了RabbitMQ的版本号、Erlang的版本号、RabbitMQ服务节点名称、cookie的hash值、RabbitMQ配置文件地址、内存限制、磁盘限制、默认账户guest的创建以及权限配置等等。
RabbitMQ常用的命令操作
- 查看队列:rabbitmqctl list_queues
- 查看exchange:rabbitmqctl list_exchanges
- 查看用户:rabbitmqctl list_users
- 查看连接:rabbitmqctl list_connections
- 查看消费者信息:rabbitmqctl list_consumers
- 查看环境:rabbitmqctl environment
- 查看未被确认的队列:rabbitmqctl list_queues name messages_unacknowledged
- 查看单个队列的内存使用情况:rabbitmqctl list_queues name memory
- 查看准备就绪的队列:rabbitmqctl list_queues name messages_ready
三、消息追踪(了解)
Firehouse
rabbitmq_tracing
消息追踪的方式
-
1.Firehouse
- 机制:friehouse是将发送给consumer的消息投递给默认交换机(amq.rabbitmq.trace topic型),发送到这个交换机的消息routingKey为public.exchange和deliver.queuename。其中exchangename和queuename为实际exchange和queue的名称,分别对应生产者投递到exchange的消息,和消费者从queue上获取的消息。
- 开启Firehouse命令:rabbitmqctl trace_on
- 关闭Firehouse命令:rabbitmqctl trace_off
- 注意:打开Firehouse会影响消息的写入功能,适当打开后请关闭
-
2.rabbitmq_tracing
- 机制:通透Firehouse是一样的,只是通过插件可以进行可视化,方便管理
- 启动插件命令:rabbitmq-plugins enable rabbitmq_tracing
为什么要进行消息追踪
- 1.某条消息异常丢失
- 2.producer获取consumer与RabbitMQ断开连接
- 3.中间件与RabbitMQ采用了同的确认机制
- 4.中间件与RabbitMQ采用了不同的转发策略
- 5.或者交换机没有与任何队列进行绑定,并且生产者不感知或者不进行相应的措施
- 6.RabbitMQ集群策略本身导致的消息丢失
四、应用问题
1.消息可靠性保障
-
消息补偿机制的目的是确保消息100%发送成功
-
消息补偿机制是目前大型企业用于解决高并发,确保消息可靠性的主流方案,面试题会问怎么设计怎么实现的
-
消息补偿机制具体流程图&解释:
-
流程解释:
-
正常流程:
- producer发送业务Q1给consumer,同时业务入producer库发送延迟消息Q3给回调服务;消费者成功消费入consumer库,发送确认消息Q2给回调服务将业务消费id写入MDB,Q3到达时会与MDB中的消费id进行比对是否一致,一致说明成功,回调服务不进行操作
-
出现异常的流程:
- Q1失败:回调服务会拿到Q3的id与MDB进行比对,未发现消费id会进行调用producer重新发送
- Q1和Q3都失败:定时检查服务会查看MDB和业务DB,看两个数据 库中id消息是否匹配,Q1和Q3未发送出去,MDB数据是比DB数据库中业务多的,这是定时检查服务会调用producer重新发送
-
-
总结:简单的回答消息补偿机制是怎么实现的,就是将消息写入数据库中,对比前后id是否缺少一致,最后的的保障是定时检查服务
2.消息的幂等性保障
-
什么是消息的幂等性保障:
- 幂等性保障就是一次或者多次请求同一个资源,对资源本身应该具有相同的结果,在MQ中指,消费多条相同的消息,得到与消费该消息一次相同的结果。
-
幂等性保障措施–乐观锁机制流程图&解释:
-
流程解释:
- 当发送一条消费消息给consumer,这条消息会携带id和version号,当这条消息被消费过后会将version进行+1 操作,当由于其他原因这条id=1&version=1的消息从producer再次发送到consumer时,无法再次消费,因为version已经发生变化,不管producer发送多少次都不会再次别consumer消费
五、集群搭建(了解,用到时查文档)
RabbitMQ的高可用集群
-
图解:
-
HAProxy解释:
- High availability proxy 高可用代理
-
集群搭建文档
- 集群搭建见:)5.RabbitMQ集群搭建(了解