消息队列能解耦、削峰、异步化，但它也会把系统可用性的一部分压到 MQ 上。只要业务链路依赖 MQ，就必须回答一个问题：如果某个队列节点挂了，消息还能不能写、能不能读、会不会丢、恢复后怎么继续。
不同 MQ 的高可用模型不一样。RabbitMQ 更容易从“队列在哪个节点上”理解，Kafka 更容易从“Topic、Partition、Replica 和 Leader”理解。把这两类模型分清，就不会把“集群”和“高可用”混成一个词。
先分清三件事
讨论 MQ 高可用，至少要分清三层：
- 服务是否可用：节点挂了以后，生产者和消费者还能不能连接并继续工作。
- 数据是否可靠：已经写入的消息是否会丢。
- 吞吐是否可扩展：增加节点后，读写能力是否能线性提升。
很多方案只能解决其中一部分。
例如，一个普通集群可能让客户端连接入口更多，但某个队列的数据仍然只在一个节点上。它看起来是集群，却不一定能保证队列级别高可用。
再比如，一个强复制方案可以提高数据可靠性，但每条消息都要同步到多个节点，会增加网络和写入成本，吞吐未必更好。
所以 MQ 高可用不是“多起几个节点”这么简单，而是要看消息实际存在哪里、故障时谁接管、复制策略是什么。
RabbitMQ 单机模式：只适合开发和低风险场景
RabbitMQ 单机模式最好理解：一个节点，一个 Broker，队列和消息都在这台机器上。
它适合：
- 本地开发；
- Demo；
- 临时测试；
- 对消息可靠性要求很低的小工具。
它不适合作为关键生产链路。因为机器、磁盘、进程或网络一旦出问题，生产和消费都会受影响。即使开启持久化，也只能降低进程重启后的消息丢失风险，不能解决节点不可用时的服务连续性问题。
单机模式的问题不是 RabbitMQ 特有，而是任何单点系统都会有的问题。
RabbitMQ 普通集群：元数据分散，队列数据不一定分散
RabbitMQ 普通集群会在多个节点之间同步交换机、队列等元数据。但一个队列的消息通常仍然主要位于创建它的那个节点上。
这带来一个容易误解的地方：集群里有多个 RabbitMQ 节点，不代表每个队列的数据都复制到了每个节点。
如果消费者连接到了不持有该队列数据的节点，可能需要跨节点拉取。这样能让客户端连接更灵活，但也会带来额外网络开销。
普通集群更偏向于：
- 管理多个节点；
- 分散不同队列的负载；
- 提供多个连接入口；
- 提升整体吞吐。
但如果某个队列所在节点不可用，这个队列本身仍然会受影响。持久化消息可能等节点恢复后还能继续处理，但故障期间不等于无感切换。
所以普通集群不能简单等同于队列高可用。
RabbitMQ 镜像队列和仲裁队列：把队列复制到多个节点
为了提升队列可用性，RabbitMQ 需要队列级别复制。
旧版本里常见说法是镜像队列：一个队列的数据会复制到多个节点，其中一个作为主副本，其余作为镜像。主节点故障后，可以由镜像节点接管。
这种模式的好处很明显：
- 单个节点故障时，队列仍有机会继续服务；
- 消息不只保存在一个节点；
- 关键队列的可靠性更高。
代价也很明显：
- 每条消息需要复制，网络开销增加；
- 队列越热，同步压力越明显；
- 队列数据复制到多个节点，不等于可以无限横向扩展单个队列吞吐；
- 配置不当时，故障切换和数据一致性会变复杂。
新版本 RabbitMQ 更推荐使用 quorum queue，也就是仲裁队列。它基于 Raft 思路，更强调一致性和明确的复制语义。无论使用哪种模式，核心都一样：生产环境不要只停留在普通集群概念，要确认关键队列是否有复制和故障接管能力。
RabbitMQ 高可用还要配合持久化和确认机制
队列复制只是高可用的一部分。消息是否可靠，还要看持久化和确认机制。
常见要点包括：
- 队列声明为 durable；
- 消息设置为 persistent；
- 生产者使用 publisher confirm；
- 消费者处理完成后再 ack；
- 失败时明确重试、死信或补偿策略；
- 连接层面配置自动恢复和合理超时。
如果只做了集群，却没有生产确认，生产者可能以为消息发出去了，但 Broker 实际没确认。消费者如果提前 ack，业务处理失败后消息也可能丢失。
所以 MQ 可靠性要看整条链路，不只看服务端部署了几个节点。
Kafka 的模型：Topic 拆成 Partition
Kafka 的高可用和扩展性，要从 Partition 开始理解。
一个 Topic 可以拆成多个 Partition。每个 Partition 是一段有序日志，可以分布在不同 Broker 上。这样，一个 Topic 的数据可以天然分散到多台机器。
例如：
- Topic A 有 6 个 Partition；
- 集群有 3 个 Broker；
- 每个 Broker 上可以放一部分 Partition；
- 生产和消费可以围绕 Partition 并行。
Kafka 的扩展性很大程度来自这里：增加 Partition 和 Broker，可以让数据和流量分布到更多节点上。
但 Partition 本身仍然需要高可用，这就引出 Replica。
Kafka Replica：每个 Partition 有多个副本
Kafka 里，每个 Partition 可以有多个 Replica。副本会分布在不同 Broker 上。
其中一个 Replica 是 Leader，生产者写入 Leader，消费者通常也从 Leader 读取；其他 Replica 是 Follower，从 Leader 同步数据。
当 Leader 所在 Broker 故障时，如果其他副本仍然可用，Kafka 可以选出新的 Leader，继续对外服务。
这就是 Kafka 高可用的基础：
- Topic 通过 Partition 分散数据；
- Partition 通过 Replica 提供冗余；
- Leader 负责读写；
- Follower 负责同步；
- Leader 故障后从可用副本中重新选举。
理解这套模型以后，就能看懂为什么 Kafka 的 Topic 设计要考虑 Partition 数量、副本因子和 Broker 分布。
ISR 和 acks 决定写入可靠性
Kafka 里还有两个非常关键的概念：ISR 和 acks。
ISR 是 in-sync replicas，表示跟得上 Leader 的同步副本集合。不是所有副本都一定健康，只有仍然同步的副本才适合作为可靠候选。
生产者的 acks 决定写入确认策略：
acks=0：生产者不等 Broker 确认，吞吐高但风险大；acks=1：Leader 写入成功就确认，性能和可靠性折中；acks=all：等待 ISR 中副本满足条件后确认，可靠性更高但延迟更高。
如果业务更看重不丢消息，通常还会配合 min.insync.replicas。例如副本因子为 3，要求至少 2 个同步副本确认。这样即使一个 Broker 故障，也能保持较好的可靠性。
高可用配置不是越强越好。越强的确认策略意味着更高延迟和更低吞吐。关键是按业务场景选择，而不是所有 Topic 使用同一套参数。
RabbitMQ 和 Kafka 的差异
两者都能做消息系统，但高可用思路不同。
RabbitMQ 更像以队列为中心。你要关心队列模式、消息持久化、队列复制、确认机制和死信处理。它适合很多传统业务异步、任务分发和路由灵活的场景。
Kafka 更像以日志分区为中心。你要关心 Topic、Partition、副本因子、ISR、acks、消费者组和保留策略。它适合高吞吐日志、事件流、数据管道和可回放消费。
选择时不要只问“哪个更高可用”。更应该问：
- 消息是否需要复杂路由；
- 是否需要高吞吐顺序日志；
- 是否需要回放；
- 单队列或单分区是否会成为瓶颈；
- 业务能接受怎样的延迟；
- 消息丢失、重复和乱序分别能不能接受。
业务侧也要接受重复和补偿
即使 MQ 服务端做了高可用，业务侧也不能假设“消息只会被处理一次”。
更现实的设计是：
- 生产端可以重试；
- 消费端保证幂等；
- 关键业务有去重键；
- 失败消息进入重试队列或死信队列；
- 定期对账和补偿；
- 监控积压、失败率和消费延迟。
很多 MQ 事故不是 Broker 完全不可用，而是消息积压、消费者异常、重复消费、重试风暴或死信没人处理。这些问题需要业务和运维一起设计闭环。
小结
MQ 高可用要看消息实际怎样复制和接管。
RabbitMQ 普通集群更多解决节点管理和入口问题，关键队列要关注镜像队列或仲裁队列，同时配合持久化、生产确认和消费 ack。Kafka 则围绕 Topic、Partition、Replica、Leader、ISR 和 acks 建立高可用与扩展能力。
真正可靠的 MQ 方案不是只把服务端集群搭起来，还要让生产、消费、重试、死信、幂等、监控和补偿形成闭环。这样节点故障时系统能继续运行，消息异常时也有路可查、有办法补。
