RabbitMQ入门系列：8、扩展内容：接收信息时：可否根据RoutingKey过滤监听信息，答案是不能。

系列目录

RabbitMQ 入门系列：1、MQ的应用场景的选择与RabbitMQ安装。

RabbitMQ 入门系列：2、基础含义：链接、通道、队列、交换机。

RabbitMQ 入门系列：3、基础含义：持久化、排它性、自动删除、强制性、路由键。

RabbitMQ 入门系列：4、基础编码：官方SDK使用：链接创建、单例改造、发送消息、接收消息。

RabbitMQ 入门系列：5、基础编码：交换机的进阶介绍及编码方式。

RabbitMQ 入门系列：6、保障消息：不丢失：发送方、Rabbit存储端、接收方。

RabbitMQ 入门系列：7、保障消息：不重复消费：产生消息的唯一ID。

RabbitMQ 入门系列：8、扩展内容：接收信息时：可否根据RoutingKey过滤监听信息，答案是不能。

RabbitMQ 入门系列：9、扩展内容：死信队列：真不适合当延时队列。

RabbitMQ 入门系列：10、扩展内容：延时队列：延时队列插件及其有限的适用场景。

前言：

初看交换机的概念时，以为会有根据绑定的RoutingKey进行过滤监听的功能。

而网上，也有一些误导人代码，连我也被误了不少时间。

答案已经在标题上有了，下面看一些错误的演示。

1、网上离谱的标准错误答案：DotNet版本

1、发送方：

ConnectionFactory factory = new ConnectionFactory(){    HostName = "127.0.0.1",    UserName = "guest",    Password = "guest",    VirtualHost = "/"};string myexchange = "myexchange";string myqueue = "myqueue";using (var connection = factory.CreateConnection()){    var channel = connection.CreateModel();    channel.ExchangeDeclare(myexchange, ExchangeType.Direct, true, false, null);    channel.QueueDeclare(myqueue, true, false, false, null);    channel.QueueBind(myqueue, myexchange, "log_info", null);    channel.QueueBind(myqueue, myexchange, "log_error", null);    for (int i = 0; i < 10; i++)    {        var msg = Encoding.UTF8.GetBytes($"{i},你好");        var routeKey = i % 2 == 0 ? "log_info" : "log_error";        channel.BasicPublish(myexchange, routingKey: routeKey, basicProperties: null, body: msg);    }}

向队列myqueue发送了10条数据：

 

可以看到，队列消息里是带有Routing Key。

然后以为可以只监听获取对应的Routing Key的数据，这种错误认知就被带出了，还演示了无效的代码：

2、接收方：

ConnectionFactory factory = new ConnectionFactory(){    HostName = "127.0.0.1",    UserName = "guest",    Password = "guest",    VirtualHost = "/"};string myexchange = "myexchange";string myqueue = "myqueue";using (var connection = factory.CreateConnection()){    var channel = connection.CreateModel();    channel.QueueBind(myqueue, myexchange, "log_info", null);    EventingBasicConsumer consumer = new EventingBasicConsumer(channel);    consumer.Received += (sender, e) =>    {        var msg = Encoding.UTF8.GetString(e.Body);        Console.WriteLine(msg + " Routing Key :" + e.RoutingKey);    };    channel.BasicConsume(myqueue, false, consumer);    Console.ReadKey();}

天真以为绑定对应路由器就有效，运行结果仍是：

真实的答案就只有一个：它是队列，不是数据库，无法根据条件过滤过查询。 

2、网上容易误导的进阶式标准错误答案2：来源参考的是Java版本

 发送方保持不变，修改接收方的代码：

ConnectionFactory factory = new ConnectionFactory(){    HostName = "127.0.0.1",    UserName = "guest",    Password = "guest",    VirtualHost = "/"};string myexchange = "myexchange";using (var connection = factory.CreateConnection()){    var channel = connection.CreateModel();    string name = channel.QueueDeclare().QueueName;    channel.QueueBind(name, myexchange, "log_info", null);    EventingBasicConsumer consumer = new EventingBasicConsumer(channel);    consumer.Received += (sender, e) =>    {        var msg = Encoding.UTF8.GetString(e.Body);        Console.WriteLine(msg + " Routing Key :" + e.RoutingKey);    };    channel.BasicConsume(name, false, consumer);    Console.ReadKey();}

重新定义临时队列，然后绑定了临时队列的名称，开启监听，然后让发送方再次发送数据：

右边发送了10条，左边根据过滤条件，收到了5条，看起来好像达到效果了。

表现上很正确，这就很TMD的误导人了。

下面看看这种是什么情况：

 

实际的情况是：

1、接收方：创建了临时队列，同时绑定log_info，监听的是临时队列。2、发送方：即发送到myqueue，对log_info的数据，再copy一份发送到临时队列。

这就很离谱了，会造成以下几个问题：

1、只能收到监听开启之后发送的数据，对myqueue之前的数据是获取不到的。也即是说，仅有双方同时在线，发送时的数据才能收到，其余条件的数据都会丢失。2、myqueue还是存有一份信息，不消费，攒着留着过年吗？

第2个条件还能通过设置过期解决，第1个条件，都不知道什么应用场景才适合，但肯定不属于MQ的应用场景。

总结：

还是一句话：它是队列，不是数据库，无法根据条件过滤过查询。