Java消息中间件篇：RabbitMQ（保证消息不丢失，重复消费问题，延迟队列，消息堆积，高可用机制），Kafka（保证消息不丢失，重复消费问题，消费的顺序性，高可用机制，数据清理机制，高性能设计）_java rabbitmq 延时消息重复消费

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

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

1.生产者确认机制

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

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

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

2.消息持久化

MQ默认是内存存储消息，开启持久化功能可以确保缓存在MQ中的消息不丢失。

①交换机持久化
②队列持久化
③消息持久化，SpringAMQP中的的消息默认是持久的，可以通过MessageProperties中的DeliveryMode来指定

3.消费者确认

RabbitMQ支持消费者确认机制，即:消费者处理消息后可以向MQ发送ack回执，MQ收到ack回执后才会删除该消息。

而SpringAMQP则允许配置三种确认模式:

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

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

2.RabbitMQ消息的重复消费问题如何解决的？

1. 保证消息的幂等性：在消费者端实现幂等性，即消费者可以多次接收到同一条消息，但对于相同的消息只会执行一次相同的操作，使用分布式锁、数据库锁（悲观锁、乐观锁)。
2. 设置消息的唯一标识符：在消息的属性中设置一个唯一标识符，并在消费者端维护一个已消费消息的标识符列表，以避免重复消费。
3. 使用acknowledgement机制：在消费者端通过手动确认（acknowledgement）的方式，告诉RabbitMQ已经处理完某条消息，然后RabbitMQ将该消息标记为已消费，不再推送给消费者。同时可以设置消息的过期时间，如果消费者在规定时间内没有确认消息处理完成，RabbitMQ会将消息重新推送给其他的消费者。
4. 使用消息的过期时间：在发布消息时设置消息的过期时间，当消息过期后，RabbitMQ会自动将消息从队列中移除，不再推送给消费者。
5. 延时队列：使用延时队列实现消息的延迟消费。将消息发送到一个延时队列，然后在延时队列中消费消息，并在一定的延迟时间后将消息转发到实际的消费队列进行消费。

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

①我们当时一个什么业务使用到了延迟队列(超时订单、限时优惠、定时发布…)
②其中延迟队列就用到了死信交换机和TTL（消息存活时间)实现的
③消息超时未消费就会变成死信（死信的其他情况:拒绝被消费，队列满了)

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

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

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

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

1.死信交换机

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

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

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

2.TTL

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

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

3.延迟队列插件

DelayExchange插件，需要安装在RabbitMQ中
RabbitMQ有一个官方的插件社区，地址为: https:/www.rabbitmq.com/community-plugins.html

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

4.RabbitMQ如果有100万消息堆积在MQ，如何解决?(消息堆积怎么解决)

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

1.解决消息堆积有三种种思路:

①增加更多消费者，提高消费速度
②在消费者内开启线程池加快消息处理速度
③扩大队列容积，提高堆积上限，采用惰性队列

2.惰性队列

惰性队列的特征如下:
①接收到消息后直接存入磁盘而非内存
②消费者要消费消息时才会从磁盘中读取并加载到内存
③支持数百万条的消息存储

在声明队列的时候可以设置属性x-queue-mode为lazy，即为惰性队列
基于磁盘存储，消息上限高
性能比较稳定，但基于磁盘存储，受限于磁盘IO，时效性会降低

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

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

那出现丢数据怎么解决呢?

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

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

1.普通集群

普通集群，或者叫标准集群(classic cluster)，具备下列特征:

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

2.镜像集群

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

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

3.仲裁队列

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

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

6.Kafka是如何保证消息不丢失？

使用Kafka在消息的收发过程都会出现消息丢失，Kafka分别给出了解决方案：
①生产者发送消息到Brocker丢失
②消息在Brocker中存储丢失
③消费者从Brocker接收消息丢失

1.生产者发送消息到Brocker丢失

设置异步发送：

消息重试：

2.消息在Brocker中存储丢失

发送确认机制acks:

3.消费者从Brocker接收消息丢失

①Kafka 中的分区机制指的是将每个主题划分成多个分区(Partition)
②topic分区中消息只能由消费者组中的唯一一个消费者处理，不同的分区分配给不同的消费者(同一个消费者组)

7.Kafka中消息的重复消费问题如何解决的？

①关闭自动提交偏移量，开启手动提交偏移量
②提交方式，最好是同步+异步提交
③幂等方案

8.Kafka是如何保证消费的顺序性

应用场景:

• 即时消息中的单对单聊天和群聊，保证发送方消息发送顺序与接收方的顺序一致
• 充值转账两个渠道在同一个时间进行余额变更，短信通知必须要有顺序

问题原因:
一个topic的数据可能存储在不同的分区中，每个分区都有一个按照顺序的存储的偏移量，如果消费者关联了多个分区不能保证顺序性。

解决方案:

• 发送消息时指定分区号
• 发送消息时按照相同的业务设置相同的key

9.Kafka的高可用机制有了解过吗？

1.集群模式

①Kafka的服务器端由被称为Broker的服务进程构成，即一个Kafka集群由多个Broke组成
②这样如果集群中某一台机器宕机，其他机器上的Broker也依然能够对外提供服务。这其实就是Kafka 提供高可用的手段之一。

2.分区备份机制

一个topic有多个分区，每个分区有多个副本，有一个leader，其余的是follower，副本存储在不同的broker中所有的分区副本的内容是都是相同的，如果leader发生故障时，会自动将其中一个follower提升为leader，保证了系统的容错性、高可用性

某一个topic中有三个分区PO、P1、P2

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

3.解释一下复制机制中的ISR

ISR (in-sync replica）需要同步复制保存的follower

分区副本分为了两类，一个是ISR，与leader副本同步保存数据，另外一个普通的副本，是异步同步数据，当leader挂掉之后，会优先从ISR副本列表中选取一个作为leader

如果leader失效后，需要选出新的leader，选举的原则如下:
第一:选举时优先从ISR中选定，因为这个列表中follower的数据是与leader同步的
第二:如果ISR列表中的follower都不行了，就只能从其他follower中选取

10.Kafka数据清理机制了解过吗？

Kafka存储结构：
①Kafka中topic的数据存储在分区上，分区如果文件过大会分段存储segment
②每个分段都在磁盘上以索引(xxxx.index)和日志文件(xxxx.log)的形式存储
③分段的好处是，第一能够减少单个文件内容的大小，查找数据方便，第二方便kafka进行日志清理。

日志的清理策略有两个:
①根据消息的保留时间，当消息保存的时间超过了指定的时间，就会触发清理，默认是168小时（7天)
②根据topic存储的数据大小，当topic所占的日志文件大小大于一定的阈值，则开始删除最久的消息。（默认关闭)

11.Kafka中实现高性能的设计有了解过吗？

Kafka高性能，是多方面协同的结果，包括宏观架构、分布式存储、ISR数据同步、以及高效的利用磁盘、操作系统特性等。主要体现有这么几点:

①消息分区:不受单台服务器的限制，可以不受限的处理更多的数据
②顺序读写:磁盘顺序读写，提升读写效率
③页缓存:把磁盘中的数据缓存到内存中，把对磁盘的访问变为对内存的访问
④零拷贝:减少上下文切换及数据拷贝
⑤消息压缩:减少磁盘IO和网络IO
⑥分批发送:将消息打包批量发送，减少网络开销