开篇介绍

大家好，我是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中，让消费者生产。