rocketmq 面试（1）

rocketmq topic图解：

1.Rocketmq怎么保证消息的有序性？

生产者端处理： Producer端发送时，指定MessageSelector，算出将消息放到哪个queue

消费端处理： 如何保证消费端 顺序消费？ 如果是使用MessageListenerOrderly(**顺序消费)**则自带顺序消费实现，如果是使用MessageListenerConcurrently（并发消费），则需要把线程池改为单线程模式。

MessageListenerOrderly(顺序消费)：有序消费，同一队列的消息同一时刻只能一个线程消费，可保证消息在同一队列严格有序消费
MessageListenerConcurrently（并发消费）：

2.Rocketmq怎么保证消息一定可达，不丢失？

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

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

3. 怎么保证brocker存储消息不丢失？
   采用同步刷盘模式，当刷盘成功后才返回producer投递消息成功。

3.怎么保证最终一致性？

事务消息

1. 发送方向 MQ 服务端发送消息。
2. MQ Server 将消息持久化成功之后，向发送方 ACK 确认消息已经发送成功，此时消息为半消息。
3. 发送方开始执行本地事务逻辑。
4. 发送方根据本地事务执行结果向 MQ Server 提交二次确认（Commit 或是 Rollback），MQ Server 收到Commit 状态则将半消息标记为可投递，订阅方最终将收到该消息；MQ Server 收到 Rollback 状态则删除半消息，订阅方将不会接受该消息。
5. 在断网或者是应用重启的特殊情况下，上述步骤4提交的二次确认最终未到达 MQ Server，经过固定时间后MQ Server 将对该消息发起消息回查。
6. 发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
7. 发送方根据检查得到的本地事务的最终状态再次提交二次确认，MQ Server 仍按照步骤4对半消息进行操作。

Producer Group
标识发送同一类消息的Producer，通常发送逻辑一致。发送普通消息的时候，仅标识使用，并无特别用处。若事务消息，如果某条发送某条消息的producer-A宕机，使得事务消息一直处于PREPARED状态并超时，则broker会回查同一个group的其 他producer，确认这条消息应该commit还是rollback。但开源版本并不支持事务消息。

4.consumer的消费模式？

1. 广播消费
   广播消费是指一个consumer只要订阅了某个topic的消息，那它就会收到该topic下的所有queue里的消息，而不管这个consumer的group是什么。所以对于广播消费来说，consumer group没什么实际意义

consumer.setMessageModel(MessageModel.BROADCASTING)

2. 集群消费
   集群消费是指，一个consumer group下的consumer，平均消费topic下的queue。假如一个topic下有4个queue，然后当前有一个consumer group，该分组下有4个consumer，那每个consumer就被分配到该topic下的一个queue，这样就达到了平均消费topic下的queue的目的。

 consumer.setMessageModel(MessageModel.CLUSTERING);