面试题储备-MQ篇 1-说说你对RabbitMQ的理解
嗯，rabbitMq是一种开源的消息中间件，采用AMQP进行消息传递
问：AMQP是什么能讲讲吗
- AMQP是一种通用的高级消息通讯协议，不只存在于rabbitMq中
- rabbitMq中的AMQP：
rabbitMq里会设置交换器和队列的对应关系，生产消息里会绑定路由key，交换器通过路由key找到对应的消息队列并进入队列，找到对应的消费者发送消息
（rabbitMq就是通过AMQP协议实现生产者和消费者之间的消息传递）
问：rabbitMq一共有几种交换机
1. 直连交换机-通过topic精准匹配获取绑定的队列
2. 主题交换机-通过topic模糊匹配消息获取绑定队列
3. 扇出交换机(广播机制)，将消息分发给所有绑定的队列，场景一般是通用消息，比如订单完成消息，在我们项目中消费等级、任务中心、Nps问卷系统等多个模块都需要监听，为了不将代码写在一起，就会通过配置多次消费完成消息分别处理
问：rabbitMq 如何保证消息不丢失
我知道一般的消息丢失场景，有可能是网络波动导致发送和拉取消息的时候消息丢失；还有可能是因为服务器宕机，导致在mq客户端或者在消费者机器上的消息丢失
对上面几种情况，rabbitMq
1）对生产者，使用confirm消息确认机制
生产者发送消息后，会等待mq服务确认消息已经被交换机投递到了绑定的队列，如果该交换机没有绑定队列，或者在broker中出现消息丢失，也会返回没有投递成功的消息，让生产者重新发送消息
2）对rabbitMq服务，使用消息持久化机制
会将消息存储到磁盘中，避免服务器宕机导致的消息丢失
3）对消费者，使用ACK事务机制
和生产者的消息重试机制差不多，消费者在消费成功后给broker返回消费成功，broker再删除消息；如果消费者出现异常或者宕机，消息就会一直存在队列中，造成消息积压
简答：
消息丢失一般是因为网络波动导致消息在传输过程中丢失或者服务器宕机导致处理时候的消息丢失，针对不同场景有不同的解决方法。
生产者在发送消息后会等待broker返回处理成功(ack),如果返回处理不成功，则重新发送消息；broker接到消息后将消息存在磁盘里，防止因为宕机导致的消息丢失；消费者处理消息成功给broker返回处理成功ack，broker接收到成功的返回后将队列中的消息删除，否则让消息一直积压在队列中，防止消费者端的消息丢失
问： rabbitMq如何保证消息不被重复消费
可以通过数据库状态字段判断比如订单id判断这个订单有没有被处理过，处理过不再处理，这种只适用于小量的消息。
如果消息并发量高，频繁请求数据库会导致数据库压力大，可以使用缓存加锁，比如key为订单id+用户id，过期时间设置5秒，防止因为网络波动导致一条消息发多次的情况。
还有一种情况，比如涉及到一些核心场景，比如接收订单消息给用户发豆发券的场景，这种场景为了保证不会因为重复消费导致超发，不会进行消息的积压和重试，直接在数据库里用一个处理状态字段来判断是否接到消息以及处理的结果，之后会另起一个数据补偿定时任务，查询表里需要补偿的数据，根据订单号查询订单信息，进行数据补偿。
问： rabbitMq如何解决消息积压问题
一般导致消息积压的原因，要么是消息并发量太大，消费者处理不过来，要么是消费者出现问题，消费速度慢或者异常无法消费消息。
一般如果是消息过多，mq进行消息限流，如果是消费者消费速度慢，可以用批量处理代替单条处理、或者使用异步部分处理逻辑的方法，增加消费速度；还有一些全量消息需要进行条件过滤，需要在消费之前先对消息进行过滤和转发，也可以避免出现大规模积压的情况。
举个我们项目里的例子，消息中心接收订单消息，这个消息是中台发送的全量订单消息，日常并发量十几万，其实我们需要的只是其中关于我们系统的一小部分，我们处理就是先通过消息过滤器过滤我们系统的订单，再根据不同业务线转发给不同的topic，可以根据每个mq的消息量和业务逻辑进行不同的限流和消费配置，对于并发量大的业务进行限流+批量消费。