【面试题】Rocketmq面试题总结

为什么使用消息队列（如RocketMQ）？

• 异步处理：解耦系统间调用，提高响应速度。
• 解耦：降低模块间的直接依赖，使系统更易于扩展和维护。
• 流量削峰：在高峰期将请求暂时存储起来，避免对后端服务造成压力。
• 广播与分布式事务：支持广播消费模式以及分布式事务消息实现最终一致性。

介绍一下RocketMQ的架构组成？

• NameServer：轻量级注册中心，负责Broker节点管理与Topic路由信息的提供。
• Broker：消息中间件的核心服务，包括MasterBroker和SlaveBroker，用于接收、存储和转发消息。
• Producer：生产者客户端，负责向Broker发送消息。
• Consumer：消费者客户端，负责从Broker拉取消息并消费。
• Topic：逻辑上的消息队列，生产者发布消息至特定Topic，消费者订阅相应Topic获取消息。

RocketMQ中如何保证消息不丢失？

• 顺序写磁盘，确保刷盘成功后再返回确认结果给Producer。
• 提供同步/异步发送方式，并且有事务消息来保证跨系统的分布式事务一致。
• 配置合理的重试策略，在网络不稳定或Broker宕机时进行消息重投。

解释一下RocketMQ的消息顺序性是如何保证的？

在单个Message Queue内部，RocketMQ可以保证消息的顺序性。通过指定同一个Producer实例，按照发送顺序写入同一个Message Queue，相应的Consumer实例按顺序拉取该Queue中的消息即可保证顺序。

谈谈RocketMQ的高可用性和负载均衡机制？

高可用性体现在：

• Broker采用主备部署，当主节点发生故障时，可自动切换到备用节点继续服务。
• NameServer集群化部署，多个NameServer之间无状态，提高了整个系统的可用性。

负载均衡机制：

• 生产者可以在发送消息时实现负载均衡，通过轮询或其他策略选择不同的Message Queue。
• 消费者组内的消费者可以根据消费情况动态调整消费队列的分配，达到负载均衡的效果。

在RocketMQ中，如果Consumer数量小于Queue的数量会怎么样？大于Queue的数量又会怎样？

如果Consumer数量小于Queue的数量，部分Consumer将会消费多个Queue，确保所有Queue都有对应的Consumer进行消费。
如果Consumer数量大于Queue的数量，则多出来的Consumer将无法分配到Queue，因此处于空闲状态，直到有新的Queue加入或者已有Queue的消费权转移。

列举几个RocketMQ在实际业务场景的应用案例？

• 订单系统中订单创建后的库存扣减操作。
• 日志收集系统，将分散的日志数据统一汇集处理。
• 实时交易流水处理、大数据实时计算前的数据缓存等。

简述一下RocketMQ的Push和Pull两种消费模式的区别？

Push模式下，Broker主动推送消息给Consumer，适用于实时性要求较高的场景，但需要处理好反压问题以防止消息堆积。
Pull模式下，Consumer主动拉取消息，它能更好地控制消费速率和处理能力，适合消息处理时间较长或者消息积压较大的场景。

在RocketMQ中，如何实现分布式事务？请简述其原理和步骤。

RocketMQ通过半消息（Half Message）机制来支持分布式事务。

具体步骤如下：
a. 发送阶段：
生产者发送预提交消息（half message），此时消息暂不能被消费，但会持久化到Broker。
根据预提交消息执行本地事务逻辑。
本地事务执行成功后，向Broker发送二次确认请求，将预提交消息变为可消费的已提交状态。
若本地事务执行失败，则发送回滚请求，Broker将会删除该预提交消息。
b. 消费阶段：
只有接收到生产者确认的消息才会投递给消费者进行消费。
c. 回查机制：
如果在一定时间内未收到生产者的二次确认或回滚请求，Broker会发起消息回查，询问生产者当前事务的状态，并根据响应决定是提交还是回滚消息。

如何在RocketMQ中实现延时消息功能？

RocketMQ通过定时队列（ScheduleMessageService）实现延时消息功能。当生产者发送一条带有延时属性的消息时，RocketMQ不会立刻投递，而是将其存储在一个特定的延时队列中，同时设置一个过期时间戳。ScheduleMessageService服务会定期扫描这些延时队列，当发现消息过期时，会将其移动到对应的正常Topic并按照普通消息流程进行消费。

RocketMQ如何支持消息过滤功能？

RocketMQ提供标签（Tag）作为消息筛选的基础。生产者在发送消息时可以为每条消息指定一个或多个Tag，而消费者在订阅Topic时不仅可以指定具体的Topic，还可以指定需要消费的Tag集合。这样，Broker在转发消息给消费者时，会根据消费者的订阅关系和消息携带的Tag信息，仅将符合Tag要求的消息推送给消费者。

RocketMQ提供了哪些监控指标和告警机制？

RocketMQ内置了丰富的监控指标，例如Broker节点状态、消息堆积量、消息发送/接收成功率、系统资源使用情况（CPU、内存、磁盘空间等）、网络流量等。通过OpenMessaging Metrics API暴露这些指标数据，可以对接Prometheus、Grafana等监控系统进行实时监控与展示。
同时，可以通过配置邮件告警、短信告警或者集成企业内部的告警系统，针对关键指标设置阈值，一旦超过阈值即触发告警通知，如消息堆积数量达到一定程度时，及时提醒运维人员排查问题。此外，RocketMQ还支持通过JMX接口进行更深入的管理与监控操作。

mq中的消息重复消费问题

在消息队列（MQ）中，消息重复消费问题是一个常见的挑战，主要发生在以下几个场景：

• 消费者故障：当消费者处理完一条消息后，在提交确认之前突然崩溃或重启，导致已经处理的消息的确认状态未被更新到消息队列系统中。当消费者重新上线时，可能会从上次中断的地方开始重新消费，从而导致消息被重复消费。
• 网络延迟或异常：在网络不稳定的情况下，消费者成功处理了消息但确认回执未能及时到达消息队列服务器，也会造成消息可能被再次投递给消费者。
• 消息重试机制：如果消息队列服务提供了消息重试功能，在消息消费失败达到一定次数后，会自动将消息重新放回队列等待下一次消费，这也可能导致消息被多次消费。

解决消息重复消费的方法主要有以下几种：

• 幂等性设计：确保消息处理逻辑具有幂等性，即同一个消息无论被消费多少次，其结果都是相同的，并且不会对业务状态产生负面影响。例如，在数据库操作中，通过主键或者事务保证同一事务只执行一次。
• 消息唯一标识与去重：
  在消费端记录已处理消息的唯一标识，如订单号、消息ID等，将其存储在数据库中并设置唯一约束，这样即使消息被重复消费，由于唯一约束的存在，后续重复的消息也不会对业务数据造成影响。
• 使用Redis或其他缓存系统作为中间件进行去重，比如使用Redis的setNX命令来判断是否已处理过该消息。
• 消息状态跟踪：消费者在处理消息前先检查消息的状态，如果发现消息已经被处理过了，则直接忽略这条消息。
• 补偿机制：对于一些无法简单实现幂等性的操作，可以引入补偿机制，即针对错误的业务操作进行逆向操作以恢复正确的业务状态。
• 消息确认机制：确保消费者正确地调用消息队列提供的确认API（如ACK），并在处理消息后立即提交确认，防止因客户端崩溃等原因造成的消息重复投递。

总之，解决消息重复消费问题需要结合具体的业务场景和技术手段，其中最重要的是设计幂等性处理逻辑和合理利用消息队列系统的确认机制。

mq的对比和选择

消息队列（Message Queue，MQ）是分布式系统中常见的组件，用于解耦、异步处理和流量削峰等场景。

以下是一些常见MQ的对比和选择建议：

• RabbitMQ：开源且广泛使用的消息中间件，遵循AMQP协议。
  特点：支持多种协议，跨语言客户端库丰富，可靠性和稳定性强，易于管理和监控，提供灵活的路由、交换机和绑定机制，支持事务和消息确认机制。
  适用场景：需要高度定制化消息路由策略，对可靠性要求较高的业务场景。
• Apache Kafka：高吞吐量、低延迟的发布订阅消息系统，主要用于大数据实时处理场景。
  特点：基于磁盘持久化的分布式流平台，具备高并发和海量数据处理能力，适用于大规模实时数据处理与日志收集。
  适用场景：大数据处理、实时流计算、日志聚合分析、监控报警等。
• Apache RocketMQ：阿里巴巴开源的分布式消息中间件，设计之初主要面向金融级互联网交易场景。
  特点：高性能、高可用、高可靠，支持顺序消息、事务消息、定时/延时消息等功能，适合于大规模分布式系统的构建。
  适用场景：电商、金融等行业的大规模消息传递，对消息顺序性、事务性有较高需求的业务场景。
• AWS SQS (Simple Queue Service)：AWS提供的云服务型消息队列，易于部署和管理。
  特点：可扩展性强，提供了标准队列和FIFO队列两种模式，分别对应常规消息传递和先进先出的消息传递需求。
  适用场景：在AWS云环境中构建应用，尤其是微服务架构中的解耦和服务间通信。
• Google Cloud Pub/Sub：Google Cloud Platform 提供的完全托管式消息队列服务。
  特点：提供同步和异步消息传递，具有高可用性和可扩展性，支持百万级别的主题和订阅。
  适用场景：GCP环境下的云原生应用开发，以及需要处理大量实时事件的场景。

选择合适的MQ产品，应考虑以下几个关键因素：

• 系统需求：消息吞吐量、延迟要求、是否需要顺序消费、事务支持等。
• 技术栈兼容性：与现有技术栈的集成难度，是否有对应的客户端库支持。
• 可靠性和容错性：系统能否保证消息不丢失，是否支持主备切换、故障恢复等高可用特性。
• 成本和运维：如果是云服务型MQ，要考虑成本投入；如果是自建MQ，需评估运维复杂度和资源开销。
• 社区活跃度和文档完善度：对于开源项目，社区的支持程度和技术文档的质量直接影响到后续的技术支持和问题解决速度。