一、为什么要使用消息队列呢？
其实就是问问你消息队列都有哪些使场景，然后你项具体是什么场景，说说你在这个场景消息队列什么？
试官问你这个问题，期望的个回答是说，你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不MQ可能会很烦，但是你现在了MQ之后带给了你很多的好处。
先说下消息队列常见的使场景吧，其实场景有很多，但是较核的有个：解耦、异步、削峰。
l解耦：引入消息队列之前，下单完成之后，需要订单服务去调用库存服务减库存，调用营销服务加营销数据……引入消息队列之后，可以把订单完成的消息丢进队列里，下游服务自己去调用就行了，这样就完成了订单服务和其它服务的解耦合。
l异步：订单支付之后，我们要扣减库存、增加积分、发送消息等等，这样一来这个链路就长了，链路一长，响应时间就变长了。引入消息队列，除了更新订单状态，其它的都可以异步去做，这样一来就来，就能降低响应时间。
l削峰：消息队列合一用来削峰，例如秒杀系统，平时流量很低，但是要做秒杀活动，秒杀的时候流量疯狂怼进来，我们的服务器，Redis，MySQL各自的承受能力都不一样，直接全部流量照单全收肯定有问题啊，严重点可能直接打挂了。我们可以把请求扔到队列里面，只放出我们服务能处理的流量，这样就能抗住短时间的大流量了。
二、为什么要选择RocketMQ?
在主流的MQ中，有很多，比如ActiveMQ、RabbitMQ、RocketMQ、Kafka等，选择中间件的可以从这些维度来考虑：可靠性，性能，功能，可运维行，可拓展性，社区活跃度。
lRabbitMQ：
优点：轻量，迅捷，容易部署和使用，拥有灵活的路由配置
缺点：性能和吞吐量不太理想，不宜进行二次开发
lRocketMQ：
优点：性能好，高吞吐量，稳定可靠，有活跃的中文社区
缺点：兼容性上不是太好
lKafka：
优点：拥有强大的性能及吞吐量，兼容性很好
缺点：由于“攒一波再处理”导致延迟比较高
三、RocketMQ有什么优缺点？
lRocketMQ优点：
单机吞吐量：十万级
可用性：非常高，分布式架构
消息可靠性：经过参数优化配置，消息可以做到0丢失
功能支持：MQ功能较为完善，还是分布式的，扩展性好
支持10亿级别的消息堆积，不会因为堆积导致性能下降
源码是Java，方便结合公司自己的业务二次开发天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况RoketMQ在稳定性上可能更值得信赖，这些业务场景在阿里双11已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择RocketMQ
lRocketMQ缺点：
支持的客户端语言不多，目前是Java及c++，其中c++不成熟
没有在MQ核心中去实现JMS等接口，有些系统要迁移需要修改大量代码
四、消息的消费模式了解吗？
消息消费模式有两种：Clustering（集群消费）和Broadcasting（广播消费）。
默认情况下就是集群消费，这种模式下一个消费者组共同消费一个主题的多个队列，一个队列只会被一个消费者消费，如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。而广播消费消息会发给消费者组中的每一个消费者进行消费。
五、RocketMQ有哪几种部署类型？分别有什么特点？
RocketMQ有4种部署类型
1）单Master
单机模式,即只有一个Broker,如果Broker宕机了,会导致RocketMQ服务不可用,不推荐使用
2）多Master模式
组成一个集群,集群每个节点都是Master节点,配置简单,性能也是最高,某节点宕机重启不会影响RocketMQ服务
缺点：如果某个节点宕机了,会导致该节点存在未被消费的消息在节点恢复之前不能被消费
）多Master多Slave模式，异步复制
每个Master配置一个Slave,多对Master-Slave,Master与Slave消息采用异步复制方式,主从消息一致只会有毫秒级的延迟
优点是弥补了多Master模式（无slave）下节点宕机后再恢复前不可订阅的问题。在Master宕机后,消费者还可以从Slave节点进行消费。采用异步模式复制，提升了一定的吞吐量。总结一句就是，采用多Master多Slave模式，异步复制模式进行部署，系统将会有较低的延迟和较高的吞吐量
缺点就是如果Master宕机,磁盘损坏的情况下,如果没有及时将消息复制到Slave,会导致有少量消息丢失
4）多Master多Slave模式，同步双写
与多Master多Slave模式，异步复制方式基本一致，唯一不同的是消息复制采用同步方式，只有master和slave都写成功以后，才会向客户端返回成功
优点：数据与服务都无单点，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高
缺点就是会降低消息写入的效率，并影响系统的吞吐量
实际部署中，一般会根据业务场景的所需要的性能和消息可靠性等方面来选择后两种
六、RocketMq的消息是有序的吗？
一个topic下有多个queue，为了保证发送有序，rocketmq提供了MessageQueueSelector队列选择机制
1.可使用hash取模法,让同一个订单发送到同一个queue中，再使用同步发送，只有消息A发送成功，再发送消息B
2.rocketmq的topic内的队列机制，可以保证存储满足FIFO，剩下的只需要消费者顺序消费即可
.rocketmq仅保证顺序发送，顺序消费由消费者业务保证
七、RocketMQ有哪些角色组成，每个角色作用和特点是什么？
Nameserver无状态，动态列表；这也是和zookeeper的重要区别之一。zookeeper是有状态的。
Producer消息生产者，负责发消息到Broker。
Broker就是MQ本身，负责收发消息、持久化消息等。
Consumer消息消费者，负责从Broker上拉取消息进行消费，消费完进行ack。
八、RocketMQBroker中的消息被消费后会立即删除吗？
不会，每条消息都会持久化到CommitLog中，每个Consumer连接到Broker后会维持消费进度信息，当有消息消费后只是当前Consumer的消费进度（CommitLog的offset）更新了。
追问：那么消息会堆积吗？什么时候清理过期消息？
l4.6版本默认48小时后会删除不再使用的CommitLog文件
l检查这个文件最后访问时间
l判断是否大于过期时间
l指定时间删除，默认凌晨4点
九、RocketMQ中的Topic和JMS得queue有什么区别？
queue就是来源于数据结构的FIFO队列。而Topic是个抽象的概念，每个Topic底层对应N个queue，而数据也真实存在queue上的。
十、RocketMq延迟消息？如何实现的？
RocketMQ支持定时消息，但是不支持任意时间精度，仅支持特定的level，例如定时5s，10s，1m等。其中，level=0级表示不延时，level=1表示1级延时，level=2表示2级延时。默认的配置是messageDelayLevel=1s5s10s0s1m2mm4m5m6m7m8m9m10m20m0m1h2h。
Messagemsg=newMessage(topic,tags,keys,body);
msg.setDelayTimeLevel();