1、消息队列的作用（使用场景）：

• 解耦：解决代码之中跨系统业务调用的耦合性。发送发只管消息正常发出，消费放只管消费关心的主题。

• 异步：消息发送成功后即可进行后续操作，无需等待消费方处理。

• 削峰：通过控制MQ每秒的写入量和消费端每秒的消费量，避免瞬时流量打垮后端服务。

2、消息队列的缺点：

• 由于引入新的组件，导致意外发生的可能性变大，使整个系统的可用性降低了。

• 使系统的复杂度变高。带来了诸如消息丢失，消息重复消费以及消息顺序性等一系列的问题。

3、常用的消息队列以及他们各自的优缺点：

4、消息队列的高可用（HA）：

1.  RabbitMQ：使用主从形式来保证高可用。

    RabbitMQ支持下列启动模式：

1. 单机模式：单节点启动

2. 普通集群模式：多台机器，每台机器启动一个实例组成集群。由于queue只会放在其中一个节点中，所以消费时如果不是连接到指定queue所在的实例，会发生数据同步。

3. 镜像集群模式：多台机器，每台机器启动一个实例组成集群。每台机器对外来说都是一模一样的，每个实例都包含你所创建的queue，同时你向queue发送的消息将自动同步到各个实例的对应queue中。

2. Kafka：天然的分布式。多台机器，每台机器启动一个实例，并且按照topic的分片数量将这些机器进行分组。每组包含一个leader节点以及其余的replica节点（统称为follower）。写的时候，leader 会负责把数据同步到所有 follower 上去，读的时候就直接读 leader 上的数据即可。leader宕机时会从follower中重新选举出一个leader。

5、消息的幂等性问题：

    常见的从业务上保证幂等性手段有如下这些：

1. 数据入库前先进行查询，如果存在则不继续插入改为更新。

2. 让发送方添加一个唯一的key，收到消息后检查key有没有存在（可以放入redis）。

3. 数据库使用唯一索引。
   

6、消息丢失的处理：

    消息可能在以下三个环节丢失：

1. 生产端：

1. RabbitMQ有两种方式可以防止：

1. 自带的事务机制

2. 2.confirm机制

2. Kafka的生产端可以认为不会丢失

2. MQ端：

1. RabbitMQ开启持久化

2. Kafka

1. 设置 topic replication.factor > 1 （每个partition至少有两个replica）

2. 设置 min.insync.replicas > 1 （每个leader至少有一个follower存活）

3. 设置 producer acks = all （每条数据写入所有的replica才算成功）

4. 设置 producer retries = max （无限重试次数）

   
   

3. 消费端：

1. RabbitMQ：关闭自动ack，处理完毕时手动发出ack

2. Kafka：关闭自动提交offset，处理完毕时手动提交offset，同时做好幂等性检查

7、消息顺序消费：

1. RabbitMQ：在 MQ 里面创建多个 queue，同一规则的数据（对唯一标识进行 hash），有顺序的放入 MQ 的 queue 里面，消费者只取一个 queue 里面获取数据消费，这样执行的顺序是有序的。或者还是只有一个 queue 但是对应一个消费者，然后这个消费者内部用内存队列做排队，然后分发给底层不同的 worker 来处理。

2. Kafka：在消费端使用内存队列，队列里的数据使用 hash 进行分发，每个线程对应一个队列，这样可以保证数据的顺序。

3. RocketMQ：生产者中把 唯一ID 进行取模，把相同模的数据放到 messagequeue 里面，消费者消费同一个 messagequeue，只要消费者这边有序消费，那么可以保证数据被顺序消费。

4. ActiveMQ：指定 JMSXGroupID，消费者会消费指定的 JMSXGroupID。