面试题：消息队列中RocketMQ与Kafka在可靠性方面的对比分析

生产者：
- 同步发送确认：生产者以同步方式发送消息时，会等待MQ的确认响应，只有收到确认后才认为消息发送成功。如果发送失败，可根据重试策略进行重试。
- 异步发送回调：异步发送消息时，通过注册回调函数来处理发送结果。若发送失败，同样可进行重试。
消费者：
- 消费重试：当消费者消费消息失败时，RocketMQ会自动进行重试，默认重试16次。重试间隔会逐渐拉长。
- 消费幂等：消费者可通过实现LocalTransactionCheckListener接口，确保消息消费的幂等性，避免重复消费造成的问题。
MQ自身：
- 持久化：RocketMQ采用CommitLog和ConsumeQueue机制，将消息持久化到磁盘。CommitLog存储所有消息，ConsumeQueue为消费队列提供索引，保证即使MQ重启，消息也不会丢失。
- 主从架构：通过主从复制机制，将消息复制到多个从节点，提高数据的可靠性和可用性。主节点故障时，从节点可切换为主节点继续提供服务。

生产者：
- acks参数：生产者发送消息时可设置acks参数。acks=0表示生产者发送完消息后不等待任何确认；acks=1表示生产者等待Leader副本确认；acks=all（或acks=-1）表示生产者等待所有ISR（In - Sync Replicas，与Leader副本保持同步的副本集合）中的副本确认，确保消息不会因为Leader副本故障而丢失。
- 重试机制：当发送失败时，Kafka生产者会根据配置的重试次数和重试间隔进行重试。
消费者：
- 手动提交偏移量：消费者可通过手动提交偏移量的方式，确保已消费的消息不会被重复消费。在处理完一批消息后，再提交偏移量，可避免消息丢失。
- 幂等性生产者：从Kafka 0.11.0.0版本开始支持幂等性生产者，通过PID（Producer ID）和Sequence Number保证消息的幂等性，避免重复消息。
MQ自身：
- 多副本机制：Kafka通过多副本机制，将消息复制到多个副本中。ISR中的副本都与Leader副本保持同步，当Leader副本故障时，会从ISR中选举新的Leader副本，保证数据不丢失。
- 日志分段与清理：Kafka的日志以分段的形式存储，并且支持根据一定的策略进行日志清理，保证磁盘空间的合理使用，同时不会丢失重要的未消费消息。

RocketMQ：
- 优点：
  - 消费重试机制灵活：默认提供16次重试，且重试间隔逐渐拉长，更符合实际业务场景中可能遇到的临时性故障恢复需求。
  - 支持事务消息：可实现分布式事务，保证消息发送和本地事务的最终一致性，适用于对事务性要求较高的场景。
- 缺点：
  - 架构相对复杂：RocketMQ的CommitLog和ConsumeQueue机制，以及主从架构等，使得其架构理解和运维难度相对较高。
Kafka：
- 优点：
  - 高吞吐量：Kafka的多副本机制和日志分段清理策略，使其在处理大量消息时具有极高的吞吐量，适合大数据领域的实时数据处理场景。
  - 简单易用：Kafka的架构相对简单，尤其是在消息生产和消费方面，使用起来较为方便，容易上手。
- 缺点：
  - 消费重试需手动实现：不像RocketMQ有默认的消费重试机制，Kafka需要开发者手动实现消费重试逻辑。
  - 事务支持有限：虽然从0.11.0.0版本开始支持幂等性生产者，但与RocketMQ完整的事务消息功能相比，在分布式事务处理能力上相对较弱。

星途面试题库