面试题：消息队列之RocketMQ核心：高可用性实现

Question

RocketMQ是如何实现高可用性的？请详细阐述其主从架构、故障转移机制以及在集群环境下如何保证数据一致性。

Answer 1

主从架构

1. 多副本机制：RocketMQ采用Master-Slave架构，一个Master可以对应多个Slave。Master负责处理读写请求，Slave则作为Master的备份，实时从Master同步数据。例如，在一个简单的生产环境中，可能配置一个Master和两个Slave，这样就有了数据的多份副本。
2. 数据同步方式：Slave通过Pull方式从Master拉取数据进行同步。Master会将CommitLog中的数据发送给Slave，Slave接收到数据后，写入自己的CommitLog，并构建对应的ConsumeQueue等索引结构。

故障转移机制

1. Master故障检测：RocketMQ的Namesrv会定期检测Broker（包括Master和Slave）的心跳。如果Master在一定时间内没有向Namesrv发送心跳，Namesrv会判定该Master故障。同时，Slave也会检测与Master的连接状态，若连接断开且在一定时间内无法恢复，也会认为Master出现故障。
2. 读请求转移：当Master故障时，Consumer读取数据的请求会自动切换到Slave。由于Slave保存了Master的数据副本，因此可以继续为Consumer提供数据服务，保证消息的正常消费。例如，在电商订单消息消费场景中，即使Master出现故障，消费者端依然可以从Slave读取订单相关消息进行后续处理。
3. 写请求处理：Master故障后，新的写请求无法再发送到该Master。通常在这种情况下，需要运维人员介入，手动将Slave提升为Master（在某些自动故障转移策略下也可自动提升），以恢复系统的写能力。

集群环境下保证数据一致性

1. 同步刷盘与异步刷盘
   • 同步刷盘：Master在接收到消息并写入CommitLog后，会等待刷盘操作完成才向Producer返回成功响应。这种方式能确保数据在Master故障时不会丢失，但会稍微影响写入性能。例如，在金融交易消息场景中，为保证资金相关消息不丢失，会采用同步刷盘。
   • 异步刷盘：Master接收到消息写入CommitLog后，立即向Producer返回成功响应，同时异步执行刷盘操作。这种方式写入性能较高，但在Master故障时可能会丢失少量未刷盘的数据。在一些对数据一致性要求不是极高且追求高写入性能的场景，如普通日志消息记录，可采用异步刷盘。
2. 数据复制一致性：通过Slave从Master实时拉取数据进行同步，保证数据副本的一致性。同时，RocketMQ会对同步进度进行监控，确保Slave与Master的数据差距在可接受范围内。例如，若Slave长时间未成功同步数据，会触发相关告警，提示运维人员进行处理。
3. 事务消息一致性：RocketMQ支持事务消息，通过两阶段提交保证消息发送与本地事务执行的一致性。在分布式事务场景中，如电商下单同时扣减库存场景，先发送半消息到Broker，本地事务执行成功后再提交消息，若本地事务失败则回滚消息，确保数据一致性。