什么场景下你们用MQ
主要还是一些异步通信的场景吧，我们会用他去做系统解耦，比如我最近负责的这个项目里面的订单模块，它支付完成就需要告知下游的配送中心，去创建一条待配送的数据，这种又不要求强一致性，就是一个很好的MQ使用场景。
MQ有哪几种交换机模式，你们用的哪种
我了解到的有4种，一个是默认交换机，给基本队列和工作队列使用的；还有FanoutExchange广播模式，DirectExchange定向路由模式和TopicExchange话题路由模式，我们项目用的Topic模式。
怎么确保消息不丢失
面试官这个问题我们生产还真遇到过，后面也去了解了一下，我们用的是RabbitMQ，它本身是有生产者确认机制、MQ消息持久化和消费者确认机制三个保证的，如果面试官还想再了解深一点我可以再展开一下。
生产者确认机制就是给每个消息指定一个唯一ID，当消息发送到MQ之后会有一个结果返回给发送者，如果是消息未投递到交换机就返回publish-confirm的nack，如果到了交换机但是没到队列就返回publish-return的ack，从而保证消息是百分百存储到消息队列中。
消息持久化就比较简单，因为RabbitMQ本身就做了队列持久化、消息持久化、交换机持久化，所以它本身是没有问题的。
消费者确认机制是通过消费者回执来确认消费者是否成功处理消息的：消费者获取消息后，应该向RabbitMQ发送ACK回执，表明自己已经处理消息。有三种配置方式：
•manual：手动ack，需要在业务代码结束后，调用api发送ack。
•auto：自动ack，由spring监测listener代码是否出现异常，没有异常返回ack；抛出异常返回nack
•none：关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除
我们项目中采用的事auto+重试次数来配置解决的。
了解过MQ的延迟消息吗
了解过的面试官，他是可以通过基于消息的延迟发送或者基于消息队列的延迟消费，前者就是给消息设置一下TTL时间，后者我们是通过安装一个DelayExchange的插件来解决的。
过去我们是在一些取消超时订单的业务场景下有实施过这个解决方案。
怎么解决消息挤压呢
可以通过
- 增加更多消费者，提高消费速度。也就是我们之前说的work queue模式（或者多线程同理）
- 扩大队列容积，提高堆积上限
