手机网站一定要与pc网站一样,昆山企业网站建设公司,简洁的公司网站,seo技术分享1.Simple#xff08;简单模式#xff09; P是生产者#xff0c;C是消费者#xff0c;Queue是消息队列。
生产者将消息放到Queue中#xff0c;消费者来消费
特点#xff1a;只有一个生产者和一个消费者#xff0c;一个信息只能被消费一次。
适应场景#xff1a;消息只…1.Simple简单模式 P是生产者C是消费者Queue是消息队列。
生产者将消息放到Queue中消费者来消费
特点只有一个生产者和一个消费者一个信息只能被消费一次。
适应场景消息只能被单个消费者处理。 2 Work Queue工作队列 P仍然代表生产者C1和C2都是消费者
这种模式只有一个生产者消费者可以有多个。当产生多条消息的时候Work Queue会将消息分配给不同的 消费者每个消费者收到的消息都不同。
特点消息不会重复会分配给不同的消费者。
适用场景集群环境中做异步处理。 2.Publish/Subscribe(发布/订阅) 这个比上面两种模式多了一个xx就是交换机也就是Exchange。
交换机起到路由作用。生产者生产的信息发送到交换机交换机通过一定规则路由到一个或者多个消息队列中。
RabbitMQ交换机有四种类型: fanout,direct, topic, headers 1. Fanout:广播将消息交给所有绑定到交换机的队列(Publish/Subscribe模式) 2. Direct:定向把消息交给符合指定routing key的队列(Routing模式) 3. Topic:通配符把消息交给符合routing pattern(路由模式)的队列(Topics模式) 4. headers类型的交换器不依赖于路由键的匹配规则来路由消息, 而是根据发送的消息内容中的 headers属性进行匹配. headers类型的交换器性能会很差,而且也不实用,基本上不会看到它的存在.
RoutingKey: 路由键.生产者将消息发给交换器时, 指定的一个字符串, 用来告诉交换机应该如何处理这个消息. Binding Key:绑定. RabbitMQ中通过Binding(绑定)将交换器与队列关联起来, 在绑定的时候一般会指定一个Binding Key, 这样RabbitMQ就知道如何正确地将消息路由到队列了. 这两个图就很好解释了 RoutingKeyBindingKey的作用. 当消息的Routing key与队列绑定的Bindingkey相匹配时消息才会被路由到这个队列.
上面这种模式生产者生产一个消息发给交换机交换机复制多分发给消息队列每个消息队列消息相同。
适应场景消息需要被多个消费者同时接收如实时通知广播。
4.Routing路由模式
Routing 模式是发布订阅模式的变种加了key作用就是过滤就是根据Routing Key来进行筛选将筛选后的消息发给对应的消息队列。
适合场景: 需要根据特定规则分发消息的场景.
看下图 5.Topics(通配符模式) 路由模式的升级版, 在routingKey的基础上,增加了通配符的功能, 使之更加灵活.
Topics和Routing的基本原理相同即生产者将消息发给交换机交换机根据RoutingKey将消息转发给与RoutingKey匹配的队列. 类似于正则表达式的方式来定义Routingkey的模式.
不同之处是routingKey的匹配方式不同Routing模式是相等匹配topics模式是通配符匹配. 适合场景: 需要灵活匹配和过滤消息的场景
6.RPC(RPC通信)
在RPC通信的过程中, 没有生产者和消费者, 比较像RPC远程调用, 大概就是通过两个队列实现了一个可回调的过程. 1. 客户端发送消息到一个指定的队列, 并在消息属性中设置replyTo字段, 这个字段指定了一个回调队列, 用于接收服务端的响应. 2. 服务端接收到请求后, 处理请求并发送响应消息到replyTo指定的回调队列 3. 客户端在回调队列上等待响应消息. 一旦收到响应客户端会检查消息的correlationId属性以 确保它是所期望的响应.
7.Publisher Confirms(发布确认)
Publisher Confirms模式是RabbitMQ提供的一种确保消息可靠发送到RabbitMQ服务器的机制。在这种模式下生产者可以等待RabbitMQ服务器的确认以确保消息已经被服务器接收并处理.
1. 生产者将Channel设置为confirm模式(通过调用channel.confirmSelect()完成)后, 发布的每一条消 息都会获得一个唯一的ID, 生产者可以将这些序列号与消息关联起来以便跟踪消息的状态. 2. 当消息被RabbitMQ服务器接收并处理后服务器会异步地向生产者发送一个确认(ACK)给生产者(包含消息的唯一ID)表明消息已经送达.
通过Publisher Confirms模式生产者可以确保消息被RabbitMQ服务器成功接收, 从而避免消息丢失的问题.
适用场景: 对数据安全性要求较高的场景. 比如金融交易, 订单处理.
过程就和下图差不多 上面这7中模式并非哪种就是最优的要根据业务场景进行选择举个例子如果要求安全性高就可以使用Publisher Confirms发布确认。
