MQ面试题整理

1.  简单模式
2. 工作模式(资源竞争)，一条消息对应一个消费者消消费。可以根据消费者的处理速度来接受消息的数量，让消费者程序发挥最大性能。应用场景：集群环境中做异步处理，发挥每台服务器最大性能。
3. 发布、订阅模式(资源共享，此引入broker),每个消费者均可以收到消息。
4. 路由模式，exchanger根据routing key路由到绑定相同binding key的queue，然后有绑定某个queue的消费者消费。
5. 主题模式：*代表一个 #代表0或多个
6. rpc,几乎不用，可用dubbo代替。

 2、为什么要用mq?

• 流量削峰 例如：高峰期，激烈猛增的下单操作，会导致数据库承受不了，此时可以用消息队列做缓冲 ，并发的订单就可以分散成一段时间处理，虽然这可能导致部分用户几秒后收到下单成功的操作，但总比不能下单要好。
• 异步 例如：A调用B可以不用等待B处理完再返回结果

• 解耦  例如：创建订单操作需要调库存系统、支付系统、物流系统等，可以不用等待直接返回结果，也会减少因某个系统故障而导致一条链路都蹦

3、MQ如何保证消息可靠？（MQ如何防止消息丢失？）基于springboot

1）生产者

productor-->exchange丢失：

开启confirm机制（发布确认机制），实现confirmCallback接口

productor-->queue路由失败：

开启return机制，实现returnCallback接口

 

            setMandatory(true)或者如上图在配置文件开启return机制

  confirm机制会重写confirm方法，根据ack判断，如果返回false则失败，编写业务逻辑，重试，重试达到3次仍然失败就持久化到数据库，人工处理。如果return机制失败，此时不可以放到死信队列，因为队列都没到达，可以放到redis去，然后用定时任务，重发。又或者放到备份交换机。

 

2）MQ服务器

•       交换机Exchange，队列Queue，消息Message 都有持久化特性（durable），持久化特性会把数据写入内存和磁盘

3）消费者

    消费者确认机制。默认情况下，MQ服务器的消息到达消费者后，消息者会立即发送ACK确认消息给MQ服务器，MQ服务器获取ACK后，从队列中删除消息。
    如果执行自动ACK确认机制的话，MQ服务器可能会在消息者接受到消息但未执行成功业务的时候，主动删除MQ消息，导致消息的丢失。
    我们可以开启手动ACK模式，然后在消费者的业务执行成功后，才使用代码发送ACK确认，以实现消息可靠。但是这种方式代码侵入性较高。Spring集成auto模式ACK机制，本质上利用AOP代理把手动ACK代码在业务执行成功后进行切入，从而既实现了手动ACK确认方式，也降低了代码耦合度。所以在开发中，直接使用Spring的ACK的manaual模式即可。
    
   

 

4、死信交换机 --延迟队列

无法被消费的消息

应用场景：1、保证业务订单的消息不丢失，消费者发生异常时，可以放到死信队列 2、三十分钟不支付订单自动取消。 另外，延迟队列的实行方式也可以是java的delayQueue、quartz、kafka的时间轮。

死信来源：

1. 消息TTL过期
2. 达到队列的最大长度
3. 消息被拒绝(basic.reject 或 basic.nack)并且 requeue=false

 注意：消息TTL有几种实现方式。1、消息TTL，这种情况如果遇到队列堵塞，前面的任务ttl比后面的ttl时间长，那任务也不会过期，因为是在发送消费者前判断过期时间 2、队列TTL，这种模式下，适用于单一的，整个任务都是一样的过期时间，像会议取消这种场景就不适用了 3、安装插件，这种情况可以解决1的问题。

5、如何保证幂等？

1、消息携带业务id，消费者去查询数据库是否存在数据，如果存在证明已经消费过，不处理。或者插入，插入利用主键唯一性约束，插入不成功报键重复异常。

2、redis setnx，利用redis原子性特性

 

 6、MQ消息堆积？

1、因为高峰导致的，可以利用死信队列

2、消费能力不足导致

1. 消费者集群处理，能用多线程处理？
2. 将消息发送到临时的consumer,然后建立一个比原来队列更长的队列，发到这个临时队列再处理
3. 采用mq惰性队列。

7、消息顺序性？

1.  消息关键key的hash值对队列取模，然后就能保证投到同一个队列，队列天然FIFO
2. producer:queue:cosumer = 1:1:1