RabbitMQ 参数们的Power “续”

renshanshan

参数中的 arguments
　　之前讲参数的一些作用的时候，忽略了最后一个字典类型的参数，因为这个参数是大有文章的，值得单独进出来说道说道。
　　这时，就不得不打开我们的 Web UI管理系统了，可以看到在这边添加queue的时候，有Arguments下面有一些说明，Message TTL，Auto expire…….

Message TTL
　　可以看到，点击一下Message TTL，它的参数名是 x-message-ttl 类型是number，那么这个应该怎么用呢？

　　一起来看看官方解释，嗯。。。其实也就是在说，在声明队列的时候可以添加这个参数，那么它的作用是让发布的message在队列中可以存活多长时间，以毫秒为单位。更通俗点就是，设置了这个参数，发布的消息在queue时间超过了你设定的时间就会被删除掉。

　　送上代码，不多说，先跑起来，这时就可以看到，在features也可以看到queue是ttl的

//声明一个queue，里面的内容自发布起五秒后被删除
channel.QueueDeclare("messagettlqueue", true, false, false, new Dictionary<string, object> { { "x-message-ttl", 5000 } });

　　这个是针对queue的，当然更加定制化的针对message也是有的，也就是说可以让queue里的某条message在多久消失


var properties = channel.CreateBasicProperties();
//设置过期时间
properties.Expiration = "5000";
channel.BasicPublish(null, "queue", properties, Encoding.UTF8.GetBytes("我五秒后就会消失"));
Auto expire

　　之前是针对 queue中的消息或者消息本身，而这个才是针对queue，这里是官方解释，也就是说，当前的queue在指定的时间内，没有consumer、basic.get也就是未被访问，就会被删除。

　　设置起来也是非常简单的


//声明一个queue，queue五秒内而且未被任何形式的消费,则被删除
channel.QueueDeclare("queue", true, false, false, new Dictionary<string, object> { { "x-expires", 5000 } });
MaxLength与MaxLength bytes
　　相信到这里大家已经可以根据名字去猜测它的作用了，没错它们是设置queue的消息最大条数与消息最大占用大小

　　并不是说，设置了最大长度为10,第11条数据插入的时候就会报错,而是在超过了最大长度后进行插入会删除之前插入的消息为本次的留出空间,也就是说无论什么时候,queue中的消息始终都是十条，相应的最大占用大小也是这个道理，当超过了这个大小的时候，会删除之前插入的消息为本次的留出空间。


//声明一个queue，最大长度10，最大大小2048bytes
channel.QueueDeclare("queue", true, false, false, new Dictionary<string, object>
{
{ "x-max-length", 10 },
{ "x-max-length-bytes", 2048}
});
Dead letter exchagne 与 Dead letter routing key
　　Dead letter 死信，可能有些人对这个词比较陌生，那么我们首先来了解什么叫死信，也就是说那些没有被投递出去的信件

　　就像上面的messagettl，maxlength等。消息因为超时或超过限制在队列里消失，这样我们就丢失了一些消息，也许里面就有一些是我们做需要获知的。而rabbitmq的死信功能则为我们带来了解决方案。设置了dead letter exchange与dead letter routingkey（要么都设定，要么都不设定）那些因为超时或超出限制而被删除的消息会被推动到我们设置的exchange中，再根据routingkey推到queue中

　　这里是consumer端，声明了一个testqueue，它里面的消息会在5秒后被删除，然后又设置了死信的exchange与routingkey。


using (var channel = RabbitMqHelper.GetConnection().CreateModel())
{
//声明一个带有死信功能功能的queue exchange: dlexchange  queue: dlexqueue
channel.QueueDeclare("testqueue", true, false, false, new Dictionary<string, object>
{
{ "x-message-ttl",5000},
{ "x-dead-letter-exchange", "dlexchange" },
{ "x-dead-letter-routing-key", "dlexqueue"}
});
//负责死信的交换机
channel.ExchangeDeclare("dlexchange", ExchangeType.Direct, true, false, null);
channel.QueueDeclare("dlexqueue", true, false, false, null);
channel.QueueBind("dlexqueue", "dlexchange", "dlexqueue", null);
var consumer = new EventingBasicConsumer(channel);
consumer.Received += (sender, e) =>
{
Console.WriteLine(Encoding.UTF8.GetString(e.Body));
};
channel.BasicConsume("testqueue", true, consumer);
Console.WriteLine("consumer启动成功");
Console.ReadKey();
}　　下面则是server端，很简单，只是发一条消息


//创建返回一个新的频道
using (var channel = RabbitMqHelper.GetConnection().CreateModel())
{
channel.BasicPublish(string.Empty, "testqueue", null, Encoding.UTF8.GetBytes("我五秒后就会消失"));
Console.ReadKey();
}这时候运行程序可以看到这里已经有了两个queue，一个是正常的queue一个是负责死信的queue，接下来我们再运行发布端程序，直接让消息消失掉

　　这时候dlexqueue里已经拿到了testqueue里消失的queue，如果这条消息被消费者消费过了的话就不会来到这里了


Maximum priority
　　不知不觉到了最后一个，这里先说一个场景，当我们打开社交软件的时候，假如这里同时有十个未读消息，但是其中有一条消息是你的女票发来的，肯定优先会看女票发来的消息，剩下的才根据其重要程度决定查看的顺序。
　　而Maximnum priority也是为我们的queue内的消息进行分级，根据级别来决定其重要程度。

　　闲话不多说，直接走代码，这里是发布者端代码，设置了五个级别，5最高， 0最低


//创建返回一个新的频道
using (var channel = RabbitMqHelper.GetConnection().CreateModel())
{
channel.QueueDeclare("priorityQueue", true, false, false, new Dictionary<string, object> { { "x-max-priority", 5 } });
var properties = channel.CreateBasicProperties();
for (var i = 0; i < 6; i++)
{
properties.Priority = (byte)i;
channel.BasicPublish(string.Empty, "priorityQueue", properties, Encoding.UTF8.GetBytes($"{i}级别的消息"));
}
Console.ReadKey();
}　　这里不用consumer拿到消息了，直接在WEB UI工具中拿数据，然后看看顺序，可以直观的发现最后发布的一条消息是第一个拿出来的，这就是因为我们设置了级别，而它的优先级是最高的