七、Topic 模式

前言 前面章节,用 direct 交换机实现了单播、多播的功能,但是看的出来是通过手动绑定,不是那么灵活。这一章,topic 交换机将会告诉我们,什么叫灵活,而且通过简单、合理的设计, topic 交换机可以完全替代 direct 、fanout 交换机。 模型 使用 topic 交换机的时候,RoutingKey 不能随便取,必须是由 ‘*’ 或者 ‘#’ 分隔的关键词列表。topic 交换机根据关键词对消息进行分发。一些合理的 RoutingKey 如:“stock.usd.nyse”,“n […]

六、Routing 模式

前言 前面 Publish/Subscribe 模式,fanout 交换机无脑的把数据分发到每一个连接的队列里,这一章节,对消息进行定向分发。 模型 可以看到,使用的是 direct 交换机,把消息用 routingKey 分类,送到不同的队列里,然后不同的消费者分别去处理相应类别的消息。 一、生产者(Producer) 直接上代码,将不同级别的日志,送往不同 routingKey 下的所有队列里: using RabbitMQ.Client; using System; using Syste […]

五、Publish/Subscribe 模式

前言 在上一章的 Work queue 模式 中,将消息分配给多个消费者进行处理,处理速度快的获取的消息次数就多。 在这一章,Publish/Subscribe 模式又是另外一个场景:广播场景。就像广播电台,谁有收音机,就可以收到电台。张三用收音机听新闻联播不影响李四也用收音机听新闻联播。 模型 通过模型图,可以看到,生产者(Producer)好像是把相同的消息,塞到了两个不同的队列里,难道有多少消费者就需要多少队列吗?生产者怎么知道有多少个队列? 从这个模式开始,就要明确 “交换机(excha […]

四、Work queues 模式

模型 这种模式跟 Simplest queue 的区别就是可以多个消费者同时消费,加快消息处理的速度。这一章只需要在前一章的基础上稍微修改即可。 一、生产者(Producer) 生产者跟 Simplest queue 的一样,这里修改一下消息的发布,循环 100 次发布100个消息到队列里: //5,向队列发布消息 for (int i = 0; i < 100; i++) { string msg = $”Task {i}”; var body = Encoding.UTF8.GetBy […]

Powered by WordPress | Theme Revised from Doo

苏ICP备18047621号

Copyright © 2017-2024 追光者博客