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的应用场景。

总结：

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