面试题：从消息发送原理角度分析RocketMQ如何保证消息的高可用和一致性

底层原理：RocketMQ 生产者采用多副本机制。当生产者发送消息时，会选择一个主 Broker 进行消息发送，同时主 Broker 会将消息同步或异步复制到从 Broker。默认情况下，生产者会采用同步双写方式，即消息发送到主 Broker 后，主 Broker 会同步将消息写入至少一个从 Broker，只有当主从都写入成功，才会给生产者返回成功响应。
配置参数：通过 brokerRole 参数可以配置 Broker 角色，有 ASYNC_MASTER（异步主）、SYNC_MASTER（同步主）、SLAVE 等。SYNC_MASTER 能保证更高的可用性，但可能会影响消息发送性能。生产者端还可以通过 sendMsgTimeout 参数设置消息发送超时时间，避免长时间等待响应。
异常处理：若消息发送过程中主 Broker 未响应，生产者会进行重试，默认重试次数为 2 次。若重试后仍失败，根据 sendLatencyFaultEnable 参数决定是否剔除故障 Broker，若开启该参数，生产者会记录 Broker 的响应延迟和可用性，在后续发送中不再选择该故障 Broker。

底层原理：RocketMQ 采用基于文件系统的存储方式，每个 Broker 上有多个 CommitLog 文件，所有主题的消息都顺序写入 CommitLog。同时，为了便于消息的快速查询，采用了 ConsumeQueue 这种索引结构，每个主题、每个队列都有对应的 ConsumeQueue，它存储了消息在 CommitLog 中的物理偏移量等信息。
配置参数：flushDiskType 参数决定了消息刷盘策略，有 ASYNC_FLUSH（异步刷盘）和 SYNC_FLUSH（同步刷盘）。SYNC_FLUSH 保证消息写入磁盘后才返回成功，提高数据可靠性，但性能相对较低；ASYNC_FLUSH 则是将消息写入内存后就返回成功，由后台线程异步刷盘，性能较高但存在一定数据丢失风险。
异常处理：若发生磁盘故障导致刷盘失败，若采用 SYNC_FLUSH，Broker 会返回错误给生产者，生产者进行重试；若采用 ASYNC_FLUSH，可能存在少量未刷盘消息丢失，但 Broker 仍能正常运行接收新消息。

底层原理：主从 Broker 之间通过数据同步机制保证消息一致性。主 Broker 接收到消息后，根据配置将消息同步或异步复制给从 Broker。同步复制时，主 Broker 等待从 Broker 确认消息写入成功；异步复制时，主 Broker 无需等待从 Broker 确认即可返回成功给生产者。
配置参数：通过 brokerRole 配置 Broker 角色来决定复制方式。ASYNC_MASTER 为异步复制，SYNC_MASTER 为同步复制。
异常处理：若从 Broker 复制消息失败，主 Broker 会记录异常并尝试重发。对于异步复制，若从 Broker 长时间未恢复，可能导致主从数据不一致，此时需要人工介入处理，如重新同步数据。

底层原理：在需要强一致性的场景下，使用 SYNC_MASTER 角色配置和 SYNC_FLUSH 刷盘策略。生产者发送消息，主 Broker 同步写入消息到磁盘并同步复制到至少一个从 Broker 后才返回成功，确保所有副本数据一致。
配置参数：设置 brokerRole 为 SYNC_MASTER，flushDiskType 为 SYNC_FLUSH。
异常处理：若主从同步或刷盘过程中出现异常，生产者会收到错误响应并进行重试，直到消息成功写入所有副本。

底层原理：采用 ASYNC_MASTER 角色配置和 ASYNC_FLUSH 刷盘策略。生产者发送消息，主 Broker 写入内存后即返回成功，同时异步将消息复制到从 Broker 并异步刷盘。虽然可能存在短暂的数据不一致，但最终所有副本数据会达到一致。
配置参数：设置 brokerRole 为 ASYNC_MASTER，flushDiskType 为 ASYNC_FLUSH。
异常处理：若从 Broker 复制或刷盘出现延迟，主 Broker 继续接收新消息，最终从 Broker 会追上主 Broker 的数据。若从 Broker 故障，恢复后会从主 Broker 重新同步数据。

星途面试题库