消息中间件

根据学习搜集的信息，结合网络内容进行的总结。

思维导图文档地址

错误和不足还请大佬指正 ヽ(=･ω･=)丿

一、RabbitMQ

可实现功能

• 异步发送（验证码、短信、邮件…）

• MySQL和Redis，ES之间的数据同步

• 分布式事务

• 削峰填谷

消息可靠性

发送者可靠性

生产者重试机制

# 在application.yaml文件内配置 
spring: 
	rabbitmq: 
		connection-timeout: 1s 			\# 设置MQ的连接超时时间 
		template: retry: enabled: true	\# 开启超时重试机制 
		initial-interval: 1000ms	    \# 失败后的初始等待时间 
		multiplier: 1 				\# 失败后下次的等待时长倍数，下次等待时长 = initial-interval \* multiplier 
		max-attempts: 3 				\# 最大重试次数

• 存在问题

​ 当网络不稳定的时候，利用重试机制可以有效提高消息发送的成功率。不过SpringAMQP提供的重试机制是阻塞式的重试，也就是说多次重试等待的过程中，当前线程是被阻塞的。 如果对于业务性能有要求，建议禁用重试机制。

生产者确认机制

当生产者发送消息给MQ后，MQ会根据消息处理的情况返回不同的回执。

# 在application.yaml文件内配置 
spring:
	rabbitmq: 
		publisher-confirm-type: correlated 	\# 开启publisher confirm机制，并设置confirm类型 
		publisher-returns: true 			\# 开启publisher return机制

• 返回结果

当消息投递到MQ，但是路由失败时，通过Publisher Return返回异常信息，同时返回ack的确认信息，代表投递成功 临时消息投递到了MQ，并且入队成功，返回ACK，告知投递成功 持久消息投递到了MQ，并且入队完成持久化，返回ACK ，告知投递成功 其它情况都会返回NACK，告知投递失败 其中ack和nack属于Publisher Confirm机制，ack是投递成功；nack是投递失败。 return则属于Publisher Return机制。 默认两种机制都是关闭状态，需要通过配置文件来开启。

• 存在问题

开启生产者确认比较消耗MQ性能，一般不建议开启。触发确认机制的情况往往是代码编写上的错误，如RoutingKey错误、交换机名称错误等。只有MQ内部故障这种需要处理，但概率往往较低。因此只有对消息可靠性要求非常高的业务才需要开启，而且仅仅需要开启ConfirmCallback处理nack就可以了。

数据持久化

• 交换机持久化

在控制台的Exchanges页面，添加交换机时可以配置交换机的Durability，设置为Durable就是持久化模式，Transient就是临时模式。

• 队列持久化

在控制台的Queues页面，添加队列时，同样可以配置队列的Durability参数

• 消息持久化

在控制台发送消息的时候，可以添加很多参数，而消息的持久化是要配置一个properties

消费者的可靠性

消费者确认机制

当消费者处理消息结束后，应该向RabbitMQ发送一个回执，告知RabbitMQ自己消息处理状态。

回执可选值

• ack：成功处理消息，RabbitMQ从队列中删除该消息

• nack：消息处理失败，RabbitMQ需要再次投递消息

• reject：消息处理失败并拒绝该消息，RabbitMQ从队列中删除该消息

确认模式

• none：不处理。即消息投递给消费者后立刻ack，消息会立刻从MQ删除。非常不安全，不建议使用

• manual：手动模式。需要自己在业务代码中调用api，发送ack或reject，存在业务入侵，但更灵活

• auto：自动模式。SpringAMQP利用AOP对我们的消息处理逻辑做了环绕增强，当业务正常执行时则自动返回ack. 当业务出现异常时，根据异常判断返回不同结果

• auto：自动模式。SpringAMQP利用AOP对我们的消息处理逻辑做了环绕增强，当业务正常执行时则自动返回ack. 当业务出现异常时，根据异常判断返回不同结果

• 如果是消息处理或校验异常，自动返回reject

失败重试机制

当消费者出现异常后，消息会不断requeue（重入队）到队列，再重新发送给消费者。如果消费者再次执行依然出错，消息会再次requeue到队列，再次投递，直到消息处理成功为止。

在application.yaml文件内配置 
spring: 
	rabbitmq: 
		listener: 
			simple: 
                retry: enabled: true 			\# 开启消费者失败重试 
                initial-interval: 1000ms 		\# 初识的失败等待时长为1秒 
                multiplier: 1 					\# 失败的等待时长倍数，下次等待时长 = multiplier \* 
                last-interval max-attempts: 3 	\# 最大尝试连接次数 
                stateless: true 				\# true无状态；false有状态。如果业务中包含事务，这里改为false

注意:

在配置文件中配置最大连接次数，在消费者出现异常时利用本地重试，而不是无限制的requeue到mq队列导致mq的消息处理飙升，导致mq的消息处理飙升，重试达到最大次数后，Spring会返回reject，消息会被丢弃

失败处理策略

• RejectAndDontRequeueRecoverer：重试耗尽后，直接reject，丢弃消息。默认就是这种方式

• ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队

• RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机 （推荐）

兜底方案

在服务中设置定时任务，定期查询要被处理的信息的状态。这样即便MQ通知失败，还可以利用定时任务作为兜底方案，确保信息状态的最终一致性。

消息重复消费

唯一消息ID

思路

1. 每一条消息都生成一个唯一的id，与消息一起投递给消费者。

2. 消费者接收到消息后处理自己的业务，业务处理成功后将消息ID保存到数据库

3. 如果下次又收到相同消息，去数据库查询判断是否存在，存在则为重复消息放弃处理。

给消息添加唯一ID

SpringAMQP的MessageConverter自带了MessageID的功能，我们只要开启这个功能即可。

 @Bean public MessageConverter messageConverter(){ 
     // 1.定义消息转换器 
     Jackson2JsonMessageConverter jjmc = new Jackson2JsonMessageConverter();
     // 2.配置自动创建消息id，用于识别不同消息，也可以在业务中基于ID判断是否是重复消息 
     jjmc.setCreateMessageIds(true); return jjmc; }

幂等

分布式锁、数据库锁（悲观锁、乐观锁）

业务判断

基于业务本身的逻辑或状态来判断是否是重复的请求或消息，不同的业务场景判断的思路也不一样。 例如：把订单状态从未支付修改为已支付。可以在执行业务时判断订单状态是否是未支付，如果不是则证明订单已经被处理过，无需重复处理。

延迟队列

在一段时间以后才执行的任务，我们称之为延迟任务，而要实现延迟任务，最简单的方案就是利用MQ的延迟消息

实现延迟消息的两种方案

• 死信交换机+TTL

• 延迟消息插件

死信队列

成为死信的条件

• 消费者使用basic.reject或 basic.nack声明消费失败，并且消息的requeue参数设置为false

• 消息是一个过期消息，超时无人消费

• 要投递的队列消息满了，无法投递

死信交换机

如果一个队列中的消息已经成为死信，并且这个队列通过dead-letter-exchange属性指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机就称为死信交换机（Dead Letter Exchange）。而此时加入有队列与死信交换机绑定，则最终死信就会被投递到这个队列中。

• 作用：
  1. 收集那些因处理失败而被拒绝的消息
  2. 收集那些因队列满了而被拒绝的消息
  3. 收集因TTL（有效期）到期的消息

TTL

如果一个队列中的消息TTL结束仍未消费，则会变成死信。

TTL超时分为两种情况

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

• 消息本身设置了存活时间

延迟队列插件 DlayExchange

本质还是三种交换机，只是添加了延迟功能。使用时只需要声明一个交换机，交换机的类型任意，然后设置delayed属性为true。 发送消息时，可以通过setHeader的x-delay属性设置延迟时间。

注意：

延迟消息插件内部会维护一个本地数据库表，同时使用Elang Timers功能实现计时。如果消息的延迟时间设置较长，可能会导致堆积的延迟消息非常多，会带来较大的CPU开销，同时延迟消息的时间会存在误差。 因此，不建议设置延迟时间过长的延迟消息。

消息堆积

解决方法

• 增加消费者，提高消费速度

• 在消费者内开启线程池加快消息处理速度

• 扩大队列容积，提高队列上限，采用惰性队列，在声明队列时设置属性x-queue-mode为lazy，即为惰性队列

惰性队列

• 接受信息后直接存入磁盘而非内存

• 消费者要消费信息时才会从磁盘中读取并加载到内存

• 支持百万条的信息存储

高可用机制

普通集群

• 会在集群的各个节点间共享部分数据，包括：交换机、队列元信息。不包含队列中的消息。

• 当访问集群某节点时，如果队列不在该节点，会从数据所在的节点传递到当前节点并返回

• 队列所在节点宕机，队列中的消息就会消失，所以不推荐这种集群方式

镜像集群

• 本质是主从模式，交换机、队列、队列中的消息会在各个mq的镜像节点之间同步备份

• 创建队列的节点被称为该队列的主节点，备份到的其他节点叫做该队列的镜像节点。

• 一个队列的主节点可能是另一个队列的镜像节点

• 所有操作都是主节点完成，然后同步给镜像节点

• 主节点宕机后，镜像节点会替代成为新的主节点

仲裁队列（3.8+）

• 与镜像队列一样，都是主从模式，支持主从数据同步

• 使用非常简单，没有负责的配置

• 主从同步基于Raft协议，具有强一致性

@Bean public Queue quorumQueue( ){ 
    return QueueBuilder
        .durable(”quorum.queue”) // 持久化 
        .quorum( ) //仲裁队列 
        .build( ); 
}

二、Kafka

消息可靠性

消息丢失的情况

• 生产者发送消息到Brocker丢失，可以设置消息重发次数

• 消息在Brocker中存储丢失，可以发送确认机制acks

• 消费者从Brocker接收消息丢失，可以禁用自动提交偏移量，改为手动提交，包括同步提交、异步提交、同步加异步提交

重复消费消息

• 禁用自动提交偏移量，改为手动提交

• 提交方式，最好为同步+异步提交

• 幂等

消费顺序性

一个topic的数据可能存储的不同的分区中，每个分区都一个按照顺序存储的偏移量，如果消费者关联了多个了分区则不能保证顺序性。可以在发送消息时指定分区号，或者发送消息时按照相同业务设置相同的key来解决

高可用机制

集群模式

Kafka的服务器端由被称为Broker的服务进程构成，即一个Kafka集群由多个Broker组成。 这样如果集群中某一个机器宕机，其他机器上的Broker也依然能够对提供服务

分区备份

• 一个topic又多个分区，每个分区有多个副本，其中有一个leader，其余的是follower，副本储存在不同的broker中。 所有的分区副本的内容都是相同的，如果leader发生故障时，会自动将其中一个follower提升为leader

ISR

• 分区副本分为两类，一个是ISR，与leader副本同步保存数据，一个是普通的副本，异步同步数据

选举规则

1、优先从ISR中选定，因为这个列表中follower的数据是与leader同步的

2、如果ISR列中的follower都不可行，则从其他follower中选取

数据存储和清理

存储机制

1、Kafka中的topic的数据存储在分区上，分区如果文件过大会分段存储segment

2、每个分段都在磁盘上以索引（xxx.index）和文件日志（xxx.log）的形式存储

3、分段的好处是，第一能够减少单个文件内容的大小，查找数据方便，第二能方便Kafka进行日志清理。

清理机制

1、根据信息的保留时间、当消息在Kafka中保存的时间超过了指定的时间，就会触发清理过程，默认为168小时

2、根据topic存储的数据大小，当topic所栈的日志文件大小阈值时，则开始删除最久的消息，需要手动开启，默认为1G

高性能设计

• 消息分区

不受单台服务器的限制，可以处理更多的数据

• 顺序读写

磁盘顺序读写，提升读写效率

• 页缓存

把磁盘中的数据缓存的内存中，把对磁盘的访问变为对内存的访问

• 零拷贝

减少上下文切换及数据拷贝

• 消息压缩

减少磁盘IO和网络IO

• 分批发送

将消息打包批量发送，减少网络开销

三、场景模拟

问题一：RabbitMQ-如何保证消息不丢失

嗯！我们当时MYSQL和Redis的数据双写一致性就是采用RabbitMQ实现同步的，这里面就要求了消息的高可用性，我们要保证消息的不丢失。主要从三个层面考虑 第一个是开启生产者确认机制，确保生产者的消息能到达队列，如果报错可以先记录到日志中，再去修复数据 第二个是开启持久化功能，确保消息未消费前在队列中不会丢失，其中的交换机、队列、和消息都要做持久化 第三个是开启消费者确认机制为auto，由spring确认消息处理成功后完成ack，当然也需要设置一定的重试次数，我们当时设置了3次，如果重试3次还没有收到消息，就将失败后的消息投递到异常交换机，交由人工处理

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

嗯，这个我们还真遇到过，是这样的，我们当时消费者是设置了自动确认机制，当服务还没来得及给MQ确认的时候，服务宕机了，导致服务重启之后，又消费了一次消息。这样就重复消费了 因为我们当时处理的支付（订单|业务唯一标识），它有一个业务的唯一标识，我们再处理消息时，先到数据库查询一下，这个数据是否存在，如果不存在，说明没有处理过，这个时候就可以正常处理这个消息了。如果已经存在这个数据了，就说明消息重复消费了，我们就不需要再消费了

其他方案：redis分布式锁、数据库的锁

问题三：RabbitMQ中死信交换机 ? （RabbitMQ延迟队列有了解过嘛）

嗯！了解过！ 我们当时的xx项目有一个xx业务，需要用到延迟队列，其中就是使用RabbitMQ来实现的。 延迟队列就是用到了死信交换机和TTL（消息存活时间）实现的。 如果消息超时未消费就会变成死信，在RabbitMQ中如果消息成为死信，队列可以绑定一个死信交换机，在死信交换机上可以绑定其他队列，在我们发消息的时候可以按照需求指定TTL的时间，这样就实现了延迟队列的功能了。 我记得RabbitMQ还有一种方式可以实现延迟队列，在RabbitMQ中安装一个死信插件，这样更方便一些，我们只需要在声明交互机的时候，指定这个就是死信交换机，然后在发送消息的时候直接指定超时时间就行了，相对于死信交换机+TTL要省略了一些步骤

问题四：如果有100万消息堆积在MQ , 如何解决 ?

我在实际的开发中，没遇到过这种情况，不过，如果发生了堆积的问题，解决方案也所有很多的 第一:提高消费者的消费能力 ,可以使用多线程消费任务 第二：增加更多消费者，提高消费速度使用工作队列模式, 设置多个消费者消费消费同一个队列中的消息 第三：扩大队列容积，提高堆积上限 可以使用RabbitMQ惰性队列，惰性队列的好处主要是 ①接收到消息后直接存入磁盘而非内存 ②消费者要消费消息时才会从磁盘中读取并加载到内存 ③支持数百万条的消息存储

问题五：RabbitMQ的高可用机制有了解过吗

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

问题六：Kafka是如何保证消息不丢失

嗯，这个保证机制很多，在发送消息到消费者接收消息，在每个阶段都有可能会丢失消息，所以我们解决的话也是从多个方面考虑 第一个是生产者发送消息的时候，可以使用异步回调发送，如果消息发送失败，我们可以通过回调获取失败后的消息信息，可以考虑重试或记录日志，后边再做补偿都是可以的。同时在生产者这边还可以设置消息重试，有的时候是由于网络抖动的原因导致发送不成功，就可以使用重试机制来解决 第二个在broker中消息有可能会丢失，我们可以通过kafka的复制机制来确保消息不丢失，在生产者发送消息的时候，可以设置一个acks，就是确认机制。我们可以设置参数为all，这样的话，当生产者发送消息到了分区之后，不仅仅只在leader分区保存确认，在follwer分区也会保存确认，只有当所有的副本都保存确认以后才算是成功发送了消息，所以，这样设置就很大程度了保证了消息不会在broker丢失 第三个有可能是在消费者端丢失消息，kafka消费消息都是按照offset进行标记消费的，消费者默认是自动按期提交已经消费的偏移量，默认是每隔5s提交一次，如果出现重平衡的情况，可能会重复消费或丢失数据。我们一般都会禁用掉自动提价偏移量，改为手动提交，当消费成功以后再报告给broker消费的位置，这样就可以避免消息丢失和重复消费了

问题七：Kafka中消息的重复消费问题如何解决的

kafka消费消息都是按照offset进行标记消费的，消费者默认是自动按期提交已经消费的偏移量，默认是每隔5s提交一次，如果出现重平衡的情况，可能会重复消费或丢失数据。我们一般都会禁用掉自动提价偏移量，改为手动提交，当消费成功以后再报告给broker消费的位置，这样就可以避免消息丢失和重复消费了 为了消息的幂等，我们也可以设置唯一主键来进行区分，或者是加锁，数据库的锁，或者是redis分布式锁，都能解决幂等的问题

问题八：Kafka是如何保证消费的顺序性

kafka默认存储和消费消息，是不能保证顺序性的，因为一个topic数据可能存储在不同的分区中，每个分区都有一个按照顺序的存储的偏移量，如果消费者关联了多个分区不能保证顺序性 如果有这样的需求的话，我们是可以解决的，把消息都存储同一个分区下就行了，有两种方式都可以进行设置，第一个是发送消息时指定分区号，第二个是发送消息时按照相同的业务设置相同的key，因为默认情况下分区也是通过key的hashcode值来选择分区的，hash值如果一样的话，分区肯定也是一样的

问题九：Kafka的高可用机制有了解过吗

嗯，主要是有两个层面，第一个是集群，第二个是提供了复制机制 kafka集群指的是由多个broker实例组成，即使某一台宕机，也不耽误其他broker继续对外提供服务 复制机制是可以保证kafka的高可用的，一个topic有多个分区，每个分区有多个副本，有一个leader，其余的是follower，副本存储在不同的broker中；所有的分区副本的内容是都是相同的，如果leader发生故障时，会自动将其中一个follower提升为leader，保证了系统的容错性、高可用性

问题十：解释一下复制机制中的ISR

ISR的意思是in-sync replica，就是需要同步复制保存的follower 其中分区副本有很多的follower，分为了两类，一个是ISR，与leader副本同步保存数据，另外一个普通的副本，是异步同步数据，当leader挂掉之后，会优先从ISR副本列表中选取一个作为leader，因为ISR是同步保存数据，数据更加的完整一些，所以优先选择ISR副本列表

问题十一：Kafka数据清理机制了解过吗

嗯，了解过~~ Kafka中topic的数据存储在分区上，分区如果文件过大会分段存储segment 每个分段都在磁盘上以索引(xxxx.index)和日志文件(xxxx.log)的形式存储，这样分段的好处是，第一能够减少单个文件内容的大小，查找数据方便，第二方便kafka进行日志清理。 在kafka中提供了两个日志的清理策略： 第一，根据消息的保留时间，当消息保存的时间超过了指定的时间，就会触发清理，默认是168小时（ 7天） 第二是根据topic存储的数据大小，当topic所占的日志文件大小大于一定的阈值，则开始删除最久的消息。这个默认是关闭的 这两个策略都可以通过kafka的broker中的配置文件进行设置

问题十二：Kafka中实现高性能的设计有了解过吗

Kafka 高性能，是多方面协同的结果，包括宏观架构、分布式存储、ISR 数据同步、以及高效的利用磁盘、操作系统特性等。主要体现有这么几点： 消息分区：不受单台服务器的限制，可以不受限的处理更多的数据 顺序读写：磁盘顺序读写，提升读写效率 页缓存：把磁盘中的数据缓存到内存中，把对磁盘的访问变为对内存的访问 零拷贝：减少上下文切换及数据拷贝 消息压缩：减少磁盘IO和网络IO 分批发送：将消息打包批量发送，减少网络开销
a中提供了两个日志的清理策略： 第一，根据消息的保留时间，当消息保存的时间超过了指定的时间，就会触发清理，默认是168小时（ 7天） 第二是根据topic存储的数据大小，当topic所占的日志文件大小大于一定的阈值，则开始删除最久的消息。这个默认是关闭的 这两个策略都可以通过kafka的broker中的配置文件进行设置

问题十二：Kafka中实现高性能的设计有了解过吗

Kafka 高性能，是多方面协同的结果，包括宏观架构、分布式存储、ISR 数据同步、以及高效的利用磁盘、操作系统特性等。主要体现有这么几点： 消息分区：不受单台服务器的限制，可以不受限的处理更多的数据 顺序读写：磁盘顺序读写，提升读写效率 页缓存：把磁盘中的数据缓存到内存中，把对磁盘的访问变为对内存的访问 零拷贝：减少上下文切换及数据拷贝 消息压缩：减少磁盘IO和网络IO 分批发送：将消息打包批量发送，减少网络开销

四、思维导图