您正在查看新的 actor API 的文档，以查看 Akka Classic 文档，请参阅 Classic Multi-DC Cluster
本章介绍如何在多个数据中心，可用性区域或区域中应用 Akka 群集。
使 Akka 群集理解数据中心边界的起因是，与同一数据中心中的节点之间的通信相比，跨数据中心的通信通常具备更高的提早和更高的故障率。
然而，节点的分组不限于数据中心的物理边界，即便这是次要用例。因为其余起因，它也能够用作逻辑分组，例如隔离某些节点以进步稳定性，或将大型群集分成较小的节点组以实现更好的可伸缩性。
相依性
要应用 Akka Cluster，请在您的我的项目中增加以下依赖项：
sbt
val AkkaVersion =“2.6.8”
libraryDependencies + =“com.typesafe.akka”%%“akka 群集类型”%AkkaVersion
马文
摇篮
动机
应用多个数据中心的起因可能很多，例如：
冗余容忍一个地位的故障，并且依然能够运行。
服务来自用户左近地位的申请，以提供更好的响应能力。
均衡许多服务器上的负载。
能够应用默认设置来运行一般的 Akka 群集，该默认设置逾越多个数据中心，但可能导致以下问题：
群集成员身份的治理在网络分区期间被暂停，如上面独自的局部所述。这意味着在数据中心之间的网络分区期间将无奈增加和删除节点。
跨数据中心网络连接的误报故障检测更加频繁。数据中心内和不同数据中心之间无奈针对故障检测设置不同的设置。
在网络分区的状况下，敞开 / 删除节点通常应针对数据中心内或跨数据中心的故障进行不同的解决。对于数据中心之间的网络分区，零碎通常不应敞开无法访问的节点，而应期待其修复或由人工或内部监视系统做出决定。对于同一数据中心内的故障，能够采纳主动的，更具攻击性的降落机制进行疾速故障转移。
很难以平安的形式将 Cluster Singleton 和 Cluster Sharding 从一个数据中心疾速故障转移到另一个数据中心。存在单例或分片实体在网络分区的两侧都处于活动状态的危险。
地位信息的不足使得难以优化通信来偏爱间隔较远的节点更近的节点。例如。如果群集感知路由器心愿将音讯路由到本人数据中心的节点，则效率会更高。
为了防止其中一些问题，每个数据中心能够运行一个独自的 Akka 群集，并在数据中心之间应用另一个通信通道，例如 HTTP，即一个内部音讯代理。然而，基于集群成员资格信息构建的许多不错的工具都失落了。例如，不可能在各个群集之间应用分布式数据。
咱们通常倡议将微服务实现为一个 Akka 集群。该服务的内部 API 是 HTTP，gRPC 或音讯代理，而不是 Akka Remoting 或 Cluster（请参阅何时和何处应用 Akka Cluster）中的附加探讨。
在多个节点上运行的服务内的外部通信将应用一般的 actor 消息传递或基于 Akka Cluster 的工具。当将此服务部署到多个数据中心时，如果外部通信因为应用了多个 Akka 群集而无奈应用一般的 Actor 消息传递，那么将很不不便。在外部应用 Akka 消息传递的益处是性能，开发的便利性以及 Actor 方面的域推理能力。
因而，能够使 Akka 群集理解数据中心，以便一个 Akka 群集能够逾越多个数据中心，并且依然能够容忍网络分区。