RabbitMq面试问题总结

名词解释

connection
客户端和服务器建立的TCP链接

channels 通道
网络信道,几乎所有操作都在channel中进行,同一个TCP链接可以建立多个channel,多路复用

message  消息
传递数据,由body和properties组成,body是消息实体内容
properties的值如下
'content_type' => '类型',
'content_encoding' => '编码',
'application_headers' => 'headers',
'delivery_mode' => '',
'priority' => '',
'correlation_id' => '',
'reply_to' => '',
'expiration' => '',
'message_id' => '',
'timestamp' => '',
'type' => '',
'user_id' => '',
'app_id' => '',
'cluster_id' => '',

Virtual host 虚拟主机
用于逻辑隔离,最上层的路由,相当于mysql的数据库
一个virtual host可以有多个exchange和queue,同一个virtual host不能有重名的exchange和queue

Exchange 交换机
接收消息,根据routing key分发消息到绑定的队列上
每个virtual host都有一个默认的exchange:AMQP default
默认的exchange会绑定全部队列,不能进行binding操作,可以直接使用Queue名作为routing key绑定,如果不存在queue则抛弃消息
交换机4个类型:
-direct:
将消息中的routing key与该exchange关联的所有binding中的routing key进行比较，如果相等，则发送到该binding对应的queue中。

-topic:
上面那个是等值匹配,这个是模糊匹配
*匹配一个单词
#配置0个或多个字符
*,#  只能写在.左右,且不能挨着字符
单词和单词之间需要用.隔开
也可以不用*,#,直接指定一个queue名,实现direct效果
-fanout:
直接把消息转发到所有binding的对应queue中,这种exchange忽略routing key,效率最高 fanout>direct>topic

-headers:
消息中的headers和该exchange关联的binding中参数进行匹配,如果匹配上了,则发送到该binding对应的queue中

queue 队列
存放消息的队列,供消费者消费

routing key 路由规则

binding
exchange和queue之间的绑定,可以包括routing key

Dead-Letter Queue 死信队列
1.消息被否定确认
2.消息在队列存活时间超过设置的TTL时间
3.消息队列的消息数量已经超过最大队列长度
那么该消息将成为死信,如果配置了死信队列,消息将会丢进死信队列中,如果没有配置,则该消息将会被丢弃
配置过程:
1.创建一个死信Exchange:ex_dlx,一个死信Queue:queue_dlx,通过Routing Key:route_dlx绑定
2.创建一个业务Exchange,一个业务Queue,通过Routing Key绑定,其中业务Queue添加属性
x-dead-letter-exchange:ex_dlx
x-dead-letter-routing-key:route_dlx

搭配x-message-ttl属性可以实现延时队列,可以实现下订单15分钟未付款关闭订单的功能

mandatory 强制性
发送消息的时候，当mandatory参数设为true时，交换器无法根据自身的类型和路由键找到一个符合条件的队列，那么RabbitMQ会调用Basic.Return命令将消息返回给生产者

Alternate exchange 备份交换器
创建Exchange的时候可以设置备份交换器,当消息不可达的时候会发送这个备份交换器,优先级别比mandatory高

消息TTL 过期时间
添加队列和发布消息的时候都可以设置TTL,如果两者都设置,那么以时间较小那个为准,消息超过TTL设置的值时,就会变成死信
属性值:x-message-ttl

队列TTL 过期时间
和消息一样,队列也有过期时间,时间到了自动删除
属性值:x-expires

持久化
交换机持久化:设置durable:true
队列持久化:设置durable:true
消息持久化:发送消息的时候设置属性deliveryMode:2

事务机制
-   channel.txSelect用于将当前信道设置成事务模式
-   channel.txCommit用于提交事务
-   channel.txRollback用于事务回滚
但是使用事务机制会吸干RabbitMQ的性能,所以有了下面的发送方确认机制

发送方确认机制
channel.confirmSelect(); //这个机制是异步的

消息分发basicQos 允许限制信道上的消费者所能保持的最大未确认消息的数量
channel.basicQos(5, false); //表示单个消费者消费了5条消息且都没有ack的情况下,服务端不会再分发消息给这个消费者
channel.basicQos(5, true); //表示通道所有消费者消费了5条消息且都没有ack的情况下,服务端不会再分发消息给这个channel

如何提高消息可靠性

设置mandatory参数或者备份交换器
设置publisher confirm机制或者事务机制
设置交换器,队列,消息都为持久化
设置消费端的autoAck为false,并在消费完消息之后再进行消息确认

本作品采用《CC 协议》，转载必须注明作者和本文链接