RabbitMQ中的一些角色:

  • publisher：生产者
  • consumer：消费者
  • exchange个：交换机，负责消息路由
  • queue：队列，存储消息
  • virtualHost：虚拟主机，隔离不同租户的exchange、queue、消息的隔离

2.1消息中间件的区别？

image.png

2.2 为什么要使用MQ？

因为项目比较大，做了分布式系统，所有远程服务调用请求都是同步执行经常出问题，所以引入了mq
image.png

2.3 RocketMQ由哪些角色组成，每个角色作用和特点是什么？

生产者（Producer）：负责产生消息，生产者向消息服务器发送由业务应用程序系统生成的消息。
消费者（Consumer）：负责消费消息，消费者从消息服务器拉取信息并将其输入用户应用程序。
消息服务器（Broker）：是消息存储中心，主要作用是接收来自 Producer 的消息并存储， Consumer 从这里取得消息。
名称服务器（NameServer）：用来保存 Broker 相关 Topic 等元信息并给 Producer ，提供 Consumer 查找 Broker 信息。

2.4 RocketMQ消费模式有几种？

消费模型由Consumer决定，消费维度为Topic。
集群消费
1.一条消息只会被同Group中的一个Consumer消费
2.多个Group同时消费一个Topic时，每个Group都会有一个Consumer消费到数据
广播消费
消息将对一 个Consumer Group 下的各个 Consumer 实例都消费一遍。即即使这些 Consumer 属于同一个Consumer Group ，消息也会被 Consumer Group 中的每个 Consumer 都消费一次。

2.5 RocketMQ如何做负载均衡？

通过Topic在多Broker中分布式存储实现。
(1)producer端
发送端指定message queue发送消息到相应的broker，来达到写入时的负载均衡
l 提升写入吞吐量，当多个producer同时向一个broker写入数据的时候，性能会下降
l 消息分布在多broker中，为负载消费做准备
默认策略是随机选择：
· producer维护一个index
· 每次取节点会自增
· index向所有broker个数取余
· 自带容错策略
其他实现：
· SelectMessageQueueByHash
· hash的是传入的args
· SelectMessageQueueByRandom
· SelectMessageQueueByMachineRoom 没有实现
也可以自定义实现MessageQueueSelector接口中的select方法
MessageQueue select(final List mqs, final Message msg, final Object arg);
(2) consumer端
采用的是平均分配算法来进行负载均衡。
其他负载均衡算法
平均分配策略(默认)(AllocateMessageQueueAveragely)
环形分配策略(AllocateMessageQueueAveragelyByCircle)
手动配置分配策略(AllocateMessageQueueByConfig)
机房分配策略(AllocateMessageQueueByMachineRoom)
一致性哈希分配策略(AllocateMessageQueueConsistentHash)
靠近机房策略(AllocateMachineRoomNearby)
追问：当消费负载均衡consumer和queue不对等的时候会发生什么？
Consumer和queue会优先平均分配，如果Consumer少于queue的个数，则会存在部分Consumer消费多个queue的情况，如果Consumer等于queue的个数，那就是一个Consumer消费一个queue，如果Consumer个数大于queue的个数，那么会有部分Consumer空余出来，白白的浪费了。

2.6消息重复消费如何解决？

影响消息正常发送和消费的重要原因是网络的不确定性。
出现原因
正常情况下在consumer真正消费完消息后应该发送ack，通知broker该消息已正常消费，从queue中剔除
当ack因为网络原因无法发送到broker，broker会认为词条消息没有被消费，此后会开启消息重投机制把消息再次投递到consumer。
消费模式：在CLUSTERING模式下，消息在broker中会保证相同group的consumer消费一次，但是针对不同group的consumer会推送多次
解决方案
l 数据库表：处理消息前，使用消息主键在表中带有约束的字段中insert
l Map：单机时可以使用map做限制，消费时查询当前消息id是不是已经存在
l Redis：使用分布式锁。

2.7 如何让RocketMQ保证消息的顺序消费

你们线上业务用消息中间件的时候，是否需要保证消息的顺序性?
如果不需要保证消息顺序，为什么不需要?假如我有一个场景要保证消息的顺序，你们应该如何保证?
首先多个queue只能保证单个queue里的顺序，queue是典型的FIFO，天然顺序。多个queue同时消费是无法绝对保证消息的有序性的。所以总结如下：
同一topic，同一个QUEUE，发消息的时候一个线程去发送消息，消费的时候 一个线程去消费一个queue里的消息。
追问：怎么保证消息发到同一个queue？
Rocket MQ给我们提供了MessageQueueSelector接口，可以自己重写里面的接口，实现自己的算法，举个最简单的例子：判断i % 2 == 0，那就都放到queue1里，否则放到queue2里。

2.8 RocketMQ如何保证消息不丢失

首先在如下三个部分都可能会出现丢失消息的情况：
Producer端
Broker端
Consumer端
2.8.1 Producer端如何保证消息不丢失
采取send()同步发消息，发送结果是同步感知的。
发送失败后可以重试，设置重试次数。默认3次。
producer.setRetryTimesWhenSendFailed(10);
集群部署，比如发送失败了的原因可能是当前Broker宕机了，重试的时候会发送到其他Broker上。
2.8.2 Broker端如何保证消息不丢失
修改刷盘策略为同步刷盘。默认情况下是异步刷盘的。
flushDiskType = SYNC_FLUSH
集群部署，主从模式，高可用。
2.8.3 Consumer端如何保证消息不丢失
完全消费正常后在进行手动ack确认。

2.9 RocketMQ的消息堆积如何处理

  1. 如果可以添加消费者解决，就添加消费者的数据量.
    2、如果出现了queue，但是消费者多的情况。可以使用准备一个临时的topic，同时创建一些queue，在临时创建一个消费者来把这些消息转移到topic中，让消费者消费。

    2.10 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。

    2.11 任何一台Broker突然宕机了怎么办？

    Broker主从架构以及多副本策略。Master收到消息后会同步给Slave，这样一条消息就不止一份了，Master宕机了还有slave中的消息可用，保证了MQ的可靠性和高可用性。而且Rocket MQ4.5.0开始就支持了Dlegder模式，基于raft的，做到了真正意义的HA。