二、RabbitMQ 进阶特性及使用场景 [.NET]

前言

经过上一篇的介绍，相信大家对RabbitMQ 的各种概念有了一定的了解，及如何使用RabbitMQ.Client 去发送和消费消息。

特性及使用场景

1. TTL 过期时间

TTL可以用来指定queue 和message多久会被去掉；在短期message数量很大，或者订单需要特定失效（例如15min支付）等场景，设置消息的过期时间可以减轻rabbitmq的压力，后者可以帮助方便的实现业务。

那么如何设置消息过期时间呢？

• 为queue中的消息整体设置

 var ttlSetting = new Dictionary<string, Object>();
  ttlSetting.Add("x-message-ttl", 10000);
queueName =  _channel.QueueDeclare(arguments: ttlSetting).QueueName;

• 为每条message设置过期时间

  var properties = _channel.CreateBasicProperties();
  properties.Expiration = "10000";
   var messageBytes = ObjectToByteArray(message);
  _channel.BasicPublish(TicketExchangeName, optType, false, properties, messageBytes);

   

队列TTL 设置

我们不但可以对message 设置过期时间，还可以对消息队列设置生存时间，当超过设定时间未被使用，该消息队列可以被自动删除。

设置方法同样是在声明队列的时候传入参数即可：

var ttlSetting = new Dictionary<string, Object>();         
ttlSetting.Add("x-expires", 6000);
 queueName =  _channel.QueueDeclare(arguments: ttlSetting).QueueName;

 2.  死信交换器和死信队列

何为死信？

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

当死信发生时，死信会通过死信交换机进入到声明的死信队列，可以通过参数声明：

_channel.ExchangeDeclare(DLExchangeName, ExchangeType.Direct);            
var arguments = new Dictionary<string, Object>();
arguments.Add("x-dead-letter-exchange", DLExchangeName);
_channel.QueueDeclare("dlqueue", arguments: arguments);

死信消息的路由，如果在消息初始被投送到的队列上设置了  x-dead-letter-routing-key 参数，则死信消息路由时以这个为准，否则按照它被产生时的路由key为准。例如，如果您将消息发布到具有路由密钥 foo 的交换，并且该消息是死信的，它将被发布到其具有路由密钥 foo 的死信交换。如果消息最初登陆的队列已声明为 x-dead-letter-routing-key 设置为 bar，则消息将发布到其带有路由键 bar 的死信交换。

查看死信队列中的消息可以帮助我们了解分析程序的运行健康情况，明确异常发生的原因。

 

3. 交换机，队列，消息的持久化

 交换机的持久化是我们在使用rabbitmq经常需要做的事情，声明交换器时将 durable 参数设置为 true 来实现的。如果不设置持久化属性的话，当 RabbitMQ 服务重启后交换器的数据就会丢失，需要注意的是，是交换器的数据丢失，消息不会丢失，只是不能将消息发送到这个交换器中了，一般生产环境使用都会把该属性设置为持久化。

队列的持久化：先介绍队列的持久化，是因为消息的持久化是依赖在队列持久化之上的。通过在声明时将durable 参数设置为 true 达到目的。

_channel.QueueDeclare(“myqueue”, true, false, arguments: ttlSetting)

消息的持久化：通过在publish 消息时，设置基本属性 DeliveryMode 来实现消息的持久性。

var properties = _channel.CreateBasicProperties();
properties.DeliveryMode = 2;

 

4.  消息的确认机制

相比于http请求和RPC，message queue的应用确实带来了不少便利，但引入新的application不可避免的增加了可靠性的考虑；如何确保消息从生产者准确的投递到了rabbitmq broker,又如何确保消费者真的消费了消息，又或者消费者没有重复消费消息？

这些都是我们在使用消息队列时候要考虑的问题，如何你使用何种技术（RabbitMQ或者是Kafka）。

 其中，在保证消息的准确投递和消费上，RabbitMQ提供了确认机制帮助我们确保消息的可靠性。

生产端的消息确认机制：

消息确认的处理办法分为：单个消息同步确认（吞吐量低），批量消息同步确认，消息异步确认。这里只介绍异步confirm的情况。

var channel = connection.CreateModel();
channel.ConfirmSelect();
channel.BasicAcks += (sender, ea) =>
{
  // code when message is confirmed
};
channel.BasicNacks += (sender, ea) =>
{
  //code when message is nack-ed
};

var outstandingConfirms = new ConcurrentDictionary<ulong, string>();

如果希望在投递失败后，重新投递，可以用 ConcurrentDictionary 存储deliverTag 和 消息体，在投递失败后，重新投递。

 

消费端的消息确认机制：

1. 自动应答

消费者在消费消息的时候，如果设定应答模式为自动，则消费者收到消息后，消息就会立即被 RabbitMQ 从 队列中删除掉。
因此，在实际开发者，我们基本上是将消费应答模式设置为手动确认更为妥当一些。

_channel.BasicConsume(queue: queueName, autoAck: true, consumer: consumer);

2. 手动应答

消费者在收到消息后：

• 可以在既定的正常情况下进行确认（告诉 RabbitMQ，我已经消费过该消息了，你可以删除该条数据了）；
• 可以在既定的异常情况下不进行确认（RabbitMQ 会继续保留该条数据），这样下一次可以继续消费该条数据。

_channel.BasicAck(ea.DeliveryTag, false);

 本文介绍了过期时间，死信队列，应答机制和持久化的设置和使用场景，后续还会继续介绍RabbitMQ的其它特性和集群搭建，欢迎大家关注和提出意见。

---------------------------------------------------