rabbitMq 基本概述

 

 

Exchange Type：

有fanout、direct、topic、headers这四种（AMQP规范里还提到两种Exchange Type，分别为system与自定义，这里不予以描述）

fanout：fanout类型的Exchange路由规则非常简单，它会把所有发送到该Exchange的消息，路由到所有与它绑定的Queue中。（发送所有的队列）。

direct：direct类型的Exchange路由规则也很简单，它会把消息路由到那些binding key与routing key完全匹配的Queue中。（routing key和bingdind key, 完全匹配）

 

topic：direct类型的Exchange路由规则是完全匹配binding key与routing key，但这种严格的匹配方式在很多情况下不能满足实际业务需求。topic类型的Exchange在匹配规则上进行了扩展，它与direct类型的Exchage相似，也是将消息路由到binding key与routing key相匹配的Queue中，但这里的匹配规则有些不同，它约定：

routingKey=”quick.orange.rabbit”

Q1=*.orange.*

Q2=*.*.rabbit* / laz   y.#

routingKey=”quick.orange.rabbit”的消息会同时路由到Q1与Q2，routingKey=”lazy.orange.fox”的消息会路由到Q1，routingKey=”lazy.brown.fox”的消息会路由到Q2，routingKey=”lazy.pink.rabbit”的消息会路由到Q2（只会投递给Q2一次，虽然这个routingKey与Q2的两个bindingKey都匹配）；routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的消息将会被丢弃，因为它们没有匹配任何bindingKey。

headers：headers类型的Exchange不依赖于routing key与binding key的匹配规则来路由消息，而是根据发送的消息内容中的headers属性进行匹配。
在绑定Queue与Exchange时指定一组键值对；当消息发送到Exchange时，RabbitMQ会取到该消息的headers（也是一个键值对的形式），对比其中的键值对是否完全匹配Queue与Exchange绑定时指定的键值对；如果完全匹配则消息会路由到该Queue，否则不会路由到该Queue。
该类型的Exchange没有用到过

--------------------------------------------

 

RPC：MQ本身是基于异步的消息处理，前面的示例中所有的生产者（P）将消息发送到RabbitMQ后不会知道消费者（C）处理成功或者失败（甚至连有没有消费者来处理这条消息都不知道）。
但实际的应用场景中，我们很可能需要一些同步处理，需要同步等待服务端将我的消息处理完成后再进行下一步处理。这相当于RPC（Remote Procedure Call，远程过程调用）。在RabbitMQ中也支持RPC。

 

RabbitMQ中实现RPC的机制是：

客户端发送请求（消息）时，在消息的属性（MessageProperties，在AMQP协议中定义了14种properties，这些属性会随着消息一起发送）中设置两个值replyTo（一个Queue名称，用于告诉服务器处理完成后将通知我的消息发送到这个Queue中）和correlationId（此次请求的标识号，服务器处理完成后需要将此属性返还，客户端将根据这个id了解哪条请求被成功执行了或执行失败）

1:服务器端收到消息并处理

2:服务器端处理完消息后，将生成一条应答消息到replyTo指定的Queue，同时带上correlationId属性

3:客户端之前已订阅replyTo指定的Queue，从中收到服务器的应答消息后，根据其中的correlationId属性分析哪条请求被执行了，根据执行结果进行后续业务处理

 

可能产生问题：--------------------------------------------------------------------

 

Message acknowledgment:在实际中，会发生消费者收到queue中的消息，但是没有处理完就会宕机。这种情况就可能会导致消息丢失，

为了避免这种情况，我们可以要求消费者在消费完成后，发送一个回执给RabbitMq，RabbitMq收到消息回执后才将该消息从queue中移除

如果mq检测出消费者与mq断开连接，如果存在多个消费者的情况下，会把该消息发送给其它消费者。这里不存在超时（一个消费者处理消息再长也不会把该消息发送给其他消费者）。

问题：如果开发者忘记把发送回执给mq，这回导致消息队列中的消息越来越多，重启后，会重复消费这些消息。

 

Message durability：如果我们希望，mq服务器重启也不会丢失消息，我么可以将消息队列和消息设置成持久化的，这样保证绝大部分的情况下，我们不会丢失消息。，但是也会有小概率（mq服务器已经接受到生产者的消息，但还没来的级转换成持久化消息服务器就断电了，那么我们将用到事务）

 

Prefetch count：如果有多个消费者订阅同一个消息队列中的消息，消息队列中的消息会平均分配给多个消费者，如果每个消息处理的时间不同，就有可能导致有的消费者一直在忙，有的一直哭空闲，所以我们设置prefetchCount 来限制消息队列每次发送给每个消费者的消息数量。比如设置的prefetchCount=1，则每次给每个消费者发送一条消息，消费者处理完，后，消息队列再给该消费者发送一条消息

https://blog.csdn.net/u013256816/article/details/59117354