一、RocketMq优点？
1）支持顺序性，可以做到局部有序，在单线程内使用该生产者发送的消息按照发送的顺序到达服务器并存储，并按照相同顺序被消费，但前提是这些消息发往同一服务器的同一个分区
2）采取长轮询+PULL消费消息，配合合理的参数设置来获得更高的响应时间，实时性不低于PUSH方式
3）提供了丰富的拉取模式
4）支持10亿级别的消息堆积，不会因为堆积导致性能下降
5）高效的订阅者水平扩展机制
二、RocketMq如何保证高可用的？
1）master和slave 配合，master 支持读、写，slave 只读，producer 只能和 master 连接写入消息，consumer 可以连接 master 和 slave。
2）当 master 不可用或者繁忙时，consumer 会被自动切换到 slave 读。即使 master 出现故障，consumer 仍然可以从 slave 读消息，不受影响。
3）创建 topic 时，把 message queue 创建在多个 broker 组上（brokerName 一样，brokerId 不同），当一个 broker 组的 master 不可用后，其他组的 master 仍然可以用，producer 可以继续发消息。
三、RocketMq消费者消费模式有几种？
1. 集群消费
一条消息只会投递到一个 Consumer Group 下面的一个实例。
2. 广播消费
消息将对一个Consumer Group 下的各个 Consumer 实例都投递一遍。即使这些 Consumer 属于同一个Consumer Group ，消息也会被 Consumer Group 中的每个 Consumer 都消费一次。
四、RocketMq的消息是有序的吗？
一个topic下有多个queue，为了保证发送有序，rocketmq提供了MessageQueueSelector队列选择机制
1）可使用hash取模法,让同一个订单发送到同一个queue中，再使用同步发送，只有消息A发送成功，再发送消息B
2）rocketmq的topic内的队列机制，可以保证存储满足FIFO，剩下的只需要消费者顺序消费即可
3）rocketmq仅保证顺序发送，顺序消费由消费者业务保证
五、RocketMq事务消息的实现机制？
RocketMQ第一阶段发送Prepared消息时，会拿到消息的地址
RocketMQ第二阶段执行本地事物，第三阶段通过第一阶段拿到的地址去访问消息，并修改消息的状态。
RocketMQ会定期扫描消息集群中的事物消息，如果发现了Prepared消息，它会向消息发送端(生产者)确认，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。
六、RocketMq会有重复消费的问题吗？如何解决？
在网络中断的情况下可能出现，需要保证消费端处理消息的业务逻辑保持幂等性
七、RocketMq延迟消息？如何实现的？
RocketMQ 支持定时消息，但是不支持任意时间精度，仅支持特定的 level，例如定时 5s， 10s， 1m 等。其中，level=0 级表示不延时，level=1 表示 1 级延时，level=2 表示 2 级延时。默认的配置是messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h。
Message msg = new Message(topic, tags, keys, body);
msg.setDelayTimeLevel(3);
八、RocketMq是推模型还是拉模型？
rocketmq不管是推模式还是拉模式底层都是拉模式，推模式也是在拉模式上做了一层封装.
消息存储在broker中，通过topic和tags区分消息队列。producer在发送消息时不关心consumer对应的topic和tags，只将消息发送到对应broker的对应topic和tags中。
推模式中broker则需要知道哪些consumer拥有哪些topic和tags，但在consumer重启或更换topic时，broker无法及时获取信息，可能将消息推送到旧的consumer中。对应consumer主动获取topic，这样确保每次主动获取时他对应的topic信息都是最新的。
九、RocketMq的负载均衡？
1）生产者负载均衡
从MessageQueue列表中随机选择一个（默认策略），通过自增随机数对列表大小取余获取位置信息，但获得的MessageQueue所在的集群不能是上次的失败集群。
集群超时容忍策略，先随机选择一个MessageQueue，如果因为超时等异常发送失败，会优先选择该broker集群下其他的messeagequeue进行发送。如果没有找到则从之前发送失败broker集群中选择一个MessageQueue进行发送，如果还没有找到则使用默认策略。
2）消费者负载均衡
1）平均分配策略(默认)(AllocateMessageQueueAveragely)
2）环形分配策略(AllocateMessageQueueAveragelyByCircle)
3）手动配置分配策略(AllocateMessageQueueByConfig)
4）机房分配策略(AllocateMessageQueueByMachineRoom)
5）一致性哈希分配策略(AllocateMessageQueueConsistentHash)
6）靠近机房策略(AllocateMachineRoomNearby)
十、RocketMq消息积压
1）提高消费并行读
同一个Consumer Group下，通过增加Consumer实例的数量来提高并行度，超过订阅队列数的Consumer实例无效。
提高单个Consumer的消费并行线程，通过修改Consumer的consumerThreadMin和consumerThreadMax来设置线程数
2）批量方式消费
通过设置Consumer的consumerMessageBathMaxSize这个参数，默认是1，一次只消费一条消息，例如设置N，那么每次消费的消息条数小于等于N
3）丢弃非重要消息
当消息发生堆积时，如果消费速度跟不上消费速度，可以选择丢弃一些不重要的消息
4）优化消息消费的过程
对于消费消息的过程一般包括业务处理以及跟数据库的交互，可以试着通过一些其他的方法优化消费的逻辑。
临时解决方案：
新建一个topic，写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的queue中。临时用一部分机器来部署consumer，每一批consumer消费一个临时queue的数据。等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息
