全屏类网站,做外贸网站进行销售 需要纳税吗,360外链,wordpress怎样改头像RabbitMQ 共提供了7种⼯作模式, 进⾏消息传递
一、七种模式的概述
1、Simple(简单模式) P#xff1a;生产者#xff0c;就是发送消息的程序
C#xff1a;消费者#xff0c;就是接收消息的程序
Queue#xff1a;消息队列#xff0c;类似⼀个邮箱, 可以缓存消息; ⽣产者…RabbitMQ 共提供了7种⼯作模式, 进⾏消息传递
一、七种模式的概述
1、Simple(简单模式) P生产者就是发送消息的程序
C消费者就是接收消息的程序
Queue消息队列类似⼀个邮箱, 可以缓存消息; ⽣产者向其中投递消息, 消费者从其中取出消息
特点: ⼀个⽣产者P⼀个消费者C, 消息只能被消费⼀次. 也称为点对点(Point-to-Point)模式
2、Work Queue(⼯作队列) 一个生产者P多个消费者C1、C2在多个消息的情况下WorkQueue会将消息分派给不同的消费者, 每个消费者都会接收到不同的消息
特点消息不会重复会分配给不同的消费者
适⽤场景: 集群环境中做异步处理⽐如12306 短信通知服务, 订票成功后, 订单消息会发送到RabbitMQ, 短信服务从RabbitMQ中获取订单信息, 并发送通知信息(在短信服务之间进⾏任务分配) 3、Publish/Subscribe(发布/订阅) 注
Exchange: 交换机 (X). 作⽤: ⽣产者将消息发送到Exchange, 由交换机将消息按⼀定规则路由到⼀个或多个队列中(上图中⽣产者将消息投递到队列中, 实际上这个在RabbitMQ中不会发⽣. ) RabbitMQ交换机有四种类型: fanout,direct, topic, headers, 不同类型有着不同的路由策略. AMQP协议⾥还有另外两种类型, System和⾃定义, 此处不再描述. 1. Fanout:⼴播将消息交给所有绑定到交换机的队列(Publish/Subscribe模式) 2. Direct:定向把消息交给符合指定routing key的队列(Routing模式) 3. Topic:通配符把消息交给符合routing pattern(路由模式)的队列(Topics模式) 4. headers类型的交换器不依赖于路由键的匹配规则来路由消息, ⽽是根据发送的消息内容中的headers属性进⾏匹配. headers类型的交换器性能会很差,⽽且也不实⽤,基本上不会看到它的存在. Exchange(交换机只负责转发消息, 不具备存储消息的能⼒, 因此如果没有任何队列与Exchange绑定或者没有符合路由规则的队列那么消息就会丢失。
RoutingKey: 路由键.⽣产者将消息发给交换器时, 指定的⼀个字符串, ⽤来告诉交换机应该如何处理这个消息.
Binding Key:绑定. RabbitMQ中通过Binding(绑定)将交换器与队列关联起来, 在绑定的时候⼀般会指定⼀个Binding Key, 这样RabbitMQ就知道如何正确地将消息路由到队列了. 如下图所示如果routingKey为orange就路由到Q1 当消息的Routing key与队列绑定的Bindingkey相匹配时消息才会被路由到这个队列.
⼀个⽣产者P, 多个消费者C1, C2, X代表交换机消息复制多份每个消费者接收相同的消息⽣产者发送⼀条消息经过交换机转发到多个不同的队列多个不同的队列就有多个不同的消费者 适合场景: 消息需要被多个消费者同时接收的场景. 如: 实时通知或者⼴播消息⽐如中国⽓象局发布天⽓预报的消息送⼊交换机, 新浪,百度, 搜狐, ⽹易等⻔⼾⽹站接⼊消息, 通过队列绑定到该交换机, ⾃动获取⽓象局推送的⽓象数据
4、Routing(路由模式) 路由模式是发布订阅模式的变种, 在发布订阅基础上, 增加路由key发布订阅模式是⽆条件的将所有消息分发给所有消费者, 路由模式是Exchange根据RoutingKey的规则,将数据筛选后发给对应的消费者队列
适合场景: 需要根据特定规则分发消息的场景.⽐如系统打印⽇志, ⽇志等级分为error, warning, info,debug, 就可以通过这种模式,把不同的⽇志发送到不同的队列, 最终输出到不同的⽂件
5、Topics(通配符模式) 路由模式的升级版, 在routingKey的基础上,增加了通配符的功能, 使之更加灵活.Topics和Routing的基本原理相同即⽣产者将消息发给交换机交换机根据RoutingKey将消息转发给与RoutingKey匹配的队列. 类似于正则表达式的⽅式来定义Routingkey的模式. 不同之处是routingKey的匹配⽅式不同Routing模式是相等匹配topics模式是通配符匹配
适合场景: 需要灵活匹配和过滤消息的场景
6、RPCRPC通信 RPC客户端发送消息到RPC_REQUEST队列中同时在replyTo属性中设置接收消息的队列RPC_RESPONSE
RPC服务器收到消息在RPC_REQUEST队列中对消息进行处理发送到RPC_RESPONSE响应队列中
过程
1. 客⼾端发送消息到⼀个指定的队列, 并在消息属性中设置replyTo字段, 这个字段指定了⼀个回调队列, ⽤于接收服务端的响应. 2. 服务端接收到请求后, 处理请求并发送响应消息到replyTo指定的回调队列 3. 客⼾端在回调队列上等待响应消息. ⼀旦收到响应客⼾端会检查消息的correlationId属性以 确保它是所期望的响应.
7、publish confirm发布确认
注他可以确保消息可以正确发送到RabbitMq的机制 1. ⽣产者将Channel设置为confirm模式(通过调⽤channel.confirmSelect()完成)后, 发布的每⼀条消 息都会获得⼀个唯⼀的ID, ⽣产者可以将这些序列号与消息关联起来以便跟踪消息的状态. 2. 当消息被RabbitMQ服务器接收并处理后服务器会异步地向⽣产者发送⼀个确认(ACK)给⽣产者(包含消息的唯⼀ID)表明消息已经送达.
通过Publisher Confirms模式⽣产者可以确保消息被RabbitMQ服务器成功接收, 从⽽避免消息丢失的问题
