在 Apache RocketMQ 中，消息从生产端到消费端的过程中，有哪些机制能够确保消息的可靠投递？请分别从生产端、Broker 存储端以及消费端来进行说明。
考察说明
考察对 RocketMQ 消息投递可靠性保障机制的理解，涉及生产端、存储端和消费端三个环节。
回答思路
- 【回答框架 1】生产端可靠性主要依靠发送端的重试机制。默认情况下，同步发送失败会重试 2 次（可配置），通过设置 retryTimesWhenSendFailed 控制。异步发送失败通过回调处理并重试，确保消息不丢失。
- 【回答框架 2】Broker 端通过持久化存储保证可靠性，默认采用异步刷盘机制，性能高但可能丢失极少量数据；也可以配置为同步刷盘，确保消息落盘后返回成功，但性能相对较低。同时，Broker 采用主从复制，主节点宕机时可切换到从节点，避免数据丢失。
- 【回答框架 3】消费端通过消费进度和 ACK 机制保证消息不丢失。消费者消费成功后向 Broker 报告消费进度（Offset），Broker 会更新 Offset。如果消费失败且未报告进度，消息会进入重试队列，按照预设的重试次数进行重试，确保消息最终被处理。
- 【回答框架 4】对于极端情况，如消息重试多次仍失败，可以配置死信队列（DLQ）存储这些消息，以便人工介入处理，避免消息永久丢失。
- 【关键点 1】生产端依赖同步/异步发送的重试机制保证消息不丢失。
- 【关键点 2】Broker 端通过同步刷盘和主从复制提升数据持久化可靠性。
- 【关键点 3】消费端通过消费进度上报和重试队列确保消息至少被消费一次。
- 【关键点 4】死信队列用于处理重试多次仍失败的消息，保证消息不永久丢失。
- 【易错点 1】认为同步发送一定不丢，实际上极端情况（如网络故障）仍需重试和持久化配合。
- 【易错点 2】忽略消费端幂等性，RocketMQ 保证至少一次投递，但业务需要自行实现幂等处理。
- 【易错点 3】同步刷盘与异步刷盘的选择需权衡性能和可靠性，不能盲目追求同步刷盘。