RabbitMQ高级特性

本文介绍一些RabbitMQ的高级特性。

一.confirm消息确认

消息确认，是指生产者投递消息后，如果broker收到消息，则会给生产者一个应答。生产者通过接收应答，来确定是否发送成功，这种机制也是消息可靠性投递的底层机制。这个过程是异步的，生产者将消息发送出去后就不用管了，内部会有一个confirm listener负责监听确认消息。

实现confirm消息确认步骤：
第一步在channel上开启确认模式：channel.confirmSelect()
第二步，在channel上添加监听：addConfirmListener
在springboot中，将spring.rabbitmq.publisher-confirms设为true，即相当于在channel上开启确认模式channel.confirmSelect()，然后定义一个回调函数，并设置到rabbitTemplate中，就可以处理确认消息。

//回调函数: confirm确认
	final ConfirmCallback confirmCallback = new RabbitTemplate.ConfirmCallback() {
		@Override
		public void confirm(CorrelationData correlationData, boolean ack, String cause) {
			System.err.println("correlationData: " + correlationData);
			System.err.println("ack: " + ack);
			if(!ack){
				System.err.println("异常处理....");
			}
		}
	};

rabbitTemplate.setConfirmCallback(confirmCallback);

确认消息有两种：ack和nack，比如到队列已满或磁盘故障时就有可能收到nack，表示不确认。当然如果网络故障等原因也可能两种都收不到，这种就需要可靠消息架构处理了。
还有要注意的是，发送端的ack和消费端的ack是两个不同的ack，因为在rabbitmq中发送端是发给exchange，消费端是从queue中接收。

二.Return消息机制

Return Listener用于处理一些不可路由的消息。比如在某些情况下，exchange不存在或者路由key路由不到，这时可以用Return Listener监听这些不可达的消息。

有一个关键属性mandatory，如果设为true，则监听器会接收到路由不可达的消息，然后进行后续处理，如果为false，那么broker端自动删除该消息。该属性默认为false，但生产环境一定要设为true。

三.消费端限流

RabbitMQ提供了一种qos（服务质量保证）功能，即在非自动确认消息的前提下，如果一定数目的消息（通过consume或者channel设置qos的值）未被确认前，不进行新的消息消费。使用basicQos实现。
void basicQos(int prefetchSize, int prefetchCount, boolean global);
prefetchCount就是告诉rabbitmq不要同时给一个消费者推送多于prefetchCount设置的数量的消息，一旦某consumer有超过prefetchCount数量的消息还没有ack，则该consumer将block掉，直到消费到未ack的值低于设置。在实际工作中可设置为1，即一条一条进行处理。
注意prefetchCount在自动确认下不生效，需要设置为人工ack。
在springboot中，可通过配置spring.rabbitmq.listener.simple.prefatch实现。

四.消息重回队列

消费端重回队列是为了对没有处理成功的消息，把消息重新回递给broker。
重回队列会把消费失败的消息重新添加到队列的尾部。重回队列可以通过channel.basicNack方法的requeue参数控制，设为true表示重回队列。
一般在实际应用中，都会设为false，关闭重回队列。因为如果如果打开此功能有可能造成无限循环的消息，而且监听方法抛出异常时本来就会重新推送。异常时消息会按照listener.retry的配置进行重发，超过重发次数后不再重发，但应用重启后会重新推送，直到超过TTL设定。注意listener.retry配置的是消费端应用内处理的，不是rabbitmq重发。

五.TTL

TTL就是time to live 的缩写，也就是生存时间。RabbitMQ支持消息的过期时间，发送时可以指定。也支持队列的过期时间，从消息进入队列开始计算，超过超时配置，自动清除消息。
消息的过期时间，可以通过程序给消息的properties设置expiration属性实现。
队列的过期时间，可以通过程序或管控台设置Arguments中的x-message-ttl实现。

RabbitMQ可以针对Queue或者针对Message设置过期时间，来控制消息的生存时间，如果超时(两者同时设置以最先到期的时间为准)，则消息变为dead letter(死信)
A: 通过队列属性设置，队列中所有消息都有相同的过期时间。
B: 对消息进行单独设置，每条消息TTL可以不同。

六.死信队列

死信队列，Dead-Letter-Exchange，简称DLX。当一条消息在一个队列中变成死信之后，它能被重新publish到另一个Exchange，这个Exchange就是DLX。
以下情况消息变成死信：
1.消息被拒绝（reject/nack），并且requeue=false
2.消息TTL过期
3.队列达到最大长度（超过设置的Arguments中的x-max-length或x-max-bytes）

DLX也是一个正常的Exchange，和普通Exchange没有区别，它能在任何的队列上被指定，实际上就是设置某个队列的属性。当这个队列中有死信时，就会将这个消息重新发布到上设置的这个DLX上，进而路由到另一个队列。
 设置DLX的步骤：
1.首先需要设置死信队列的Exchange和queue，然后进行绑定，比如：Exchange：dlx.exchange;  Queue: dlx.queue; RoutingKey: #
2.建立正常队列时，加上一个参数：arguments.put("x-dead-letter-exchange","dlx.exchange"); 指向死信队列。

七.其它

每个消费者对应的listener有个Exclusive参数，默认为false, 如果设置为true，concurrency就必须设置为1，即只能单个消费者消费队列里的消息，适用于必须严格执行消息队列的消费顺序（先进先出）。