rabbitmq笔记-rabbitmq进阶-数据可靠性，rabbitmq高级特性

消息何去何从

mandatory和immediate是channel.basicPublish方法的两个参数，都有消息传递过程中不可达目的地时将消息返回给生产者的功能。

mandatory参数

• true：交换器无法根据自身的类型 和路由键找到符合条件的队列，rabbitmq调用Basic.Return命令将消息返回给生产者
  • 生产者调用channel.addReturnListener添加ReturnListener监听器实现
• false：消息直接丢弃

immediate参数

告诉服务器至少将该消息路由到一个队列中，否则将消息返回给生产者。

Rabbitmq3.0去掉了对immediate参数支持，建议采用TTL和DLX方法替代

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

备份交换器（AE）

生产者发送消息不设置mandatory，消息未被路由会丢失，设置了，需要添加ReturnListener。如果不想编程复杂也不想消息丢失使用备份交换器。

使用：

• 声明交换器时添加alternate-exchange参数实现
  • channel.exchangeDeclare(“myAe”,“fanout”,true,false,null);
  • channel.queueDeclare(“unroutedQueue”,true,false,false,null);
  • channel.queueBind(“unroutedQueue”,“myAe”,“”);
• 通过策略（Policy）实现
  • rabbitmqctl set_policy AE “^normalExchange$” ‘{“alternate-exchange”:“myAE”}’

特殊情况：

• 如果设置了备份交换器不存在，客户端和RabbitMQ服务端都不会有异常出现，此时消息会丢失
• 如果备份交换器没有绑定任何队列，客户端和rabbitmq服务端都不会有异常出现，此时消息会丢失
• 如果备份交换器没有任何匹配的队列，客户端和rabbitmq服务端都不会有异常出现，此时消息会丢失
• 如果备份交换器和mandatory参数一起使用，那么mandatory参数无效

过期时间（Time to Live ，TTL）

设置消息TTL

• 通过队列属性设置，队列中所有消息都有相同的过期时间（一旦过期，就从队列中抹去，消息已经在队列头部，只要定期从队列头部开始扫描即可）

  • channel.queueDeclare方法中加入x-message-ttl参数实现，单位ms

    • Map<String,Object> args = new HashMap<String,Object>();
      args.put("x-message-ttl",6000);
      channel.queueDeclare(queueName,durable,exclusive,autoDelete,args);
      

  • 通过Policy方式设置ttl

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

  • 通过调用http api接口设置

• 通过对消息本身单独设置，每条消息的ttl可以不同（即使过期，也不会马上抹去，是否过期是在即将投递到消费者之前判定的）

  • 代码设置
    • 设置AMQP.BasicProperties属性
    • set属性：deliveryMode（持久化消息），expiration（ttl时间）
  • 通过 http api接口设置

• 如果两个方法一起使用，消息的ttl以两者之间较小的数值为准，消息在队列中一旦超过设置的ttl时，就会变成死信，消费者将无法再收到该消息

• 不设置ttl，表示此消息不会过期，ttl=0，表示除非此时可以直接将消息投递到消费者，否则立即丢弃。

设置队列TTL

channel.queueDeclare方法中的x-expires参数可以控制队列被自动删除前处于未使用状态的时间（未使用：队列上没有任何消费者，队列也没有被重新声明，并在过期时间段内也未调用过Basic.Get命令）

Map<String, Object> args = new HashMap<String,Object>();
args.put("x-expires", 1800000);
channel.queueDeclare("myqueue",false,false,false,args);

死信队列

当消息在一个队列中变成死信后，能被重新被发送到另一个交换器中，这个交换器就是DLX，死信交换器，绑定DLX的队列就是死信队列

消息变成死信情况

• 消息被拒绝
• 消息过期
• 队列达到最大长度

当队列中存在死信时，rabbitmq会自动将这个消息重新发布到设置的DLX上去，进而被路由到另一个队列，死信队列，可以监听这个队列的消息进行相应处理

设置方法

• 代码设置：
  • channel.queueDeclare方法中设置x-dead-letter-exchange为队列添加DLX
• 通过Policy方式设置

延迟队列

延迟队列存储的对象是对应的延迟消息（当消息被发送以后，并不想让消费者立刻拿到消息，而是等待特定时间后，消费者才能拿到这个消息进行消费）。

场景：

• 订单系统，30min内未支付，进行异常处理
• 手机遥控设备指定时间工作

通过DLX 和TTL模拟延迟队列的功能。

假设一个应用中需要将每条消息都设置为10秒延迟，生产者通过exchange.normal交换器将发送的消息存储在queue.normal队列，消费者订阅的是queue.dlx队列，当消息从queue.normal整个队列中过期之后被存入queue.dlx队列，消费者恰巧消费到了延迟10秒的这条消息。

优先级队列

实现：通过设置队列的x-max-priority参数实现

默认最低优先级为0，越高越优先消费

前提：如果在消费速度大于生成者的速度且broker中没有消息堆积的情况下，对发送的消息设置优先级就没什么意义了。

RPC实现

客户端发送请求消息，服务端回复响应的消息，为了接收响应的消息，需要在请求消息中发送一个回调队列

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

• replyTo：用来设置一个回调队列
• correlationId：用来关联请求和其调用RPC之后的回复，每一个请求设置一个唯一的correlationId

可以为每一个客户端创建一个单一的回调队列。

持久化

• 交换器持久化：通过在声明队列是将durable参数置为true实现的。如果不持久化，rabbitmq服务重启后，相关的交换器元数据会丢失，消息不丢失，只是不能将消息发送到这个交换器中了。
• 队列持久化：通过在声明队列时将durable置为true，如果不设置持久化，rabbitmq重启后，相关队列元数据会丢失，此时数据也会丢失。
• 消息持久化：通过将消息的投递模式BasicProperties中的diliveryMode属性设置为2即可实现消息的持久化
• 设置了队列和消息的持久化，rabbitmq服务重启后，消息依旧存在。

将交换器、队列、消息都设置持久化后不能保证数据百分百丢失。

生产者确认

确定消息到底有没有正确到达服务器。可以通过事务机制和发送方确认机制

事务机制

rabbitmq客户端与事务机制相关方法

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

开启事务流程

• 客户端发送Tx.select，将信道置为事务模式
• Broker回复Tx.Select-Ok,确认已将信道置为事务模式
• 在发送完消息后，客户端发送Tx.Commit提交事务
• Broker回复Tx.Commit-Ok，确认提交事务
• 如果发生异常，在捕获异常后，channel.txRollback()回滚

缺点：会有性能损失

发送方确认机制

• 生产者将信道设置成confirm模式（channel.confirmSelect），rabbitmq同意：Confirm.Select-Ok；
• 一旦信道进入confirm模式，所有在该信道上发布的消息都会被指派一个唯一id
• 一旦消息被投递到匹配的队列后，rabbitmq会发送一个确认给生产者（包含消息唯一id），使得生产者知晓消息已经正确到达了目的地。

事务机制在一条消息发送后会使发送端阻塞，等待rabbitmq回应后才发下一条消息，而发送发确认机制最大好处是异步的。生产者通过回调方法处理该确认消息。如果rabbitmq因自身内部错误导致消息丢失，会发送一条nack命令，生产者应用程序同样可以在回调方法中处理nack命令。

publisher confirm优势

• 批量confirm方法，每发送一批消息后，调用channel.waitForConfirms方法，等待服务器的确认返回
• 异步confirm方法：提供一个回调方法，服务端确认了一条或多条消息后客户端会回调这个方法进行处理。

消费端要点介绍

消息分发

rabbitmq队列拥有多个消费者时，队列收到的消息将以轮询的分发方式发送给消费者，每条消息只会发送给订阅列表里的一个消费者。

• 问题：如果某些空闲，某些忙碌造成整体下降
• 方法：channel.basicQos方法允许限制信道上的消费者所能保持的最大未确认消息的数量。如果达到上限，就不会向这个消费者再发送任何消息，知道消费者确认了某条消息后，相应计数减1，之后消费者可以继续接受消息。

消息顺序性

指消费者消费到的消息和发送者发布的消息的顺序是一致的。

打破顺序性的情形

• 如果生产者使用了事务机制，发送消息遇到异常进行了事务回滚，需重新补偿发送，如果是另一个线程实现，则出现乱序。
• 如果生产者发送的消息设置了不同的超时时间，并设置了死信队列，顺序不一致。
• 设置了优先级，也不是顺序的。

要保证消息的顺序性，需要业务方使用rabbitmq之后进一步处理，例如在消息体内添加全局有序标识实现。

弃用QueueingConsumer

缺陷

• 内存溢出问题：队列堆积较多的消息，导致消费者客户端内存溢出假死，不断堆积
  • 使用Basic.Qos限制某个消费者所保持未确认消息的数量。
• 会拖累同一个connection下的所有信道，性能降低
• 同步递归调用QueueingConsumer会产生死锁
• rabbitmq的自动连接恢复机制不支持Queueing Consumer这种形式
• QueueingConsumer不是事件驱动的

消息传输保障

一般消息中间件消息传输保障分为三个层级

• 最多一次
• 最少一次
• 恰好一次

rabbitmq支持其中的最多一次和最少一次，其中最少一次投递实现需要考虑

• 消息生产者需要开启事务机制或publisher confirm机制，以确保消息可以可靠地传输到rabbitmq中
• 消息生产者需要配合使用mandatory参数或者备份交换器来确保消息能够从交换器路由到队列中，进而能够保存下来而不会被丢弃
• 消息和队列都需要进行持久化处理，以确保rabbitmq服务器在遇到异常情况时不会造成消息丢失
• 消费者在消费消息的同时需要将autoAck设置为false，然后通过手动确认的方式去确认已经正确消费的消息，以避免在消费端引起不必要的消息丢失。

参考：《RabbitMQ实战指南》