1.MQ选型

1.MQ如何选型？ RabbitMQ、RocketMQ、Kafka 选型的正确姿势

开源，横向扩展，性能，

kafka 异步，批量。kafka 发消息不是立即发送，是等一等批量发送，延迟性比较高。

系统中为什么使用MQ：异步，削峰，解耦 

列举出三个业务场景： 

缺点：

保证消息队列的可用性。

系统复杂性增加，

如何保证数据的幂等性：重复消费

2.主题 （Topic）和 队列 （broker ，partition）有什么区别

3.如何保证消息不丢失

怎样去发现消息丢失的问题，怎么监控。

生产者：请求确认机制，保证我的消息，发送到 broker的时候，你存储了给我一个回复。

同步刷盘：异步刷盘，同步刷盘，多份，一个broker宕机了，也能保证消息不丢失。

消费者 关闭自动提交，消费完再发送 Act消息。

4.消息挤压的问题

上线前 压测，发现 消息挤压的问题。

生产者 和 消费者 的问题。

发送端性能优化：要么 发送端变快了

消费端性能优化：要么消费端变慢了

1.监控功能，

2.扩 消费实例，对一些 不重要的功能降级，提升服务器消费的能力（1. 修改参数批量拉取，并行度消费 ，在 晚上 业务不繁忙的时候 改为 多线程 异步处理  2. 增加实例， 3.业务跳过非重要的消息  4.优化每条消息的消费过程）。

3.优化代码,锁，死锁的问题。

4.使用异步模式 提升性能

5.RabbitMQ 部署， 单机，还是 集群（普通集群，镜像集群模式）

MQ的 高可用是怎么保证的：

管理控制台，设置 镜像集群模式，如果某台 机器 宕机，其他机器上有完整的数据。

6.如何保证消息的顺序性：

单一生产者，串行发生，同一个 broker，同一 consumer， 通过 ...保证消息在同一个 broker

消息重试，因为 2 阻塞在一个地方。消息错乱。

一次性就消费一条。

性能热点，不需要保证消费的消息要分开。

7.重复消费的问题，怎么保证 幂等性

1.每条消费的消息 都在 MySQL中 保存，发送时候 生成唯一ID 作为唯一主键。

2. 唯一ID，状态机