来自活动/活动文档 -
we have developed active/active high availability for queues
这个解决方案仍然需要一个 RabbitMQ 集群，这意味着它无法应对 与集群内的网络分区无缝连接，因此不是 建议跨 WAN 使用（当然，客户端仍然可以从 尽可能近和尽可能远）
“不建议跨 WAN 使用”是什么意思。
我无法理解这句话-
如果我在ec2上购买三台机器，我需要建立一个域控制器/dns服务器吗？
这个限制是什么意思？为什么？
【问题讨论】：
复制是一个对时间敏感的应用程序，这意味着必须进行时间假设才能使分布式状态在副本之间同步。
根据定义，互联网是一个异步网络，网络异步演进，无法对交付时间做出假设，即使定义了 MPLS（多协议标签交换）路径：BGP (边界网关协议）引入了很多不可预测性，路径可能非常不可预测，这转化为不可预测的延迟。
如上所述，不可预测的延迟是 Active-Active 复制的杀手锏（即在副本之间同步镜像状态以达到一致的分布式状态）。
另一个需要考虑的问题在于网络分区：在一组副本中，可以隔离一个或多个副本，从而创建“不一致副本的孤岛”：让我们假设副本集R = { R1, R2, R3, ..., RN }，出于网络连接原因（例如 BGP 问题），副本的子集，如 {R1, R2, R3} 可能与其余的隔离。网络分区意味着分布式状态的不一致：副本的子集将是一致的，但在全局范围内，它们独立地演变为损坏的分布式状态。
CAP Theorem 处理 WAN（广域网，即 Internet）上的复制问题。它指出：
一致性、可用性和分区无法通过 WAN 或其他异步网络实现，需要为大型分布式系统选择三分之二（例如，众所周知的 NoSQL 数据库的可用性和网络分区）。
回到最初的问题：根据上述，该声明（来自 RabbitMQ 文档）试图以务实的方式总结我上面强调的问题（即无法通过 WAN 实现主动-主动复制）。因此，如果您需要通过 WAN 复制您的 Broker 实例，RabbitMQ 部署中通常会使用 Shoveling 和 Federation 等技术。
【讨论】：
这意味着如果您的集群中有 3 个 EC2 实例，它们应该位于同一个数据中心。例如，不是美国东部和美国西部*。 RabbitMQ 使用 Erlang 的节点通信，非常健谈。低延迟通信对于拥有高性能集群至关重要。
*理想情况下，即使是同一个子网，但这并不总是可能的。
【讨论】：