系列目录
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的应用场景。
总结:
还是一句话:它是队列,不是数据库,无法根据条件过滤过查询。
文章来源: 博客园
- 还没有人评论,欢迎说说您的想法!