幂等性、Confirm消息确认机制、限流、死信队列

幂等性概念

• 我们可以借鉴数据库的乐观锁机制
• 比如我们执行一条更新库存的SQL语句
• UPDATE T_REPS SET COUNT = COUNT - 1 , VERSION = VERSION + 1 WHERE VERSION = 1;
• 用乐观锁的形式保证了库存在高并发的情况下也不会被错误的更新，这就保证了幂等性。

消费端实现幂等性，就意味着，我们的消息永远不会消费多次，即使我们收到了多条一样的消息。

幂等性保障

• 唯一ID + 指纹码机制
  • 好处：实现简单
  • 坏处：高并发下有数据库写入的性能瓶颈，可以跟进ID进行分库分表进行算法路由，达到分压分流的效果从而提高性能
• 利用Redis的原子性去实现
  • 使用Redis进行幂等，需要考虑的问题
  • 第一：是否要进行数据库落库，如果落库的话，关键解决的问题是数据库和缓存如何做到原子性？
  • 第二：如果不进行落库，那么都存储到缓存中，如何设置定时同步的策略持久化数据？

Confirm 消息确认机制

• 消息的确认，是指生产者投递消息后，如果Broker收到消息，则会给我们生产者一个应答。
• 生产者进行接收应答，用来确定这条消息是否正常的发送到Broker，这种方式也是消息的可靠性投递的核心保障。

如何实现Confirm确认消息？

• 在channel上开启确认模式：channel.confirmSelect()。
• 在channel上添加监听：addConfirmListener，监听成功和失败的返回结果，根据具体的结果对消息进行重新发送、或记录日志等后续处理。

Return 消息机制

• Return Listener 用于处理一些不可路由的消息。
• 消息生产者通过制定一个Exchange和Routingkey，把消息送达到某一个队列中去，然后我们的消费者监听队列，进行消费处理操作。在某些情况下，如果我们在发送消息的时候，当前的Exchange不存在或者指定的路由key路由不到，这个时候如果我们需要监听这种不可达的消息，就要使用Return Listener。
• 在基础API中有一个关键的配置项：
• Mandatory：如果为true，则监听器会接收到路由不可达的消息，然后进行后续处理，如果为false，那么broker端自动删除该消息。

消费端自定义监听

• 我们一般就是在代码中编写while死循环，不停地进行consumer.nextDelivery获取下一条消息，然后进行消费处理。
• 但是我们使用自定义的Consumer更加的方便，解耦性更加的强，也是在实际工作中最常用的使用方式。

消费端限流

• 假设一个场景，首先，我们Rabbitmq服务器有上万条未处理的消息，我们随便打开一个消费者客户端，会出现下面情况：
• 巨量的消息瞬间全部推送过来，但是我们单个客户端无法同时处理这么多数据。
• RabbitMQ提供了一种qos（服务质量保证）功能，即在非自动确认消息的前提下，如果一定数目的消息（通过基于consume或者channel设置qos的值）未被确认前，不进行消费新的消息。
• void BasicQos(unit prefetchSize, ushort prefetchCount, bool global)；
  • prefetchSize：消费单条消息的大小限制，0表示不限制
  • prefetchCount：会告诉RabbitMQ不要同时给一个消费者推送多余N个消息，即一旦有N个消息还没有ack，则该consumer将block掉，直到有消息ack
  • global：true/false，是否将上面设置应用于channel级别的还是consumer级别。
• prefetchSize和global这两项，rabbitmq没有实现，暂且不研究，prefetch_count在no_ask=false的情况下生效，即在自动应答的情况下这两个值是不生效的。

TTL队列

• TTL是Time To Live的缩写，也就是生存时间
• RabbitMQ支持消息的过期时间，在消息发送时可以进行指定
• RabbitMQ支持队列的过期时间，从消息入队列开始计算，只要超过了队列的超时时间配置，那么消息会自动的清除。

死信队列

• DLX：Dead-Letter-Exchange
• 利用DLX，当消息在一个队列中变成死信之后（消息没有被任何消费者消费），他能被重新publish到另一个Exchange，这个Exchange就是DLX。
• 消息变成死信有以下几种情况
  • 消息被拒绝（basic.reject / basic.nack）并且requeue=false
  • 消息TTL过期
  • 队列达到最大长度
• DLX也是一个正常的Exchange，和一般的Exchange没有区别，他能在任何的队列上被指定，实际上就是设置某个队列的属性。
• 当这个队列中有死信时，RabbitMQ就会自动的将这个消息重新发布到设置的Exchange上去，进而被路由到另一个队列。
• 可以监听这个队列中消息做相应的处理，这个特性可以弥补RabbitMQ3.0以前支持的immediate参数的功能。