RabbitMQ面试题总结

梅子清酒
438 阅读31分钟

生产者建立tcp连接，复用tcp连接建立channel信道，信道与交换机相连，交换机根据不同路由键绑定队列；每条消息都绑定路由键，消息到达交换机后，交换机根据消息的路由键和与队列绑定的路由键进行消息的分发，将消息发送到不同的队列。

1. RabbitMQ的实用优点

总得来说，有三大确实的好处

  • 应用解耦

举例说明：有这样一个业务场景：我们在网上购买一件商品，支付成功之后库存要减少一，如果是传统的软件架构中，必须是先支付，然后再减少库存，这两个操作必须是在同一事务中，即操作原子性，但是这样做的话效率是极其低下的，如果使用RabbitMQ的话，我们需要将消息发送给各自的队列来进行消息处理，支付和库存的操作之间没有了关联性，这样支付系统和库存系统之间就进行了解耦。

  • 流量削峰

rabbitMQ可以使用缓冲队列的方式，在访问量急剧增大的时候，减少并发访问的压力，比较常见的业务场景就是秒杀和签到系统，一般来说流量的削峰有两个处理方式：

  1. 上游队列缓冲，限速发送
  2. 下游队列缓冲，限速执行

当然，常见的场景是采用第二种方式，不影响客户使用的响应速度和使用体验等，

我们知道RabbitMQ中消息是通过信道Channel来传给对应的队列的，而消费端监听这个队列处理其中的消息也是有处理时间的，这时我们需要解决的就是如果队列上有一定数量的消息未被确认，则不进行新的消息的消费

rabbitMQ提供channel.basicQos方法来限制信道上的消费者所能保持的最大未确认消息的数量，说到未确认，我们需要先知道RabbitMQ为了保证消息可靠的到达消费者那里， 提供了消息确认机制，通过autoAck参数来控制，如果autoAck为true，默认消息消费者自动确认消息，此时消息可能未被处理结束，如果autoAck为false的话，则需要消费者手动来确认消息

结合上面两点，我们可以利用rabbitMQ在服务的下游来限速执行达到流量削峰的目的

  • 异步处理

很多的业务场景中，需要发出一个指示，但是并不要求立即执行，可能对什么时候执行，或者只要执行就可以了有不同的需求，而对象这样的RabbitMQ提供不同的解决方法，用户发送发送的消息储存在RabbitMQ中，由rabbitMQ传递给消费者来进行消费，也可以通过死信队列来实现延迟队列的效果，让消息定时被消费等等。

当然RabbitMQ还有很多其他的好处，比如：很容易实现集群环境的搭建，能定制路由设置消息传递的规则以及消息分发和消息缓冲等优点

2. 消息基于什么传输，这样做有什么优点？

RabbitMQ是基于信道Channel的方式来传输数据，排除了使用TCP链接来进行数据的传输，因为TCP链接创建和销毁对于系统性能的开销比较大，且并发能力受系统资源的限制，这样很容易造成rabbitMQ的性能瓶颈。

消费者链接RabbitMQ其实就是一个TCP链接，一旦链接创建成功之后，就会基于链接创建Channel，每个线程把持一个Channel,Channel复用TCP链接，减少了系统创建和销毁链接的消耗，提高了性能

3. 如何确保消息正确的发送到RabbitMQ

发送方发送消息到RabbitMQ，有可能发送失败，失败的原因有如下的可能:

  • 交换器无法根据自身的类型和路由键匹配到队列（mandatory）
  • 当与路由键匹配的所有队列都没有消费者时（延时队列和死信队列）

对于上面的情况，RabbitMQ提供发送方确认机制来去报消息正确发送到RabbitMQ服务

发送方确认机制是指消息生产者将信道设置成confirm模式，一旦信道进入confirm模式，所有在该信道上发布的消息都会指派一个唯一的id，一旦消息被投递到RabbitMQ服务中国，RabbitMQ就会发送一个确认给生产者。

发送方确认模式是异步的，不影响生成者继续发送消息，可扩展性也就增大了

其实还有另外一种解决方法，发送方如果觉得异步确认对于代码而言变的复杂了，那么可以不设置mandatory

额外补充下，发送方确认其实还有事务机制，主要有如下的方法进行设置：

  • channel.txSelect: 将当前的Channel设置为事务模式
  • channel.txCommit: 提交当前的事务
  • channel.txRollback: 事务回滚 跟数据库的事务比较像，也的确能解决发送方能确认消息是否发送到RabbitMQ中，但是事务机制很耗费性能，所以不提倡使用事务，仅供了解即可

4. 如何确保消息接收方消费消息

消费方通过监听队列，从Channel中获取队列中存储的数据并进行消费——即为消费者订阅队列，可以执行autoAck参数，当autoAck为false时，RabbitMQ会等待消费者显示的回复确认信号之后，才会从内存（或者硬盘）中删除消息。

所以确保消费者消费消息，只需要设置autoAck参数为false即可，这样就确保RabbitMQ会等待消息消费完成之后才删除消息。但是这个特性却衍生出新的问题，如果消费端处理消息失败，没有手动显示回复确认信号， 则RabbitMQ不会在内存或硬盘中删除该消息，导致该消息会阻塞在队列中，后续的消息也会被阻塞住导致消息无法消费。

对于上面出现的问题，我们可以使用RabbitMQ提供的补偿机制和死信队列来实现消费失败的消息保存。

rabbitMQ提供配置参数来开启消费者重试机制，也能配置配置最大重试次数和重试间隔时间，rabbitMQ对于消息消费失败达到一定次数后，就会放弃该消息，我们可以手动实现，如果消费失败达到最大重试次数后，将数据转发到死信队列上，由死信队列的消费者来实现消息的持久化到数据库或者日志文件中，一般重试次数我们设置为3此，间隔时间为5s。

img

也可以消费者手动实现业务层判断，如果同一消息消费了多次，则可以手动拒绝该消息，然后该消息自动进入死信队列，这样基于rabbitMQ的死信队列的特性来自动实现消息的保存，优点是rabbitMQ的封装框架不需要进行额外的代码，性能方面有了保障，缺点是这个工作交给了消费者手动实现。具体的还得看实际业务的需求。

5. 如何避免消息的重复消费和重复投递

在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重和幂等的依据（消息投递失败并重传），避免重复的消息进入队列；在消息消费时，要求消息体中必须要有一个bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重和幂等的依据，避免同一条消息被重复消费

6. 消息如何分发（路由）★★★★★

个人觉的消息分发和消息路由属于同一问题，生产者将消息发送到Exchange上，然后Exchange将消息路由到一个或者多个队列上，如果路由不到，将消息根据发送者确认机制回传给生产者，或者直接丢弃；消费者订阅队列上的消息，以上就是消息的流经的整个流程

  • 生产者链接到RabbitMQ，建立一个Connection，然后基于该Connection开启Channel
  • 生产者声明一个Exchange，并设置相关属性（Exchange类型fanout、direct、topic和headers、是否持久化）
  • 生产者声明一个Queue，并设置相关属性（是否持久化）
  • 生产者将消息发送给Exchange,一般会指定一个RoutingKey，用来指定这个消息的路由规则，而这个RoutingKey需要与Exchange类型和BindingKey联合作用才能最终生效
  • 相应的Exchange根据接收到的消息的路由键查找匹配的队列，如果匹配上将消息发送到队列上，如果查询不到根据发送者确认模式，是否返回给发送者或者丢掉
  • 消费者链接到RabbitMQ，建立一个Connection，然后基于该Connection开启 Channel
  • 消费者订阅队列，根据autoAck是否为false来决定是否手动确认消息
  • RabbitMQ服务接收到消息确认，删除队列中该消息

7. 如何确保消息不丢失

消息丢失有以下三种情况：

  • 生产者发送消息到RabbitMQ中，如果没有对应Exchange、或者Exchange没有匹配队列，或者队列没有任何消费者都可能导致消息的丢失

对于发送失败的，我们可以使用生产者确认机制来让发送失败的消息回传给生产者，或者使用备份交换机的方式来处理发送失败的消息

RabbitMQ 发送方消息确认模式有以下三种：普通确认模式，批量确认模式，异步监听确认模式。spring整合RabbitMQ后只使用了异步监听确认模式。

【注】异步监听模式，可以实现边发送消息边进行确认，不影响主线程任务执行。

  • rabbitMQ服务重启、关闭、宕机情况下导致的消息丢失

RabbitMQ持久化包括三个部分：Exchange的持久化、Queue的持久化和Message的持久化

我们要持久化消息，则必须持久化Queue，因为Message是存储在Queue上的，如果Queue不持久化的话，Message即便是持久化了，重启服务也会因为没有存储的载体导致Message的丢失

这里注意下，将所有的消息持久化，这样会严重影响RabbitMQ的性能，对于可靠性不是那么高的消息可以不采用持久化来提高系统整体的吞吐量

spring整合后默认开启了交换机，队列，消息的持久化，所以不修改任何设置就可以保证消息不在RabbitMQ丢失。但是为了以防万一，还是可以申明下。

  • 消费者设置autoAck为true,可能导致消费者还没有来得及消费就宕机了，其实也是变相的消息丢失

这个需要我们在消费消息时，设置autoAck为true，同时注意解决消费异常的情况，具体的参考面试题4

1.使用RabbitMQ有什么好处？

1.解耦，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 2.异步，将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度 3.削峰，并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常

2.RabbitMQ 中的 broker 是指什么？cluster 又是指什么？

broker 是指一个或多个 erlang node 的逻辑分组，且 node 上运行着 RabbitMQ 应用程序。 cluster 是在 broker 的基础之上，增加了 node 之间共享元数据的约束。

3. RabbitMQ 概念里的 channel、exchange 和 queue 是逻辑概念，还是对应着进程实体？分别起什么作用？

Queue 具有自己的 erlang 进程；exchange 内部实现为保存 binding 关系的查找表；channel 是实际进行路由工作的实体，即负责按照 routing_key 将 message 投递给 queue 。由 AMQP 协议描述可知，channel 是真实 TCP 连接之上的虚拟连接，所有 AMQP 命令都是通过 channel 发送的，且每一个 channel 有唯一的 ID。一个 channel 只能被单独一个操作系统线程使用，故投递到特定 channel 上的 message 是有顺序的。但一个操作系统线程上允许使用多个 channel 。

4. vhost 是什么？起什么作用？

vhost 可以理解为虚拟 broker ，即 mini-RabbitMQ server。其内部均含有独立的 queue、exchange 和 binding 等，但最最重要的是，其拥有独立的权限系统，可以做到 vhost 范围的用户控制。当然，从 RabbitMQ 的全局角度，vhost 可以作为不同权限隔离的手段（一个典型的例子就是不同的应用可以跑在不同的 vhost 中）。

5. 消息基于什么传输？

由于TCP连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制。

6. 消息如何分发？

若该队列至少有一个消费者订阅，消息将以循环（round-robin）的方式发送给消费者。每条消息只会分发给一个订阅的消费者（前提是消费者能够正常处理消息并进行确认）。

7. 消息怎么路由？

从概念上来说，消息路由必须有三部分：交换器、路由、绑定。生产者把消息发布到交换器上；绑定决定了消息如何从路由器路由到特定的队列；消息最终到达队列，并被消费者接收。

消息发布到交换器时，消息将拥有一个路由键（routing key），在消息创建时设定。 通过队列路由键，可以把队列绑定到交换器上。 消息到达交换器后，RabbitMQ会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）。如果能够匹配到队列，则消息会投递到相应队列中；如果不能匹配到任何队列，消息将进入 “黑洞”。

常用的交换器主要分为一下三种：

  • direct：如果路由键完全匹配，消息就被投递到相应的队列
  • fanout：如果交换器收到消息，将会广播到所有绑定的队列上
  • topic：可以使来自不同源头的消息能够到达同一个队列。使用topic交换器时，可以使用通配符。 比如：“*” 匹配特定位置的任意文本， “.” 把路由键分为了几部分，“#” 匹配所有规则等。 特别注意：发往topic交换器的消息不能随意的设置选择键（routing_key），必须是由"."隔开的一系列的标识符组成。

8. 什么是元数据？元数据分为哪些类型？包括哪些内容？与 cluster 相关的元数据有哪些？元数据是如何保存的？元数据在 cluster 中是如何分布的？

在非 cluster 模式下，元数据主要分为 Queue 元数据（queue 名字和属性等）、Exchange元数据（exchange 名字、类型和属性等）、Binding 元数据（存放路由关系的查找表）、Vhost元数据（vhost 范围内针对前三者的名字空间约束和安全属性设置）。 在 cluster 模式下，还包括 cluster 中 node 位置信息和 node 关系信息。元数据按照 erlang node 的类型确定是仅保存于 RAM 中，还是同时保存在 RAM 和 disk 上。元数据在 cluster 中是全 node 分布的。

9. 在单node 系统和多 node 构成的 cluster 系统中声明 queue、exchange ，以及进行 binding 会有什么不同？

答：当你在单 node 上声明 queue 时，只要该 node 上相关元数据进行了变更，你就会得到 Queue.Declare-ok 回应；而在 cluster 上声明 queue ，则要求 cluster 上的全部 node 都要进行元数据成功更新，才会得到 Queue.Declare-ok 回应。另外，若 node 类型为 RAM node 则变更的数据仅保存在内存中，若类型为 disk node 则还要变更保存在磁盘上的数据。

死信队列&死信交换器：DLX 全称（Dead-Letter-Exchange）,称之为死信交换器，当消息变成一个死信之后，如果这个消息所在的队列存在x-dead-letter-exchange参数，那么它会被发送到x-dead-letter-exchange对应值的交换器上，这个交换器就称之为死信交换器，与这个死信交换器绑定的队列就是死信队列。

10. 如何确保消息正确地发送至RabbitMQ？

RabbitMQ使用发送方确认模式，确保消息正确地发送到RabbitMQ。 发送方确认模式：将信道设置成confirm模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的ID。一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）。如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息。发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。

11. 如何确保消息接收方消费了消息？

接收方消息确认机制：消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。这里并没有用到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。

下面罗列几种特殊情况：

  • 如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下一个订阅的消费者。（可能存在消息重复消费的隐患，需要根据bizId去重）
  • 如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息。

12. 如何避免消息重复投递或重复消费？

在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重和幂等的依据（消息投递失败并重传），避免重复的消息进入队列；在消息消费时，要求消息体中必须要有一个bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重和幂等的依据，避免同一条消息被重复消费。

这个问题针对业务场景来答分以下几点：

1.比如，你拿到这个消息做数据库的insert操作。那就容易了，给这个消息做一个唯一主键，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。

2.再比如，你拿到这个消息做redis的set的操作，那就容易了，不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作。

3.如果上面两种情况还不行，上大招。准备一个第三方介质,来做消费记录。以redis为例，给消息分配一个全局id，只要消费过该消息，将<id,message>以K-V形式写入redis。那消费者开始消费前，先去redis中查询有没消费记录即可。

13. 如何解决丢数据的问题?

1.生产者丢数据

生产者的消息没有投递到MQ中怎么办？从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm模式来确保生产者不丢消息。

transaction机制就是说，发送消息前，开启事物(channel.txSelect())，然后发送消息，如果发送过程中出现什么异常，事物就会回滚(channel.txRollback())，如果发送成功则提交事物(channel.txCommit())。

然而缺点就是吞吐量下降了。因此，按照博主的经验，生产上用confirm模式的居多。一旦channel进入confirm模式，所有在该信道上面发布的消息都将会被指派一个唯一的ID(从1开始)，一旦消息被投递到所有匹配的队列之后，rabbitMQ就会发送一个Ack给生产者(包含消息的唯一ID)，这就使得生产者知道消息已经正确到达目的队列了.如果rabiitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。

2.消息队列丢数据

处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。这个持久化配置可以和confirm机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。

那么如何持久化呢，这里顺便说一下吧，其实也很容易，就下面两步

①、将queue的持久化标识durable设置为true,则代表是一个持久的队列

②、发送消息的时候将deliveryMode=2

这样设置以后，rabbitMQ就算挂了，重启后也能恢复数据。在消息还没有持久化到硬盘时，可能服务已经死掉，这种情况可以通过引入mirrored-queue即镜像队列，但也不能保证消息百分百不丢失（整个集群都挂掉）

3.消费者丢数据

启用手动确认模式可以解决这个问题

①自动确认模式，消费者挂掉，待ack的消息回归到队列中。消费者抛出异常，消息会不断的被重发，直到处理成功。不会丢失消息，即便服务挂掉，没有处理完成的消息会重回队列，但是异常会让消息不断重试。

②手动确认模式，如果消费者来不及处理就死掉时，没有响应ack时会重复发送一条信息给其他消费者；如果监听程序处理异常了，且未对异常进行捕获，会一直重复接收消息，然后一直抛异常；如果对异常进行了捕获，但是没有在finally里ack，也会一直重复发送消息(重试机制)。

③不确认模式，acknowledge="none" 不使用确认机制，只要消息发送完成会立即在队列移除，无论客户端异常还是断开，只要发送完就移除，不会重发。

14. 死信队列和延迟队列的使用?

死信消息：

消息被拒绝（Basic.Reject或Basic.Nack）并且设置 requeue 参数的值为 false 消息过期了 队列达到最大的长度

过期消息：

在 rabbitmq 中存在2种方可设置消息的过期时间，第一种通过对队列进行设置，这种设置后，该队列中所有的消息都存在相同的过期时间，第二种通过对消息本身进行设置，那么每条消息的过期时间都不一样。如果同时使用这2种方法，那么以过期时间小的那个数值为准。当消息达到过期时间还没有被消费，那么那个消息就成为了一个 死信 消息。

**队列设置：**在队列申明的时候使用 x-message-ttl 参数，单位为 毫秒

**单个消息设置：**是设置消息属性的 expiration 参数的值，单位为 毫秒

**延时队列：**在rabbitmq中不存在延时队列，但是我们可以通过设置消息的过期时间和死信队列来模拟出延时队列。消费者监听死信交换器绑定的队列，而不要监听消息发送的队列。

有了以上的基础知识，我们完成以下需求：

需求：用户在系统中创建一个订单，如果超过时间用户没有进行支付，那么自动取消订单。

分析：

1、上面这个情况，我们就适合使用延时队列来实现，那么延时队列如何创建 2、延时队列可以由 过期消息+死信队列 来时间 3、过期消息通过队列中设置 x-message-ttl 参数实现 4、死信队列通过在队列申明时，给队列设置 x-dead-letter-exchange 参数，然后另外申明一个队列绑定x-dead-letter-exchange对应的交换器。

    ConnectionFactory factory = new ConnectionFactory(); 
    factory.setHost("127.0.0.1"); 
    factory.setPort(AMQP.PROTOCOL.PORT); 
    factory.setUsername("guest"); 
    factory.setPassword("guest"); 
    Connection connection = factory.newConnection(); 
    Channel channel = connection.createChannel();
     
    // 声明一个接收被删除的消息的交换机和队列 
    String EXCHANGE_DEAD_NAME = "exchange.dead"; 
    String QUEUE_DEAD_NAME = "queue_dead"; 
    channel.exchangeDeclare(EXCHANGE_DEAD_NAME, BuiltinExchangeType.DIRECT); 
    channel.queueDeclare(QUEUE_DEAD_NAME, false, false, false, null); 
    channel.queueBind(QUEUE_DEAD_NAME, EXCHANGE_DEAD_NAME, "routingkey.dead"); 
     
    String EXCHANGE_NAME = "exchange.fanout"; 
    String QUEUE_NAME = "queue_name"; 
    channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.FANOUT); 
    Map<String, Object> arguments = new HashMap<String, Object>(); 
    // 统一设置队列中的所有消息的过期时间 
    arguments.put("x-message-ttl", 30000); 
    // 设置超过多少毫秒没有消费者来访问队列，就删除队列的时间 
    arguments.put("x-expires", 20000); 
    // 设置队列的最新的N条消息，如果超过N条，前面的消息将从队列中移除掉 
    arguments.put("x-max-length", 4); 
    // 设置队列的内容的最大空间，超过该阈值就删除之前的消息
    arguments.put("x-max-length-bytes", 1024); 
    // 将删除的消息推送到指定的交换机，一般x-dead-letter-exchange和x-dead-letter-routing-key需要同时设置
    arguments.put("x-dead-letter-exchange", "exchange.dead"); 
    // 将删除的消息推送到指定的交换机对应的路由键 
    arguments.put("x-dead-letter-routing-key", "routingkey.dead"); 
    // 设置消息的优先级，优先级大的优先被消费 
    arguments.put("x-max-priority", 10); 
    channel.queueDeclare(QUEUE_NAME, false, false, false, arguments); 
    channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, ""); 
    String message = "Hello RabbitMQ: "; 
     
    for(int i = 1; i <= 5; i++) { 
    	// expiration: 设置单条消息的过期时间 
    	AMQP.BasicProperties.Builder properties = new AMQP.BasicProperties().builder()
    			.priority(i).expiration( i * 1000 + ""); 
    	channel.basicPublish(EXCHANGE_NAME, "", properties.build(), (message + i).getBytes("UTF-8")); 
    } 
    channel.close(); 
    connection.close();

15. 使用了消息队列会有什么缺点?

1.系统可用性降低:你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性降低

2.系统复杂性增加:要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增大。

16. 消息队列的作用与使用场景

异步：批量数据异步处理（批量上传文件） 削峰：高负载任务负载均衡（电商秒杀抢购） 解耦：串行任务并行化（退货流程解耦） 广播：基于Pub/Sub实现一对多通信

17. 多个消费者监听一个队列时，消息如何分发?

  • 轮询: 默认的策略，消费者轮流，平均地接收消息
  • 公平分发: 根据消费者的能力来分发消息，给空闲的消费者发送更多消息

//当消费者有x条消息没有响应ACK时，不再给这个消费者发送消息

channel.basicQos(int x)

18. 无法被路由的消息去了哪里?

无设置的情况下，无法路由（Routing key错误）的消息会被直接丢弃 解决方案： 将mandatory设置为true，并配合ReturnListener，实现消息的回发

声明交换机时，指定备份的交换机

 Map<String,Object> arguments = new HashMap<String,Object>();
	arguments.put("alternate-exchange","备份交换机名");

19. 消息在什么时候会变成死信?

  • 消息拒绝并且没有设置重新入队
  • 消息过期
  • 消息堆积，并且队列达到最大长度，先入队的消息会变成DL

20. RabbitMQ如何实现延时队列?

利用TTL（队列的消息存活时间或者消息存活时间），加上死信交换机

 // 设置属性，消息10秒钟过期
AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder()
		.expiration("10000") // TTL

 // 指定队列的死信交换机
Map<String,Object> arguments = new HashMap<String,Object>();
arguments.put("x-dead-letter-exchange","DLX_EXCHANGE");

21. 如何保证消息的可靠性投递

发送方确认模式： 将信道设置成confirm模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的ID。 一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）。 如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息。 发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。

接收方确认机制 接收方消息确认机制：消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。 这里并没有用到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。保证数据的最终一致性； 下面罗列几种特殊情况： 如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下一个订阅的消费者。（可能存在消息重复消费的隐患，需要去重） 如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息。

22. 消息幂等性

生产者方面：可以对每条消息生成一个msgID，以控制消息重复投递

 AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder()
	porperties.messageId(String.valueOF(UUID.randomUUID()))

消费者方面：消息体中必须携带一个业务ID，如银行流水号，消费者可以根据业务ID去重，避免重复消费

23. 消息如何被优先消费

//生产者
 Map<String, Object> argss = new HashMap<String, Object>();
        argss.put("x-max-priority",10);

//消费者
AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder()
                .priority(5) // 优先级，默认为5，配合队列的 x-max-priority 属性使用

24. 如何保证消息的顺序性

一个队列只有一个消费者的情况下才能保证顺序，否则只能通过全局ID实现（每条消息都一个msgId，关联的消息拥有一个parentMsgId。可以在消费端实现前一条消息未消费，不处理下一条消息；也可以在生产端实现前一条消息未处理完毕，不发布下一条消息）

25. RabbitMQ的集群模式和集群节点类型

**普通模式：**默认模式，以两个节点（rabbit01，rabbit02）为例来进行说明，对于Queue来说，消息实体只存在于其中一个节点rabbit01（或者rabbit02），rabbit01和rabbit02两个节点仅有相同的元数据，即队列结构。当消息进入rabbit01节点的Queue后，consumer从rabbit02节点消费时，RabbitMQ会临时在rabbit01，rabbit02间进行消息传输，把A中的消息实体取出并经过B发送给consumer，所以consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连rabbit01或rabbit02，出口总在rabbit01，会产生瓶颈。当rabbit01节点故障后，rabbit02节点无法取到rabbit01节点中还未消费的消息实体。如果做了消息持久化，那么等到rabbit01节点恢复，然后才可被消费。如果没有消息持久化，就会产生消息丢失的现象。

**镜像模式：**把需要的队列做成镜像队列，存在与多个节点属于RabibitMQ的HA方案，该模式解决了普通模式中的问题，其实质和普通模式不同之处在于，消息体会主动在镜像节点间同步，而不是在客户端取数据时临时拉取，该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉，所以在对可靠性要求比较高的场合中适用

节点分为内存节点（保存状态到内存，但持久化的队列和消息还是会保存到磁盘），磁盘节点（保存状态到内存和磁盘），一个集群中至少需要一个磁盘节点

26.如何自动删除长时间没有消费的消息

// 通过队列属性设置消息过期时间
        Map<String, Object> argss = new HashMap<String, Object>();
        argss.put("x-message-ttl",6000);

 // 对每条消息设置过期时间
        AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder()
                .expiration("10000") // TTL

27.消息基于什么传输

RabbitMQ使用信道的方式来传输数据。信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制

28.如何确保消息不丢失

消息持久化，当然前提是队列必须持久化 RabbitMQ确保持久性消息能从服务器重启中恢复的方式是，将它们写入磁盘上的一个持久化日志文件，当发布一条持久性消息到持久交换器上时，Rabbit会在消息提交到日志文件后才发送响应。 一旦消费者从持久队列中消费了一条持久化消息，RabbitMQ会在持久化日志中把这条消息标记为等待垃圾收集。如果持久化消息在被消费之前RabbitMQ重启，那么Rabbit会自动重建交换器和队列（以及绑定），并重新发布持久化日志文件中的消息到合适的队列。

订阅模式

在订阅模型中，一共有四个角色：

  • P：生产者，也就是要发送消息的程序，但是不再发送到队列中，而是发给X（交换机）
  • C：消费者，消息的接受者，会一直等待消息到来。
  • Queue：消息队列，接收消息、缓存消息。
  • Exchange：交换机，图中的X。一方面，接收生产者发送的消息。另一方面，知道如何处理消息，例如递交给某个特别队列、递交给所有队列、或是将消息丢弃。到底如何操作，取决于Exchange的类型。Exchange有常见以下3种类型：
    • Fanout：广播，将消息交给所有绑定到交换机的队列
    • Direct：定向，把消息交给符合指定routing key 的队列
    • Topic：通配符，把消息交给符合routing pattern（路由模式） 的队列

​ Exchange（交换机）只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与Exchange绑定，或者没有符合路由规则的队列，那么消息会丢失！

Routing路由模式特点：

img

  • 队列与交换机的绑定，不能是任意绑定了，而是要指定一个RoutingKey（路由key）
  • 消息的发送方在 向 Exchange发送消息时，也必须指定消息的 RoutingKey。
  • Exchange不再把消息交给每一个绑定的队列，而是根据消息的RoutingKey进行判断，只有队列的Routingkey与消息的 Routing key完全一致，才会接收到消息

Topics通配符模式：

img

Topic类型与Direct相比，都是可以根据RoutingKey把消息路由到不同的队列。只不过Topic类型Exchange可以让队列在绑定Routingkey 的时候使用通配符！

Routingkey 一般都是有一个或多个单词组成，多个单词之间以”.”分割，例如： item.insert

通配符规则：

#：匹配一个或多个词

*：匹配不多不少恰好1个词

Topic主题模式可以实现 Publish/Subscribe发布与订阅模式 和 Routing路由模式 的功能；只是Topic在配置routing key 的时候可以使用通配符，显得更加灵活。

生产者：

//创建连接
Connection connection = ConnectionUtil.getConnection();

// 创建频道
Channel channel = connection.createChannel();

/**
* 声明交换机
* 参数1：交换机名称
* 参数2：交换机类型，fanout、topic、topic、headers
*/
channel.exchangeDeclare(TOPIC_EXCHAGE, BuiltinExchangeType.TOPIC);


// 发送信息
String message = "新增了商品。Topic模式；routing key 为 item.insert " ;
channel.basicPublish(TOPIC_EXCHAGE, "item.insert", null, message.getBytes());
System.out.println("已发送消息：" + message);

// 发送信息
message = "修改了商品。Topic模式；routing key 为 item.update" ;
channel.basicPublish(TOPIC_EXCHAGE, "item.update", null, message.getBytes());
System.out.println("已发送消息：" + message);

// 发送信息
message = "删除了商品。Topic模式；routing key 为 item.delete" ;
channel.basicPublish(TOPIC_EXCHAGE, "item.delete", null, message.getBytes());
System.out.println("已发送消息：" + message);

// 关闭资源
channel.close();
connection.close();

消费者：

Connection connection = ConnectionUtil.getConnection();

// 创建频道
Channel channel = connection.createChannel();

//声明交换机
channel.exchangeDeclare(Producer.TOPIC_EXCHAGE, BuiltinExchangeType.TOPIC);

// 声明（创建）队列
/**
* 参数1：队列名称
* 参数2：是否定义持久化队列
* 参数3：是否独占本次连接
* 参数4：是否在不使用的时候自动删除队列
* 参数5：队列其它参数
*/
channel.queueDeclare(Producer.TOPIC_QUEUE_1, true, false, false, null);

//队列绑定交换机
channel.queueBind(Producer.TOPIC_QUEUE_1, Producer.TOPIC_EXCHAGE, "item.update");
channel.queueBind(Producer.TOPIC_QUEUE_1, Producer.TOPIC_EXCHAGE, "item.delete");

//创建消费者；并设置消息处理
DefaultConsumer consumer = new DefaultConsumer(channel){
@Override
/**
* consumerTag 消息者标签，在channel.basicConsume时候可以指定
* envelope 消息包的内容，可从中获取消息id，消息routingkey，交换机，消息和重传标志(收到消息失败后是否需要重新发送)
* properties 属性信息
* body 消息
*/
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
//路由key
System.out.println("路由key为：" + envelope.getRoutingKey());
//交换机
System.out.println("交换机为：" + envelope.getExchange());
//消息id
System.out.println("消息id为：" + envelope.getDeliveryTag());
//收到的消息
System.out.println("消费者1-接收到的消息为：" + new String(body, "utf-8"));
}
};
//监听消息
/**
* 参数1：队列名称
* 参数2：是否自动确认，设置为true为表示消息接收到自动向mq回复接收到了，mq接收到回复会删除消息，设置为false则需要手动确认
* 参数3：消息接收到后回调
*/
channel.basicConsume(Producer.TOPIC_QUEUE_1, true, consumer);
avatar
文章
阅读
粉丝