面试题：消息队列之RabbitMQ集群运维与高可用

Question

假设RabbitMQ集群中的一个节点出现故障，简述从故障检测到恢复服务的完整流程，以及如何确保消息的可靠性不丢失。同时说明在集群高可用方面，镜像队列和普通队列的区别及应用场景。

Answer 1

故障检测到恢复服务的完整流程

1. 故障检测：
   • RabbitMQ 自身有心跳机制，节点之间通过心跳检测彼此状态。若节点在一定时间内未收到其他节点的心跳，会标记该节点为不可达。
   • 管理员也可通过监控工具（如 RabbitMQ 管理界面、Prometheus + Grafana 等）实时查看节点状态，若节点状态显示异常，可确认故障。
2. 自动处理：
   • 对于镜像队列，RabbitMQ 集群会自动将镜像队列的主节点切换到其他健康的镜像节点上。其他节点会继续提供服务，应用程序无感知（只要连接配置的是集群地址，而非单个节点地址）。
   • 对于普通队列，若故障节点是队列所在节点，队列将不可用，应用程序发送和接收消息会失败。
3. 手动恢复：
   • 修复故障节点的硬件、网络或软件问题（如重启节点服务、修复网络连接等）。
   • 重新启动故障节点上的 RabbitMQ 服务。
   • 若使用的是镜像队列，该节点启动后，会自动同步队列状态，重新成为镜像队列的一部分。
   • 对于普通队列，若队列之前持久化且未在故障时丢失，节点恢复后队列会恢复正常；若队列未持久化且丢失，需重新创建队列及相关绑定关系等。

确保消息可靠性不丢失的方法

1. 消息持久化：
   • 生产者发送消息时，将消息设置为持久化（deliveryMode = 2）。这样消息会先写入磁盘，即使节点重启也不会丢失。
   • 队列声明时也设置为持久化，确保队列元数据在节点重启后依然存在。
2. 确认机制（publisher confirm）：
   • 生产者开启确认模式（channel.confirmSelect()），当消息成功到达 Broker 时，Broker 会返回确认（basicAck）给生产者，生产者可根据确认判断消息是否成功发送。若未收到确认，可进行消息重发。
3. 事务机制：
   • 生产者开启事务（channel.txSelect()），在发送消息后执行提交（channel.txCommit()）操作。若提交过程中出现异常，可回滚（channel.txRollback()）事务，确保消息不丢失。但事务机制会严重影响性能，一般不建议大量使用。
4. 镜像队列：
   • 采用镜像队列，将队列镜像到多个节点。当某个节点故障时，其他镜像节点可继续提供服务，消息不会丢失。

镜像队列和普通队列的区别及应用场景

1. 区别：
   • 高可用性：
     • 镜像队列：多个节点保存相同的队列副本，当主节点故障时，会自动切换到其他镜像节点，保证高可用性。
     • 普通队列：只存在于单个节点，若该节点故障，队列不可用。
   • 资源消耗：
     • 镜像队列：由于要在多个节点同步数据，会消耗更多的磁盘、网络和内存资源。
     • 普通队列：资源消耗主要集中在单个节点。
   • 数据同步：
     • 镜像队列：主节点和镜像节点之间实时同步消息和队列状态，确保数据一致性。
     • 普通队列：不存在节点间的数据同步问题。
2. 应用场景：
   • 镜像队列：适用于对消息可靠性和高可用性要求极高的场景，如金融交易系统、订单处理系统等，不允许消息丢失且需要保证服务始终可用。
   • 普通队列：适用于对成本敏感、对消息可靠性要求相对较低的场景，如日志收集、一些非关键业务的异步处理等，即使队列所在节点故障导致部分消息丢失，对整体业务影响不大。