面试题：消息队列里RocketMQ与Kafka在消息可靠性保障机制上的对比

消息不丢失
- 生产者：RocketMQ 生产者采用同步发送消息方式时，会等待 Broker 确认。若 Broker 未正常响应，生产者会收到异常，可进行重试。异步发送时，也可通过回调函数获取发送结果，若失败同样可重试。
- Broker：
  - RocketMQ 的 Broker 支持同步刷盘和异步刷盘两种方式。同步刷盘时，消息写入磁盘后才向生产者返回成功响应，确保消息不会因 Broker 宕机丢失。
  - 采用多副本机制（如 Dledger 模式），Master 节点将消息复制到 Slave 节点，当 Master 故障时，Slave 可切换为 Master，保证消息不丢失。
- 消费者：消费者采用拉模式，消费成功后才向 Broker 提交偏移量。若消费过程中出现异常，可根据偏移量重新消费消息。
消息不重复消费
- RocketMQ 提供了唯一的消息 ID，消费者在消费消息时可通过判断消息 ID 来避免重复消费。同时，消费者可以在业务层面实现幂等性操作，例如基于数据库唯一约束等方式，确保重复消息只产生一次实际业务影响。

消息不丢失
- 生产者：Kafka 生产者发送消息时可设置 acks 参数。当 acks = all 时，生产者会等待所有副本都确认收到消息才认为发送成功。若发送失败，可通过重试机制重新发送。
- Broker：Kafka 采用多副本机制，每个分区有多个副本，其中一个为 Leader，其余为 Follower。Leader 负责处理读写请求，Follower 从 Leader 同步数据。当 Leader 故障时，会从 Follower 中选举新的 Leader，确保数据不丢失。
- 消费者：Kafka 消费者采用拉模式，消费偏移量可由消费者自行控制。消费者可将偏移量保存到外部存储（如 Kafka 自身的 _consumer_offsets 主题或外部数据库），若消费失败，可根据保存的偏移量重新消费。
消息不重复消费：Kafka 消费者可以利用消息的偏移量和幂等性操作来避免重复消费。消费者可通过判断偏移量是否已处理过，若已处理则跳过。在业务层面，同样可实现幂等性操作，如对数据库进行操作时利用唯一键等方式保证重复消息不产生额外影响。

RocketMQ
- 优点：
  - 同步刷盘机制能更严格地保证消息在 Broker 端的可靠性，几乎可以做到消息零丢失。
  - 消息不重复消费实现相对简单，提供了消息 ID 方便消费者判断。
- 缺点：同步刷盘会影响性能，相比 Kafka 的异步刷盘，RocketMQ 在高吞吐量场景下性能可能稍逊一筹。同时，RocketMQ 的架构相对复杂，运维成本较高。
Kafka
- 优点：高吞吐量，异步刷盘和高效的网络设计使其在处理海量消息时性能卓越。多副本机制保证了数据的高可用性和可靠性。
- 缺点：在某些极端情况下，如 Leader 副本刚接收消息还未同步给 Follower 副本就发生故障，可能会丢失少量数据。而且 Kafka 本身不提供像 RocketMQ 那样简单的消息 ID 用于判断重复消费，需要消费者自行实现更复杂的逻辑。

RocketMQ：适用于对消息可靠性要求极高，如金融交易、订单处理等场景。这些场景不允许消息丢失或重复，RocketMQ 的同步刷盘和消息 ID 机制能很好地满足需求，虽然性能略有牺牲，但可通过集群部署等方式提升整体处理能力。
Kafka：适用于大数据领域，如日志收集、实时数据分析等场景。这些场景对吞吐量要求高，对少量消息丢失或重复相对容忍，Kafka 的高吞吐量和简单架构能高效处理海量数据。

星途面试题库