深圳 网站策划,海东营销网站建设,网站对联代码div,开发公司 网站建设RabbitMQ 共提供了7种⼯作模式,进⾏消息传递,.
官⽅⽂档:RabbitMQ Tutorials | RabbitMQ 1.Simple(简单模式) P:⽣产者,也就是要发送消息的程序 C:消费者,消息的接收者 Queue:消息队列,图中⻩⾊背景部分.类似⼀个邮箱,可以缓存消息;⽣产者向其中投递消息,消费者从其中取出消息… RabbitMQ 共提供了7种⼯作模式,进⾏消息传递,.
官⽅⽂档:RabbitMQ Tutorials | RabbitMQ 1.Simple(简单模式) P:⽣产者,也就是要发送消息的程序 C:消费者,消息的接收者 Queue:消息队列,图中⻩⾊背景部分.类似⼀个邮箱,可以缓存消息;⽣产者向其中投递消息,消费者从其中取出消息. 特点:⼀个⽣产者P⼀个消费者C,消息只能被消费⼀次.也称为点对点(Point-to-Point)模式.适⽤场景:消息只能被单个消费者处理 2.Work Queue(工作队列) ⼀个⽣产者P多个消费者C1,C2.在多个消息的情况下,Work Queue 会将消息分派给不同的消费者,每个消费者都会接收到不同的消息. 特点:消息不会重复,分配给不同的消费者. 适⽤场景:集群环境中做异步处理。⽐如 12306 短信通知服务,订票成功后,订单消息会发送到RabbitMQ,短信服务从 RabbitMQ 中获取订单信息,并发送通知信息(在短信服务之间进⾏任务分配) 3.Publish/Subscribe(发布/订阅) 图中 X 表⽰交换机,在订阅模型中多了⼀个 Exchange ⻆⾊,过程略有变化 ⼀个⽣产者P,多个消费者C1,C2,X 代表交换机消息复制多份每个消费者接收相同的消息 ⽣产者发送⼀条消息经过交换机转发到多个不同的队列多个不同的队列就有多个不同的消费者 适合场景:消息需要被多个消费者同时接收的场景.如:实时通知或者⼴播消息 ⽐如中国⽓象局发布天⽓预报的消息送⼊交换机,新浪,百度,搜狐,⽹易等⻔户⽹站接⼊消息,通过队列绑定到该交换机,⾃动获取⽓象局推送的⽓象数据 概念介绍Exchange:交换机(X) 作⽤:⽣产者将消息发送到 Exchange,由交换机将消息按⼀定规则路由到⼀个或多个队列中(上图中⽣产者将消息投递到队列中,实际上这个在 RabbitMQ 中不会发⽣因为在 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 路由键.⽣产者将消息发给交换器时,指定的⼀个字符串,⽤来告诉交换机应该如何处理这个消息. BindingKey:绑定.RabbitMQ 中通过Binding(绑定)将交换器与队列关联起来,在绑定的时候⼀般会指定⼀个 Binding Key,这样 RabbitMQ 就知道如何正确地将消息路由到队列了. ⽐如下图:如果在发送消息时,设置了 RoutingKey 为 orange,消息就会路由到Q1 当消息的 Routingkey与队列绑定的 Bindingkey 相匹配时消息才会被路由到这个队列. BindingKey其实也属于路由键中的⼀种, 官⽅解释为:the routingkey to use for the binding. 可以翻译为:在绑定的时候使⽤的路由键.⼤多数时候,包括官⽅⽂档和 RabbitMQ Java API 中都把 BindingKey 和 RoutingKey看作RoutingKey,为了避免混淆,可以这么理解: 1. 在使⽤绑定的时候,需要的路由键是 BindingKey. 2. 在发送消息的时候,需要的路由键是 RoutingKey.
4.Routing(路由模式) 路由模式是发布订阅模式的变种,在发布订阅基础上,增加路由 key 发布订阅模式是⽆条件的将所有消息分发给所有消费者,路由模式是 Exchange 根据 RoutingKey 的规则,将数据筛选后发给对应的消费者队列 适合场景:需要根据特定规则分发消息的场景. ⽐如系统打印⽇志,⽇志等级分为 error,warning,info,debug,就可以通过这种模式,把不同的⽇志发送到不同的队列,最终输出到不同的文件 5.Topics(通配符模式) 路由模式的升级版,在 routingKey 的基础上,增加了通配符的功能,使之更加灵活.Topics 和Routing 的基本原理相同即⽣产者将消息发给交换机交换机根据 RoutingKey 将消息转 发给与 RoutingKey 匹配的队列.类似于正则表达式的⽅式来定义 Routingkey 的模式. 不同之处是routingKey 的匹配⽅式不同Routing 模式是相等匹配topics 模式是通配符匹配. 在 topic 类型的交换机在匹配规则上,有些要求: 1. RoutingKey是⼀系列由点( . )分隔的单词,⽐如 stock.usd.nyse , nyse.vmw , quick.orange.rabbit 2. BindingKey 和 RoutingKey ⼀样,也是点( . )分割的字符串. 3. Binding Key中可以存在两种特殊字符串,⽤于模糊匹配 * 表⽰⼀个单词,如 m mq # 表⽰多个单词(0-N个) ⽐如 • Binding Key为d.a.b会同时路由到 Q1 和 Q2 • Binding Key 为d.a.f 会路由到Q1 • Binding Key 为c.e.f 会路由到Q2 • Binding Key 为d.b.f 会被丢弃,或者返回给⽣产者(需要设置 mandatory 参数) 适合场景:需要灵活匹配和过滤消息的场景 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 服务器成功接收,从⽽避免消息丢失的问题.
消息丢失问题 作为消息中间件,都会⾯临消息丢失的问题.消息丢失⼤概分为三种情况: 1. ⽣产者问题.因为应⽤程序故障,⽹络抖动等各种原因,⽣产者没有成功向 broker 发送消息. 2. 消息中间件⾃⾝问题.⽣产者成功发送给了Broker,但是 Broker 没有把消息保存好,导致消息丢失. 3. 消费者问题.Broker 发送消息到消费者,消费者在消费消息时,因为没有处理好,导致 broker 将消费失败的消息从队列中删除了. RabbitMQ 也对上述问题给出了相应的解决⽅案.问题 2 可以通过持久化机制.问题 3 可以采⽤消息应答机制.针对问题1,可以采⽤发布确认( Publisher Confirms )机制实现. 适⽤场景:对数据安全性要求较⾼的场景.比如⾦融交易,订单处理. 原理 ⽣产者将信道设置成 confirm(确认) 模式,⼀旦信道进⼊ confirm 模式,所有在该信道上⾯发布的消息都会被指派⼀个唯⼀的ID(从1开始),⼀旦消息被投递到所有匹配的队列之后,RabbitMQ 就会发送⼀个确认给⽣产者(包含消息的唯⼀ID) 这就使得⽣产者知道消息已经正确到达⽬的队列了,如果消息和队列是可持久化的,那么确认消息会在将消息写⼊磁盘之后发出.broker 回传给⽣产者的确认消息中 deliveryTag 包含了确认消息的序号,此外 broker 也可以设置 channel.basicAck⽅法中的 multiple 参数,表⽰到这个序号之前的所有消息都已经得到了处理. 发送⽅确认机制最⼤的好处在于它是异步的,⽣产者可以同时发布消息和等待信道返回确认消息. 1. 当消息最终得到确认之后,⽣产者可以通过回调⽅法来处理该确认消息. 2. 如果 RabbitMQ 因为⾃⾝内部错误导致消息丢失,就会发送⼀条 nack(Basic.Nack) 命令,⽣产者同样 可以在回调⽅法中处理该 nack 命令
实现思路 异步 confirm ⽅法的编程实现最为复杂. Channel 接⼝提供了⼀个⽅法 addConfirmListener. 这个⽅法可以添加 ConfirmListener 回调接⼝. ConfirmListener 接⼝中包含两个⽅法: handleAck(long deliveryTag, boolean multiple) 和 handleNack(long deliveryTag, boolean multiple) ,分别对应处理 RabbitMQ 发送给⽣产者的 ack成功处理 和 nack未成功处理 deliveryTag 表⽰发送消息的序号.multiple 表⽰是否批量确认.我们需要为每⼀个 Channel 维护⼀个已发送消息的序号集合.当收到 RabbitMQ 的 confirm 回调时,从集合中删除对应的消息.当Channel 开启 confirm 模式后,channel 上发送消息都会附带⼀个从 1 开始递增的 deliveryTag 序号.我们可以使⽤ SortedSet 的有序性来维护这个已发消息的集合. 1. 当收到 ack 时,从序列中删除该消息的序号.如果为批量确认消息,表⽰⼩于等于当前序号 deliveryTag 的消息都收到了,则清除对应集合 2. 当收到 nack 时,处理逻辑类似,不过需要结合具体的业务情况,进⾏消息重发等操作.
3种消息确认模式的对比 可以看到异步确认模式的效率远超于另外的两种消息确认模式。
