RocketMQ是阿里最核心的中间件之一，每天处理万亿级消息。理解它的可靠性保证体现了你对阿里基础设施和分布式消息系统的深度认知。
生产者端：同步发送加重试机制、事务消息实现本地事务与消息的原子性。
Broker端：同步刷盘与异步刷盘的权衡、主从同步复制（syncDoubleWrite模式）。
消费者端：业务成功后手动ACK、失败消息进重试队列、最终进死信队列。
端到端：消息轨迹追踪、定期对账机制。
RocketMQ从三个层面保证可靠性。生产者端，同步发送模式等待Broker确认后才返回成功，失败自动重试（默认2次）。对于需要本地事务和消息原子性的场景，事务消息采用半消息机制：消息对消费者不可见，直到本地事务提交，回查机制处理状态不明确的情况。Broker端，同步刷盘模式确保消息写入磁盘后才确认生产者，Dledger多副本同步保证副本间数据一致。消费者端，只有业务逻辑成功后才标记消息已消费——处理失败的消息进入重试队列，指数退避重试，达到最大次数后进入死信队列人工排查。同时在消费端用消息ID去重表实现幂等，安全处理重复投递。
区分"至少一次"和"恰好一次"语义——RocketMQ主要保证至少一次投递，精确一次靠应用层幂等实现。
了解同步刷盘（更安全但慢）和异步刷盘（更快但宕机有丢失风险）的权衡。
一定要提到事务消息——这是RocketMQ的独特亮点，面试官非常喜欢考察。
RocketMQ原生支持事务消息、延时消息和消息过滤，Kafka在日志流式处理的吞吐量上更强。RocketMQ专为业务消息设计，可靠性和功能丰富度优先于原始吞吐。
异步刷盘下消息可能丢失。开启同步刷盘后，Broker在磁盘写入完成后才确认，已确认的消息不会丢失。所以关键业务消息必须用同步刷盘。