RabbitMQ 不同部署模式的CAP倾向

RabbitMQ 在 CAP 定理中的角色不是单一的，它会根据你选择的部署模式和配置，在 CP 和 AP 之间切换。

简单来说：

• 使用集群和镜像队列，RabbitMQ 倾向于 CP（一致性和分区容错性）。
• 使用联邦（Federation）或 Shovel 插件，RabbitMQ 则更偏向 AP（可用性和分区容错性）。

这个选择是 RabbitMQ 的一个核心特性，你可以根据自己的业务需求来决定是更看重数据一致性，还是服务可用性。

🧐 深入解析：两种核心模式

1. CP 倾向：集群 + 镜像队列（数据一致性优先）

当你在 RabbitMQ 中配置集群，并对关键队列启用镜像队列（Mirrored Queues） 时，系统会优先保证数据的一致性。

• 工作原理：镜像队列会在集群的多个节点上保存副本。所有操作（如发布消息）都会以相同顺序应用到主节点（Master）和所有镜像节点（Slave）上。这种“原子广播”机制确保了副本间数据的强一致性。
• 面对网络分区时的行为：当集群发生网络分区时（CAP 中的 P），为避免数据不一致（即“脑裂”），RabbitMQ 的默认策略是 pause_minority（暂停少数派）。集群会判断哪一侧的节点数量更多。少数派的节点会被自动暂停，不再提供服务。多数派的节点继续工作，保证了这部分节点数据的一致性。代价：牺牲了部分节点的可用性（A），换取了数据的一致性（C）。

2. AP 倾向：联邦（Federation）/ Shovel（高可用性优先）

当你的需求跨越多个数据中心，或网络连接不稳定时，RabbitMQ 的联邦（Federation） 和 Shovel 插件提供了另一种选择。

• 工作原理：这两个插件允许你在不同的 RabbitMQ 集群或 Broker 之间异步地、松耦合地复制消息。它们是“最终一致性”的，消息的复制不是实时的，会有延迟。
• 面对网络分区时的行为：由于联邦和 Shovel 本身就是为了在不可靠网络上工作而设计的，它们天然具备分区容错性（P）。当链路断开时，两端的 Broker 可以各自独立继续提供服务，保证了可用性（A）。
• 代价：在网络恢复前，两端的消息状态可能不一致，牺牲了强一致性（C）。

📌 补充说明：底层基础与高级配置

• 底层依赖：RabbitMQ 的集群能力构建于 Erlang 的分布式数据库 Mnesia 之上。Mnesia 本身的设计选择是 CA（一致性和可用性），而非 P（分区容错性）。这解释了为何原生集群在网络分区时需要人工介入，也凸显了镜像队列和联邦插件的重要性。
• 更精细的控制：对于镜像队列，你还可以通过 ha-promote-on-shutdown 和 ha-promote-on-failure 等策略参数，在 CP 和 AP 之间进行更细致的微调。设置为 when-synced：倾向于 CP，只有数据完全同步的节点才能被提升为主节点。设置为 always：倾向于 AP，只要有镜像节点存活就尝试接管，优先保证可用性。

💎 总结

RabbitMQ 的设计哲学很清晰：把选择权交给开发者。

• 如果你的业务金融、订单等场景，数据绝不能出错，那么请选择集群 + 镜像队列，并配置为 CP 模式。
• 如果你的业务日志收集、监控等场景，服务不能中断比偶尔丢几条消息更重要，那么可以考虑 AP 模式的配置，或使用联邦/Shovel。