面经-消息队列

面试题

RocketMQ流程

rocketmq消息发送流程：

• producer从nameserver获取broker地址
• 发送消息到broker
  • broker收到消息后会返回ack，如果没有收到ack，producer将会重发（默认重发2次）
• broker持久化消息
  • 根据broker设置的刷盘方式，异步刷盘|同步刷盘、同步写|异步写
• consumer消费消息
  • 消费消息后响应ack

RocketMQ持久化过程

消息重复消费

理论上各种消息队列都不能保证消息不被重复消费，以rocketmq为例，主要有两种情况可能出现重复消费

• 生产者投递消息后未收到ack(生产者宕机，ack响应网络延迟)，生产者会认为消息没有发送成功并重新进行发送相同msgid的消息
• 当消费者拉取消息后进行消费，消费者的ack未能正确响应到broker

消息队列其实没有办法保证消息不被重复消费，这种情况应该业务代码来保证，保证幂等性即可

RocketMQ架构

rocketmq系统架构主要有四部分：producer、consumer、broker、nameserver

producer

消息生产者，负责投递消息。producer通过MQ负载均衡模块选择broker节点进行消息投递

consumer

消息消费者，负责消费消息。消费者从broker中获取消息并进行消费，消费成功后向broker进行ack

nameserver

nameserver是broker和topic的路由、注册中心。

• 心跳检测：定期检查broker是否存活
• 路由信息管理：nameserver中保存有broker集群的路由、消费信息，生产者和消费者可以通过查询nameserver获取集群信息

broker

broker负责存储、转发消息

消息丢失的场景

rocketmq消息丢失主要有三种情况

1. 生产者发送消息时broker宕机导致未能接收到消息或未能响应消息
2. broker接收到消息 后存储到内存中在未持久化的情况下宕机导致消息丢失
3. 消费者未能成功消费信息即返回ack

第一种情况

针对第一种情况，可以使用rocketmq的事务消息，事务消息会先发送half消息

假设broker未能接收到half消息，则生产者会执行rollback。

假设broker收到half消息后未能正确返回ack就宕机了，此时rocketmq会有补偿机制，定期对half消息进行回查确认消息状态

第二种情况

针对第二种情况，rocketmq默认采用的是异步刷盘的方式，这种刷盘方式可能会因为宕机出现消息丢失的情况，可以修改刷盘方式为同步刷盘。broker只会在消息持久化成功后才返回ack

同时可以基于集群多副本的形式来避免消息丢失（避免磁盘文件损坏导致消息丢失）

第三种情况

rocketmq天然就是消费消息成功才返回ack，只需要确保避免异步消费消息