欢迎关注《Java面试题2.0》合集发布页，持续更新中！
RocketMQ概述
RocketMQ 是一款分布式、队列模型的消息中间件，具有以下特点： 能够保证严格的消息顺序 提供丰富的消息拉取模式 高效的订阅者水平扩展能力 实时的消息订阅机制 亿级消息堆积能力
RocketMQ包含的组件
NameServer：单点，供Producer和Consumer获取Broker地址
Producer：产生并发送消息
Consumer：接受并消费消息
Broker：消息暂存，消息转发
Name Server
Name Server是RocketMQ的寻址服务。用于把Broker的路由信息做聚合。客户端依靠Name Server决定去获取对应topic的路由信息，从而决定对哪些Broker做连接。
Broker
Broker是处理消息存储，转发等处理的服务器。
Broker以group分开，每个group只允许一个master，若干个slave。
只有master才能进行写入操作，slave不允许。
slave从master中同步数据。同步策略取决于master的配置，可以采用同步双写，异步复制两种。
RocketMQ优点
1.强调集群无单点，可扩展
2.任意一点高可用，水平可扩展
3.海量消息堆积能力，消息堆积后，写入低延迟。
4.支持上万个队列
5.消息失败重试机制
6.消息可查询
7.开源社区活跃
8.成熟度（经过双十一考验）
RocketMQ重试机制
MQ 消费者的消费逻辑失败时，可以通过设置返回状态达到消息重试的结果。
MQ 消息重试只针对集群消费方式生效；广播方式不提供失败重试特性，即消费失败后，失败消息不再重试，继续消费新的消息。
注意:每次重试后，消息ID都不一致，所以不能使用消息ID判断幂等。
RocketMQ如何解决消息幂等
注意:每次重试后，消息ID都不一致，所以不能使用消息ID判断幂等。
解决办法:使用自定义全局ID判断幂等，例如流水ID、订单号
集群消费模式和广播模式的区别
广播消费
一条消息被多个Consumer消费，几十这些Consumer属于同一个ConsumerGroup，消息也会被ConsumerGroup中的每个Consumer消费一次，广播消费中的ConsumerGroup概念可以认为在消息划分层面没有意义，适用于一些分发消息的场景，比如我订单下单成功了，需要通知财务系统，客服系统等等这种分发的场景，可以通过修改Consumer中的MessageModel来设置消费方式为广播消费
集群消费
适用场景
适用于消费端集群化部署，每条消息只需要被处理一次的场景。此外，由于消费进度在服务端维护，可靠性更高。
注意事项
集群消费模式下，每一条消息都只会被分发到一台机器上处理。如果需要被集群下的每一台机器都处理，请使用广播模式。
集群消费模式下，不保证每一次失败重投的消息路由到同一台机器上。
RocketMQ 集群部署模式
单 master 模式
也就是只有一个 master 节点，称不上是集群，一旦这个 master 节点宕机，那么整个服务就不可用，适合个人学习使用。
多 master 模式
多个 master 节点组成集群，单个 master 节点宕机或者重启对应用没有影响。
优点：所有模式中性能最高
缺点：单个 master 节点宕机期间，未被消费的消息在节点恢复之前不可用，消息的实时性就受到影响。
注意：使用同步刷盘可以保证消息不丢失，同时 Topic 相对应的 queue 应该分布在集群中各个节点，而不是只在某各节点上，否则，该节点宕机会对订阅该 topic 的应用造成影响。
多 master 多 slave 异步复制模式
在多 master 模式的基础上，每个 master 节点都有至少一个对应的 slave。master
节点可读可写，但是 slave 只能读不能写，类似于 mysql 的主备模式。
优点： 在 master 宕机时，消费者可以从 slave 读取消息，消息的实时性不会受影响，性能几乎和多 master 一样。
缺点：使用异步复制的同步方式有可能会有消息丢失的问题。
多 master 多 slave 同步双写模式
同多 master 多 slave 异步复制模式类似，区别在于 master 和 slave 之间的数据同步方式。
优点：同步双写的同步模式能保证数据不丢失。
缺点：发送单个消息 RT 会略长，性能相比异步复制低10%左右。
刷盘策略：同步刷盘和异步刷盘（指的是节点自身数据是同步还是异步存储）
同步方式：同步双写和异步复制（指的一组 master 和 slave 之间数据的同步）
注意：要保证数据可靠，需采用同步刷盘和同步双写的方式，但性能会较其他方式低。
RocketMQ-事务消息设计思路
两个核心概念：两阶段提交、事务状态定时回查
两阶段提交
上面已经提到，因为消息发送是一个远程调用，由于网络的不稳定，无法和本地事务的执行处于一个原子操作中，针对这个缺点，RocketMQ基于两阶段提交协议做了如下改动
第一阶段：生产者向MQ服务器发送事务消息(prepare消息)，服务端确认后回调通知生产者执行本地事务(此时消息为Prepare消息，存储于RMQ_SYS_TRANS_HALF_TOPIC队列中，不会被消费者消费)
第二阶段：生产者执行完本地事务后(业务执行完成，同时将消息唯一标记，如transactionId与该业务执行记录同时入库，方便事务回查)，根据本地事务执行结果，返回Commit/Rollback/Unknow状态码
1、服务端若收到Commit状态码，则将prepare消息变为提交(正常消息，可被消费者消费)
2、收到Rollback则对消息进行回滚(丢弃消息)
3、若状态为Unknow，则等待MQ服务端定时发起消息状态回查，超过一定重试次数或者超时，消息会被丢弃
事务状态定时回查
在第二阶段中，生产者在本地事务执行完成后，需要向MQ服务器返回响应状态码，发送状态码的过程也是通过Netty发送网络请求，假设由于网络原因发送失败怎么办？本地事务已经提交/回滚了，但是Commit/Rollback状态码却没发出去，那么MQ服务器上这条prepare消息状态岂不是无法被投递/回滚
因此，MQ服务端会定时扫描存储于RMQ_SYS_TRANS_HALF_TOPIC中的消息，若消息未被处理，则向消费发送者发起回调检查，检查消息对应本地事务执行状态。从而保证消息事务状态最终能和本地事务的状态一致。上图中的4、5、6就是MQ服务端定时回查步骤。
延迟消息
producer端设置消息delayLevel延迟级别，消息属性DELAY中存储了对应了延时级别
broker端收到消息后，判断延时消息延迟级别，如果大于0，则备份消息原始topic，queueId，并将消息topic改为延时消息队列特定topic(SCHEDULE_TOPIC)，queueId改为延时级别-1
mq服务端ScheduleMessageService中，为每一个延迟级别单独设置一个定时器，定时(每隔1秒)拉取对应延迟级别的消费队列
根据消费偏移量offset从commitLog中解析出对应消息
从消息tagsCode中解析出消息应当被投递的时间，与当前时间做比较，判断是否应该进行投递
若到达了投递时间，则构建一个新的消息，并从消息属性中恢复出原始的topic，queueId，并清除消息延迟属性，从新进行消息投递
消息顺序发送的实现思路及原理
要保证消息的顺序消费，有三个关键点
消息顺序发送
消息顺序存储
消息顺序消费
第一点，消息顺序发送，多线程发送的消息无法保证有序性，因此，需要业务方在发送时，针对同一个业务编号(如同一笔订单)的消息需要保证在一个线程内顺序发送，在上一个消息发送成功后，在进行下一个消息的发送。对应到mq中，消息发送方法就得使用同步发送，关键点在于单线程同步顺序发送消息
第二点，消息顺序存储，mq的topic下会存在多个queue，要保证消息的顺序存储，同一个业务编号的消息需要被发送到一个queue中。对应到mq中，需要使用MessageQueueSelector来选择要发送的queue，即对业务编号进行hash，然后根据队列数量对hash值取余，将消息发送到一个queue中。关键点在于根据业务唯一编号Hash后选择同一消息队列(分区)
第三点，消息顺序消费，要保证消息顺序消费，同一个queue就只能被一个消费者所消费，因此对broker中消费队列加锁是无法避免的。同一时刻，一个消费队列只能被一个消费者消费，消费者内部，也只能有一个消费线程来消费该队列。即，同一时刻，一个消费队列只能被一个消费者中的一个线程消费。关键点在于保证一个队列同一个时刻只能被一个消费者中一个线程消费
保证消息不丢失的方法
Producer发送消息阶段
1、提供SYNC的发送消息方式，等待broker处理结果。
RocketMQ提供了3种发送消息方式，分别是：
同步发送：Producer 向 broker 发送消息，阻塞当前线程等待 broker 响应 发送结果。
异步发送：Producer 首先构建一个向 broker 发送消息的任务，把该任务提交给线程池，等执行完该任务时，回调用户自定义的回调函数，执行处理结果。
Oneway发送：Oneway 方式只负责发送请求，不等待应答，Producer 只负责把请求发出去，而不处理响应结果。
我们在调用producer.send方法时，不指定回调方法，则默认采用同步发送消息的方式，这也是丢失几率最小的一种发送方式。
2、发送消息如果失败或者超时，则重新发送。
3、broker提供多master模式，即使某台broker宕机了，保证消息可以投递到另外一台正常的broker上。
如果broker只有一个节点，则broker宕机了，即使producer有重试机制，也没用，因此利用多主模式，当某台broker宕机了，换一台broker进行投递。
总结
producer消息发送方式虽然有3种，但为了减小丢失消息的可能性尽量采用同步的发送方式，同步等待发送结果，利用同步发送+重试机制+多个master节点，尽可能减小消息丢失的可能性。
Broker处理消息阶段
1、提供同步刷盘的策略
我们知道，当消息投递到broker之后，会先存到page cache，然后根据broker设置的刷盘策略是否立即刷盘，也就是如果刷盘策略为异步，broker并不会等待消息落盘就会返回producer成功，也就是说当broker所在的服务器突然宕机，则会丢失部分页的消息。
2、提供主从模式，同时主从支持同步双写
即使broker设置了同步刷盘，如果主broker磁盘损坏，也是会导致消息丢失。
因此可以给broker指定slave，同时设置master为SYNC_MASTER，然后将slave设置为同步刷盘策略。
此模式下，producer每发送一条消息，都会等消息投递到master和slave都落盘成功了，broker才会当作消息投递成功，保证休息不丢失。
总结
在broker端，消息丢失的可能性主要在于刷盘策略和同步机制。
RocketMQ默认broker的刷盘策略为异步刷盘，如果有主从，同步策略也默认的是异步同步，这样子可以提高broker处理消息的效率，但是会有丢失的可能性。因此可以通过同步刷盘策略+同步slave策略+主从的方式解决丢失消息的可能。
Consumer消费消息阶段
1、consumer默认提供的是At least Once机制
从producer投递消息到broker，即使前面这些过程保证了消息正常持久化，但如果consumer消费消息没有消费到也不能理解为消息绝对的可靠。因此RockerMQ默认提供了At least Once机制保证消息可靠消费。
何为At least Once？
Consumer先pull 消息到本地，消费完成后，才向服务器返回ack。
通常消费消息的ack机制一般分为两种思路：
1、先提交后消费；
2、先消费，消费成功后再提交；
思路一可以解决重复消费的问题但是会丢失消息，因此Rocket默认实现的是思路二，由各自consumer业务方保证幂等来解决重复消费问题。
2、消费消息重试机制
当消费消息失败了，如果不提供重试消息的能力，则也不能算完全的可靠消费，因此RocketMQ本身提供了重新消费消息的能力。
总结
consumer端要保证消费消息的可靠性，主要通过At least Once+消费重试机制保证。
重复消费问题怎么解决？
1.幂等性。比如支付成功后的回调，如果订单状态是已支付，直接返回true。
2. 消息去重表。
消息堆积的原因是什么？
1、消息堆积是一个相对值，针对consumer消费消息，某个topic队列中最大的maxOffset与当前消费消息的currOffset的差异值，大于某个特定的阈值，才会出现消息堆积。
2、当发送消息高于消息消费的速率，则可能出现消息堆积。
3、其他条件保存正常水平，存在消息堆积的那一部分消息会随着时间不断减少直至消息被消费。
4、针对过多的消息堆积，可以选择丢弃不重要的消息，即仅仅记录日志，而不真正消费，以此保证消息的完整性，以此来特殊处理消息的堆积情况。
1603
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
