共计 2089 个字符，预计需要花费 6 分钟才能阅读完成。
开篇介绍
大家好，我是 Java 最全面试题库 的提裤姐，明天这篇是中间件面试题系列的第二篇，次要总结了 RocketMQ 相干的面试题；在后续，会沿着第一篇开篇的常识线路始终总结上来，做到日更！如果我能做到百日百更，心愿你也能够跟着百日百刷，一百天养成一个好习惯。
多个 MQ 如何选型？
RabbitMQ
erlang 开发，对音讯沉积的反对并不好，当大量音讯积压的时候，会导致 RabbitMQ 的性能急剧下降。每秒钟能够解决几万到十几万条音讯。
RocketMQ
java 开发，面向 互联网集群化，功能丰富，对在线业务的响应时延做了很多的优化，大多数状况下能够做到毫秒级的响应，每秒钟大略能解决几十万条音讯。
Kafka
Scala 开发，面向 日志，功能丰富，性能最高。当你的业务场景中，每秒钟音讯数量没有那么多的时候，Kafka 的时延反而会比拟高。所以，Kafka 不太适宜在线业务场景。
ActiveMQ
java 开发，简略，稳固，性能不如后面三个。不举荐。
RocketMQ 组成部分有哪些？
Nameserver
无状态，动静列表；这也是和 zookeeper 的重要区别之一。zookeeper 是有状态的。
Producer
音讯生产者，负责发消息到 Broker。
Broker
就是 MQ 自身，负责收发音讯、长久化音讯等。
Consumer
音讯消费者，负责从 Broker 上拉取音讯进行生产，生产完进行 ack。
RocketMQ 生产模式有几种?
集群生产
- 一条音讯只会被同 Group 中的一个 Consumer 生产
- 多个 Group 同时生产一个 Topic 时，每个 Group 都会有一个 Consumer 生产到数据
播送生产
- 音讯将对一个 Consumer Group 下的各个 Consumer 实例都生产一遍。即即便这些 Consumer 属于同一个 Consumer Group，音讯也会被 Consumer Group 中的每个 Consumer 都生产一次。
音讯反复生产如何解决？
呈现起因
失常状况下在 consumer 真正生产完音讯后应该发送 ack，告诉 broker 该音讯已失常生产，从 queue 中剔除
当 ack 因为网络起因无奈发送到 broker，broker 会认为词条音讯没有被生产，尔后会开启音讯重投机制把音讯再次投递到 consumer。
生产模式：在 CLUSTERING 模式下，音讯在 broker 中会保障雷同 group 的 consumer 生产一次，然而针对不同 group 的 consumer 会推送屡次
解决方案
- 数据库表：解决音讯前，应用音讯主键在表中带有束缚的字段中 insert
- Map：单机时能够应用 map 做限度，生产时查问以后音讯 id 是不是曾经存在
- Redis：应用分布式锁。
RocketMQ 如何保障音讯的程序生产？
首先多个 queue 只能保障单个 queue 里的程序，queue 是典型的 FIFO，人造程序。多个 queue 同时生产是无奈相对保障音讯的有序性的。
能够应用同一topic，同一个 QUEUE，发消息的时候一个线程去发送音讯，生产的时候 一个线程去生产一个 queue 里的音讯。
RocketMQ 如何保障音讯不失落？
Producer 端
采取 send() 同步发消息，发送后果是同步感知的。
发送失败后能够重试，设置重试次数。默认 3 次。
Broker 端
批改刷盘策略为同步刷盘。默认状况下是异步刷盘的。
集群部署
Consumer 端
齐全生产失常后在进行手动 ack 确认
RocketMQ 如何实现分布式事务？
1、生产者向 MQ 服务器发送 half 音讯。
2、half 音讯发送胜利后，MQ 服务器返回确认音讯给生产者。
3、生产者开始执行本地事务。
4、依据本地事务执行的后果（UNKNOW、commit、rollback）向 MQ Server 发送提交或回滚音讯。
5、如果错过了（可能因为网络异样、生产者忽然宕机等导致的异常情况）提交 / 回滚音讯，则 MQ 服务器将向同一组中的每个生产者发送回查音讯以获取事务状态。
6、回查生产者本地事物状态。
7、生产者依据本地事务状态发送提交 / 回滚音讯。
8、MQ 服务器将抛弃回滚的音讯，但已提交（进行过二次确认的 half 音讯）的音讯将投递给消费者进行生产。
Half Message：预处理音讯，当 broker 收到此类音讯后，会存储到 RMQ_SYS_TRANS_HALF_TOPIC 的音讯生产队列中
查看事务状态 ：Broker 会开启一个定时工作，生产RMQ_SYS_TRANS_HALF_TOPIC 队列中的音讯，每次执行工作会向音讯发送者确认事务执行状态（提交、回滚、未知），如果是未知，Broker 会定时去回调在从新查看。
超时：如果超过回查次数，默认回滚音讯。
也就是他并未真正进入 Topic 的 queue，而是用了长期 queue 来放所谓的half message，等提交事务后才会真正的将 half message 转移到 topic 下的 queue。
RocketMQ 的音讯沉积如何解决？
1、如果能够增加消费者解决，就增加消费者的数据量
2、如果呈现了 queue，然而消费者多的状况。能够应用筹备一个长期的 topic，同时创立一些 queue，在长期创立一个消费者来把这些音讯转移到 topic 中，让消费者生产。
