消息队列面试总结-优快云博客

本文链接：https://blog.youkuaiyun.com/efsgerd/article/details/149804626

消息队列面试总结

什么是消息队列？

消息队列（Message Queue）是一种基于异步通信模式的中间件技术，它通过在发送者和接收者之间建立一个 “缓冲区”（即队列），实现消息的暂存、传递和处理。简单来说，消息队列就像现实中的 “信箱”：发送者将消息放入信箱，接收者按需从信箱中取走消息，二者无需实时交互，甚至可以在不同时间、不同系统中运行。

消息队列使用场景有哪些？

异步通信：异步通信通过消息队列实现 “发送即忘” 的非阻塞交互，解决同步调用中的延迟问题。生产者发送消息后无需等待消费者处理结果，可立即执行后续操作，大幅提升系统响应速度。例如用户注册场景中，注册系统发送消息后瞬间反馈用户，而验证码、档案创建等后续流程由其他服务异步处理，将原本的多步同步等待转化为高效的并行处理，显著优化用户体验。
系统解耦：系统解耦借助消息队列打破服务间的直接依赖，使生产者与消费者通过消息格式间接交互，而非硬编码的接口调用。当某个系统升级、替换或新增功能时，只需保证消息格式兼容，其他关联系统无需修改，极大降低维护成本。以电商订单链路为例，订单系统只需发送订单消息，库存、物流、积分等服务通过监听队列独立处理，实现了业务扩展时的 “零侵入” 升级，提升系统灵活性与可维护性。
削峰填谷：流量削峰利用消息队列的缓冲能力，应对秒杀、促销等场景的突发高并发压力。大量请求先被队列暂存，后端服务按自身处理能力匀速消费，避免瞬间流量压垮后端资源。在秒杀活动中，队列可拦截超出承载的请求并返回友好提示，同时消费者按数据库、接口的最大负荷平稳处理请求，将 “脉冲式流量” 转化为 “匀速流量”，保障系统在高并发下的稳定性与可用性。
可靠传递：数据可靠传递通过消息队列的持久化、确认机制和重试机制，确保关键业务消息不丢失。消息发送后被持久化存储，消费者处理完成需发送确认信号，未确认的消息会在服务恢复后重新投递。例如金融交易通知场景中，转账消息经队列持久化，即使通知服务临时宕机，消息也不会丢失，待服务恢复后自动重新处理，有效避免因网络中断、服务故障导致的业务异常，保障核心数据的一致性与完整性。

消息重复消费怎么解决

消费端幂等处理：可使用唯一标识符判断，如利用消息 ID 或业务唯一标识，通过数据库唯一索引防止重复插入数据，或用 Redis 的SET NX命令判断消息是否已处理。也可使用分布式锁，确保同一时刻只有一个节点能执行操作，避免重复处理。
消息去重：可在消费者端使用缓存或数据库记录已处理的消息 ID，消费前检查是否已处理。还可在消息队列端，通过记录已发送的消息 ID，避免重复推送。另外，也可以使用布隆过滤器，它是一种高效的数据结构，可判断消息是否被处理过，虽然存在假阳性问题，但可结合 Redis 缓存进一步确认，以提高准确性。
确保消息确认机制：消费者成功处理消息后，应及时向消息队列发送确认回执（ack），让消息队列删除或标记已消费的消息。若未及时发送 ack，可能导致消息队列重新投递消息，从而产生重复消费。
设置消息有效期：在消息中设置有效期，超过有效期的消息将被丢弃，避免过期消息被重复消费。例如，可根据业务场景设置消息在几分钟或几小时内有效，超过该时间后，消息队列自动将其删除。
生产端优化：生产者发送消息时，为消息生成唯一的去重 key，若因网络问题发送失败重试，沿用相同的去重 key。同时，生产者可将去重 key 持久化，如写入磁盘，防止掉电丢失。

消息丢失怎么解决？

一、生产端：确保消息成功发送到队列

开启发送确认机制：
生产者发送消息后，等待消息队列的 “发送成功回执”（如 Kafka 的acks=all、RabbitMQ 的publisher-confirms），仅收到确认后才视为发送成功；若失败则触发重试（需限制重试次数避免死循环）。
消息本地持久化：
发送前将消息暂存本地磁盘 / 数据库，若未收到队列确认，可从本地重试发送，防止因生产者宕机导致消息丢失。
避免同步阻塞过度：
高并发场景下，可采用 “异步确认 + 批量重试” 减少性能损耗，但需确保重试逻辑可靠。
- 批量重试做法：
- 生产者维护一个 “待重试消息队列”（内存队列或本地磁盘队列），将发送失败的消息暂存于此；
- 不立即重试，而是按批次、按间隔时间统一重试（例如每 500ms 批量重试一次，或累计到 100 条失败消息后批量重试）；
- 重试时可先检查队列状态（如通过健康检查接口确认队列是否已经恢复），避免无效重试。

二、消息队列端：确保消息不丢失

强制持久化消息：
队列需将消息写入磁盘（如 Kafka 的log.flush.interval.messages设置刷盘阈值、RabbitMQ 的durable=true标记队列持久化），避免内存数据因集群宕机丢失。
集群高可用部署：
采用多副本机制（如 Kafka 的replication-factor≥2、RabbitMQ 镜像队列），确保单个节点故障时，消息可从其他副本恢复。
合理设置消息过期时间：
避免因 “消息过期被自动删除” 导致丢失（非核心场景可设置，核心业务建议不设或设长有效期）。

三、消费端：确保消息成功处理并确认

延迟确认消息（Ack）：
消费者需在业务逻辑完全处理成功后，再向队列发送确认回执（如 Kafka 的auto.offset.commit=false手动提交偏移量、RabbitMQ 的basicAck），避免 “处理中宕机” 导致队列重复投递时消息丢失。
- 具体逻辑
  1. 消费者提前确认 → 队列标记消息 “已处理” 并删除 / 隐藏
  2. 消费者处理途中故障 → 业务逻辑中断（未完成）
  3. 服务恢复后 → 队列中已无此消息（因已标记处理），消费者无法再次获取
  4. 最终结果 → 消息实际未处理完成，但被队列判定为 “已成功消费”，彻底丢失，且无法重试
失败重试与死信队列：
若消费失败，不直接丢弃消息，而是通过重试机制（如设置重试次数和间隔）再次尝试；多次失败后放入死信队列，人工干预处理，防止消息因处理失败被永久丢弃。

消息队列的可靠性怎么保障？

**消息持久化：**确保消息队列能够持久化消息是非常关键的。在系统崩溃、重启或者网络故障等情况下，未处理的消息不应丢失。例如，像 RabbitMQ 可以通过配置将消息持久化到磁盘，通过将队列和消息都设置为持久化的方式（设置durable = true），这样在服务器重启后，消息依然可以被重新读取和处理。
**消息确认机制：**消费者在成功处理消息后，应该向消息队列发送确认（acknowledgment）。消息队列只有收到确认后，才会将消息从队列中移除。如果没有收到确认，消息队列可能会在一定时间后重新发送消息给其他消费者或者再次发送给同一个消费者。以 Kafka 为例，消费者通过commitSync或者commitAsync方法来提交偏移量（offset），从而确认消息的消费。
**消息重试策略：**当消费者处理消息失败时，需要有合理的重试策略。可以设置重试次数和重试间隔时间。例如，在第一次处理失败后，等待一段时间（如 5 秒）后进行第二次重试，如果重试多次（如 3 次）后仍然失败，可以将消息发送到死信队列，以便后续人工排查或者采取其他特殊处理。

消息队列的顺序性怎么保证？

1. 生产者端：确保消息按顺序进入同一 “单元”

生产者需将同一业务流的消息（如同一订单的消息）路由到同一分区 / 队列，避免分散。

Kafka：通过指定partition key（分区键），相同 key 的消息会被路由到同一分区（Kafka 的分区内消息严格有序）。例如：订单 ID 作为 partition key，同一订单的所有消息进入同一分区。
RabbitMQ：避免使用扇形交换机（Fanout Exchange）或主题交换机（Topic Exchange）路由到多个队列，改用直连交换机（Direct Exchange）将同一业务流的消息路由到单一队列。
RocketMQ：发送顺序消息时，需指定MessageQueueSelector，通过自定义规则将同一业务标识（如订单 ID）的消息路由到同一 MessageQueue（RocketMQ 的队列内有序）。

2.Broker 端：保证单一 “单元” 内的顺序存储

主流消息队列的单一分区 / 队列内部默认保证消息顺序（按写入时间排序），这是顺序性的基础：

Kafka 的分区本质是一个有序的日志文件，消息按发送顺序追加写入，消费时也按顺序读取。
RabbitMQ 的单一队列是一个 FIFO（先进先出）的消息缓冲区，消息按接收顺序排队，先入队的消息先被消费。
RocketMQ 的每个 MessageQueue 是独立的有序存储单元，消息按发送顺序存储。

注意：Broker 的故障恢复（如分区副本同步）不会破坏分区 / 队列内的顺序，因为副本同步时会严格按原顺序复制消息。

3.消费者端：避免并行处理，保证串行消费

即使 Broker 保证了消息顺序，若消费者并行处理，仍会导致乱序。因此消费者需确保：同一分区 / 队列的消息被单线程消费。

Kafka：消费者组（Consumer Group）中，每个分区仅被一个消费者实例消费（避免多实例并行）；且该消费者实例内部用单线程处理消息（或多线程但按顺序提交处理结果）。
RabbitMQ：同一队列仅配置一个消费者（避免多消费者并行），且消费者内部用单线程处理消息（禁用多线程消费同一队列）。
RocketMQ：顺序消息的消费者需通过MessageListenerOrderly接口实现，框架会确保同一 MessageQueue 的消息被单线程串行处理，且前一条消息处理完成后才会拉取下一条。

如何保证幂等写？

基于唯一标识（ID）的幂等控制：通过给每个写入操作分配全局唯一的业务 ID，执行前检查该 ID 是否已处理，避免重复写入。这是最通用的方案。

基于乐观锁的幂等控制：通过版本号（Version）或时间戳（Timestamp） 标记数据的当前状态，更新时验证状态是否匹配，避免旧操作覆盖新操作

基于状态机的幂等控制：通过业务状态的流转规则限制重复操作，仅允许状态从 “预期状态” 向 “目标状态” 转换，避免无效重复更新

基于分布式锁的幂等控制：通过分布式锁（如 Redis 锁、ZooKeeper 锁）确保同一资源的写入操作在同一时间仅被一个线程执行，避免并发导致的重复写入。

消息队列的消息积压怎么解决？

临时解决：
1. 紧急扩容消费者，提升消费速度
2. 暂停非核心消费，优先处理积压消息
3. 跳过无效消息，避免资源浪费
4. 批量消费 + 异步处理，提高单条消息处理效率
优化消费者处理逻辑，减少单条消息的处理耗时，提升单位时间内的消费数量。
- 批量消费：若 MQ 支持批量拉取（如 Kafka 的fetch.min.bytes、max.poll.records），调整参数让消费者一次拉取多条消息，批量处理（如批量写入数据库、批量调用接口）。
- 异步化处理：将耗时操作（如数据库写入、外部 API 调用）改为异步（如提交到线程池、写入本地队列后异步处理），减少消费线程阻塞。
1. 临时分流：将积压消息迁移到新队列处理
若原队列 / 分区存在瓶颈（如单分区队列无法水平扩容），可通过 “消息重放” 将积压消息迁移到新的多分区队列，再用多消费者并行处理。
长期优化：
1. 生产者端：控制发送速率，避免流量突发
通过限流、削峰等手段，避免生产者短时间内发送大量消息，超出消费者处理能力。
- 具体方案：
  - 流量控制：使用令牌桶 / 漏桶算法限制生产者发送速率（如 Guava 的RateLimiter），确保消息发送 TPS≤消费者最大处理 TPS。
  - 异步缓冲：非核心消息通过异步队列缓冲，避免同步发送阻塞主线程，同时平滑流量波动。
  - 业务分级：对消息按优先级分类（如核心消息、普通消息、低优先级消息），使用不同队列存储，核心队列配置更高的消费资源。
1. 消费者端：优化处理能力，提升稳定性
消费者是处理消息的核心，需从逻辑、性能、容错三方面优化，确保消费速率匹配生产速率。

（1）优化消费逻辑，减少处理耗时
- 异步化：将消费逻辑中的耗时操作（如数据库写入、RPC 调用）改为异步处理（如使用线程池、消息中间件二次转发），缩短单条消息的处理时间。
  - 示例：消费订单消息时，先将订单数据写入本地内存队列，再由异步线程批量写入数据库，避免每条消息单独写库。
- 减少外部依赖：避免在消费逻辑中调用不稳定的外部接口，必要时通过缓存（如 Redis）预存数据，或降级为本地逻辑。
- 批量处理：默认开启批量消费（如 Kafka 的max.poll.records设置为合理值，如 100），减少网络交互和锁竞争开销。
（2）提高消费并发能力，支持水平扩展
- 合理设计队列 / 分区：创建多分区 / 多队列（如 Kafka 按业务 ID 哈希分区，RabbitMQ 使用多个队列 + 交换机路由），确保消费者可通过增加实例数水平扩容（消费者数≤分区 / 队列数）。
- 无状态设计：消费者逻辑需无状态（不依赖本地内存数据），支持随时扩容或缩容，避免因状态共享导致的并发问题。
（3）完善容错与重试机制，避免消费阻塞
- 失败重试策略：对消费失败的消息，设置有限次数的重试（如最多重试 3 次），超过次数后转移到死信队列（DLQ），由人工或专门的重试服务处理，避免无效重试占用资源。
  - 示例：使用 Spring Cloud Stream 时，配置spring.cloud.stream.bindings.input.consumer.max-attempts=3，并绑定死信队列。
- 熔断降级：当消费者依赖的下游服务（如数据库、RPC 服务）故障时，通过熔断机制（如 Resilience4j）暂停调用，返回默认结果或缓存数据，避免消费者线程阻塞。
- 监控告警：实时监控消费延迟（消息在队列中的存活时间）和消费速率，当延迟超过阈值（如 5 分钟）时触发告警（如短信、钉钉通知），及时介入处理。
1. Broker 端：优化配置，提升存储与调度能力
- 合理配置队列 / 分区：根据业务流量规划分区 / 队列数量（如按预估 TPS 的 2-3 倍设置分区数），确保并行处理能力。
- 优化存储性能：使用高性能存储介质（如 SSD）提升 Broker 的读写速度；调整 Broker 缓存参数（如 Kafka 的log.flush.interval.messages），减少磁盘 IO 频率。
- 消息过期与清理：为非核心消息设置合理的过期时间（TTL），避免无效消息长期占用存储空间；开启自动清理机制（如 Kafka 的日志保留策略），定期删除过期消息。

事务消息如何实现？

事务消息是解决 “生产者本地事务与消息发送一致性” 的核心方案，“生产者本地事务与消息发送一致性” 是分布式系统中数据一致性的核心问题，本质上是要解决 “本地业务操作” 与 “消息发送到队列” 这两个动作的 “原子性”—— 即要么两者都成功，要么两者都失败，避免出现 “业务成功但消息没发出去” 或 “消息发出去了但业务没成功” 的不一致状态。

发送半事务消息
生产者向 Broker 发送 “半事务消息”，Broker 接收后存储在本地（但标记为 “待确认”，不投递到消费者），并返回 “消息已接收” 确认给生产者。
执行本地事务
生产者收到 Broker 的确认后，执行本地业务逻辑（如订单创建、库存扣减）。
提交事务状态
本地事务执行完成后，生产者向 Broker 发送事务状态指令：
- 若本地事务成功：发送 COMMIT 指令，Broker 将半事务消息标记为 “可投递”，投递给消费者。
- 若本地事务失败：发送 ROLLBACK 指令，Broker 删除半事务消息（不投递）。
事务状态回查（兜底机制）
若生产者在发送事务状态指令前宕机（或网络故障），Broker 会定时（默认 1 分钟）向生产者发起 “事务回查” 请求（通过生产者注册的回查接口）。
生产者收到回查后，检查本地事务实际结果，再次向 Broker 发送 COMMIT 或 ROLLBACK 指令，确保消息状态最终一致。

消息队列是参考哪种设计模式？

发布订阅模式（核心）：

模式定义：生产者（发布者，Publisher）将消息发送到一个 “中间媒介”（消息队列的 Broker），消费者（订阅者，Subscriber）通过订阅该媒介接收消息。发布者和订阅者之间完全解耦，彼此不知道对方的存在，仅通过中间媒介通信。

在消息队列中的体现：
- 生产者（Publisher）：向消息队列的特定主题（Topic）或队列（Queue）发送消息，无需关心谁会消费。
- 消息队列 Broker：作为中间媒介，负责存储消息、管理订阅关系，并将消息推送给订阅者（或供订阅者拉取）。
- 消费者（Subscriber）：订阅感兴趣的主题 / 队列，接收并处理消息，无需关心消息来自哪个生产者。
观察者模式：

模式定义：对象（主题）维护一个依赖列表（观察者），当主题状态变化时，自动通知所有观察者并触发其更新。

与消息队列的关联：消息队列的 “订阅 - 通知” 机制本质上是观察者模式的分布式扩展。例如，当主题（Topic）有新消息时，Broker 会主动通知所有订阅该主题的消费者（观察者），触发消费逻辑。

区别：观察者模式通常是进程内的同步通知，而消息队列通过 Broker 实现跨进程、跨服务的异步通知，更适合分布式系统。

RocketMQ和Kafka的区别是什么？如何做技术选型？

kafka优缺点
- 优点：Kafka 的优点在于其超高的吞吐量，单节点即可轻松轻松支持十万级 TPS，集群部署下能应对百万级消息流转，尤其适合日志采集、大数据同步等海量数据场景。它与大数据生态如 Flink、Spark、Hadoop 等深度集成，是实时数据管道的事实标准，在流处理场景中应用广泛。同时，其开源历史悠久，全球社区活跃，文档丰富，问题解决方案多，且提供多种语言的客户端，对非 Java 技术栈更友好。在存储和扩展方面，消息按分区存储，支持数据分片和水平扩展，通过日志分段和索引机制优化了存储效率。
- 缺点：其可靠性配置复杂，默认配置下有消息丢失风险，需手动开启副本同步、调整刷盘策略才能达到较高可靠性；功能相对基础，不原生支持事务消息、定时消息等高级特性，需业务层自行实现；默认配置下延迟为毫秒级，虽可优化但仍不及部分竞品；运维成本高，分区、副本等参数需手动调优，对运维人员专业度要求高。
rocketmq优缺点
- 优点：RocketMQ 的优势体现在极强的可靠性上，原生支持多副本同步、同步刷盘机制，能保障消息零丢失，适合金融交易等核心业务场景。它内置了事务消息、定时消息、重试机制等丰富的高级特性，开箱即用，降低了业务开发复杂度。其延迟性能优异，单节点延迟可达微秒级，适合实时通讯等对响应速度敏感的场景。同时，它与 Spring Cloud、Dubbo 等主流 Java 框架无缝衔接，API 设计符合 Java 开发者习惯，开发效率高，且提供可视化控制台，参数配置简洁，运维简单，中小团队也能快速部署，云原生支持也较好。
- 缺点：但 RocketMQ 的吞吐量略逊于 Kafka，单节点 TPS 为万级，虽能满足大部分企业级场景，但在超大规模数据吞吐上稍显不足；生态偏向 Java 技术栈，非 Java 客户端的成熟度和功能完整性不如 Kafka，多语言团队使用成本较高；国际化文档和社区支持较弱，核心维护力量以国内团队为主，英文文档和海外社区活跃度不及 Kafka；与大数据工具的集成度也一般，在纯大数据流处理场景中适配成本略高。

如何做技术选型？

业务单一收发消息以及需要很高的吞吐量并且接收小部分的消息丢失优先选择kafka
需要极高的消息可靠性，技术栈为java，且需要用到消息的高级特性，事务消息，延迟队列等，直接选择rocketmq。

rocketm延时消息的原理

底层实现核心流程

延时消息的生命周期可分为 “存储→等待→转发→消费” 四个阶段，核心依赖内部延时主题和定时调度服务。

消息发送：路由至内部延时主题

当生产者发送延时消息时（通过设置Message#delayTimeLevel指定级别），Broker 接收到消息后会执行以下操作：

修改主题：将消息的目标主题（用户指定的 topic）临时改为内部延时主题SCHEDULE_TOPIC_XXXX（ RocketMQ 预留的系统主题，专门存储延时消息）。
计算到期时间：根据延时级别对应的时间，计算消息的到期时间（到期时间 = 发送时间 + 延时级别对应的毫秒数），并将其存入消息属性中。
持久化存储：消息被写入 Broker 的 CommitLog（全局消息日志），并通过 ConsumeQueue（消息消费索引）建立SCHEDULE_TOPIC_XXXX的索引，便于后续快速查询。

等待阶段：定时任务监控到期消息

Broker 端的ScheduleMessageService是延时消息的核心调度组件，负责监控SCHEDULE_TOPIC_XXXX中消息的到期状态，具体逻辑如下：

按级别分队列：SCHEDULE_TOPIC_XXXX包含多个队列，每个队列对应一个延时级别（例如，队列 0 对应级别 1，队列 1 对应级别 2，以此类推）。这种设计确保同级别延时消息集中存储，避免跨级别扫描的性能损耗。
定时扫描：ScheduleMessageService为每个延时级别启动一个定时任务（基于Timer或线程池实现），定期扫描对应队列的 ConsumeQueue，检查消息是否到期（当前时间 >= 消息到期时间）。
高效索引：ConsumeQueue 中存储了消息在 CommitLog 中的偏移量和到期时间，定时任务通过遍历 ConsumeQueue 即可快速定位到期消息，无需全量扫描 CommitLog。

转发阶段：将到期消息投递至目标主题

当定时任务检测到到期消息后，ScheduleMessageService会执行转发操作：

恢复目标主题：将消息的主题从SCHEDULE_TOPIC_XXXX改回用户最初指定的目标主题（例如user_topic）。
重新存储与索引：修改后的消息会被重新写入 CommitLog（此时消息内容不变，仅主题变更），并为目标主题的 ConsumeQueue 建立新索引，确保消费者可从目标主题中获取消息。
原子性保证：转发过程通过 Broker 的事务机制确保原子性，避免消息丢失或重复转发（例如，通过 CommitLog 的事务标记确认消息已成功转发）。

消费阶段：消费者获取并处理消息

消息转发至目标主题后，消费者通过正常的消费流程（从目标主题的 ConsumeQueue 拉取消息）获取并处理消息，此时消息已与普通消息无差异。

RocektMQ怎么处理分布式事务？

利用事务消息，假如a给b转100块钱，即a-100，b+100，则在Broker端向a确认消息后，a会执行本地事务。其他与事务消息一致。

b+100并且返回ack给broker才会被认为消费成功，若b+100不成功，则Broker会重试消息，直到消费成功，或者重试次数达到限制，若重试次数达到限制仍然消费失败则进入兜底补偿策略
补偿策略：
- 死信队列（DLQ）收集失败消息：当消息重试达到最大次数仍失败时，Broker 会将消息转入 “死信队列”（专门存储无法消费的消息）。
- 监听死信队列触发补偿：系统可监听死信队列，当发现 “A 转 B” 的消息进入死信队列时，触发补偿逻辑：
  - 自动执行 A 的 “回滚操作”（A 的余额 + 100），并记录日志（如 “转账失败，A 已退款”）。
  - 若自动回滚失败（如 A 账户已发生其他操作），则触发告警，由人工介入处理（如手动调整 A 和 B 的余额）。

RocketMQ消息顺序怎么保证？

RocketMQ 保证消息顺序的核心思路是 “分区有序”，即通过将需要保持顺序的消息发送到同一个队列（Queue）中，利用队列的 FIFO（先进先出）特性实现局部有序，再结合消费端的串行处理确保最终顺序一致。

生产端：确保消息按顺序进入同一队列

要保证同一类消息的顺序，需通过以下机制将其路由到同一个队列：

指定消息队列选择器（MessageQueueSelector）
生产者发送消息时，通过自定义 MessageQueueSelector，根据业务标识（如订单 ID）计算队列索引，确保相同标识的消息被发送到同一个队列。
禁止异步发送重试若使用异步发送且失败重试，重试消息可能被发送到其他队列，破坏顺序。因此需使用同步发送，或确保重试时仍路由到原队列。

服务端：队列的 FIFO 存储特性

RocketMQ 的队列（Queue）是 严格有序的存储结构：

消息写入队列时，按发送顺序追加存储（先发送的消息在队列中位置更靠前）。
消息在 CommitLog（全局日志）中虽然可能乱序存储，但每个队列的 ConsumeQueue（消费索引）会记录消息在 CommitLog 中的偏移量，确保消费时能按队列顺序读取。

消费端：确保消息按顺序处理

即使消息在队列中有序，若消费端并行处理仍会导致顺序混乱，因此需：

单线程消费
消费者注册回调函数时，通过 MessageListenerOrderly 接口（而非并发消费的 MessageListenerConcurrently），确保同一队列的消息被 单线程串行处理。
底层原理：消费端对每个队列加锁，同一时刻只有一个线程处理该队列的消息，处理完一条再处理下一条。
禁止消费重试乱序
若消息消费失败，重试消息会被发回原队列尾部（而非插入原位置），可能导致顺序问题。因此需在业务代码中确保消费逻辑可重试，或在失败时人工介入处理。

RocketMQ怎么保证消息不被重复消费

消费端幂等处理
服务端消息去重

RocketMQ消息积压了，怎么办？

扩容，暂停消费端非核心线程，提高消息处理速度，将不重要的消息处理异步化，消息迁移至临时主题，由专门的消费组处理。

对Kafka有什么了解吗？

高吞吐量：消息以磁盘顺序写入（避免随机 IO），并通过页缓存（Page Cache）减少磁盘直接读写。支持批量发送 / 拉取消息，减少网络请求次数。分区机制实现并行处理，单 Broker 可轻松支持每秒数十万条消息的吞吐。
高可靠性：
- 副本机制：通过多副本同步（ISR 机制，In-Sync Replicas）确保数据不丢失（可配置 min.insync.replicas 控制写入可靠性）。
- 持久化：消息被持久化到磁盘，即使 Broker 宕机，重启后可恢复数据。
低延迟：结合页缓存和零拷贝（Zero-Copy）技术，消息从 Broker 到消费者的传递延迟可低至毫秒级。
容错性：支持集群部署，避免故障宕机。

Kafka 为什么这么快？

一、磁盘存储：顺序写入 + 页缓存，突破磁盘 IO 瓶颈

传统消息系统（如早期的 RabbitMQ）常因随机磁盘 IO 导致性能低下（磁盘磁头频繁移动，效率极低），而 Kafka 通过对磁盘存储的优化，让磁盘 IO 不再成为瓶颈。

顺序写入而非随机写入
Kafka 的消息在分区（Partition）内按追加（Append） 方式写入，即新消息永远追加到分区文件的末尾，避免了随机读写（如修改、删除中间数据）。
- 磁盘的顺序写入速度接近内存（机械硬盘顺序写入可达 100MB/s 以上，SSD 更高），而随机写入速度可能只有几 MB/s，差距高达 10-100 倍。
- 同时，Kafka 会定期将小文件合并为大文件（Log Compaction 机制），减少磁盘碎片，进一步提升读写效率。
利用操作系统页缓存（Page Cache）
Kafka 不自己实现缓存，而是直接依赖操作系统的页缓存（内存中的一块区域，用于缓存磁盘文件数据）：
- 消息写入时，先写入页缓存，由操作系统后台异步将数据刷入磁盘（可通过 flush.ms 控制刷盘频率），避免了应用程序直接操作磁盘的开销。
- 消息读取时，优先从页缓存命中（内存读写），只有未命中时才读取磁盘，极大减少了磁盘 IO 次数。
- 页缓存由操作系统管理，比应用程序自建缓存更高效（如利用预读、缓存淘汰算法等）。

二、并行处理：分区机制最大化利用集群资源

Kafka 通过分区（Partition） 实现了天然的并行性，将消息处理压力分散到多个节点和线程，是高吞吐量的核心保障。

分区是并行的最小单位
- 每个 Topic 被划分为多个分区，分区独立存储、独立处理读写请求，且不同分区可分布在不同 Broker 节点上。
- 生产者可向多个分区并行发送消息，消费者组（Consumer Group）的多个消费者可并行消费不同分区的消息（消费者数量 ≤ 分区数量时，无空闲消费者）。
- 例如：一个 Topic 有 10 个分区，分布在 3 个 Broker 上，生产者可同时向 10 个分区写消息，消费者组可启动 10 个消费者并行读取，吞吐量随分区数量线性提升（只要集群资源足够）。
副本机制不阻塞主流程
为保证可靠性，Kafka 为分区设置多个副本（Replica），但 Leader 副本处理读写请求，Follower 副本异步同步 Leader 数据（通过拉取机制）。
- 生产者写入消息时，只需等待 Leader 写入成功（或配置 acks 等待部分副本同步），无需等待所有副本完成，避免了同步阻塞对性能的影响。
- 副本同步通过 ISR（In-Sync Replicas） 机制优化：只要求 “活跃的副本”（与 Leader 保持同步的副本）同步数据，不等待故障副本，进一步提升效率。

三、网络传输：零拷贝 + 批量处理，减少数据拷贝和请求开销

网络传输是消息系统的另一大开销，Kafka 通过 “零拷贝” 和 “批量处理” 大幅降低了网络传输的 CPU 和时间成本。

零拷贝（Zero-Copy）技术
传统消息系统中，消息从 Broker 磁盘到消费者的传输需经过多次数据拷贝和状态切换：
```
磁盘 → 内核缓冲区（OS Page Cache）→ 用户缓冲区（应用程序）→ 内核 socket 缓冲区 → 网络网卡
```
每次拷贝都涉及用户态与内核态的切换（上下文切换开销大）。

Kafka 利用操作系统的 sendfile 系统调用实现零拷贝：
- 数据直接从 内核缓冲区（Page Cache） 拷贝到 网卡缓冲区，跳过了用户态的应用程序缓冲区，减少 2 次数据拷贝和 2 次上下文切换。
- 对于大消息场景，零拷贝可将性能提升 30% 以上。
批量发送与拉取
- 生产者（Producer）可配置 batch.size（批量大小，默认 16KB）和 linger.ms（等待时间，默认 0），当消息积累到指定大小或等待时间到达后，批量发送到 Broker，减少网络请求次数（一次请求传输多条消息）。
- 消费者（Consumer）通过 fetch.min.bytes 和 fetch.max.wait.ms 配置，批量拉取消息（积累到一定大小或等待一定时间后拉取），同样减少网络交互。
- 批量处理能显著降低单位消息的网络开销（如 TCP 握手、头部信息等）。

四、轻量设计：简化功能，减少额外开销

Kafka 为追求高性能，刻意简化了部分功能，避免不必要的处理开销：

不支持复杂的消息路由（如 RabbitMQ 的交换机、路由键），只按 Topic + 分区进行简单路由，减少 Broker 的处理逻辑。
不存储消息的复杂元数据（如消息优先级、过期时间等），只记录偏移量（Offset）和基础属性，降低存储和处理成本。
消息一旦写入分区，默认不支持修改或删除（仅通过 Log Retention 机制定期清理旧数据），避免了磁盘随机修改的开销。

五、消费者拉取模式：按需消费，避免压力堆积

Kafka 采用消费者主动拉取（Pull） 消息的模式，而非 Broker 推送（Push）：

消费者可根据自身处理能力调整拉取频率和批量大小，避免被 Broker 强制推送大量消息导致过载。
Broker 只需被动等待拉取请求，无需维护每个消费者的状态（如缓存待推送消息），减少了 Broker 的内存和 CPU 消耗。

消息推送模型和kafka拉取模型介绍一下

一、消息推送模型（Push Model）

核心逻辑

Broker 作为主动方，一旦检测到新消息到达，会直接将消息推送给已订阅的消费者，无需消费者主动请求。

消费者启动时需向 Broker 注册订阅关系，Broker 会维护消费者的连接状态和订阅信息。
消息到达 Broker 后，Broker 立即通过已建立的连接将消息 “推” 给消费者。

典型场景与案例

适用于实时性要求极高的场景，如即时通讯（IM）、实时通知（短信、APP 推送）、监控告警等。
代表系统：RabbitMQ（默认模式）、MQTT 协议、WebSocket 推送等。

优点

实时性强：消息到达后无延迟推送，消费者无需等待，能最快获取消息。
消费者实现简单：消费者只需专注于消息处理逻辑，无需设计 “何时拉取消息” 的逻辑，开发成本低。

缺点

消费者压力不可控：Broker 无法感知消费者的实际处理能力，若消费者处理速度慢，Broker 持续推送可能导致消费者缓冲区溢出、线程阻塞甚至崩溃（即 “推送风暴”）。
Broker 负担重：Broker 需维护每个消费者的连接状态、消费进度等信息，还需实现复杂的流量控制策略（如限制推送速率），增加了 Broker 的内存和 CPU 开销。
灵活性差：消费者无法自主控制消息获取节奏（如 “批量拉取 100 条再处理”），只能被动接受 Broker 的推送频率。

二、Kafka 的消息拉取模型（Pull Model）

核心逻辑

消费者作为主动方，通过向 Broker 发送 “拉取请求（Pull Request）” 获取消息，Broker 仅在收到请求后返回消息。

消费者需自主决定拉取时机（如定时拉取或按需触发），并在请求中指定目标分区和起始偏移量（Offset）。
Broker 收到请求后，返回分区中偏移量之后的消息（可配置批量大小）。

Kafka 拉取模型的关键设计

基于偏移量（Offset）的进度管理：
消费者通过记录 “已消费到的偏移量”（保存在 Kafka 内部的 __consumer_offsets 主题或本地），自主控制下次拉取的起点，Broker 无需跟踪每个消费者的进度，极大降低了 Broker 负担。
可配置的拉取策略：
消费者通过参数灵活控制拉取行为，平衡实时性和效率：
- fetch.min.bytes：拉取的最小数据量，不足时 Broker 会等待（避免频繁拉取小批量消息，减少网络交互）。
- fetch.max.wait.ms：最大等待时间，若未达到 fetch.min.bytes，到时间后也会返回消息（避免无限等待，保证一定实时性）。
- max.poll.records：单次拉取的最大消息条数，防止消费者一次性接收过多消息导致处理过载。
分区并行拉取：
消费者组（Consumer Group）的多个消费者可分别拉取不同分区的消息，通过分区并行性提升整体拉取效率，适配高吞吐场景。

优点

消费者主导节奏：消费者可根据自身处理能力（如 CPU、内存负载）调整拉取频率和批量大小，避免过载（例如处理快时多拉取，处理慢时少拉取）。
Broker 负担轻：Broker 无需维护消费者状态，仅被动响应拉取请求，资源消耗低，适合大规模集群和高吞吐场景。
灵活性高：支持批量拉取（减少网络交互）、按偏移量回溯消费（如重新处理历史数据）、暂停 / 恢复拉取等操作，适配复杂业务（如大数据批处理）。

缺点

实时性受拉取频率影响：消息到达后需等待消费者下一次拉取请求才能送达，若拉取间隔长，可能增加延迟（可通过缩短拉取间隔缓解，但会增加网络开销）。
消费者实现复杂：消费者需自行管理拉取频率、偏移量记录、重试逻辑（如拉取失败时重试），开发成本略高。
空轮询问题：若 Broker 暂无新消息，拉取请求可能返回空结果，导致 “空轮询” 浪费资源（Kafka 通过 fetch.max.wait.ms 缓解：Broker 会等待一段时间再返回空结果，减少请求次数）。

Kafka 如何保证顺序读取消息？

一、分区内消息的写入有序性

Kafka 的消息顺序保障首先依赖于 “分区（Partition）” 这一核心设计，分区是 Kafka 实现顺序性的基础单位：

分区内消息的追加写入
每个 Topic 被划分为多个分区，生产者发送的消息会被分配到指定分区（通过分区器或自定义路由策略）。同一分区内的消息采用 “追加写入” 方式（类似日志文件），即新消息永远追加到分区文件的末尾，不允许修改或插入中间位置。
- 这种写入方式确保了分区内的消息严格按照发送顺序存储，先发送的消息在分区中位置更靠前，后发送的消息位置更靠后。
- 例如：生产者向分区 0 依次发送消息 A、B、C，分区 0 中消息的存储顺序一定是 A → B → C。
分区间无序性
需注意：不同分区间的消息无法保证顺序。因为消息可能被分配到不同分区，而不同分区的写入和处理是并行的，因此跨分区的消息顺序无法保证（这是 Kafka 权衡吞吐量和顺序性的结果）。

二、偏移量（Offset）与顺序读取

Kafka 通过 偏移量（Offset） 标识分区内每条消息的位置，消费者通过按偏移量递增的顺序拉取消息，实现顺序读取：

偏移量的定义
每个分区内的消息都有一个唯一的、从 0 开始递增的整数偏移量（如 0、1、2、3…），用于唯一标识消息在分区中的位置。偏移量越大，消息越新（后写入）。
- 例如：分区 0 中消息 A 的偏移量为 0，B 为 1，C 为 2，严格按发送顺序递增。
消费者按偏移量顺序拉取
消费者拉取消息时，会指定一个 “起始偏移量”，Broker 则返回该偏移量之后的所有消息（按偏移量从小到大的顺序）。
- 消费者处理完一批消息后，会提交 “已消费到的最大偏移量”（如处理完偏移量 0-2 的消息后，提交偏移量 2）。
- 下次拉取时，消费者会从已提交偏移量的下一个位置（如 3）开始拉取，确保消息按顺序被处理，不重复、不遗漏。
偏移量的持久化
消费者提交的偏移量会被持久化存储（早期存在 ZooKeeper 中，Kafka 2.8+ 可存储在内部主题 __consumer_offsets 中），即使消费者重启，也能从上次提交的偏移量继续拉取，保证顺序性不中断。

三、消费者组与分区的绑定

为避免多消费者并行处理导致的顺序混乱，Kafka 通过 “消费者组（Consumer Group）” 机制确保每个分区仅被一个消费者处理：

分区分配策略
消费者组中的多个消费者会通过 “分区分配策略”（如 Range、RoundRobin）分配到不同的分区，每个分区在同一时刻仅被组内一个消费者消费。
- 例如：一个 Topic 有 3 个分区，消费者组有 2 个消费者，则可能消费者 1 处理分区 0 和 1，消费者 2 处理分区 2。
单消费者串行处理分区消息
由于一个分区仅被一个消费者处理，且该消费者会按偏移量顺序拉取消息，因此能保证单个分区的消息被串行处理，避免多线程并行导致的顺序错乱。
- 即使消费者内部使用多线程，也需确保同一分区的消息被同一个线程处理（如通过分区号哈希绑定线程），否则可能破坏顺序。

kafka 消息积压怎么办？

增加消费者实例可以提高消息的消费速度，从而缓解积压问题。你需要确保消费者组中的消费者数量不超过分区数量，因为一个分区同一时间只能被一个消费者消费。

增加 Kafka 主题的分区数量可以提高消息的并行处理能力。在创建新分区后，你需要重新平衡消费者组，让更多的消费者可以同时消费消息。

Kafka为什么一个分区只能由消费者组的一个消费者消费？这样设计的意义是什么？

如果两个消费者负责同一个分区，那么就意味着两个消费者同时读取分区的消息，由于消费者自己可以控制读取消息的offset，多个消费者同时提交该分区的偏移量，导致偏移量混乱（例如，C1 提交 offset=100，C2 同时提交 offset=80，覆盖了正确进度）。，因为这就相当于多线程读取同一个消息，会造成消息处理的重复，且不能保证消息的顺序。

消费线程数和分区数的关系是怎么样的？

线程数不应超过分区数，否则多余的线程会处于空闲状态

Kafka如何做到高可用？

一、核心：分区多副本（Replica）机制

Kafka 最核心的高可用设计是分区副本，通过为每个分区创建多个副本，实现数据冗余和故障容错。

副本角色与职责

Leader 副本：每个分区有且仅有一个 Leader 副本，负责处理所有生产者的写入请求和消费者的读取请求（所有读写操作只与 Leader 交互）。
Follower 副本：每个分区可以有多个 Follower 副本（数量由 replication.factor 配置，通常设为 3），仅负责从 Leader 副本同步数据（通过拉取机制），不处理客户端请求。
ISR 集合（In-Sync Replicas）：与 Leader 保持同步的副本集合（包括 Leader 自身）。Follower 需在 replica.lag.time.max.ms（默认 30 秒）内完成与 Leader 的数据同步，否则会被踢出 ISR。只有 ISR 中的副本才有资格参与 Leader 选举（确保数据一致性）。

副本同步与数据可靠性

生产者写入消息时，Leader 接收消息后，会异步将消息同步给所有 ISR 中的 Follower。
可通过生产者参数acks 控制写入可靠性：
- acks=1（默认）：仅 Leader 写入成功即返回，性能好但可能丢失数据（若 Leader 宕机且 Follower 未同步）。
- acks=-1（或 all）：需所有 ISR 副本写入成功才返回，可靠性最高（但性能略低）。
- 配合 min.insync.replicas（默认 1）：可设置 “至少多少个 ISR 副本写入成功才确认”（如设为 2，确保 Leader + 1 个 Follower 同步成功）。

二、故障自动转移：Leader 选举与控制器（Controller）

当 Leader 副本所在的 Broker 宕机或故障时，Kafka 会自动从 ISR 中选举新的 Leader，确保分区服务不中断，这一过程由控制器（Controller） 协调。

控制器的作用

控制器是 Kafka 集群中的一个特殊 Broker，负责管理整个集群的 Leader 选举、分区分配、Broker 上下线等元数据变更。
控制器通过 ZooKeeper（或 KRaft 模式下的元数据分区）监控集群状态，当检测到 Broker 宕机时，立即触发该 Broker 上所有分区的 Leader 重新选举。

Leader 选举机制

当 Leader 故障（如 Broker 宕机），控制器会从该分区的 ISR 集合中选举新 Leader（通常优先选择同步最完整的 Follower，或按 “最小 ID” 等策略）。
选举完成后，控制器将新 Leader 信息广播给所有 Broker 和客户端，客户端自动切换到新 Leader 进行读写。
整个过程通常在秒级完成，对客户端几乎透明（客户端会自动重试连接新 Leader）。

Kafka和RocketMq的生产者消息确认机制

Kafka 的生产者确认（基于副本同步）

Kafka 通过 acks 参数控制消息写入的确认级别，核心关注 “消息是否被足够多的副本同步”，以平衡可靠性和性能：

acks=0：生产者发送消息后立即返回成功，不等待 Broker 确认。
- 优点：性能最高；缺点：消息可能丢失（如 Broker 宕机）。
acks=1（默认）：仅等待Leader 副本写入成功后返回确认。
- 优点：性能与可靠性平衡；缺点：若 Leader 宕机且 Follower 未同步，消息可能丢失。
acks=-1（或 all）：需等待所有 ISR 副本（In-Sync Replicas，与 Leader 保持同步的副本）写入成功后返回确认。
- 优点：可靠性最高；缺点：性能略低（需等待多副本同步）。

补充：配合 min.insync.replicas 参数（默认 1），可进一步限制 “ISR 中至少多少个副本成功写入才确认”（如 acks=-1 + min.insync.replicas=2，确保 Leader + 1 个 Follower 同步成功）。

RocketMQ 的生产者确认（基于 Broker 持久化）

RocketMQ 的发送确认更关注 “消息是否被 Broker 接收并持久化”，不直接暴露副本同步的细节，而是通过返回状态码明确结果：

同步发送：生产者发送消息后，等待 Broker 处理完毕并返回状态（如 SEND_OK 表示成功）。
异步发送：生产者发送后立即返回，通过回调函数接收 Broker 的处理结果。
事务消息：通过两阶段提交确认（半消息发送 → 本地事务执行 → 提交 / 回滚确认）。

RabbitMq的特性有哪些？

**持久化机制：**RabbitMQ 支持消息、队列和交换器的持久化。当启用持久化时，消息会被写入磁盘，即使 RabbitMQ 服务器重启，消息也不会丢失。

**消息确认机制：**提供了生产者确认和消费者确认机制。生产者可以设置 confirm 模式，当消息成功到达 RabbitMQ 服务器时，会收到确认消息；消费者在处理完消息后，可以向 RabbitMQ 发送确认信号，告知服务器该消息已被成功处理，服务器才会将消息从队列中删除。

**镜像队列：**支持创建镜像队列，将队列的内容复制到多个节点上，提高消息的可用性和可靠性。当一个节点出现故障时，其他节点仍然可以提供服务，确保消息不会丢失。

**多种交换器类型：**RabbitMQ 提供了多种类型的交换器，如直连交换器（Direct Exchange）、扇形交换器（Fanout Exchange）、主题交换器（Topic Exchange）和头部交换器（Headers Exchange）。不同类型的交换器根据不同的规则将消息路由到队列中。例如，扇形交换器会将接收到的消息广播到所有绑定的队列中；主题交换器则根据消息的路由键和绑定键的匹配规则进行路由。