【RabbitMQ】进阶总结

 

消息传递情况

mandatory

• mandatory=true，如果交换器无法根据自身的类型和路由键找到一个符合条件的队列，RabbitMQ会调用 Basic.Return 命令将消息返回给生产者
• mandatory=false，上述情形下，RabbitMQ 将消息直接丢弃
• 生产者通过调用 channel.addReturnListener 添加监听器接收返回结果

---

immediate

• immediate=true，如果交换器在消息路由到队列时发现队列上并不存在任何消费者，该消息将不会存入队列中。当与路由键匹配的所有队列都没有消费者时，该消息会通过 Basic.Return 返回生产者
• 和mandatory相比，mandatory如果路由不到队列则返回消息，immediate如果队列中没有消费者则返回消息

---

备份交换器

AE可以将未被路由的消息存储到 RabbitMQ 中

Map args = new HashMap();
args.put("alternate-exchange","myAe");

// 声明普通交换器（AE交换器作为备份交换器）
channel.exchangeDeclare("normalExchange","direct",true,false,args);
// 声明AE交换器
channel.exchangeDeclare("myAe","fanout",true,false,null);

// 普通队列 绑定 普通交换器
channel.queueBind("normalQueue","normalExchange","normalKey");

// 声明 未路由队列
channel.queueDeclare("unroutedQueue",true,false,false,null);
// 未路由队列 绑定 AE交换器
channel.queueBind("unroutedQueue","myAe","");

特殊情况

• 若备份交换器不存在，客户端和 RabbitMQ 服务端都不会有异常出现，消息丢失
• 若备份交换器没有绑定任何队列，客户端和 RabbitMQ 服务端都不会有异常出现，消息丢失
• 若备份交换器没有匹配任何队列，客户端和 RabbitMQ 服务端都不会有异常出现，消息丢失
• 若备份交换器和mandatory参数一起使用，该参数无效

 

过期时间（TTL）

通过队列设置消息TTL

Map args = new HashMap();
args.put("x-message-ttl",6000); // 单位毫秒
channel.queueDeclare(queueName,durable,exclusive,autoDelete,args);

Policy方式

rabbitmqctl set_policy TTL ".*" '{"message-ttl":6000}' --apply-to queues

• 不设置TTL：该消息不会过期
• TTL为0：若直接可以投递到消费者，否则立刻被丢弃

消息过期：一旦过期，从队列中抹去

---

设置每条消息TTL

在 channel.basicPublish 方法中加入 expiration 参数，单位毫秒

AMQP.BasicProperties.Builder builder = new AMQP.BasicProperties.Builder();
builder.deliveryMode(2);
builder.expiration("60000");
AMQP.BasicProperties properties = builder.build();
channel.basicPublish(exchangeName,routingKey,mandatory,properties,"ttlTestMessage".getBytes());

消息过期：消息过期后，不会马上从队列中抹去，在即将投递到消费者之前判定

---

设置队列的TTL

通过 channel.queueDeclare 方法中的 x-expires 参数可以控制队列被自动删除前处于未使用状态的时间

RabbitMQ 会确保在过期时间到达后将队列删除，在 RabbitMQ 重启后，过期时间会重置

 

死信队列

当消息在一个队列中变成死信，会被重新发送到死信交换器（DLX），绑定DLX的队列称为死信队列

死信原因：1.消息被拒绝； 2.消息过期； 3. 队列达到最大长度

绑定死信队列：在 channel.queueDeclare 方法中设置 x-dead-letter-exchange 参数为此队列添加 DLX

 

延迟队列

消息当被发送以后，并不想让消费者立刻拿到消息，而是等待特定时间后，才能拿到消费

用法：

1. 每条消息设置为10秒过期时间
2. 通过 exchange.normal 交换器把发送的消息存储到 queue.normal 队列中
3. 消费者订阅 queue.dlx 队列
4. 10秒后，消息过期转存到 queue.dlx ，消费者消费到了延迟10秒的这条消息

 

优先级队列

具有高优先级的队列有高的优先权，优先级高的消息优先被消费

AMQP.BasicProperties.Builder builder = new AMQP.BasicProperties.Builder();
builder.priority(5);
AMQP.BasicProperties properties = builder.build();
channel.basicPublish("exchange_priority","rk_priority",properties,("message").getBytes());

• 默认优先级为0，最高为队列设置的最大优先级
• 如果Broker中有消息堆积，优先级高的消息可以被优先消费

 

RPC实现

String callbackQueueName = channel.queueDeclare().getQueue();
BasicProperties props = new BasicProperties.Builder().replyTo(callbackQueueName).build();
channel.basicPublish("","rpc_queue",props,message.getBytes());

RPC 处理流程：

1. 客户端启动时，创建一个匿名的回调队列
2. 客户端为 RPC 请求设置2个属性：replyTo 告知 RPC 服务端回复请求时的目的队列；correlationId 标记一个请求
3. 请求被发送到 rpc_queue 队列中
4. RPC 服务端监听 rpc_queue 队列中的请求，当请求到来时，服务端会处理并且把带有结果的消息发送给客户端。接收队列是 replyTo 设定的回调队列
5. 客户端监听回调队列，有消息时，检查 correlationId 属性，如果与请求匹配，就是返回结果

 

持久化

持久化可以提高 RabbitMQ 的可靠性，防止在异常情况（重启、关闭、宕机）下数据丢失

持久化的各种情况

• RabbitMQ 持久化分为3个部分：交换器的持久化、队列的持久化、消息的持久化
• 若交换器不设置持久化，服务重启后，交换器元数据丢失，但消息存在
• 若队列不设置持久化，服务重启后，队列元数据丢失，消息也会丢失
• 若队列设置持久化，消息不设置，服务重启后，队列元数据存在，但消息丢失
• 若所有消息设置持久化，会严重RabbitMQ性能，需要在吞吐量和可靠性之间做权衡
• 生产环境会设置镜像队列保证系统的高可用性

 

生产者确认

事务机制

事务方法：

• channel.txSelect： 用于将当前信道设置成事务模式
• channel.txCommit：用于提交事务
• channel.txRollback：用于事务回滚

事务流程：

1. 客户端发送 Tx.Select，将信道置为事务模式
2. Broker回复 Tx.Select-Ok，确认已将信道置为事务模式
3. 发完消息后，客户端发送 Tx.Commit 提交事务
4. Broker 回复 Tx.Commit，确认事务提交

事务问题：事务机制会耗尽 RabbitMQ 的性能

---

发送方确认机制

1. 生产者将信道设置成 confirm 模式
2. 信道进入 confirm 模式后，所有在信道上发布的消息都会被指派一个唯一ID
3. 消息被投递到所有匹配的队列后，RabbitMQ 发送一个确认给生产者

发送方确认机制好处：相比于事务，它是异步非阻塞的

 

消费端要点

消息分发

• 当 RabbitMQ 队列有多个消费者，消息会以轮询方式分发给消费者
• 但是这样会造成因为各机器性能不同而引起负载不均
• 消费端通过调用 channel.basicQos 方法，设置允许限制信道上的消费者保持最大未确认消息数量
• 一旦达到未确认消息数量上限，则停止向这个消费者发送消息，实现了“滑动窗口”效果

---

消息顺序性

• 生产者使用了事务机制，事务回滚后，补发信息可能在其它线程实现
• 启用 publiser confirm时，发生发生超时、中断，导致错序
• 生产者设置了延迟队列，但是超时时间设置的不一样
• 消息设置了优先级，消费端收到的消息必然不是顺序性的

---

弃用 QueueingConsumer

• 队列中有大量消息，可能导致内存溢出或假死
• 可以使用 Basic.Qos 方法得到有效解决
• QueueingConsumer会拖累一个 Connection 下的所有信道，使性能降低
• 同步调用 QueueingConsumer 会产生死锁

 

消息传输保障

消息传输保障等级

• At most once：最多一次。消息可能丢失，但绝不会重复传输
• At least once：最少一次。消息绝不会丢失，但可能重复传输
• Exactly once：恰好一次。每条消息肯定会，有且传输一次

最少一次：需要考虑 事务、mandatory、持久化处理、autoAck
最多一次：无须考虑以上问题，随便发送与接收
恰好一次：RabbitMQ 目前无法保障