在这里插入图片描述

1、RabbitMQ

1.1、如何保证消息不丢失？

RabbitMQ-如何保证消息不丢失？

要回答这个问题，我们首先需要了解RabbitMQ的使用场景

异步发送（验证码、短信）
MySql和Redis、ES之间的数据同步
分布式事务
削峰填谷

那消息丢失的情况有哪些呢？有四种情况

在这里插入图片描述

消息未到达交换机
消息未到达队列
消息在队列中丢失
消费者未接收消息

生产者确认机制

RabbitMQ提供了publisher confirm机制来避免发送消息到MQ过程中的丢失。消息发送到MQ之后，会返回一个结果给发送者，表示消息是否消费成功

在这里插入图片描述

消息失败之后如何处理呢？

回调方法即时重发
记录日志
保存到数据库然后定时重发，成功发送后即刻删除表中的数据

消息持久化

在这里插入图片描述

消费者确认机制

RabbitMQ支持消费者确认机制，即：消费者处理消息后可以向MQ发送ack回执，MQ收到ack回执后才会删除该消息。而SpringAMQP则允许配置三种确认模式：

manual：手动ack，需要在业务代码结束后，调用api发送ack。
auto：自动ack，由spring监测listener代码是否出现异常，没有异常则返回ack；抛出异常则返回nack
none：关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除

我们可以利用Spring的retry机制，在消费者出现异常时利用本地重试，设置重试次数，当次数达到了以后，如果消息依然失败，将消息投递到异常交换机，交由人工处理

在这里插入图片描述

小总结

RabbitMQ-如何保证消息不丢失

开启生产者确认机制，确保生产者的消息能到达队列
开启持久化功能，确保消息未消费前在队列中不会丢失
开启消费者确认机制为auto，由spring确认消息处理成功后完成ack
开启消费者失败重试机制，多次重试失败后将消息投递到异常交换机，交由人工处理

面试快速答法

在这里插入图片描述

1.2、消息的重复消费问题

RabbitMQ消息的重复消费问题如何解决的?

产生消息重复消费的原因有哪些？

网络波动
消费者挂了

解决方案：

每条消息设置一个唯一的标识id：支付id，订单id，文章id、活动推文id（自己的项目）
幂等方案：可以通过加锁，分布式锁，数据库锁（乐观锁、悲观锁）

面试快速答法

在这里插入图片描述

1.3、死信交换机

RabbitMQ中死信交换机 ? (RabbitMQ延迟队列有了解过嘛?)

延迟队列：进入队列的消息会被延迟消费
场景：超时订单、限时优惠、定时发布

延迟队列 = 死信交换机 + TTL（生存时间）

那什么是死信交换机呢?

死信交换机

当一个队列中的消息满足下列情况之一时，可以成为死信（dead letter）：

消费者使用basic.reject或 basic.nack声明消费失败，并且消息的requeue参数设置为false
消息是一个过期消息，超时无人消费
要投递的队列消息堆积满了，最早的消息可能成为死信

如果该队列配置了dead-letter-exchange属性，指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机称为死信交换机（Dead Letter Exchange，简称DLX）。

在这里插入图片描述

TTL

TTL，也就是Time-To-Live。如果一个队列中的消息TTL结束仍未消费，则会变为死信，ttl超时分为两种情况：

消息所在的队列设置了存活时间
消息本身设置了存活时间

在这里插入图片描述

延迟队列插件

DelayExchange插件，需要安装在RabbitMQ中，DelayExchange的本质还是官方的三种交换机，只是添加了延迟功能。因此使用时只需要声明一个交换机，交换机的类型可以是任意类型，然后设定delayed属性为true即可。

在这里插入图片描述

小总结

RabbitMQ中死信交换机 ? (RabbitMQ延迟队列有了解过嘛)

我们当时的爱心雨伞项目有一个定时发布志愿活动，需要用到延迟队列其中就是用RabbitMQ实现的。
其中的延迟队列就用到了延迟队列和TTL （消息存活时间）实现的
如果消息超时未消费就会变成死信。（死信的其他情况：拒绝被消费、队列满了）

延迟队列插件实现延迟队列DelayExchange

声明一个交换机，添加delayed属性为true
发送消息时，添加x-delay头，值为超时时间

面试快速答法

在这里插入图片描述

1.4、消息堆积怎么解决

RabbitMQ如果有100万消息堆积在MQ , 如何解决(消息堆积怎么解决)

当生产者生产消息的速度超过了消费者消费消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信（产生死信的条件之一：队列消息堆积满），可能会被丢弃，这就是消息堆积问题

在这里插入图片描述

解决消息堆积有三种思路：

增加更多的消费者，提高消费速度
在消费者中开启线程池来加快处理消息的速度
扩大队列容积，让队列可以存放更多的消息，使用惰性队列

惰性队列

惰性队列的特性如下：

接收到消息后直接存入磁盘而非内存
消费者要消费消息时才从磁盘中读取并加载到内存中
支持数百万条的消息存储

在这里插入图片描述

小总结

如果有100万消息堆积在MQ , 如何解决(消息堆积怎么解决)?

这里提供三种解决思路：

增加更多的消费者，提高消费速度
在消费者中开启线程池嘛，加快消息的处理速度
扩大队列容积，提高堆积上限，采用惰性队列
- 在声明队列的时候可以设置属性x-queue-model为lazy，即为惰性队列
- 基于磁盘存储，消息存储的上限高
- 性能比较稳定，但基于磁盘存储，受限于磁盘IO，时效性会降低

面试快速答法

在这里插入图片描述

1.5、集群

RabbitMQ的高可用机制有了解过嘛?

在生产环境下，使用集群来保证高可用性
集群有普通集群、镜像集群、仲裁队列

普通集群

普通集群，具备以下特征：

会在集群的各个节点间共享部分数据，包括：交换机、队列元信息。但不包括队列中的消息
当访问集群某节点时，如果队列不在该节点，会从数据所在节点传递到当前节点并返回
队列所在节点宕机，队列中的消息就会丢失

镜像集群

镜像集群：本质是主从模式，具备下面的特征

交换机、队列、队列中的消息会在各个mq的镜像节点之间同步备份
创建队列的节点被称为该队列的主节点，备份到的其他节点叫做该队列的镜像节点
一个队列的主节点可能是另一个队列的镜像节点
所有的操作都是主节点完成，然后同步给镜像节点
主节点宕机后，镜像节点会代替成为新的主节点

仲裁队列

仲裁队列：仲裁队列是3.8版本以后才有的新功能，用来替代镜像队列，具备以下特征：

与镜像队列一样，都是主从模式，支持主从数据同步
使用非常简单，没有复杂的配置
主从同步基于Raft协议，强一致

在这里插入图片描述

小总结

RabbitMQ的高可用机制有了解过嘛

在生产环境下，我们当时采用镜像模式搭建的集群，共有三个节点
镜像队列结构是一主多从（从就是镜像），所有的操作都是主节点完成，然后同步给镜像节点
主宕机后，镜像节点会替代成为新的主（如果在主从同步完成前，主就已经宕机，可能出现数据丢失）

那出现数据丢失怎么办？

我们可以采用仲裁队列，同镜像队列一样，都是主从模式，支持主从数据同步，主从同步基于Raft协议，强一致
使用起来非常简单，不需要额外的数据，在声明队列的时候只要指定这个队列是仲裁队列即可

面试快速答法

在这里插入图片描述

2、Kafka

2.1、Kafka是如何保证消息不丢失

Kafka是如何保证消息不丢失?

使用Kafka在消息的收发过程中都会出现消息的丢失，Kafka分别给出了解决方案

生产者发送消息到Broker丢失
消息在Broker中存储丢失
消费者从Broker接收消息丢失

在这里插入图片描述

生产者发送消息到Broker丢失

解决方案：

设置异步发送

在这里插入图片描述

消息重试

在这里插入图片描述

消息在Broker中存储丢失

在这里插入图片描述

解决方案：

发送确认机制acks

确认机制	说明
acks=0	生产者在成功写入消息之前不会等待任何来自服务器的响应,消息有丢失的风险，但是速度最快
acks=1（默认值）	只要集群首领节点收到消息，生产者就会收到一个来自服务器的成功响应
acks=all	只有当所有参与赋值的节点全部收到消息时，生产者才会收到一个来自服务器的成功响应

消费者从Broker接收消息丢失

在这里插入图片描述