RabbitMQ高级特性（2）

一、消费端限流

1.什么是消费端的限流

假设一个场景，首先，Rabbitmq服务器有上万条未处理的消息，我们随便打开一个消费者客户端，就会出现：巨大的消息瞬间全部推送过来，但是我们单个客户端无法同时处理这么多数据！

2.RabbitMQ提供了一种Qos（服务质量控制）功能，即在非自动确认消息的前提下，如果一定数目的消息（通过基于consume或者channel设置Qos的值）未被确认前，不进行消费新的消息。

void BasicQos（uint prefetchSize,ushort prefetchCount,bool global）;

prefetchCount:会告诉RabbitMQ不要同时给一个消费者推送多于N个消息，即一旦有N个消息还没有ACK，则该comsumer将block掉，直到有消息ack

global:true/false 是否将上面的设置应用于channel，就是限制是channel级别还是consumer级别

二、消费端的手动ACK和NACK

消费端进行消费的时候，如果由于业务异常我们可以进行日志的记录，然后进行补偿！

如果由于服务器宕机等严重问题，那我们就需要手动进行ACK保障消费端消费成功！

三、消费端的重回队列

1.消费端重回队列是为了对没有处理成功的消息，把消息重新会递给Broker

2.一般我们在实际应用中，都会关闭重回队列，也就是设置为false

四、TTL队列/消息

1.TTL

TTL：time  to live 的缩写，也就是生存时间

RabbitMQ支持消息的过期时间，在消息发送时可以进行指定

RabbitMQ支持队列的过去时间，从消息入队列开始计算，只要超过了队列的超时时间配置，那么消息会自动删除

2.DLX

DLX：Dead-Letter-Exchange，死信队列

利用DLX，当消息在一个队列中变成死信（dead message）之后，它能被重新publish到另一个Exchange，这个Exchange就是DLX

DLX也是一个正常的Exchange，和一般的Exchange没有区别，它能在任何的队列上被指定，实际上就是设置某个队列的属性

当一个队列中有死信时，RabbitMQ就会自动的将这个消息重新发布到设置的Exchange上去，进而被路由到另一个队列

可以监听DLX这个队列中的消息做相应的处理，这个特性可以弥补RabbitMQ3.0以前支持的immediate参数的功能

3.消息变成死信的情况

消息被拒绝（basic.reject/basic.nack），并且requeue=false

消息TTL过期

队列达到最大长度

4.DLX死信队列设置

首先需要设置死信队列的exchange（dlx.exchange）、queue(dlx.queue)和路由规则（RoutingKey:#），然后进行绑定

然后进行正常交换机、队列、绑定，只不过我们需要在队列上加上一个参数即可：arguments.put("x-dead-letter-exchange","dlx.exchange");