一、RocketMQ集群

 RocketMQ集群由于无法选主，所以当Master挂了以后，slave需要手动切换master。这一点不好

二、RocketMQ为什采用NameSr，而不是zk

ZK是CP，NameSr是AP。RocketMQ选择了高可用。

RocketMQ的集群思想与Kafka有很大区别，在Kafka中borker这个概念分为Master和slave，可以通过zk选主进行切换和高可用。RocketMQ中Master对应的Borker 和 slave对应的borker是搭建环境的时候指定好的，他不需要选举。从这里可以看出Kafka的核心思想是通过主从切换保证集群的高可用。而RocketMQ是通过故障转移保证集群的高可用。例如：当RocketMQ中某个masterBorker挂了，那本来该发送到这个borker中对应队列的消息，此时将会被发送到其他Master上（对于普通消息）。

三、RocketMQ的顺序消息

全局顺序：就是我希望所有的消息你都给我按序消费，对应这样的消息我们可以创建topic时只分配一个队列。这样就失去了高可用的，高吞吐量的效果。

局部顺序：这类顺序消息很常见，我们就是根据一定的算法将同类型的消息路由到同一个队列中。发送消息，要实现 MessageQueueSelector 该接口，重写select()方法，按照自己的算法将相同类别的消息发送大同一个Queue中。

消费端处理： 如何保证消费端顺序消费？

• MessageListenerOrderly(顺序消费)：有序消费，同一队列的消息同一时刻只能一个线程消费，可保证消息在同一队列严格有序消费
• MessageListenerConcurrently（并发消费）：如果是使用该方式，则需要把线程池改为单线程模式。

四、消息重试的原理与死信队列

Producer

• 如果是异步发送 那么重试次数只有1次
• 对于同步而言，超时异常也是不会再去重试。
• Product默认是2次；他是立即重试
• 发送超时，不会重试

Consumer:

• Consumer默认是16次
• Consumer是有一定时间间隔的。它照1S,5S,10S,30S,1M,2M····2H进行重试。
• Consumer在广播情况下重试失效

RocketMQ 规定，以下三种情况统一按照消费失败处理并会发起重试。

• 业务消费方返回 ConsumeConcurrentlyStatus.RECONSUME_LATER
• 业务消费方返回null
• 业务消费方主动/被动抛出异常

RocketMQ 消费失败后会将消息加入到重试队列（设置重试消息的TOPIC， 重试队列名称为：%RETRY%+consumergroup），如果当前消息的重试次数大于最大重试次数，那么就开始走死信队列。 跟重试消息一样，也是设置死信队列的TOPIC %DLQ%+ 实际的消费组 ，我们可以对死性对了进行处理。但是在实际工作中我们一般重试三次，如果还是失败也给borker返回成功，同时我们会将该消息记录下来，后期补偿。

注意：RocketMQ消息重试功能需要区分事务消息、顺序消息、与普通消息。

• 普通消息：该类型消息的重试，会触发故障转移，就是当第一次发送消息失败，重试发送会换一个borker。
• 顺序消息：该类型消息重试，不会触发故障转移，就是一直往同一个borker上发送。

五、如何保证消息零丢失

生产者：

• 同步发送： Producer 向 broker 发送消息，阻塞当前线程等待 broker 响应 发送结果。
• 异步发送： Producer 首先构建一个向 broker 发送消息的任务，把该任务提交给线程池，等执行完该任务时，回调用户自定义的回调函数，执行处理结果。
• Oneway发送： Oneway 方式只负责发送请求，不等待应答，Producer 只负责把请求发出去，而不处理响应结果。我们使用同步发送返送，并且捕获返回结果进行重试，可以减小消息发送丢失。

Conusmer：PushConsumer为了保证消息肯定消费成功，只有使用方明确表示消费成功，RocketMQ才会认为消息消费成功。中途断电，抛出异常等都不会认为成功——即都会重新投递。ConsumeConcurrentlyStatus.CONSUME_SUCCESS

brocker存储消息：采用同步刷盘模式，当刷盘成功后才返回producer投递消息成功。