1. 项目中你用过消息队列，为什么要用消息队列呢？-----------说白了就是业务场景，顺便考察了面试者的开发项目经验。
2. 如果项目中用了消息队列，会有哪些优点和缺点呢？（结合自己的实际项目把不用消息队列时的耦合扩展成本太高、同步时效太长、并发造成的请求压力……详细介绍下，主要还是项目中的实践）会有哪些项目中遇到的坑，如何避免这些坑？（MQ属于第三方的一个产品，引入系统中当然会增加业务逻辑对该产品的依赖，而且提防这个MQ产品挂掉，提防MQ重复发送，丢失消息，或者由于内部某个线程延时导致消息顺序紊乱，）
3. 你接触的消息队列产品有哪些？它们有什么异同之处？---------RocketMQ、RabbitMQ、activeMQ、kafka……这应该是有不同的吞吐量，说实话不清楚它们具体的异同，我只用过一种。。。。。自己有兴趣自己查吧
4. 如何保证消息队列的高可用？------聊集群相关的应用场景，本来消息队列就是为了大规模数据请求引入的一个第三方产品，单机版的岂不是画蛇添足？
5. 消息队列重复消费情况------对于kafka会有一个消息编号，专业术语offset。消费者按照编号顺序消费队列，并且定时上交消费记录，如果出现消费者宕机则重启以后依照offset编号继续。如果消息队列的offset没有提交消费者已经消费的消息，那么消费者重启后就产生重复消费。
6. 如何保证消息队列的幂等性---------前面挖的坑，既然有了重复消息，那就得去重解决呀。把接收到的消息先查询一下已写入的库，如果不存在那就消费。相当于在数据库写入之前做一个查询验证。
7. 消息队列丢失消息的可能性------------生产者弄丢了（消息MQ开启事务监控MQ是否受到消息但由于同步阻塞原因性能比较低，还有一种属于异步回调机制效率比较高……）、MQ宕机弄丢了（消息队列开启的持久化……创建持久化和发送时的设置持久化缺一不可），消费者消费时弄丢（消息队列的ack机制……）。
8. 消息队列的顺序性如何保证？
9. 消息队列的延时以及过期失效？
10. 消息队列存满了，而有上百万的消息持续积压问题------硬件扩容，多加几台机器消费消息。
11. 如何设计一个消息队列架构呢？说说你的看法？---------把消息队列就看作一个假设在数据库和客户端请求中间的一个中间件，这个中间件接受来自成千上万的客户端请求，然后将请求落地到数据库中。而且实现这个消息队列架构要考虑扩展（加物理机分布式架构），安全（顺序和丢失问题，那就为队列消息编号）……

总结：总体来说面试官的知识深度非常优秀，估计知识面广度也很优秀，表面上是面试一个知识点“消息队列”，实际上穿插考察了实际开发场景中遇到的各种各样的坑问题，这就是典型的“牵一发而动全身”式的考察。