RabbitMQ 的7种工作模式

        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种消息确认模式的对比

        可以看到异步确认模式的服从远超于别的的两种消息确认模式。


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。