RocketMQ面试

1、RocketMQ应用场景

• 异步解耦
• 削峰填谷
• 顺序消息
• 分布式事物
• 大数据分析
• 分布式模缓存同步

2、MQ缺点

• 系统可用性降低
• 系统复杂度提高
• 一致性问题

3、RocketMQ高可用机制

• 主机和从机配合，主机支持读写，从机只支持读，生产者只能和主机连接写入消息，消费者可以连接主机和从机
• 消费者高可用：当主机不可用或者繁忙时，消费者会被自动切换到从机读，所以即使主机出现故障，消费者仍然可以在从机读取消息，不受影响
• 生产者高可用：创建topic时，把消息队列建在多个broker组上（brokerName一样，brokerId不同），当一个broker组的主机不可用后，其他组的主机仍然可用，生产者可以继续发消息

4、如何保证消息不被重复消费

• 使用redis的set操作，使用幂等性
• RocketMQ会返回一个CONSUME_SUCCESS成功标志

5、MQ如何保证消息不丢失？

Producer如何保证消息不丢失？

• 默认情况下，可以通过同步的方式阻塞式地发送，checkSendStatus状态是OK，表示消息一定成功地投递到了Broker，状态超时或者失败，则会触发默认的2次重试。此方法的发送结果，可能是Broker存储成功了，也有可能没成功
• 采用事物消息的投递方式，并不能保证消息100%投递成功到了Broker，但是如果消息发送Ack失败的话，此消息会存储在CommitLog中，但是对消费队列是不可见的。可以在日志中查看到这条异常的消息，严格意义来讲，消息并没有完全丢失
• RocketMQ支持日志的索引，如果一条消息发送之后超时，也可以通过查询日志的API，来check是否在Broker存储成功
  Broker如何保证消息不丢失？
• 消息支持持久化到CommitLog里面，即使宕机重启，未消费的消息也是可以加载出来的
• Broker自身支持同步刷盘、异步刷盘的策略，可以保证接收到的消息一定存储在本地的内存中
• Broker集群支持1主N从的策略，支持同步复制和异步复制的方式，同步复制可以保证即使Master磁盘崩溃，消息仍然不会丢失
  Consumer如何保证消息不丢失？
• Consumer自身维护一个持久化的offset，标记已经成功消费或者已经成功发回到Broker的消息下标
• 如果消息消费失败，那么它会把这个消息发回给Broker，发回成功后，再更新自己的offset
• 如果Consumer消费失败，发回给Broker时，Broker挂掉了，那么Consumer会定时重试这个操作
• 如果Consumer和Broker一起挂掉了，消息也不会丢失，因为Consumer里的offset是持久化的，重启之后，继续拉取offset之前的消息到本地