一、消费端限流
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");
网友评论