RabbitMQ工作模式 - 主题模式(Topic 模式) --- 2022-04-03

RabbitMQ工作模式 - 主题模式(Topic 模式) --- 2022-04-03,第1张

RabbitMQ主题模式(Topic)跟路由模式类似,区别在于主题模式的路由匹配支持通配符模糊匹配,而路由模式仅支持完全匹配。

说明:

1、P 代表生产者 , X 代表交换机,红色Q1、Q2代表队列,C1、C2 代表消费者。

2、交换机类型为topic

3、topic交换机转发消息逻辑:将消息中的Routing key与该Exchange关联的所有Binding中的Routing key进行 模糊匹配 ,如果匹配,则发送到绑定的Queue中。

topic支持的通配符如下:

如上图:

队列Q1绑定的routing key = *.orange.*

队列Q2绑定的routing key = *.*.rabbit 和 lazy.#

如果消息的routing key = “quick.orange.rabbit”, 则匹配Q1和Q2两个队列。

跟路由模式一样,区别就是订阅条件更灵活,即Routing key的匹配规则更灵活。

rocketMq概念介绍

rocketMq-namesrv介绍

rocketMq-Topic创建过程

rocketMq-producer介绍

rocketMq-consumer介绍

rocketMq - rebalance介绍

rocketMq - 并发消费过程

rocketMq - 串行消费过程

rocketMq-broker介绍

rocketMq-broker消息存储介绍

rocketMq - commitLog

rocketMq - index介绍

rocketMq-延迟消息介绍

rocketMq-事务消息介绍

rocketMq消息查询

rocketMq和kafka的架构区别

rocketMq - master/slave同步

Topic可以理解为在rocketMq体系当中作为一个逻辑消息组织形式,一般情况下一类业务消息会申请一个topic来实现业务之间隔离。

说明:

    该图分享自:  RocketMQ概念模型

    Topic是一个逻辑上的概念,实际上在每个broker上以queue的形式保存,也就是说每个topic在broker上会划分成几个逻辑队列,每个逻辑队列保存一部分消息数据,但是保存的消息数据实际上不是真正的消息数据,而是指向commit log的消息索引。

    Topic创建的时候可以用集群模式去创建(这样集群里面每个broker的queue的数量相同),也可以用单个broker模式去创建(这样每个broker的queue数量可以不一致)。

    每个broker上的角色是等同的,也就是说每个broker上面的queue保存了该topic下一部分消息,注意是一部分而不是全量消息。

说明:

    在rocketMq编译后的bin目录下有一个mqadmin的工具,该工具作为rocketMq的CLI工具对外提供,使用时候可以通过sh mqadmin -h 或者sh mqadmin command -h查看用法。

    updateTopic和deleteTopic是实际中 *** 作topic的命令。

说明:

    创建topic需要指定的参数,

    -b 指定broker上创建topic

    -c 指定cluster创建topic

    -n 指定namesrv地址,cluster模式下必须从namesrv获取broker地址

    -t topic的名字标志

    -r/w 读写队列的个数,建议相等

    -p queue的读写权限

    -o 待研究不确定是不是保证全局有序消息的配置

说明:

    topic的创建过程涉及到3个组件,分别是mqadmin、broker、namesrv。

    整个创建过程是mqadmin->broker->namesrv。

    mqadmin通知broker创建topic和对应的queue信息。

    broker转发通知namesrv保存topic和broker的原信息,同时在本地持久化一份topic配置。

    broker在这个时候不真正创建本地的队列信息

说明:

    参见 UpdateTopicSubCommand类

    注册参数和updateTopic显示帮助是一致的

说明:

    支持cluster模式下创建topic和支持broker模式下创建topic

说明:

    通知broker创建topic。

说明:

    集群模式下首先通过namesrv获取所有的broker的master地址,然后通知每个broker去创建topic,每个broker的创建过程跟指定单个broker是一致的。

说明:

    参见AdminBrokerProcessor类

说明:

    broker本地通过updateTopicConfig保存topic的配置信息并持久化

    broker通过registerBrokerAll通知namesrv保存topic信息

说明:

    broker通知namesrv注册该broker下的topic信息,具体的namesrv地址是在registerBrokerAll内部访问namesrv获取的。

说明:

    参见DefaultRequestProcessor类

说明:

    参见DefaultRequestProcessor类

说明:

    参见RouteInfoManager类

主体模式其实就是在路由模式的基础上,支持了对key的通配符匹配(星号以及井号),以满足更加复杂的消息分发场景。

“#” : 匹配一个或者多个

“* ”:匹配一个

例如上图中,lazy.#可以匹配到key=lazy.a或者key=lazy.a.b。 .orange只能匹配到a.orange,无法匹配a.b.orange

其中rec1中的key为“#.log”,rec2中的key为“*.log”。结合上图的运行结果,我们更好理解型号以及井号的匹配规则。

“#.log”匹配了error.log、success.log以及a.b.log

“ .log”只匹配了error.log以及success.log

“#” :匹配一个或者多个

“ *”:匹配一个

生产者:

消费者:


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/bake/11528373.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-16
下一篇 2023-05-16

发表评论

登录后才能评论

评论列表(0条)

保存