MQ 面试

为什么要用MQ？MQ有哪些使用场景？

什么是消息队列

消息队列是一种异步的通信方式，用于在分布式系统中管理消息传递。消息队列采用了生产者-消费者模型，生产者将消息发送到队列中，而消费者则从队列中接收消息。

为什么要使用消息队列

其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？

面试官问你这个问题，期望的一个回答是说，你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用MQ可能会很麻烦，但是你现在用了MQ之后带给了你很多的好处。消息队列的常见使用场景，其实场景有很多，但是比较核心的有3个：解耦、异步、削峰。

解耦

A系统发送个数据到BCD三个系统，接口调用发送，那如果E系统也要这个数据呢？那如果C系统现在不需要了呢？现在A系统又要发送第二种数据了呢？而且A系统要时时刻刻考虑BCDE四个系统如果挂了咋办？要不要重发？我要不要把消息存起来？

--------补入课程手画图

你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用MQ给他异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个MQ去进行系统的解耦。

异步

A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要30ms，BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是30 + 300 + 450 + 200 = 980ms，接近1s。

异步后，BCD三个系统分别写库的时间，A系统就不再考虑了。

削峰

每天0点到16点，A系统风平浪静，每秒并发请求数量就100个。结果每次一到16点~23点，每秒并发请求数量突然会暴增到1万条。但是系统最大的处理能力就只能是每秒钟处理1000个请求啊。怎么办？需要我们进行流量的削峰，让系统可以平缓的处理突增的请求。

讲一讲RabbitMQ的AMQP协议

AMQP

是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。目标是实现一种在全行业广泛使用的标准消息中间件技术，以便降低企业和系统集成的开销，并且向大众提供工业级的集成服务。主要实现有 RabbitMQ。

客户端与RabbitMQ的通讯

连接

首先作为客户端（无论是生产者还是消费者），你如果要与RabbitMQ通讯的话，你们之间必须创建一条TCP连接，当然同时建立连接后，客户端还必须发送一条“问候语”让彼此知道我们都是符合AMQP的语言的，比如你跟别人打招呼一般会说“你好！”，你跟国外的美女一般会说“hello!”一样。你们确认好“语言”之后，就相当于客户端和RabbitMQ通过“认证”了。你们之间可以创建一条AMQP的信道。

信道

概念：信道是生产者/消费者与RabbitMQ通信的渠道。信道是建立在TCP连接上的虚拟连接，什么意思呢？就是说rabbitmq在一条TCP上建立成百上千个信道来达到多个线程处理，这个TCP被多个线程共享，每个线程对应一个信道，信道在RabbitMQ都有唯一的ID ,保证了信道私有性，对应上唯一的线程使用。

疑问：为什么不建立多个TCP连接呢？原因是rabbit保证性能，系统为每个线程开辟一个TCP是非常消耗性能，每秒成百上千的建立销毁TCP会严重消耗系统。所以rabbitmq选择建立多个信道（建立在tcp的虚拟连接）连接到rabbit上。

从技术上讲，这被称之为“多路复用”，对于执行多个任务的多线程或者异步应用程序来说，它非常有用。

虚拟主机

虚拟消息服务器，vhost，本质上就是一个mini版的mq服务器，有自己的队列、交换器和绑定，最重要的，自己的权限机制。Vhost提供了逻辑上的分离，可以将众多客户端进行区分，又可以避免队列和交换器的命名冲突。Vhost必须在连接时指定，rabbitmq包含缺省vhost：“/”，通过缺省用户和口令guest进行访问。

rabbitmq里创建用户，必须要被指派给至少一个vhost，并且只能访问被指派内的队列、交换器和绑定。Vhost必须通过rabbitmq的管理控制工具创建。

交换器类型

共有四种direct,fanout,topic,headers，其种headers(几乎和direct一样)不实用，可以忽略。

Direct

路由键完全匹配，消息被投递到对应的队列， direct交换器是默认交换器。声明一个队列时，会自动绑定到默认交换器，并且以队列名称作为路由键：channel->basic_public($msg,’’,’queue-name’)

Fanout

消息广播到绑定的队列，不管队列绑定了什么路由键，消息经过交换器，每个队列都有一份。

Topic

通过使用“”和“#”通配符进行处理，使来自不同源头的消息到达同一个队列，”.”将路由键分为了几个标识符，“”匹配1个，“#”匹配一个或多个。

RabbitMQ如何才能做到消息不丢失？

1. 生产者确保消息到MQ
   RabbitMQ 支持发布者确认（Publisher Confirm）机制，即发布者在将消息发送到队列后，等待 RabbitMQ 服务器的确认消息。如果 RabbitMQ 成功将消息保存到队列中，会返回一个确认消息给发布者。如果 RabbitMQ 服务器无法将消息保存到队列中，会返回一个 Nack（Negative Acknowledgement）消息给发布者。通过发布者确认机制，可以确保消息被成功发送到 RabbitMQ 服务器。
   
   
   
2. 确保消息路由到正确的队列
   注意这里，只有路由失败才会走这个方法
   
   
3. 确保消息在队列正确存储
   在发送消息时，可以设置消息属性 delivery_mode 为 2，表示该消息需要被持久化，即将消息保存到磁盘中，即使 RabbitMQ 服务器宕机也能够保证消息不会丢失。可以在创建队列时将 durable 属性设置为 True，表示该队列也需要被持久化，以便在 RabbitMQ 服务器宕机后能够重新创建队列和绑定。

• 发送持久化
  
  
• 队列持久化
  
  

4. 确认机制
   在 RabbitMQ 中，消费者通过 basic.ack 命令向 RabbitMQ 服务器确认已经消费了某条消息。如果消费者在处理消息时发生错误或宕机，RabbitMQ 服务器会重新将消息发送给其他消费者。在确认消息之前，RabbitMQ 会将消息保存在内存中，只有在收到消费者的确认消息后才会删除消息。需要把自动确认机制改为手动确认机制
   
   

   @Component
   public class Receiver implements ChannelAwareMessageListener {
       //消费的方法
       @Override
       public void onMessage(Message message, Channel channel) throws Exception {
           try {
               String msg = new String(message.getBody());
               System.out.println("Receiver>>>>>>>接收到消息:"+msg);
               try {
   				// channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
   
                   System.out.println("Receiver>>>>>>消息已消费");
   
   
                   channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
   
   
                   // 这条消息变成死信消息
                   // System.out.println("Receiver>>>>>>消息拒绝且requeue=false,变为死信消息");
                   // channel.basicReject(message.getMessageProperties().getDeliveryTag(),false);
   
               } catch (Exception e) {
                   System.out.println(e.getMessage());
                   // Reject在拒绝消息时,一次只能拒绝一条消息。
                   // channel.basicReject(message.getMessageProperties().getDeliveryTag(),true);
                   // Nack则可以一次性拒绝多个消息
                   channel.basicNack(message.getMessageProperties().getDeliveryTag(), false,true);
                   System.out.println("Receiver>>>>>>拒绝消息，要求Mq重新派发");
                   throw e;
               }
   
           } catch (Exception e) {
               System.out.println(e.getMessage());
           }
       }
   }
   

5. 备份队列
   RabbitMQ 支持备份队列（Alternate Exchange）机制，即在消息发送到队列之前，先将消息发送到备份队列中。如果主队列无法接收消息，RabbitMQ 会将消息发送到备份队列中。备份队列通常是一个交换机，可以在创建队列时通过 x-dead-letter-exchange 属性来指定备份队列。

Kafka如何做到消息不丢失？

Kafka 通过多种机制来确保消息不丢失，包括副本机制、ISR（In-Sync Replicas）机制、ACK 机制等。

1. 副本机制

   Kafka 通过副本机制来确保消息不会丢失。在 Kafka 中，每个分区都可以配置多个副本，每个副本保存分区的完整副本，当一个副本宕机时，Kafka 会自动将副本切换到其他可用的副本上。因此，即使其中一个副本宕机，也能够保证消息不会丢失。

2. ISR 机制

   在 Kafka 中，副本分为 Leader 副本和 Follower 副本。Leader 副本负责处理消息，Follower 副本只是简单地复制 Leader 副本的数据。当 Follower 副本落后于 Leader 副本时，Kafka 会将 Follower 副本从 ISR 中移除。只有当 Follower 副本与 Leader 副本的差距不大时，才会将 Follower 副本重新加入 ISR，确保消息不会丢失。

3. ACK 机制

   在 Kafka 中，生产者发送消息时可以指定 acks 参数，表示生产者等待的确认数。acks 参数有三个取值：

   • acks=0 表示生产者不等待确认消息，直接将消息发送到 Kafka 集群。这种方式可能会导致消息丢失，不建议使用。
   • acks=1 表示生产者在 Leader 副本收到消息后，就将消息视为发送成功。如果 Leader 副本在发送消息后立即宕机，消息可能会丢失。如果 Follower 副本成功复制了消息，但 Leader 副本在宕机前没有来得及将消息写入磁盘，则这条消息将会丢失。
   • acks=all 表示生产者在所有 ISR 副本都确认接收到消息后，才将消息视为发送成功。这种方式可以最大程度地确保消息不会丢失，但是会降低消息发送的性能。

   通过上述机制的使用，可以最大程度地确保 Kafka 中的消息不会丢失。需要根据实际场景选择合适的参数配置来平衡消息发送的性能和可靠性。

RocketMQ如何做到消息不丢失？

RocketMQ 通过多种机制来确保消息不丢失，包括刷盘机制、消息拉取机制、ACK 机制等。

1. 刷盘机制

RocketMQ 中的消息分为内存消息和磁盘消息，内存消息在 Broker 内存中进行读写，磁盘消息则保存在磁盘上。RocketMQ 支持同步刷盘和异步刷盘两种方式，通过刷盘机制可以确保消息在 Broker 宕机时不会丢失。在同步刷盘模式下，消息写入磁盘时，会等待磁盘的写入完成才返回写入成功的响应。在异步刷盘模式下，消息写入磁盘后立即返回写入成功的响应，但是不等待磁盘写入完成

2. ACK 机制

在 RocketMQ 中，Producer 发送消息后，Broker 会返回 ACK 确认信号，表示消息已经成功发送。如果 Broker 没有收到 ACK 确认信号，就会尝试重新发送该消息，直到消息被确认为止。

RocketMQ 采用主从复制机制，每个消息队列都有一个主节点和多个从节点，主节点负责消息的写入和读取，从节点负责备份数据。当主节点宕机时，从节点会自动接管主节点的工作，确保消息不会丢失

3. 消息存储机制

RocketMQ 默认使用双写模式来存储消息，即将消息同时写入内存和磁盘中，然后再将内存中的消息异步刷盘到磁盘中。这种方式可以保证消息的可靠性，即使系统宕机，也能够尽可能地保证消息不会丢失。

除此之外，RocketMQ 还提供了多种机制来保证消息不丢失，例如事务消息、延迟消息、顺序消息等，这些机制可以根据业务需求进行选择和使用。

需要注意的是，为了确保消息的可靠性，RocketMQ 的发送消息的速度可能会受到一定的限制，需要在消息可靠性和性能之间进行权衡。

关于重复消费—幂等性处理方案

什么是幂等性？

对于消息接收端的情况,幂等的含义是采用同样的输入多次调用处理函数,得到同样的结果。例如，一个SQL操作

update stat_table set count= 10 where id =1

这个操作多次执行,id等于1的记录中的 count字段的值都为10,这个操作就是幂等的,我们不用担心这个操作被重复。

再来看另外一个SQL操作

update stat_table set count= count +1 where id= 1;

这样的SQL操作就不是幂等的,一旦重复,结果就会产生变化。

常见办法

因此应对消息重复的办法是,使消息接收端的处理是一个幂等操作。这样的做法降低了消息中间件的整体复杂性,不过也给使用消息中间件的消息接收端应用带来了一定的限制和门槛。

1. MVCC：

多版本并发控制，乐观锁的一种实现，在生产者发送消息时进行数据更新时需要带上数据的版本号，消费者去更新时需要去比较持有数据的版本号，版本号不一致的操作无法成功。例如博客点赞次数自动+1的接口：

public boolean addCount(Long id, Long version);

update blogTable set count= count+1,version=version+1 where id=321 and version=123

每一个version只有一次执行成功的机会，一旦失败了生产者必须重新获取数据的最新版本号再次发起更新。

2. 去重表：

利用数据库表单的特性来实现幂等，常用的一个思路是在表上构建唯一性索引，保证某一类数据一旦执行完毕，后续同样的请求不再重复处理了（利用一张日志表来记录已经处理成功的消息的ID，如果新到的消息ID已经在日志表中，那么就不再处理这条消息。）

以电商平台为例子，电商平台上的订单id就是最适合的token。当用户下单时，会经历多个环节，比如生成订单，减库存，减优惠券等等。每一个环节执行时都先检测一下该订单id是否已经执行过这一步骤，对未执行的请求，执行操作并缓存结果，而对已经执行过的id，则直接返回之前的执行结果，不做任何操作。这样可以在最大程度上避免操作的重复执行问题，缓存起来的执行结果也能用于事务的控制等。

什么是延时消息，怎么实现

比如常说的订单支付，可以保留用户半小时的订单，用户半小时后不支付就取消订单
处理方案，就是向MQ发送半小时的延时消息

• RabbitMQ 死信消息
  绑定交换机
  
  绑定队列
  
  
  

• RocketMQ延时消息
  

• Kafka自身没有延时消息

如何保证消息的顺序性

1. RabbitMQ

   • 单个队列：在一个队列中，RabbitMQ保证消息的顺序性。消息是按顺序发送到队列中的，消费者按顺序消费消息。要保证顺序性，通常只让一个消费者来处理队列中的消息。

   • Publisher Confirms 和消费者手动确认：使用Publisher Confirms可以确保生产者端按顺序发送的消息被确认。同样，消费者可以通过手动确认消息来确保消息按顺序处理。

   • 消息分发策略：在RabbitMQ中，多个消费者连接到同一个队列时，消息是以循环（Round Robin）方式分发的。这种情况下，如果需要确保顺序性，可以考虑将消息路由到专门的队列中，使消息只被一个消费者处理。

2. Kafka
   Kafka通过分区（Partition）机制来保证消息的顺序性：

   • 单分区：在Kafka中，同一分区内的消息是有序的。生产者在发送消息时，使用相同的Key将消息路由到相同的分区内。由于每个分区中的消息是按顺序写入和读取的，因此只要确保消息的Key一致，就可以保证消息的顺序性。

   • 分区和副本机制：Kafka的分区和副本机制也确保了在分区中的消息顺序。在副本发生故障时，Kafka会选举新的Leader来继续维持消息的顺序。

   • 单消费者组中的单线程消费：在消费者组中，单个分区只能被一个消费者实例消费，因此分区内的消息顺序不会被打乱。

3. RocketMQ
   RocketMQ通过消息队列和消息的MessageQueueSelector选择器来确保顺序性：

   • 顺序消息：在RocketMQ中，可以使用顺序消息（Orderly Message）来保证顺序性。生产者发送顺序消息时，可以使用MessageQueueSelector根据某个业务Key（如订单ID）将消息路由到相同的消息队列中。

   • 消费顺序消息：消费端可以通过MessageListenerOrderly接口来确保消息是按顺序消费的。在这种模式下，RocketMQ会确保一个消费者线程按顺序从一个队列中获取消息。

   • 分区和Queue：RocketMQ的每个主题（Topic）都有多个消息队列。通过将消息路由到特定队列，生产者和消费者都可以确保消息按顺序发送和处理。

   • 消费异常使用 CHICDEND_CURRENT_QUEUE_A_MONMENT 参数，可以在消息消费异常时暂时挂起队列消费，从而保证消息的顺序性

     @Bean
     public RocketMQTemplate rocketMQTemplate(RocketMQProperties rocketMQProperties) {
         RocketMQTemplate rocketMQTemplate = new RocketMQTemplate();
         rocketMQTemplate.setProducerGroup("your-producer-group");
         rocketMQTemplate.setNamesrvAddr(rocketMQProperties.getNameServer());
     
         // 设置参数来挂起当前队列的消费，以保证消息的顺序性
         rocketMQTemplate.setProducerParam("CHICDEND_CURRENT_QUEUE_A_MONMENT", "true");
     
         return rocketMQTemplate;
     }
     

消息积压

1. RabbitMQ

• 增加消费者数量：

  通过增加消费者实例数量来提高消息的消费速率。
  可以通过水平扩展消费者来实现，但需要注意 RabbitMQ 的负载均衡机制，确保每个消费者分担合理的负载。

• 增加消费端并发：

  可以增加单个消费者的并发处理能力，通过配置 prefetch_count 来控制 RabbitMQ 发送给每个消费者的消息数量。

• 优化消费逻辑：

  检查消费者的处理逻辑，看看是否有耗时操作，进行优化，比如批量处理消息，减少数据库交互次数。

• 临时提高队列消息的 TTL：

  对于不需要持久化的消息，临时提高消息的 TTL（Time To Live）值，自动丢弃过期消息。

• 处理死信队列：

  对于积压严重的队列，可以将消息转移到死信队列（Dead Letter Queue）中，稍后再处理。

2. Kafka

• 增加消费者组：

  在 Kafka 中，可以通过增加消费者组的数量来提高消费速率。每个消费者组可以并行地消费不同分区的数据。

• 增加分区数：

  增加主题的分区数，以便更多的消费者能够并行消费消息。不过要注意，增加分区数后，需要相应增加消费者实例，否则分区数的增加可能不会有明显效果。

• 调整消费端的配置：

  例如调整 fetch.min.bytes、fetch.max.wait.ms、max.poll.records 等参数，增加每次拉取的消息量和频率。

• 优化生产者和消费者逻辑：

  确保生产者不生产过多的重复消息，消费者处理消息时尽量减少阻塞操作。

• 扩展 Kafka 集群：

  如果现有的 Kafka 集群处理能力不足，可以增加节点数来提高整体处理能力。

3. RocketMQ

• 扩展消费者：

  增加消费者数量和实例，提升消费吞吐量。

• 优化消费逻辑：

  类似于 RabbitMQ 和 Kafka，优化消费端逻辑，减少耗时操作，批量处理消息。

• 调整消费并发：

  通过配置 consumeThreadMax 等参数，增加消费线程的数量。

• 增加队列数：

  RocketMQ 中，每个主题（Topic）可以有多个队列，增加队列数可以提高并行消费的能力。

• 延迟消费：

  如果消息的处理可以延迟进行，可以通过 RocketMQ 的延迟队列功能，暂时缓解消费压力，后续再处理。