1、说说你们公司线上生产环境用的是什么消息中间件？

  1. rocketMQ、kafka、rabbitMQ都会用到；
  2. RabbitMQ是erlang开发的，对消息堆积的支持不是很友好，当大量的消息积压，会导致rabbitMQ的性能急剧下降，处理消息的量级是十万级的
  3. rocketMQ是Java开发的，阿里巴巴开源项目，面向互联网集群化，功能丰富，对在线业务的响应时延做了很多优化，大多数情况下可以做到毫秒级别的响应，处理消息的量级是几十万级的。
  4. kafka是scala开发的，面向日志功能丰富，性能最高，当你的业务场景中，每秒钟消息数量没有那么多的时候，kafka的时延反而会比较高，所以kafka不太适合在线业务场景。


2、为什么要使用MQ？

  1. 因为项目比较大，做了分布式系统，所有远程服务调用请求都是同步执行的，这会经常出些问题，所以引入了MQ，方便解耦，实现异步操作，有效提高响应时间，削峰，请求量达到顶峰时，后端service可以保持固定的小芬速率，不会被压垮。


3、RocketMQ有哪些角色组成？每个角色的作用和特点是什么？

  1. 有Nameserver命名服务器，负责指引服务端和消费端找到broker，它是无状态的动态列表；
  2. Producer消息生产者，负责发送消息给broker
  3. broker就是MQ本身，负责收发消息，持久化消息等
  4. consumer消息消费者，负责从broker 上拉取消息进行消费 ，消费完进行ack


4、rocketMQ中的Topic和JMS的queue有什么区别？

  1. queue就是来源于数据结构的FIFO队列，而topic是个抽象的概念，每个topic底层对应N个queue，而数据也真实的存在queue上的。


5、rocketMQ broker中的消息被消费后，会立即删除吗？

  1. 不会，每条消息都会持久化到CommitLog中，每个CommitLog连接到broker后会维持消费进度信息，当有消息被消费后，只是当前的consumer的消费进度被更新；


6、那么消息会堆积吗？什么时候清理过期消息？

  1. 4.6版本后默认48小时后会删除不再使用的CommitLog文件。

7、rocketMQ消费模式有几种？

  1. 首先消费模型由consumer决定的，消费维度为topic，有集群消费：一条消息只会被group中的一个consumer消费，同个topic下的多个group，每个group都会有一个consumer消费到数据。广播消费：一个consumer group下的各个consumer实例都消费一遍该消息。


8、消费消息时push还是pull？

  1. rocketMQ没有真正意义的push，都是pull，虽有push类，但实际底层实现采用的时长轮询机制，即为拉取方式。


9、为什么要主动拉取消息而不使用事件监听方式？

  1. 事件驱动方式时建立好的长连接，有事件的方式来实时推送。如果broker主动推送消息的话有可能push速度快，消费速度慢的情况，那么就会造成消息在consumer端堆积过多，同时又不能被其他的consumer消费的情况，而pull的方式可以根据当前自身的情况来pull，不会造成过多的压力而造成瓶颈，所以采取了pull方式。


10、broker如何处理拉取请求的？

  1. consumer首次请求broker，broker先判断消息是否符合消费条件，符合就响应consumer并等待下次的请求。没有就挂起consumer的请求，即不断开连接，也不返回数据，并每隔1毫秒检查commitLog中是否有新消息，，有消息就返回。


11、rocketMQ如何做到负载均衡的？

  1. 通过topic在多个broker中分布式存储实现。
  1. producer端；
    1. 发送端指定message queue发送消息到相应的broker，来达到写入时的负载均衡，来提高写入时的吞吐量。
  2. 默认的策略时随机选择的。
    1. producer维护一个index
    2. 每次消费消息时节点都会自增
    3. index向所有的broker个数取余
    4. 自带容错策略


12、消息重复消费？

  1. 影响消息正常发送和消费的重要原因是网络的不稳定性导致的。
  2. 在clustering模式下，消息在broker中会保证相同的group下的consumer消费一次，但针对不同group下的consumer会推送多次。
  3. 解决方案：处理消息前，使用消息主键在表中带有约束的字段中插入。或者使用分布式锁。


13、如何让rocketMQ保证消息的顺序消费？

  1. 同一个topic同一个queue，发送消息时用一个线程去执行，消费时再用一个线程去执行，这样就能保证消息顺序消费了。


14、怎么保消息发送到同一个queue呢？

  1. rocketMQ给我们提供了MessageQueueSelector接口，可以自己重写里面的接口，实现自己的算法。


15、rocketMQ如何保证消息不丢失？

  1. 在consumer端、broker端、producer端都可能存在消息丢失的风险
  2. producer端的策略：
    1. 采取send方法同步发送消息，发送结果是同步感知的
    2. 发送失败后可以重试，设置重试次数，默认3秒
    3. 通过集群部署提高可用性。
  3. broker端的策略：
    1. 秀爱刷盘策略为同步刷盘。
    2. 通过集群部署提高可用性。
  4. consumer端的策略：
    1. 完全消费正常后再进行手动ack确认。


16、rocketMQ的消息堆积该如何处理？

  1. 首先找到是什么原因导致的消息堆积，是producer太多了，consumer太少了导致的还是其他的原因，总之先定位问题，然后看下消息消费的速度是否正常，正常的话，可以通过上线更多consumer临时解决消息堆积问题。


17、堆积的消息会不会进入死信队列？

  1. 不会，消息在失败后会进入重试队列，重试16次才会进入死信队列。


18、rocketMQ在分布式事务支持这块机制的底层原理？

  1. 分布式系统中的事务可以使用TCC、2PC来解决分布式系统中的消息原子性
  2. RocketMQ4.3+提供了分布式事务功能，通过事务，消息能达到分布式事务的最终一致性。