共计 1618 个字符，预计需要花费 5 分钟才能阅读完成。
模块信息
要应用 Cluster Singleton，必须在我的项目中增加以下依赖项：
sbt
val AkkaVersion =“2.6.8”
libraryDependencies + =“com.typesafe.akka”%%“akka 群集类型”%AkkaVersion
马文
摇篮
[+] 显示我的项目信息
介绍
对于某些用例，确保集群中某个地位恰好有一个特定类型的 actor 运行十分不便，有时甚至是强制性的。
一些例子：
对某些集群范畴内统一的决策或整个集群零碎中的动作进行协调的繁多责任点
内部零碎的繁多入口点
独身客人，很多工人
集中命名服务或路由逻辑
应用单例不应该是首选设计。它具备几个毛病，例如单点瓶颈。单点故障也是一个相干问题，然而在某些状况下，此性能通过确保最终将启动另一个单例实例来解决此问题。
正告
确保不要应用群集敞开策略，免得在网络呈现问题或零碎过载（长时间的 GC 暂停）时将群集拆分为几个独自的群集，因为这将导致启动多个 Singleton，每个独自的群集一个！请参阅唐宁。
独身经理
集群单例模式治理所有集群节点或标记有特定角色的一组节点中的一个单例角色实例。单例管理器是一个参与者，应该在集群中的所有节点或所有具备指定角色的节点上尽早应用 ClusterSingleton.init 启动。
理论的独身演员是
从最旧的节点开始，办法是从提供的 Behavior 中创立子 actor。它能够确保在任何工夫点最多运行一个单例实例。
始终在具备指定角色的最早成员上运行。
最早的成员由 akka.cluster.Member#isOlderThan 确定。从集群中删除该成员时，这可能会扭转。请留神，在短时间内，切换过程中没有流动的单例。
当最旧的节点正在来到群集时，在启动新的单例之前，将由最旧的节点和新的最旧的节点进行替换。
群集故障检测器将告诉最旧的节点何时因为 JVM 解体，硬敞开或网络故障等起因而无法访问。在敞开并删除该节点之后，新的最旧的节点将接管并创立新的单例 actor。对于这些故障状况，将不会进行顺畅的移交，然而通过所有正当的办法都能够避免一个以上的流动单例。某些极其状况最终会通过可配置的超时来解决。能够通过应用租赁来减少安全性。
单例代理
要与集群中的给定命名单例进行通信，您能够通过代理 ActorRef 拜访它。在节点上为给定的 singletonName 调用 ClusterSingleton.init 时，将返回 ActorRef。通过此 ActorRef，您能够将音讯发送到单例实例，而与单例实例处于活动状态的节点无关。能够屡次调用 ClusterSingleton.init，如果在此节点上曾经有一个单例管理器在运行，则不会启动其余管理器，并且如果有一个正在运行的 ActorRef 返回代理。
代理会将所有音讯路由到单例的以后实例，并跟踪集群中最旧的节点并发现单例的 ActorRef。可能在一段时间内单例不可用，例如，当节点来到群集时。在这些状况下，代理将缓冲发送到单例的音讯，而后在单例最终可用时将其传递。如果缓冲区已满，则通过代理发送新音讯时，代理将抛弃旧音讯。缓冲区的大小是可配置的，能够通过应用缓冲区大小 0 来禁用它。
值得注意的是，因为这些参与者的分散性，音讯总是会失落。与平常一样，应该在单例（确认）和客户端（重试）参与者中实现其余逻辑，以确保至多一次传递音讯。
单例实例将不会在状态为 WeaklyUp 的成员上运行。
须要留神的潜在问题
最后应用此模式仿佛很迷人，然而它有一些毛病，上面列出了其中的一些毛病：
群集单例可能很快成为性能瓶颈。
您不能依附集群单例来提供不间断的服务，例如当已运行单例的节点死亡时，将须要几秒钟的工夫来留神到这一点，并将单例迁徙到另一个节点。
如果应用了多个单例，请留神，所有这些都将在最旧的节点（或具备配置角色的最旧的节点）上运行。群集分片与使“单个”实体放弃流动联合起来可能是更好的抉择。
正告
确保不要应用会导致群集拆分为几个拆散局部的群集敞开策略
