RocketMQ面试题：
RocketMQ中的Topic和普通的Queue队列有什么区别？
queue就是来源于数据结构的FIFO队列(先进先出队列)。而Topic是个抽象的概念，每个Topic底层对应N个queue，而数据也真实存在queue上。
RocketMQ Broker中的消息被消费后会立即删除吗？
不会，每条消息都会持久化到CommitLog中，每个Consumer连接到Broker后会维持消费进度信息，当有消息消费后只是当前Consumer的消费进度(CommitLog的offset)进行了偏移。
追问： 那么消息会堆积吗？什么时候清理过期消息？
4.6版本默认是48小时后删除不再使用的CommitLog文件
- 检查这个文件最后访问时间
- 判断是否大于过期时间
- 指定时间删除，默认凌晨4点
RocketMQ消费模式有几种？
消费模型有Consumer决定，消费维度为Topic
- 集群消费
- 一条消息只会被通Group中的一个Consumer消费
- 多个Group同时消费一个Topic时，每个Group都会有一个Consumer消费到数据
- 广播消费
- 消息将对一个Consumer Group下的各个Consumer实例都消费一遍。即是这些Consumer属于用一个Consumer Group, 消息会被Consumer Group中的每个Consumer都消费一次。
消费消息是push还是pull？
RockerMQ没有真正意义的push,都是pull, 虽然有push类，但实际底层实现采用的是长轮询机制，即拉取方式
- broker端属性 longPollingEnable 标记是否开启长轮询。默认开启
追问： 为什么要主动拉取消息而不使用事件监听方式？
事件驱动方式是建立好长连接，由事件(发送数据)的方式来实时推送。
如果Borker 主动推送消息的话，有可能Push速度快，消费速度慢的情况，那么就会造成消息在consumer端堆积过多，同时又不能被其他consumer消费的情况。而pull的方式可以根据当前自身情况来pull，不会造成过多的压力而造成瓶颈。所以采用了pull的方式。
Broker 如何处理拉取请求的？
Consumer首次请求Broker
- Broker中有是否有符合条件的消息
- 有
- 响应Consumer
- 等待下次Consumer的请求
- 没有
- DefaultMessageStore#ReputMessageService#run方法
- PullRequestHoldService 来Hold连接，每5s执行一次检查pullRequestTable有没有消息，有的话立即推送
- 每1ms检查commitLog中是否有新消息，有的话写入到pullRequestTable
- 当有新消息的时候返回请求
- 挂起consumer的请求，即不断开连接，也不返回数据
- 使用consumer的offset
RocketMQ如何做负载均衡？
通过Topic在多Broker中分布式存储实现。
Producer端
发送端指定message queue发送消息到相应的Broker，来达到写入时的负载均衡。
- 提升写入吞吐量，当多个producer同时向一个broker写入数据时候，性能会下降。
- 消息分布在多Broker中，为负载消费做准备
默认策略是随机选择：
- producer 维护一个index
- 每次取节点会自增
- index向所有broker个数取余
- 自带容错策略
Consumer 端
采用的是平均分配算法来进行负载均衡。
其他负载均衡算法
- 平均分配策略(默认)(AllocateMessagesQueueAveragely)
- 环形分配策略(AllocateMessageQueueAveragelyByCircle)
- 手动配置分配策略(AllocateMessageQueueByConfig)
- 机房分配策略(AllocateMessagesQueueByMachineRoom)
- 一致性哈希分配策略(AllocateMessageQueueConsistentHash)
- 靠近机房策略(AllocateMachineRoomNearby)
追问：当消费负载均衡consumer和queue不对等的时候会发生什么？
Consumer 和 queue会优先平均分配，如果Consumer少于queue的个数，则会存在部分Consumer消费多个queue的情况，如果Consumer等于queue的个数，那就是一个Consumer消费一个queue,如果Consumer个数大于queue的个数，那么会有部分Consumer空余出来，白白的浪费。
消息重复消费（幂等性）
影响消息正常发送和消费的重要原因是网络的不确定性。
- 引起重复消费的原因
- ACK
- 消费模式
正常情况下，在consumer真正消费完消息后，应该发送ack,通知broker该消息已经正常消费，从queue中剔除当ack因为网络原因无法送到broker,borker会认为词条消息没有被消费，此后会开启消息重投机制，把消息再次投递到consumer
在Clustering模式下，消息在broker中会保证相同group的consumer消费一次，但是针对不同Group的Consumer会推送多次
- 解决方案
- 数据库表
- Map
- Redis
处理消息钱，使用消息主键在表中带有约束的字段中插入(通过数据库的唯一索引进行控制)
单机时可以使用Map，消息主键做key，每次消息来了，进行map查询看是否已处理
分布式锁
如何让RocketMQ保证消息的顺序消费
[ 你们线上业务用消息中间件的时候，是否需要保证消息的顺序性？
如果不需要保证消息顺序，为什么不需要？假如我有一个场景要保证消息的顺序，你们应该如何保证？]
首先多个queue只能保证单个queue里的顺序，queue是典型的FIFO,天然顺序。多个queue同时消费是无法绝对保证消息的有序性的。
- 所以总结如下：
同一topic，同一QUEUE,发消息的时候一个线程去发送消息，消费的时候一个线程去消费queue里的消息。
追问：怎么保证消息发到同一个queue？
RocketMQ给我们提供了接口，可以自己实现算法
rocketMQ如何保证消息不丢失？
首先在如下三个部分可能会发生丢失消息的情况：
- producer端
- Broker端
- Consumer端
Producer 端如何保证消息不丢失？
- 采取send()同步发消息，发送结果是同步感知的。
- 发送失败后可以重试，设置重试次数，默认3次。
- 集群部署，比如发送失败了的原因可能是当前Broker宕机了，重试的时候会发送到其他Broker上。
Broker端如何保证消息不丢失？
- 修改刷盘策略为同步刷盘。默认情况下是异步刷盘的。
- 集群部署，主从模式，高可用。
consumer端如何保证消息不丢失？
- 完全消费正常后再进行ACK应答。
RocketMQ的消息堆积如何处理？
「 下游消费体系如果宕机了，导致几百万条消息在消息中间件里积压，此时怎么处理？
你们线上是否遇到过消息积压的生产故障？如果没有遇到过，你考虑一下如何应对？」
首先要找到是什么原因导致的消息堆积，是producer太多了，还是Consumer太少了导致的还是说其它情况，总之先定位问题。
然后看下消息消费速度是否正常，正常的话，可以通过上线更多consumer临时解决消息堆积问题
追问：如果Consumer和Queue不对等，上线了多台也在短时间内无法消费完堆积的消息怎么办？
- 准备一个临时的topic
- queue的数量是堆积的几倍
- queue分布到多Broker中
- 上线一台Consumer做消息的搬运工，把原来的topic中的消息挪到新的topic里，不做业务逻辑处理，只是挪过去
- 上线N台Consumer同时消费临时Topic的数据
- 改BUG
- 恢复原来的Consumer,继续消费之前的Topic
追问：堆积时间过长消息超时了？
RocketMQ中的消息只会在commitLog被删除的时候才会消失，不会超时。也就是说未被消费的消息不会存在超时删除这种情况
追问：堆积的消息会不会进死信队列？
不会，消息在消费失败后会进入重试队列，18此尝试之后仍然失败才会进入死信队列。
RocketMQ在分布式事务支持这块机制的底层原理？
「你们用的是RocketMQ?RocketMQ很大的一个特点是对分布式事务的支持，你说说他在分布式事务支持这块机制的底层原理？」
分布式系统中的事务可以使用TCC(Try、Confirm、Cancel)、2pc来解决分布式系统中的消息原子性
RocketMQ4.3+提供分布式事务功能，通过RocketMQ事务消息能达到分布式事务的最终一致
RocketMQ实现方式：
- Half Message: 预处理消息，当broker 收到此类消息后，会存储到RMQ_SYS_TRANS_HALF_TOPIC 的消费队列中
- 检查事务状态：Broker会开启一个定时任务，消费RMQ_SYS_TRANS_HALF_TOPIC 队列中的消息，每次执行任务会向消息发送者确认事务执行状态(提交、回滚、未知)，如果是为止，Broker会定时去回调再重新检查。
- 超时：如果超时回查次数，默认回滚消息。
也就是他并未真正进入Topic的queue,而是用了临时queue来放所谓的half message,等提交事务后才会真正的讲half message转移到topic下的queue。
高吞吐量下如何优化生产者和消费者的性能？
开发
- 同一group下，多机部署，并行消费
- 单个Consumer提高消费者线程个数
- 批量消费
- 消息批量拉取
- 业务逻辑批量处理
RocketMQ 是如何保证数据的高容错性的？
- 在不开启容错的情况下，轮询队列进行发送，如果失败了，重试的时候过滤失败的Broker
- 如果开启了容错策略，会通过RocketMQ的预测机制来预测一个Broker是否可用
- 如果上次失败的Broker可用那么还是会选择该Broker的队列
- 如果上述情况失败，则随机选择一个进行发送
- 在发送消息的时候会记录一下调用的时间与是否报错，根据时间去预测broker的可用时间
任何一台Broker突然宕机了怎么办？
Broker主从架构以及多副本策略。Master收到消息后会同步给Slave，这样一条消息就不止一份了，Master宕机了还有slave中的消息可用，保证了MQ的可靠性和高可用性。而且RocketMQ4.5.0开始支持Dlegder模式，基于raft的，做到了真正意义的HA。
Broker 把自己的信息注册到哪个NameServer上？
Broker会向所有的NameServer上注册自己信息，而不是某一个，是每一个，全部！