Akka

组件间的近程通信、组件内的本地通信以及组件内的状态在并发状况下的保护，都是基于Akka Actor来实现的 1、Akka与Actor模型Akka是构建高并发、分布式、可扩大利用的框架。Akka让开发者只须要关注业务逻辑，不须要写底层代码来反对可靠性、容错和高性能。Akka带来了诸多益处，比方 : 提供新的多线程模型，不须要应用低级的锁和原子性的操作来解决内存可见性问题提供通明的近程通信，不再须要编写和保护简单的网络代码提供集群式、高可用的架构，不便构建真正的响应式模式的利用Akka是基于Actor模型实现的，Actor模型相似于Erlang的并行模型，能使实现并发、并行和分布式应用更加简略Actor是Actor模型中最重要的形成局部，作为最根本的计算单位，能接管音讯并基于其执行计算。 每个Actor都有本人的邮箱，用来存储接管到的音讯。每个Actor维持公有的状态，来实现Actor之间的隔离每个Actor都是由单个线程负责从各自的邮箱拉取音讯，并间断解决接管到的音讯。对于接管到的音讯，Actor能够更改其外部的状态，或者将其传给其余Actor，或者创立新的ActorActorSystem是Actor的工厂和管理者。ActorSystem会为其Actor提供调度、配置和日志等公共服务。多个ActorSystem能够共存于同一台机器中。如果一个ActorSystem是以RemoteActorRefProvider的形式启动的，则它能够被近程ActorSystem拜访到。ActorSystem能主动判断Actor音讯是出自同一个ActorSystem的Actor还是来自近程ActorSystem的Actor。本地的Actor间通信，音讯通过共享内存传递;而近程的Actor间通信，音讯通过网络栈传递2、理解Actor的创立、启动以及音讯的发送Server端RemoteServerActor通过继承AbstractActor来实现Actor，并实现AbstractActor的 createReceive办法，来实现接管到音讯的解决逻辑 : 接管到String的音讯，将音讯内容打印到控制台。 public class RemoteServerActor extends AbstractActor { @Override public Receive createReceive() { return receiveBuilder() .match(String.class, message-> { System.out.println(message); }) .build(); }}RemoteServerActorLauncher类首先通过加载remote.conf的配置(其中配置的provider为 RemoteActorRefProvider)，来创立名为remote、反对近程通信的ActorSystem;再通过 actorSystem调用actorOf办法创立并启动名为remoteServerActor的Actor实例，并返回Actor地址 (ActorRef);最初通过ActorRef调用tell办法向RemoteServerActor发送音讯 RemoteServerActorLauncher启动Actor和发送音讯 public class RemoteServerActorLauncher { public static void main(String[] args) { Config config = ConfigFactory.load("remote.conf"); ActorSystem actorSystem = ActorSystem.create("remote", config); ActorRef actor = actorSystem.actorOf(Props.create(RemoteServerActor.class), "remoteServerActor"); actor.tell("hello!", ActorRef.noSender()); } }remote.conf配置 : akka { actor { provider = "akka.remote.RemoteActorRefProvider" } remote { enabled-transports = ["akka.remote.netty.tcp"] netty.tcp { hostname = "127.0.0.1" port = 50050 } } }在这个示例中，整个Actor创立与音讯发送的流程具体步骤如下 : 1) 创立近程的ActorSystem2) 创立并启动RemoteServerActorLauncher实例，返回ActorRef，创立音讯并通过ActorRef发送音讯3) ActorRef将音讯委托给Dispatcher发送到Actor4) Dispatcher把音讯暂存在邮箱中，Dispatcher中封装了一个线程池，用于音讯派发，实现异步音讯发送的成果5) 从邮箱中取出音讯，委派给RemoteServerActorLauncher中通过createReceive办法创立的Receive实例来解决 ...

1、简说AkkaFlink 外部节点之间的通信是用 Akka，比方 JobManager 和 TaskManager 之间的通信。 而 operator 之间的数据传输是利用 Netty，所以是不是有必要说一下Akka ? Akka和Actor并发问题的外围就是存在数据共享，同时有多个线程对一份数据进行批改，就会呈现错乱的状况 解决该问题个别有两种形式 :1、基于JVM内存模型的设计，通常须要通过加锁等同步机制保障共享数据的一致性。然而加锁在高并发的场景下，往往性能不是很好2、应用消息传递的形式Actor的根底就是消息传递，一个Actor能够认为是一个根本的计算单元，它能接管音讯并基于其执行运算，它也能够发送音讯给其余Actor。Actors 之间互相隔离，它们之间并不共享内存 Actor 自身封装了状态和行为，在进行并发编程时，Actor只须要关注音讯和它自身。而音讯是一个不可变对象，所以 Actor 不须要去关注锁和内存原子性等一系列多线程常见的问题。 所以Actor是由状态（State）、行为（Behavior）和邮箱（MailBox，能够认为是一个音讯队列）三局部组成 状态：Actor 中的状态指Actor对象的变量信息，状态由Actor本人治理，防止了并发环境下的锁和内存原子性等问题行为：Actor 中的计算逻辑，通过Actor接管到的音讯来扭转Actor的状态邮箱：邮箱是 Actor 和 Actor 之间的通信桥梁，邮箱外部通过 FIFO（先入先出）音讯队列来存储发送方Actor音讯，接受方Actor从邮箱队列中获取音讯任意一个Actor即可发送音讯，也能够承受音讯 Akka是一个构建在JVM上，基于Actor模型的的并发框架，反对Java和Scala两种API 2、Akka详解应用 Akka 能够让你从为 Actor 零碎创立基础设施和编写管制根本行为所需的高级代码中解脱进去。为了了解这一点，让咱们看看在代码中创立的Actor与Akka在外部创立和治理的Actor之间的关系，Actor的生命周期和失败解决 Akka的Actor层级Akka的Actor总是属于父Actor。通常，你能够通过调用 getContext().actorOf() 来创立 Actor。与创立一个“独立的”Actor不同，这会将新Actor作为一个子节点注入到曾经存在的树中，创立Actor的Actor成为新创建的子Actor的父级。你可能会问，你发明的第一个Actor的父节点是谁?如下图所示，所有的 Actor 都有一个独特的父节点，即用户守护者。能够应用 system.actorOf() 在以后Actor下创立新的Actor实例。创立 Actor 将返回一个无效的 URL 援用。例如，如果咱们用 system.actorOf(..., "someActor") 创立一个名为 someActor 的 Actor，它的援用将包含门路 /user/someActor 事实上，在你在代码中创立 Actor 之前，Akka 曾经在零碎中创立了三个 Actor 。这些内置的 Actor 的名字蕴含 guardian ，因为他们守护他们所在门路下的每一个子 Actor。守护者 Actor 包含 : / ，根守护者( root guardian )。这是零碎中所有Actor的父Actor，也是零碎自身终止时要进行的最初一个 Actor/user ，守护者( guardian )。这是用户创立的所有Actor的父 Actor。不要让用户名混同，它与最终用户和用户解决无关。应用Akka库创立的每个Actor都将有一个当时筹备的固定门路/user//system ，零碎守护者( system guardian )。这是除上述三个Actor外，零碎创立的所有Actor的父Actor示例： ...

多节点测试模块信息要应用多节点测试，必须在我的项目中增加以下依赖项: 多节点测试概念当咱们议论Akka中的多节点测试时，是指在不同JVM中的多个actor零碎上运行协调测试的过程。多节点测试套件包含三个次要局部。 -测试协调。协调和管制被测节点。-多节点标准。这是启动TestConductor，并让所有节点连贯到它的封装。-SbtMultiJvm插件。在多台机器上的多个JVM中启动测试。 测试协调多节点测试的根底是TestConductor。它是一个Akka扩大插件，可插入网络堆栈，用于协调参加测试的节点，并提供以下性能: -节点地址查找:查找到另一个测试节点的残缺门路（无需在测试节点之间共享配置）-节点屏障协调:在命名的屏障处期待其余节点。-网络故障注入:限度流量，抛弃数据包，插入并从新插入节点。这是测试协调的示意图。 测试协调服务器负责协调屏障，并向作用在屏障上的测试协调客户端发送命令。限度与其余客户端之间的网络流量。无关可能的操作的更多信息，请参见akka.remote.testconductor.ConductorAPI文档。 多节点标准多节点标准包含两局部。MultiNodeConfig负责通用配置、枚举和命名被测节点。MultiNodeSpec蕴含许多便当性能，用于使测试节点互相交互。无关可能的操作的更多信息，请参见akka.remote.testkit.MultiNodeSpecAPI文档。 通过在要运行被测节点的所有JVM上设置的java零碎属性来配置MultiNodeSpec。能够在JVM命令行上应用-Dproperty=value设置这些值。 这些是可用的属性-multinode.max-nodes测试能够具备的最大节点数。-multinode.host此节点的主机名或IP。必须应用InetAddress.getByName可解析。-multinode.port此节点的端口号。默认为0，它将应用随机端口。-multinode.server-host服务器节点的主机名或IP。必须应用InetAddress.getByName可解析。-multinode.server-port服务器节点的端口号。默认为4711-multinode.index在为测试定义的角色序列中此节点的索引。索引0是非凡的，该机器将是服务器。所有故障注入和限流必须从此节点实现。 SbtMultiJvm插件SbtMultiJvm插件已更新，能够通过主动生成相干的multinode.*属性来运行多节点测试。这意味着您能够将它们作为一般的多jvm测试运行，而无需任何非凡配置就能够在一台计算机上运行多节点测试。而后，通过应用插件的多节点增加，无需进行任何更改能够在多台计算机上分布式运行这些测试。 多节点特定增加该插件还具备许多新的multi-node-*sbt工作和设置，以反对在多台计算机上运行测试。将必要的测试类和依赖项打包为散发到其余具备SbtAssembly的计算机上的jar文件，其名称格局为<projectName>_<scalaVersion>-<projectVersion>-multi-jvm-assembly.jar 留神为了可能在多台计算机上散发和启动测试，假设主机和指标零碎都是POSIX零碎，并且具备ssh和rsync。这些是可用的sbt多节点配置-multiNodeHosts,用于运行测试的一系列主机，格局为user@host:java，其中host是惟一必须的局部。将覆盖文件中的设置。-multiNodeHostsFileName,一个文件，用于读取运行测试的主机。每行一个，格局与上述雷同。默认为根底我的项目目录中的multi-node-test.hosts。-multiNodeTargetDirName,指标计算机上将jar文件复制到的目录的名称。在用于rsync jar文件的ssh用户的根本目录中，默认值为multi-node-test。-multiNodeJavaName指标计算机上默认Java可执行文件的名称。默认为java。 以下是一些如何定义主机的示例 localhost应用默认java的localhost上的以后用户。user1@host1主机host1上的用户user1，默认Java。user2@host2:/usr/lib/jvm/java-7-openjdk-amd64/bin/java应用Java7的主机host2上的用户user2。host3:/usr/lib/jvm/java-6-openjdk-amd64/bin/java应用Java6的主机host3上的以后用户。运行多节点测试要从sbt外部以多节点模式运行所有多节点测试（即散发jar文件并近程启动测试），请应用multiNodeTest工作: multiNodeTest要以多jvm模式（即本地计算机上的所有JVM）运行它们，请执行以下操作: multi-jvm:test要运行单个测试，请应用multiNodeTestOnly工作: multiNodeTestOnlyyour.MultiNodeTest要以多jvm模式运行单个测试，请执行以下操作: multi-jvm:testOnlyyour.MultiNodeTest能够列出多个测试名称来运行多个特定测试。sbt中的制表符补全使实现测试名称变得容易。 多节点测试示例首先，咱们须要一些脚手架，以将MultiNodeSpec与您喜爱的测试框架连接起来。 让咱们定义一个接口STMultiNodeSpec，该接口应用ScalaTest启动和进行MultiNodeSpec。 而后，咱们须要定义一个配置。 让咱们应用两个节点"node1和"node2"，并将其称为MultiNodeSampleConfig。 而后最初到节点测试代码。 这将启动两个节点，并演示一个阻碍，以及一个近程actor音讯发送/接管。 注意事项编写多节点测试时，须要牢记两点，否则测试的行为可能会令人诧异。 不要敞开第一个节点。第一个节点是控制器，如果敞开，测试将失败。为了可能应用blackhole，passThrough和限流，必须通过在MultiNodeConfig中指定testTransport（on = true）来激活故障注入和节流传输适配器。节流，停机和其余故障注入只能从第一个节点（也就是控制器）进行。节点敞开后，不要应用node（address）来申请节点的地址。在敞开节点之前先获取地址。不要从其余线程而不是主测试线程，应用诸如地址查找，障碍物等MultiNodeSpec的办法。这也意味着您不应该在actor，future或scheduled task中应用它们。配置多节点测试模块有多个配置属性，请参考参考配置。

同时反对多个JVM中正在运行的应用程序（objectswithmainmethods）和ScalaTest测试。对于多个零碎互相通信的集成测试很有用。 建设多JVM测试是一个sbt插件，您能够在https://github.com/sbt/sbt-mu...。要在您的我的项目中配置它，您应该执行以下步骤： 1.通过将以下内容增加到您的project/plugins.sbt中，将其增加为插件： 2.通过启用MultiJvmPlugin并设置MultiJvm配置，将multi-JVM测试增加到build.sbt或project/Build.scala。 请留神，默认状况下，MultiJvm测试源位于src/multi-jvm/...中，而不位于src/test/...中。 运行测试多JVM工作与惯例工作类似：test，testOnly和run，然而在multi-jvm配置下。 因而，在Akka中，要在akka近程我的项目中运行所有的多JVM测试，请应用（在sbt提示符下）： 或者能够先更改为akka-remote-tests我的项目，而后运行测试： 要运行单个测试，请应用testOnly： 能够列出多个测试类名来运行多个特定测试。sbt中的制表符实现性能使实现测试名称变得容易。 也能够通过在测试名称和--之后增加testOnly来指定JVM选项。例如： 创立应用程序测试通过命名约定来发现并组合测试。MultiJvm测试源位于src/multi-jvm/...中。应用以下模式命名测试： 也就是说，每个测试的名称两头都有MultiJvm。它之前的局部将单个TestName下的测试/应用程序组合在一起，它们将一起运行。前面的局部NodeName是每个分叉JVM的区别名。 因而，要创立一个名为Sample的3节点测试，您能够创立以下三个应用程序： 当在sbt提示符下调用multi-jvm：runsample.Sample时，将生成三个JVM，每个节点一个。它看起来像这样： 更改默认值您能够为分叉的JVM指定JVM选项： 您能够通过将以下配置增加到我的项目中来更改多JVM测试源目录的名称： 您能够更改MultiJvm标识符。例如，要将其更改为ClusterTest，请设置multiJvmMarker： 当初，您的测试应命名为{TestName}ClusterTest{NodeName}。 JVM实例的配置您能够为每个衍生的JVM定义特定的JVM选项。为此，您能够创立一个以测试中的节点命名的文件，后缀为.opts，并将其放在与测试雷同的目录中。 例如，要将JVM选项-Dakka.remote.port=9991和-Xmx256m提供给SampleMultiJvmNode1，让咱们创立三个*.opts文件并将这些选项增加到它们中。用空格分隔多个选项。SampleMultiJvmNode1.opts: SampleMultiJvmNode2.opts: SampleMultiJvmNode3.opts: ScalaTest还反对创立ScalaTest测试而不是应用程序。为此，请应用与上述雷同的命名约定，但要创立ScalaTest套件，而不要应用object创立main函数。您须要在类门路上具备ScalaTest。这是与上述示例相似的示例，但应用的是ScalaTest： 要仅运行这些测试，能够在sbt提示符下调用multi-jvm：testOnlysample.Spec。 多节点增加SbtMultiJvm插件也做了一些补充，以适应该局部中形容的may change模块multi node testing。 示例我的项目Cluster example project是一个示例我的项目，能够下载并带有如何运行的阐明。 该我的项目阐明了集群性能，还包含带有sbt-multi-jvm插件的MultiJVMTesting。

# Serialization with Jackson# 依赖要应用Jackson序列化，必须在我的项目中增加以下依赖项：# 介绍您能够在“序列化”局部中找到无关Akka序列化的概念。 本节形容如何应用Jackson序列化应用程序特定的音讯、持久性事件和快照。Jackson反对基于文本的JSON和二进制格局。在许多状况下，Jackson能够对一般类进行序列化而无需任何其余提醒，然而有时须要应用正文来指定如何将对象转换为JSON/字节。# 用法要为某个类启用Jackson序列化，您须要在序列化绑定配置中配置它或它的一个超类。 通常，您将为此创立一个标记器接口，并让音讯实现该接口。而后，在序列化绑定中将标记器接口的类名称配置为：jackson-json或jackson-cbor一个好的约定是将标记接口命名为CborSerializable或JsonSerializable。在本文档中，咱们应用MySerializable来明确表明Akka不提供标记接口自身。这是Jackson了解构造的根底类所须要的。上面介绍了须要正文的几种状况。请留神，只有顶级类或其标记接口必须在serialization-bindings定义，而不是它在成员字段中援用的嵌套类。>留神增加-parameters Java编译器选项，以供ParameterNamesModule应用。它缩小了某些正文。# 平安出于平安起因，不容许将Jackson序列化程序绑定到开放式类型,可能是序列化小工具的指标对象，例如：- java.lang.Object- java.io.Serializable- java.util.Comparable。Jackson数据绑定定义的可能序列化小工具类的回绝列表，须要查看并禁止反序列化。>正告不要应用@JsonTypeInfo(use = Id.CLASS)或ObjectMapper.enableDefaultTyping，因为应用多态类型会带来安全隐患。##格局反对以下格局，如上所述，您抉择在序列化绑定配置中应用哪种格局。- jackson-json-基于一般文本的JSON- jackson-cbor-二进制CBOR数据格式二进制格局比JSON格局更紧凑，性能稍好。# 注解## 单参数构造函数您可能会遇到如下异样：MismatchedInputException：无奈结构...的实例(只管存在至多一个Creator)：无奈从Object值反序列化(没有基于委托或基于属性的Creator) 这可能是因为该类的构造函数带有单个参数，例如：能够通过增加@JsonCreator或@JsonProperty注解来解决：或者如Jackson文档中所述，应用JsonCreator.Mode.PROPERTIES配置ParameterNamesModule。## 多态类型多态类型是某个根本类型具备多个代替实现的状况。 如果嵌套字段或汇合是多态类型，则必须应用@JsonTypeInfo和@JsonSubTypes注解列出该类型的具体实现。例：如果您尚未定义正文，则会看到如下异样：InvalidDefinitionException：无奈结构...的实例(不存在任何创建者，如默认结构一样)：形象类型须要映射到具体类型，具备自定义反序列化器或蕴含其余类型信息 请留神，对于顶级类，这不是必须的，但对于其中的字段，则须要。在此示例中，在动物园外部应用动物，该动物作为音讯发送或保留。如果动物是独立发送或长久保留的，则不须要正文，因为被序列化的是具体的子类Lion或Elephant。在应用这些注解指定容许的子类时，类名将不包含在序列化示意中，这对于避免反序列化时加载歹意序列化小工具很重要。>正告不要应用@JsonTypeInfo(use=Id.CLASS)或ObjectMapper.enableDefaultTyping，因为应用多态类型会带来安全隐患。# 架构演变在应用事件溯源以及进行滚动更新时，架构演变成为开发应用程序的重要方面。需要以及咱们对业务畛域的了解可能会(并且将会)随工夫而变动。Jackson序列化器提供了一种在反序列化期间执行JSON树模型转换的办法。对于文本格式和二进制格局，它以雷同的形式工作。咱们将钻研几种无关类如何演变的计划。## 移除字段无需迁徙任何代码即可删除字段。 Jackson序列化程序将疏忽该类中不存在的属性。## 新增字段无需迁徙任何代码即可增加可选字段。默认值为Optional.empty。旧类：具备新的可选Discount属性和具备默认值的note字段的新类：假如咱们要领有一个没有默认值的必填字段discount：要增加新的必填字段，咱们必须应用JacksonMigration类并在迁徙代码中设置默认值。这是增加discount字段的迁徙类的样子：笼罩currentVersion办法以定义以后(最新)版本的版本号。 当不应用任何迁徙时，第一个版本始终为1。只有执行不带迁徙代码就无奈向后兼容的更改，请减少此版本号。应用transform办法将旧的JSON构造转换为新的JSON构造。 JsonNode是可变的，因而您能够增加和删除字段，或更改值。 请留神，您必须转换为特定的子类，例如ObjectNode和ArrayNode能力拜访更改器。迁徙类必须在配置文件中定义：note字段可能也做同样的事件，在ItemAddedMigration中增加默认值“”。## 重命名字段假如咱们要在上一个示例中将productId字段重命名为itemId。迁徙代码如下：## 构造变动以相似的形式，咱们能够进行任意的构造更改。旧类：新类Address 类迁徙代码如下：## 重命名类也能够重命名该类。 例如，让咱们将OrderAdded重命名为OrderPlaced。旧类：新类迁徙代码如下：请留神，重写transformClassName办法，定义新的类名称。必须应用旧的类名作为键来配置这种类型的迁徙。能够删除理论的类。## 从序列化绑定中删除当某个类不再用于序列化时，能够将其从序列化绑定中删除，但仍要容许反序列化，则必须在allowed-class-prefix配置中列出该类。例如，在通过序列化更改进行滚动更新期间，或在读取旧的存储数据时，此性能很有用。从Jackson序列化程序更改为另一个序列化程序(例如Protobuf)从而更改序列化绑定时，也能够应用它，然而依然能够应用Jackson来反序列化旧数据。这是类名称或类名称前缀的列表。# Jackson模块默认状况下，以下Jackson模块是启用的：您能够批改配置akka.serialization.jackson.jackson-modules以启用其余模块。ParameterNamesModule要求启用-parameters Java编译器选项。## 压缩JSON可能很简短，对于大型音讯，压缩大型无效负载可能会有所帮忙。 对于jackson-json绑定，默认配置为：反对的压缩算法为：gzip，lz4。应用“敞开”禁用压缩。 Gzip通常比lz4慢。大于compress-larger-than属性的音讯将被压缩。能够通过将算法属性设置为敞开来禁用压缩。它依然可能解压缩序列化时压缩的有效载荷，例如如果更改此配置。对于杰克逊cbor和自定义绑定，默认状况下禁用杰克逊json压缩，但能够采纳与上述配置雷同的形式启用，但用绑定名称替换杰克逊json（例如杰克逊cbor）。附加配置每个绑定的配置默认状况下，在akka.serialization.jackson局部中定义了Jackson序列化程序及其ObjectMappers的配置。能够在更特定的akka.serialization.jackson。<binding name>局部中笼罩该配置。akka.serialization.jackson.jackson-json { 序列化性能{ WRITE_DATES_AS_TIMESTAMPS =敞开 }}akka.serialization.jackson.jackson-cbor { 序列化性能{ WRITE_DATES_AS_TIMESTAMPS =开启 }}也能够定义多个绑定并为它们应用不同的配置。例如，近程音讯和长久事件的不同设置。

# Serialization with Jackson# 依赖要应用Jackson序列化，必须在我的项目中增加以下依赖项：# 介绍您能够在“序列化”局部中找到无关Akka序列化的概念。 本节形容如何应用Jackson序列化应用程序特定的音讯、持久性事件和快照。Jackson反对基于文本的JSON和二进制格局。在许多状况下，Jackson能够对一般类进行序列化而无需任何其余提醒，然而有时须要应用正文来指定如何将对象转换为JSON/字节。# 用法要为某个类启用Jackson序列化，您须要在序列化绑定配置中配置它或它的一个超类。 通常，您将为此创立一个标记器接口，并让音讯实现该接口。而后，在序列化绑定中将标记器接口的类名称配置为：jackson-json或jackson-cbor一个好的约定是将标记接口命名为CborSerializable或JsonSerializable。在本文档中，咱们应用MySerializable来明确表明Akka不提供标记接口自身。这是Jackson了解构造的根底类所须要的。上面介绍了须要正文的几种状况。请留神，只有顶级类或其标记接口必须在serialization-bindings定义，而不是它在成员字段中援用的嵌套类。>留神增加-parameters Java编译器选项，以供ParameterNamesModule应用。它缩小了某些正文。# 平安出于平安起因，不容许将Jackson序列化程序绑定到开放式类型,可能是序列化小工具的指标对象，例如：- java.lang.Object- java.io.Serializable- java.util.Comparable。Jackson数据绑定定义的可能序列化小工具类的回绝列表，须要查看并禁止反序列化。>正告不要应用@JsonTypeInfo(use = Id.CLASS)或ObjectMapper.enableDefaultTyping，因为应用多态类型会带来安全隐患。##格局反对以下格局，如上所述，您抉择在序列化绑定配置中应用哪种格局。- jackson-json-基于一般文本的JSON- jackson-cbor-二进制CBOR数据格式二进制格局比JSON格局更紧凑，性能稍好。# 注解## 单参数构造函数您可能会遇到如下异样：MismatchedInputException：无奈结构...的实例(只管存在至多一个Creator)：无奈从Object值反序列化(没有基于委托或基于属性的Creator) 这可能是因为该类的构造函数带有单个参数，例如：能够通过增加@JsonCreator或@JsonProperty注解来解决：或者如Jackson文档中所述，应用JsonCreator.Mode.PROPERTIES配置ParameterNamesModule。## 多态类型多态类型是某个根本类型具备多个代替实现的状况。 如果嵌套字段或汇合是多态类型，则必须应用@JsonTypeInfo和@JsonSubTypes注解列出该类型的具体实现。例：如果您尚未定义正文，则会看到如下异样：InvalidDefinitionException：无奈结构...的实例(不存在任何创建者，如默认结构一样)：形象类型须要映射到具体类型，具备自定义反序列化器或蕴含其余类型信息 请留神，对于顶级类，这不是必须的，但对于其中的字段，则须要。在此示例中，在动物园外部应用动物，该动物作为音讯发送或保留。如果动物是独立发送或长久保留的，则不须要正文，因为被序列化的是具体的子类Lion或Elephant。在应用这些注解指定容许的子类时，类名将不包含在序列化示意中，这对于避免反序列化时加载歹意序列化小工具很重要。>正告不要应用@JsonTypeInfo(use=Id.CLASS)或ObjectMapper.enableDefaultTyping，因为应用多态类型会带来安全隐患。# 架构演变在应用事件溯源以及进行滚动更新时，架构演变成为开发应用程序的重要方面。需要以及咱们对业务畛域的了解可能会(并且将会)随工夫而变动。Jackson序列化器提供了一种在反序列化期间执行JSON树模型转换的办法。对于文本格式和二进制格局，它以雷同的形式工作。咱们将钻研几种无关类如何演变的计划。## 移除字段无需迁徙任何代码即可删除字段。 Jackson序列化程序将疏忽该类中不存在的属性。## 新增字段无需迁徙任何代码即可增加可选字段。默认值为Optional.empty。旧类：具备新的可选Discount属性和具备默认值的note字段的新类：假如咱们要领有一个没有默认值的必填字段discount：要增加新的必填字段，咱们必须应用JacksonMigration类并在迁徙代码中设置默认值。这是增加discount字段的迁徙类的样子：笼罩currentVersion办法以定义以后(最新)版本的版本号。 当不应用任何迁徙时，第一个版本始终为1。只有执行不带迁徙代码就无奈向后兼容的更改，请减少此版本号。应用transform办法将旧的JSON构造转换为新的JSON构造。 JsonNode是可变的，因而您能够增加和删除字段，或更改值。 请留神，您必须转换为特定的子类，例如ObjectNode和ArrayNode能力拜访更改器。迁徙类必须在配置文件中定义：note字段可能也做同样的事件，在ItemAddedMigration中增加默认值“”。## 重命名字段假如咱们要在上一个示例中将productId字段重命名为itemId。迁徙代码如下：## 构造变动以相似的形式，咱们能够进行任意的构造更改。旧类：新类Address 类迁徙代码如下：## 重命名类也能够重命名该类。 例如，让咱们将OrderAdded重命名为OrderPlaced。旧类：新类迁徙代码如下：请留神，重写transformClassName办法，定义新的类名称。必须应用旧的类名作为键来配置这种类型的迁徙。能够删除理论的类。## 从序列化绑定中删除当某个类不再用于序列化时，能够将其从序列化绑定中删除，但仍要容许反序列化，则必须在allowed-class-prefix配置中列出该类。例如，在通过序列化更改进行滚动更新期间，或在读取旧的存储数据时，此性能很有用。从Jackson序列化程序更改为另一个序列化程序(例如Protobuf)从而更改序列化绑定时，也能够应用它，然而依然能够应用Jackson来反序列化旧数据。这是类名称或类名称前缀的列表。# Jackson模块默认状况下，以下Jackson模块是启用的：您能够批改配置akka.serialization.jackson.jackson-modules以启用其余模块。ParameterNamesModule要求启用-parameters Java编译器选项。## 压缩JSON可能很简短，对于大型音讯，压缩大型无效负载可能会有所帮忙。 对于jackson-json绑定，默认配置为：反对的压缩算法为：gzip，lz4。应用“敞开”禁用压缩。 Gzip通常比lz4慢。大于compress-larger-than属性的音讯将被压缩。能够通过将算法属性设置为敞开来禁用压缩。它依然可能解压缩序列化时压缩的有效载荷，例如如果更改此配置。对于杰克逊cbor和自定义绑定，默认状况下禁用杰克逊json压缩，但能够采纳与上述配置雷同的形式启用，但用绑定名称替换杰克逊json（例如杰克逊cbor）。附加配置每个绑定的配置默认状况下，在akka.serialization.jackson局部中定义了Jackson序列化程序及其ObjectMappers的配置。能够在更特定的akka.serialization.jackson。<binding name>局部中笼罩该配置。akka.serialization.jackson.jackson-json { 序列化性能{ WRITE_DATES_AS_TIMESTAMPS =敞开 }}akka.serialization.jackson.jackson-cbor { 序列化性能{ WRITE_DATES_AS_TIMESTAMPS =开启 }}也能够定义多个绑定并为它们应用不同的配置。例如，近程音讯和长久事件的不同设置。

<h1>序列化</h1># 依赖要应用序列化，必须在我的项目中增加以下依赖项：# 介绍Akka actor互相发送的音讯是JVM对象。actor在同一个JVM上传递音讯很简略。通过援用传递实现。然而，音讯逾越JVM，必须通过某种模式的序列化，能力达到在不同主机上运行的actor。(即对象转换为字节数组，或从字节数组复原音讯)。Akka中的序列化机制容许您编写自定义序列化程序，并定义用哪个序列化程序。在许多状况下，应用Jackson进行序列化是一个不错的抉择，如果您没有其余抉择，咱们倡议应用。如果您想更好地管制音讯的架构演变，则Google Protocol Buffers是很好的抉择，然而它须要更多的工作来开发和保护序列化示意模式与畛域示意模式的映射。Akka自身应用Protocol Buffers来序列化内部消息(例如集群gossip音讯)。# 用法## 配置为了使Akka晓得要应用哪个序列化程序，您须要编辑配置：“akka.actor.serializers”，将名称绑定到要应用的akka.serialization.Serializer的实现中，如下所示：在将名称绑定到不同的序列化实现之后，须要指定哪个类应用哪个Serializer，这在“akka.actor.serialization-bindings”局部中实现：您只须要指定音讯的接口名称或形象基类即可。在不置可否的状况下，即音讯实现了几个配置的类，将应用最具体的配置类，即所有其余候选者的超类。如果无奈满足此条件，例如已配置用于序列化的两个标记接口都实用，并且都不是另一个的子类型，将收回正告。>留神 如果将Scala用于音讯协定，并且音讯蕴含在Scala object中，则为了援用这些音讯，您将须要应用规范Java类名称。 对于蕴含在名为Wrapper的Scala object中的名为Message的音讯，您须要将其援用为Wrapper$Message而不是Wrapper.Message。 Akka默认为几种原始类型和protobuf com.google.protobuf.GeneratedMessage(protobuf2)和com.google.protobuf.GeneratedMessageV3(protobuf3)提供序列化程序(后者仅取决于akka-remote模块)，因而如果您将原始的protobuf音讯作为actor音讯发送，则无需为此增加配置。 ## 程式化 如果要应用Akka序列化,以编程形式进行序列化/反序列化，请参见以下示例：清单是一种类型提醒，因而同一序列化程序可用于不同的类。请留神，从字节反序列化时，须要清单和serializer的标识符。 重要的是，以这种形式应用序列化程序标识符来反对滚动更新，其中类的serialization-bindings可能已从一个序列化程序更改为另一个序列化程序。 因而，由字节，序列化ID和清单组成的三个局部应始终一起传输或存储，以便能够应用不同的序列化绑定配置对它们进行反序列化。SerializationExtension是经典扩大，但能够与akka.actor.typed.ActorSystem一起应用，如下所示：# 个性化此页面上的第一个代码段蕴含一个配置文件，该配置文件援用了自定义序列化程序docs.serialization.MyOwnSerializer。 咱们将如何创立这样的自定义序列化程序？## 创立新的序列化器自定义序列化程序必须继承akka.serialization.JSerializer，并且能够如下定义：标识符必须是惟一的。抉择要用于反序列化的序列化器时，将应用该标识符。如果您意外地配置了多个具备雷同标识符的序列化程序，这些序列化程序将被检测到并阻止ActorSystem启动。它能够是硬编码的值，因为它必须放弃雷同的值以反对滚动更新。清单是一种类型提醒，因而同一序列化程序可用于不同的类。 fromBinaryJava中的manifest参数是被序列化的对象的类。在fromBinary中，您能够在类上进行匹配，并将字节反序列化为不同的对象。而后，您只须要填写空白，将其绑定到配置中的名称，而后列出应应用其反序列化的类。启动ActorSystem时，serializers将由SerializationExtension初始化，因而，序列化程序自身不能从其构造函数拜访SerializationExtension。相同，它应该提早拜访SerializationExtension。## 字符串清单的序列化器下面阐明的序列化程序反对基于类的清单(类型提醒)。对于须要随工夫变动的数据进行序列化，倡议应用SerializerWithStringManifest而不是Serializer，因为清单(类型提醒)是String而不是Class。这意味着能够挪动/删除该类，并且serializer仍能够通过匹配String来反序列化旧数据。这对于持久性特地有用。清单字符串还能够编码一个版本号，该版本号可用于fromBinary中以不同形式反序列化,将旧数据迁徙到新的畛域对象。如果数据最后是应用Serializer进行序列化的，并且在零碎的更高版本中更改为SerializerWithStringManifest，则清单字符串将是残缺的类名(如果您应用includeManifest = true)，否则它将是空字符串。这是SerializerWithStringManifest的样子：您还必须将其绑定到配置中的名称，而后列出应由其序列化的类。如果清单未知，倡议将IllegalArgumentException或java.io.NotSerializableException放入fromBinary中。这样就能够引入新的音讯类型，并将其发送到不晓得它们的节点。在执行滚动降级时，即运行具备混合版本的集群一段时间后，通常须要这样做。这些异样在经典近程解决层中被视为临时问题。该问题将被记录，并且音讯被抛弃。其余异样将断开TCP连贯，因为它可能表明传输的字节损坏。 Artery TCP将所有反序列化异样解决为暂时性问题。## 序列化ActorRefsactor援用通常蕴含在音讯中。当与Jackson一起应用序列化时，所有ActorRef都能够序列化，然而如果您正在编写本人的序列化器，则可能想晓得如何正确地序列化和反序列化它们。要应用字符串对actor进行序列化、反序列化，能够应用ActorRefResolver。例如，以下是Ping和Pong音讯序列化：经典ActorRef的序列化在Classic Serialization进行了形容。经典和Typed actor援用具备雷同的序列化格局，因而能够调换。## actor的深度序列化倡议应用Akka Persistence，对外部actor状态进行深度序列化。# Akka音讯的序列化Akka正在应用Protobuf 3对Akka定义的音讯进行序列化。这种依赖关系隐含在akka-protobuf-v3中，以便应用程序能够应用Protobuf的另一个版本。应用程序应应用规范的Protobuf依赖关系，而不是akka-protobuf-v3。# Java序列化家喻户晓，Java序列化速度很慢，并且容易受到各种类型的攻打-毕竟，它素来都不是为高吞吐量消息传递而设计的。可能有人认为网络带宽和提早会限度近程消息传递的性能，然而序列化是一个更为典型的瓶颈。>留神默认状况下，应用Java序列化的Akka序列化是禁用的，并且Akka自身不对其外部任何音讯应用Java序列化。不倡议在生产中启用Java序列化。生产中禁用的Java序列化程序收回的日志音讯,应视为序列化程序阻止的潜在攻打，因为它们可能示意内部操作试图发送旨在应用Java序列化作为攻打向量的歹意音讯。尝试应用SECURITY标记记录。然而，对于晚期原型制作来说，应用起来十分不便。因而，为了与依赖Java序列化的旧零碎兼容，能够应用以下配置启用它：当应用Java序列化时，Akka仍会记录正告，增加以下内容敞开正告：## Java序列化兼容性当应用Java序列化时，混合次要的Scala版本并不平安，因为Scala无奈保障兼容性，这可能会导致十分令人诧异的谬误。# 滚动降级序列化的近程音讯(或长久事件)由序列化器ID，清单和二进制有效载荷组成。反序列化时，仅查看serializer-id以抉择要用于fromBinary的序列化器。音讯类(绑定)不用于反序列化。该清单仅在Serializer中用于决定如何反序列化无效负载，因而一个Serializer能够解决许多类。这意味着能够通过执行两个滚动降级步骤来切换到新的序列化程序来更改音讯的序列化。1. 增加Serializer类，并在akka.actor.serializers配置中定义它，而不在akka.actor.serialization-bindings中定义它。为此更改执行滚动降级。这意味着序列化程序类存在于所有节点上并已注册，但仍未用于序列化任何音讯。这很重要，因为在滚动降级过程中，旧节点依然不理解新的序列化程序，因而无奈反序列化具备该格局的音讯。2. 第二个更改是用akka.actor.serialization-bindings配置中定义那些序列化程序，对某些类注册序列化程序。为此更改执行滚动降级。这意味着新节点在发送音讯时将应用新的序列化器，而旧节点将可能反序列化新格局。发送音讯时，旧节点将持续应用旧序列化程序，而新节点将可能反序列化旧格局。作为可选的第三步，如果旧的序列化程序未用于持久性事件，则能够将其齐全删除。依然必须能够反序列化旧序列化程序存储的事件。# 内部Akka序列化器- Kryo serializer for Akka- Twitter Chill Scala extensions for Kryo## 验证通常，在本地actor(即同一JVM)之间发送的音讯不会进行序列化。对于测试，有时可能心愿对所有音讯(近程音讯和本地音讯)强制进行序列化。如果要执行此操作以验证音讯可序列化，则能够启用以下配置选项：通过扩大标记接口akka.actor.NoSerializationVerificationNeeded或在配置akka.actor.no-serialization-verification-needed-class-prefix中定义类名称前缀，能够将某些音讯从验证中排除。如果要验证Props是否可序列化，能够启用以下配置选项：>正告咱们倡议仅在运行测试时关上这些配置选项。 在生产中关上这些选项是没有意义的，因为这会对本地消息传递的性能产生负面影响，而不会带来任何收益。

<h1>序列化</h1># 依赖要应用序列化，必须在我的项目中增加以下依赖项：# 介绍Akka actor互相发送的音讯是JVM对象。actor在同一个JVM上传递音讯很简略。通过援用传递实现。然而，音讯逾越JVM，必须通过某种模式的序列化，能力达到在不同主机上运行的actor。(即对象转换为字节数组，或从字节数组复原音讯)。Akka中的序列化机制容许您编写自定义序列化程序，并定义用哪个序列化程序。在许多状况下，应用Jackson进行序列化是一个不错的抉择，如果您没有其余抉择，咱们倡议应用。如果您想更好地管制音讯的架构演变，则Google Protocol Buffers是很好的抉择，然而它须要更多的工作来开发和保护序列化示意模式与畛域示意模式的映射。Akka自身应用Protocol Buffers来序列化内部消息(例如集群gossip音讯)。# 用法## 配置为了使Akka晓得要应用哪个序列化程序，您须要编辑配置：“akka.actor.serializers”，将名称绑定到要应用的akka.serialization.Serializer的实现中，如下所示：在将名称绑定到不同的序列化实现之后，须要指定哪个类应用哪个Serializer，这在“akka.actor.serialization-bindings”局部中实现：您只须要指定音讯的接口名称或形象基类即可。在不置可否的状况下，即音讯实现了几个配置的类，将应用最具体的配置类，即所有其余候选者的超类。如果无奈满足此条件，例如已配置用于序列化的两个标记接口都实用，并且都不是另一个的子类型，将收回正告。>留神 如果将Scala用于音讯协定，并且音讯蕴含在Scala object中，则为了援用这些音讯，您将须要应用规范Java类名称。 对于蕴含在名为Wrapper的Scala object中的名为Message的音讯，您须要将其援用为Wrapper$Message而不是Wrapper.Message。 Akka默认为几种原始类型和protobuf com.google.protobuf.GeneratedMessage(protobuf2)和com.google.protobuf.GeneratedMessageV3(protobuf3)提供序列化程序(后者仅取决于akka-remote模块)，因而如果您将原始的protobuf音讯作为actor音讯发送，则无需为此增加配置。 ## 程式化 如果要应用Akka序列化,以编程形式进行序列化/反序列化，请参见以下示例：清单是一种类型提醒，因而同一序列化程序可用于不同的类。请留神，从字节反序列化时，须要清单和serializer的标识符。 重要的是，以这种形式应用序列化程序标识符来反对滚动更新，其中类的serialization-bindings可能已从一个序列化程序更改为另一个序列化程序。 因而，由字节，序列化ID和清单组成的三个局部应始终一起传输或存储，以便能够应用不同的序列化绑定配置对它们进行反序列化。SerializationExtension是经典扩大，但能够与akka.actor.typed.ActorSystem一起应用，如下所示：# 个性化此页面上的第一个代码段蕴含一个配置文件，该配置文件援用了自定义序列化程序docs.serialization.MyOwnSerializer。 咱们将如何创立这样的自定义序列化程序？## 创立新的序列化器自定义序列化程序必须继承akka.serialization.JSerializer，并且能够如下定义：标识符必须是惟一的。抉择要用于反序列化的序列化器时，将应用该标识符。如果您意外地配置了多个具备雷同标识符的序列化程序，这些序列化程序将被检测到并阻止ActorSystem启动。它能够是硬编码的值，因为它必须放弃雷同的值以反对滚动更新。清单是一种类型提醒，因而同一序列化程序可用于不同的类。 fromBinaryJava中的manifest参数是被序列化的对象的类。在fromBinary中，您能够在类上进行匹配，并将字节反序列化为不同的对象。而后，您只须要填写空白，将其绑定到配置中的名称，而后列出应应用其反序列化的类。启动ActorSystem时，serializers将由SerializationExtension初始化，因而，序列化程序自身不能从其构造函数拜访SerializationExtension。相同，它应该提早拜访SerializationExtension。## 字符串清单的序列化器下面阐明的序列化程序反对基于类的清单(类型提醒)。对于须要随工夫变动的数据进行序列化，倡议应用SerializerWithStringManifest而不是Serializer，因为清单(类型提醒)是String而不是Class。这意味着能够挪动/删除该类，并且serializer仍能够通过匹配String来反序列化旧数据。这对于持久性特地有用。清单字符串还能够编码一个版本号，该版本号可用于fromBinary中以不同形式反序列化,将旧数据迁徙到新的畛域对象。如果数据最后是应用Serializer进行序列化的，并且在零碎的更高版本中更改为SerializerWithStringManifest，则清单字符串将是残缺的类名(如果您应用includeManifest = true)，否则它将是空字符串。这是SerializerWithStringManifest的样子：您还必须将其绑定到配置中的名称，而后列出应由其序列化的类。如果清单未知，倡议将IllegalArgumentException或java.io.NotSerializableException放入fromBinary中。这样就能够引入新的音讯类型，并将其发送到不晓得它们的节点。在执行滚动降级时，即运行具备混合版本的集群一段时间后，通常须要这样做。这些异样在经典近程解决层中被视为临时问题。该问题将被记录，并且音讯被抛弃。其余异样将断开TCP连贯，因为它可能表明传输的字节损坏。 Artery TCP将所有反序列化异样解决为暂时性问题。## 序列化ActorRefsactor援用通常蕴含在音讯中。当与Jackson一起应用序列化时，所有ActorRef都能够序列化，然而如果您正在编写本人的序列化器，则可能想晓得如何正确地序列化和反序列化它们。要应用字符串对actor进行序列化、反序列化，能够应用ActorRefResolver。例如，以下是Ping和Pong音讯序列化：经典ActorRef的序列化在Classic Serialization进行了形容。经典和Typed actor援用具备雷同的序列化格局，因而能够调换。## actor的深度序列化倡议应用Akka Persistence，对外部actor状态进行深度序列化。# Akka音讯的序列化Akka正在应用Protobuf 3对Akka定义的音讯进行序列化。这种依赖关系隐含在akka-protobuf-v3中，以便应用程序能够应用Protobuf的另一个版本。应用程序应应用规范的Protobuf依赖关系，而不是akka-protobuf-v3。# Java序列化家喻户晓，Java序列化速度很慢，并且容易受到各种类型的攻打-毕竟，它素来都不是为高吞吐量消息传递而设计的。可能有人认为网络带宽和提早会限度近程消息传递的性能，然而序列化是一个更为典型的瓶颈。>留神默认状况下，应用Java序列化的Akka序列化是禁用的，并且Akka自身不对其外部任何音讯应用Java序列化。不倡议在生产中启用Java序列化。生产中禁用的Java序列化程序收回的日志音讯,应视为序列化程序阻止的潜在攻打，因为它们可能示意内部操作试图发送旨在应用Java序列化作为攻打向量的歹意音讯。尝试应用SECURITY标记记录。然而，对于晚期原型制作来说，应用起来十分不便。因而，为了与依赖Java序列化的旧零碎兼容，能够应用以下配置启用它：当应用Java序列化时，Akka仍会记录正告，增加以下内容敞开正告：## Java序列化兼容性当应用Java序列化时，混合次要的Scala版本并不平安，因为Scala无奈保障兼容性，这可能会导致十分令人诧异的谬误。# 滚动降级序列化的近程音讯(或长久事件)由序列化器ID，清单和二进制有效载荷组成。反序列化时，仅查看serializer-id以抉择要用于fromBinary的序列化器。音讯类(绑定)不用于反序列化。该清单仅在Serializer中用于决定如何反序列化无效负载，因而一个Serializer能够解决许多类。这意味着能够通过执行两个滚动降级步骤来切换到新的序列化程序来更改音讯的序列化。1. 增加Serializer类，并在akka.actor.serializers配置中定义它，而不在akka.actor.serialization-bindings中定义它。为此更改执行滚动降级。这意味着序列化程序类存在于所有节点上并已注册，但仍未用于序列化任何音讯。这很重要，因为在滚动降级过程中，旧节点依然不理解新的序列化程序，因而无奈反序列化具备该格局的音讯。2. 第二个更改是用akka.actor.serialization-bindings配置中定义那些序列化程序，对某些类注册序列化程序。为此更改执行滚动降级。这意味着新节点在发送音讯时将应用新的序列化器，而旧节点将可能反序列化新格局。发送音讯时，旧节点将持续应用旧序列化程序，而新节点将可能反序列化旧格局。作为可选的第三步，如果旧的序列化程序未用于持久性事件，则能够将其齐全删除。依然必须能够反序列化旧序列化程序存储的事件。# 内部Akka序列化器- Kryo serializer for Akka- Twitter Chill Scala extensions for Kryo## 验证通常，在本地actor(即同一JVM)之间发送的音讯不会进行序列化。对于测试，有时可能心愿对所有音讯(近程音讯和本地音讯)强制进行序列化。如果要执行此操作以验证音讯可序列化，则能够启用以下配置选项：通过扩大标记接口akka.actor.NoSerializationVerificationNeeded或在配置akka.actor.no-serialization-verification-needed-class-prefix中定义类名称前缀，能够将某些音讯从验证中排除。如果要验证Props是否可序列化，能够启用以下配置选项：>正告咱们倡议仅在运行测试时关上这些配置选项。 在生产中关上这些选项是没有意义的，因为这会对本地消息传递的性能产生负面影响，而不会带来任何收益。

正告此模块以后被标记为可能会更改，因为它是一项新性能，须要依据理论应用反馈的状况确定最终API。这意味着API或语义能够更改，而不会收回正告或弃用期限。还不建议您在生产中立刻应用此模块。模块信息要应用牢靠的交付，请将模块增加到您的我的项目中： 介绍失常的消息传递可靠性最多只能传递一次，这意味着音讯可能会失落。那应该很少见，但依然可能。 对于某些actors之间的交互，这是不可承受的，并且须要至多一次交付或无效一次解决。此处介绍的牢靠交付工具有助于实现这一指标。没有应用程序的合作，它不可能在幕后主动实现。这是因为确认音讯何时已被齐全解决是业务级别的问题。仅确保将其通过网络传输或传递到参与者的邮箱是不够的，因为参与者可能在解决音讯之前就解体了。 依据须要检测，从新发送和删除反复邮件。此外，它还包含用于音讯发送的流控制，以防止疾速生产者吞没较慢的用户或以比能够通过网络传输的音讯更高的速率发送音讯。这可能是参与者之间交互中的常见问题，会导致致命谬误，例如OutOfMemoryError，因为参与者的邮箱中排队的邮件过多。失落音讯的检测和流控制是由用户方驱动的，这意味着生产方方的发送速度不会快于用户方的要求。除非消费者方要求，否则生产者方不会推送重发。 有3种受反对的模式，以下各节中进行了介绍： 点对点工作拉分片

正告此模块以后被标记为可能会更改，因为它是一项新性能，须要依据理论应用反馈的状况确定最终API。这意味着API或语义能够更改，而不会收回正告或弃用期限。还不建议您在生产中立刻应用此模块。模块信息要应用牢靠的交付，请将模块增加到您的我的项目中： 介绍失常的消息传递可靠性最多只能传递一次，这意味着音讯可能会失落。那应该很少见，但依然可能。 对于某些actors之间的交互，这是不可承受的，并且须要至多一次交付或无效一次解决。此处介绍的牢靠交付工具有助于实现这一指标。没有应用程序的合作，它不可能在幕后主动实现。这是因为确认音讯何时已被齐全解决是业务级别的问题。仅确保将其通过网络传输或传递到参与者的邮箱是不够的，因为参与者可能在解决音讯之前就解体了。 依据须要检测，从新发送和删除反复邮件。此外，它还包含用于音讯发送的流控制，以防止疾速生产者吞没较慢的用户或以比能够通过网络传输的音讯更高的速率发送音讯。这可能是参与者之间交互中的常见问题，会导致致命谬误，例如OutOfMemoryError，因为参与者的邮箱中排队的邮件过多。失落音讯的检测和流控制是由用户方驱动的，这意味着生产方方的发送速度不会快于用户方的要求。除非消费者方要求，否则生产者方不会推送重发。 有3种受反对的模式，以下各节中进行了介绍： 点对点工作拉分片

模块信息分布式公布订阅主题API在外围的akka-actor-typed的模块中可用,然而仅在集群应用程序中应用时： Topic Actor通过应用actor示意每个pub子主题，能够实现分布式公布订阅,akka.actor.typed.pubsub.Topic。 主题actor须要在订阅者宿主的每个节点上运行，或者要向该主题公布音讯。 主题的标识是能够公布的音讯类型的元组和主题名称的字符串，然而倡议不要定义具备不同类型和雷同主题名称的多个主题。 而后，本地actors能够订阅主题（并勾销订阅）： 公布音讯到该主题 Pub Sub可伸缩性每个主题都由一个“接待员”服务key示意，这意味着主题的数量将扩大到数千或数万，但对于更多的主题，则须要自定义解决方案。这也意味着特定主题的很高周转率将无奈失常工作，因而对于此类用例，倡议应用自定义解决方案。 主题actor充当代理，并委派给解决反复数据的本地订阅者，这样，公布的音讯仅发送到节点一次，而不论该节点上有多少订阅者。 当主题actor没有主题订阅者时，它将从接待员中登记本人，这意味着将不会向该actor公布已公布的音讯。 牢靠传递与Akka的“消息传递可靠性”一样，分布式pub子模式下的消息传递保障最多只能传递一次。换句话说，音讯可能会失落。除了具备订阅者的节点的注册表最终是统一的之外，这意味着在一个节点上订阅一个actor会有短暂的提早，而后能力在其余节点上晓得并公布。 如果您心愿至多一次传递保障，咱们建议您抉择Alpakka Kafka。

您正在查看新的actor API的文档，以查看Akka Classic文档，请参阅Classic Multi-DC Cluster 本章介绍如何在多个数据中心，可用性区域或区域中应用Akka群集。 使Akka群集理解数据中心边界的起因是，与同一数据中心中的节点之间的通信相比，跨数据中心的通信通常具备更高的提早和更高的故障率。 然而，节点的分组不限于数据中心的物理边界，即便这是次要用例。因为其余起因，它也能够用作逻辑分组，例如隔离某些节点以进步稳定性，或将大型群集分成较小的节点组以实现更好的可伸缩性。 相依性要应用Akka Cluster，请在您的我的项目中增加以下依赖项： sbtval 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群集能够逾越多个数据中心，并且依然能够容忍网络分区。

正告此模块以后被标记为可能会更改，因为它是一项新性能，取得理论应用状况的反馈后确定最终确定API。这意味着API或语义能够更改，而不会收回正告或弃用期限。还不建议您在生产中立刻应用此模块。模块信息要应用Akka Sharded守护过程，必须在我的项目中增加以下依赖项： 介绍分片守护过程提供了一种运行N个actor的办法，每个actor都有一个从0开始的数字ID，而后在整个集群中放弃流动，并保持平衡。当须要从新均衡时，actor将进行，并由在所有节点上放弃流动运行的节点触发，而后在新节点上启动（放弃流动应被视为实现细节，并且在未来的版本中可能会更改）。 预期的用例是将数据处理工作负载调配给肯定数量的workers，每个worker都须要解决数据子集。通常须要依据CQRS应用程序中所有EventSourcedBehaviors可用的事件流来创立投影。应用N个标记中的一个标记事件，这些标记用于在N个worker之间调配生产、更新投影的工作量。 对于须要放弃单个worker存活的状况，请参阅“群集单例” 根本例子要设置一组与Sharded Daemon过程一起运行的actor，集群中的每个节点在启动时都须要运行雷同的初始化： 提供了一种额定的工厂办法，以实现进一步的可配置性并为actor提供失常的进行音讯。 actors寻址在须要将音讯发送给守护过程actors的用例中，倡议将零碎接待员与一个ServiceKey一起应用，所有守护过程actors都将其注册到播送中，或者须要更细粒度的消息传递时应用单个ServiceKey。 可扩展性该群集工具仅实用于大量消费者，无奈很好地扩大到大范畴。在大型集群中，倡议应用角色限度节点数量，分片守护程序过程将在其上运行。

ShardRegion actor在群集中的每个节点或标记有特定角色的节点组上启动。应用两个特定应用程序的函数创立ShardRegion，以从传入音讯中提取实体标识符和分片标识符。分片是一起治理的一组实体。对于特定分片中的第一条音讯，ShardRegion向地方协调器ShardCoordinator申请分片的地位。 ShardCoordinator决定哪个ShardRegion领有该Shard，并告诉该ShardRegion。该region将确认此申请并创立Shard监管者作为子actor。而后，在Shard actor须要时将创立各个实体。因而，传入音讯通过ShardRegion和Shard达到指标实体。 如果分片宿主是另一个ShardRegion实例，则将音讯转发到该ShardRegion实例。在解析分片的地位时，对该分片的传入音讯进行缓冲，而后在晓得分片宿主时进行传递。后续到已解析分片的音讯能够立刻传递到指标目的地，而无需波及ShardCoordinator。 场景一旦晓得了分片的地位，ShardRegions就会间接发送音讯。如下达到此状态的场景。在场景中，应用以下表示法： SC-分片协调员M#-音讯1、2、3等SR#-ShardRegion 1、2 3等S#-分片1 2 3等E#-实体1 2 3，等等。实体是指由集群分片治理的Actor。#是一个数字，用于辨别实例，因为集群中有多个实例。 场景1：发送音讯到本地ShardRegion的未知分片1.传入音讯M1到ShardRegion实例SR1。2.M1映射到分片S1。 SR1不晓得S1，因而向SC询问S1的地位。3.SC答复S1的来自SR1。4.SR1创立子actor代表分片S1，并将音讯转发给它。5.S1为E1创立子actor，并将音讯转发给它。6.SR1能够解决所有达到SR1的传入S1的音讯，而无需SC。 场景2：音讯发送到近程ShardRegion的未知分片1.音讯M2传入ShardRegion实例SR1。2.M2映射到S2。 SR1不理解S2，因而向SC询问S2的地位。3.SC答复S2的来自SR2。4.SR1向S2发送为SR2的缓冲音讯。5.SR1能够在没有SC的状况下，解决达到SR1的传入S2的所有音讯。它将音讯转发到SR2。6.SR2收到无关S2的音讯，询问SC，它答复S2的来自SR2，如场景1形容的。 分片地位为了确保特定实体actor的最多一个实例在集群中的某处运行，重要的是所有节点对分片的地位具备雷同的认识。因而，分片调配决定由地方ShardCoordinator决定，地方ShardCoordinator作为集群单例运行，即所有集群节点中或标记有特定角色的一组节点中的最老的一个实例。 在可插拔shard allocation strategy中定义了决定分片位于何处的逻辑。 分片再均衡为了可能应用集群中新增加的成员，协调器利用分片的从新均衡，行将实体从一个节点迁徙到另一个节点。在从新均衡过程中，协调器首先告诉所有ShardRegion actors，已开始为分片进行切换。这意味着它们将开始缓冲该分片的传入音讯，就像分片地位未知一样。在从新均衡过程中，协调器将不答复任何申请在从新均衡的分片地位的申请，即本地缓冲将持续进行，直到切换实现为止。负责从新均衡分片的ShardRegion将通过向其发送指定的stopMessage（默认PoisonPill）来进行该分片中的所有实体。当所有实体都终止后，领有实体的ShardRegion将向协调员确认切换已实现。尔后，协调器将回复对分片地位的申请，从而为分片调配新的地位，而后将ShardRegion actor中的缓冲消息传递到新地位。这意味着实体的状态不会被传输或迁徙。如果实体的状态很重要，则它应该是长久的（长久化），例如应用持久性（或参见经典持久性），以便能够在新地位复原它。 可插拔分片调配策略中定义了决定从新分片的逻辑。默认实现ShardCoordinator.LeastShardAllocationStrategy从具备最多先前调配的分片数量的ShardRegion中抉择分片进行切换。而后将它们调配给具备起码数量先前调配的分片的ShardRegion（即群集中的新成员）。 对于LeastShardAllocationStrategy，有一个可配置的阈值（rebalance-threshold），该阈值要求开始进行从新均衡时必须相差多大。分片最多的区域和分片起码的区域中的分片数量之差必须大于从新均衡阈值能力产生从新均衡。 从新均衡阈值1给出最佳散布，因而通常是最佳抉择。较高的阈值意味着能够同时从新均衡更多的分片，而不是一个接一个。这能够使从新均衡过程更快，然而不同节点之间的分片（因而负载）数量可能显着不同。 ShardCoordinator状态ShardCoordinator中的分片地位状态对于分布式数据（或参见经典分布式数据）是长久（长久）的，以应答故障。 从集群中删除（通过故障）解体或无法访问的协调器节点后，新的ShardCoordinator单例actor将接管并复原状态。在这样的故障期间，具备已知地位的分片依然可用，而发送给新（未知）分片的音讯将被缓冲，直到新的ShardCoordinator可用为止。 音讯排序只有发件人应用雷同的ShardRegion actor将消息传递到实体actor，就将保留音讯的程序。只有未达到缓冲区限度，就以尽力而为的形式发送音讯，并具备至少一次的发送语义，形式与一般音讯发送雷同。 牢靠传递通过应用“牢靠传递”性能，能够增加具备至多一次语义的牢靠的端到端消息传递。 开销因为与协调器的往返途程，针对以新的或先前未应用的分片为指标的音讯引入了一些额定的提早。分片的从新均衡也可能会减少提早。在设计应用程序特定的分片分辨率（例如，防止太细的分片。晓得分片的地位后，惟一的开销就是通过ShardRegion而不是间接发送音讯。

模块信息要应用Akka群集分片，必须在我的项目中增加以下依赖项： 介绍当您须要在群集中的多个节点之间散布actors,并心愿可能应用其逻辑标识符与actors进行交互，而又不用关怀actors在群集中的物理地位（随工夫变动）时，群集分片将十分有用。 例如，它能够是代表畛域驱动设计术语中的聚合根的actors。在这里，咱们称这些actors为“实体”。这些actors通常具备长久（长久）状态，然而此性能并不限于具备长久状态的actors。 Akka Cluster Sharding简介视频是学习Cluster Sharding的一个很好的终点。 当您有许多有状态的actors一起耗费超过一台机器能够提供的资源（例如内存）时，通常应用集群分片。如果只有几个有状态的actors，则在“群集单例”节点上运行它们可能会更容易。 在这种状况下，分片意味着具备标识符（称为实体）的actors能够主动散布在集群中的多个节点上。每个实体actor仅在一个中央运行，并且能够将音讯发送到实体，发送方无需晓得指标actor的地位。这是通过扩大提供的ShardRegion actor发送音讯来实现的，该actor晓得如何将带有实体ID的音讯路由到最终目的地。 如果启用了该性能，则群集分片将不会在状态为WeaklyUp的成员上处于活动状态。 正告请确保不要应用“群集敞开”策略，免得在网络呈现问题或零碎过载（长时间的GC暂停）时将群集拆分为几个独自的群集，因为这将导致启动多个分片和实体，每个独自的群集中都有一个！请参阅Downing。根本例子通过ClusterSharding扩大拜访分片: 分片常与持久性一起应用，然而任何行为都能够与分片一起应用，例如 根本计数器： 每个实体类型都有一个key，该key用于检索给定实体标识符的EntityRef。 请留神，在示例的Counter.create函数中，未调用entityId参数，它是用来演示如何将其传递给实体的。 另一种执行此操作的办法是，如果须要，将entityId作为音讯的一部分发送。 而后，通过EntityRef将音讯发送到特定实体。 也能够将办法包装在ShardingEnvelope中或定义提取器性能，并将音讯间接发送到shard区域。 应在每种实体类型的每个节点上调用群集分片初始化。 能够应用角色来管制创立实体actors的节点。 init办法将依据节点的角色是否与实体的角色相匹配来创立ShardRegion或代理。 指定角色： 长久化示例应用分片时，能够将实体移至群集中的不同节点。 持久性可用于在actor挪动后复原其状态。 Akka Persistence基于单写程序原理，对于特定的PersistenceId，仅一个持久性actor实例处于活动状态。 如果多个实例要同时保留事件，则事件将交织并且在重播时可能无奈正确解释。 群集分片通常与持久性一起应用，以确保每个PersistenceId（entityId）只有一个流动实体。 这是用作分片实体的持久性actor的示例： 初始化和应用实体： 请留神，如何从Behavior的工厂函数中的EntityTypeKey和EntityContext提供的EntityId结构惟一的PersistenceId。这是定义PersistenceId的一种典型办法，然而其余格局也是可能的，如PersistenceId section所述。 向持久性实体发送音讯与该实体不是持久性实体雷同。惟一的区别是，当挪动实体时，状态将被复原。在下面的示例中，应用ask，但能够应用tell或其余任何交互模式。 无关更多详细信息，请参见persistence。 分片调配分片是一起治理的一组实体。分组通常是由entityId的哈希函数定义的。对于特定的实体标识符，分片标识符必须始终雷同。否则，实体actor可能会意外地同时在多个中央启动。 默认状况下，分片标识符是实体标识符的hashCode的绝对值，以分片总数取模。分片的数量通过以下形式配置： 依据教训，分片的数量应比打算的最大群集节点数量大十倍。不肯定要确切。分片少于节点数会导致某些节点不会托管任何分片。分片过多会导致分片的管理效率升高，例如从新均衡开销，并减少了提早，因为每个分片的第一条音讯的路由中都蕴含了协调器。 集群中所有节点的number-of-shards配置值必须雷同，并在退出时通过配置查看进行验证。更改值须要进行集群中的所有节点。 分片被调配给集群中的节点。由分片调配策略决定在何处调配分片。默认实现ShardCoordinator.LeastShardAllocationStrategy将新的分片调配给ShardRegion（节点），并且之前调配的分片数量起码。此策略能够由应用程序指定的实现形式代替。 外局部片调配另一种调配策略是ExternalShardAllocationStrategy，它容许通过ExternalShardAllocation扩大来显式管制分片在何处调配。例如，这能够用于将Kafka分区生产与分片地位相匹配。 要应用它，将其设置为您实体上的调配策略： 对于尚未调配的任何shardId，它将调配给申请节点。 进行明确调配： 任何新的或挪动的分片调配都将在下一次从新均衡时挪动。 从客户端到分片调配策略的通信是通过分布式数据进行的。它应用单个LWWMap，能够反对成千上万的分片。更高版本能够应用多个keys来反对更多的分片。 内部调配策略的示例我的项目Kafka to Cluster Sharding是一个示例我的项目，能够下载并带有如何运行的阐明，该示例演示了如何应用外局部片将Kafka分区生产对接分片。 自定义分片调配初始化实体类型或显式应用withAllocationStrategy函数时，能够将可选的自定义分片调配策略传递到可选参数中。无关如何实现自定义ShardAllocationStrategy的详细信息，请参见akka.cluster.sharding.AbstractShardAllocationStrategy的API文档。 运行原理请参阅Cluster Sharding concepts。 钝化如果实体的状态是持久性的，则能够进行不用于缩小内存耗费的实体。这是通过实体actors的特定于应用程序的实现来实现的，例如，通过定义接管超时（context.setReceiveTimeout）。如果邮件在本身进行时曾经入队，则该邮箱中的排队音讯将被抛弃。为了反对优雅的钝化而不失落此类音讯，实体actor能够发送ClusterSharding.Passivate到创立实体时传递给工厂办法的ActorRef <ShardCommand>。可选的stopMessage音讯将发送回该实体，而后该实体应自行进行，否则它将主动进行。在接管钝化和实体终止之间，分片将缓冲传入的音讯。尔后，将这些缓冲的消息传递到实体的新化身。 初始化如下： 请留神，在下面的示例中，将stopMessage指定为GoodByeCounter。该音讯会因从新均衡或钝化而自行进行发送给实体。如果未定义stopMessage，它将主动进行而不接管特定音讯。如果实体须要在进行之前执行一些异步革除或交互，则定义自定义进行音讯可能会很有用。 主动钝化如果实体在akka.cluster.sharding.passivate-idle-entity-after中配置的持续时间内未收到音讯，或者通过将ClusterShardingSettings上的passivateIdleEntityAfter标记显式设置为适合的工夫以使actor放弃活动状态，则这些实体将被主动钝化。请留神，仅对通过分片发送的音讯进行计数，因而在此流动中不计入间接发送给ActorRef的音讯或actor发送给本身的音讯。能够通过设置akka.cluster.sharding.passivate-idle-entity-after = off来禁用钝化。如果启用了“记住实体”，它将主动禁用。 分片状态有两种类型的状态治理： ShardCoordinator State-分片地位。这存储在状态存储中。记住实体-流动分片和每个分片中的实体，这是可选的，默认状况下处于禁用状态。这存储在“记住实体存储”中。状态存储状态存储对于分片是必不可少的，它蕴含分片的地位。 ShardCoordinator在节点之间挪动后须要加载此状态。 状态存储有两个选项： ...

模块信息要应用Cluster Singleton，必须在我的项目中增加以下依赖项： sbtval 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的成员上运行。 须要留神的潜在问题最后应用此模式仿佛很迷人，然而它有一些毛病，上面列出了其中的一些毛病： 群集单例可能很快成为性能瓶颈。您不能依附集群单例来提供不间断的服务，例如当已运行单例的节点死亡时，将须要几秒钟的工夫来留神到这一点，并将单例迁徙到另一个节点。如果应用了多个单例，请留神，所有这些都将在最旧的节点（或具备配置角色的最旧的节点）上运行。群集分片与使“单个”实体放弃流动联合起来可能是更好的抉择。正告确保不要应用会导致群集拆分为几个拆散局部的群集敞开策略

介绍近程DeathWatch应用心跳音讯和故障检测器来检测网络故障和JVM解体。 Hayashibara等人施行的“ Phi应计故障检测器”解释了心跳达到工夫。 故障检测器心跳心跳默认状况下每秒发送一次，这是可配置的。它们在申请/回复握手中执行，并且回复输出到故障检测器。 故障的可疑水平由称为phi的值示意。 phi故障检测器的根本思维是在能够动静调整以反映以后网络情况的标度上表白phi的值。 phi的值计算如下： phi = -log10（1-F（timeSinceLastHeartbeat））其中F是正态分布的累积散布函数，具备依据历史心跳达到间隔时间估算的平均值和标准偏差。 应计的故障检测器使监督和解释拆散。这使得它们实用于更宽泛的场景，并且更适宜构建通用的故障检测服务。其思维是保留从其余节点接管到的心跳计算出的故障统计数据的历史记录，并试图通过思考多个因素以及它们随工夫的累积如何进行有依据的猜想，以便提出更好的倡议。猜想特定节点是否处于运行状态。不仅要答复“节点是否断开？”问题，还要答复“是”或“否”。它返回一个phi值，示意节点产生故障的可能性。 下图阐明了自上一个心跳以来phi如何随着工夫减少而减少。

Akka群集的外围是群集成员，以跟踪哪些节点是群集的一部分,及其运行状况。应用gossip和故障检测来流传群集成员关系。 在群集成员关系服务之上构建了一些高级群集工具。 介绍集群由一组成员节点组成。每个节点的标识符是主机名：端口：uid元组。 Akka应用程序能够散布在群集中，每个节点托管应用程序的某些局部。集群成员资格与在该应用程序的该节点上运行的参与者是拆散的。节点能够是群集的成员，而无需托管任何参与者。通过向群集中要退出的节点之一收回“退出”命令来启动退出群集。 节点标识符在外部还蕴含一个UID，该ID在该hostname：port上惟一标识此actor零碎实例。 Akka应用UID可能牢靠地触发近程死亡监督。这意味着从同一集群中删除该集群后，该actor零碎再也无奈退出该集群。要将具备雷同hostname：port的actor零碎重新加入集群，您必须进行actor零碎，并启动一个具备雷同hostname：port的新零碎，而后它将接管到不同的UID。 成员状态群集成员状态是专用的CRDT，这意味着它具备枯燥合并性能。当不同节点上产生并发更改时，更新始终能够合并并收敛到雷同的最终后果。 join-退出集群时的瞬态 弱启动-网络拆散时的过渡状态（仅当akka.cluster.allow-weakly-up-members = on时） 向上-失常运行状态 来到/退出-失常移除期间的状态 down-标记为down（不再是集群决策的一部分） 已移除-逻辑删除状态（不再是成员） 成员工夫跟踪成员生命周期的事件是： ClusterEvent.MemberJoined-新成员已退出集群，其状态已更改为JoiningClusterEvent.MemberUp-新成员已退出集群，其状态已更改为UpClusterEvent.MemberExited-成员正在来到集群，其状态已更改为“正在退出”。请留神，当此事件在另一个节点上公布时，该节点可能曾经敞开。ClusterEvent.MemberRemoved-从集群中齐全删除的成员。ClusterEvent.UnreachableMember-由至多一个其余节点的故障检测器检测到的成员被视为不可达。ClusterEvent.ReachableMember-成员在不可拜访之后，再次被认为是可拜访的。先前将其检测为不可达的所有节点已将其再次检测为可达。 成员生命周期通过调用将节点置于联接状态的联接操作，将节点引入集群。一旦所有节点都晓得新节点正在退出（通过八卦收敛），领导者将把成员状态设置为up。 如果节点以平安的预期形式来到群集，例如通过协调关机，则它将调用leave操作，将其切换到来到状态。领导者在来到状态下看到节点上的收敛后，领导者便会将其移至进口。一旦所有节点都看到退出状态（收敛），领导者就会从群集中删除该节点，并将其标记为已删除。 如果节点不可拜访，那么八卦交融是不可能的，因而大多数领导者行为都是不可能的（例如，容许节点成为集群的一部分）。为了可能向前挪动，该节点必须再次变得可拜访，或者必须将节点明确“敞开”。这是必须的，因为无法访问的节点的状态未知，并且群集无奈晓得该节点是否已解体或因为网络问题或GC暂停而临时无法访问。请参阅上面无关用户操作的局部，以理解如何敞开节点。 退出或敞开的节点上的参与者零碎无奈再次退出集群。特地是，在无法访问时被敞开并随后从新取得连贯的节点无奈重新加入群集。相同，必须在节点上重新启动该过程，创立一个新的参与者零碎，该零碎能够再次通过退出过程。 一种非凡状况是在不经验来到或降落过程的状况下重新启动的节点，例如因为托管该节点的计算机意外重新启动。当节点的新实例尝试重新加入群集时，群集可能仍将旧实例视为不可拜访。然而，在这种状况下，很显然旧节点已隐没，因为新实例将具备与其旧实例雷同的地址（主机和端口）。在这种状况下，先前的实例将被主动标记为已敞开，而新实例能够在无需人工干预的状况下重新加入群集。 Leader领导者的目标是在达到收敛时确认状态变动。八卦收敛后，领导者能够由每个节点明确地确定。依据以后群集的组成，可能要求任何节点都表演领导者的角色。 没有收敛，不同的节点可能对哪个节点是领导者有不同的认识。因而，只有在存在收敛以确保所有节点都批准集群的以后状态并且状态更改源自单个节点的状况下，才容许大多数领导者动作。大多数惯例状态更改（例如将节点从联接更改为向上）都是这种类型的。 在其余状况下，即便以后无奈达到收敛，也须要采取措施。值得注意的是，如果故障检测器确定群集中的一个或多个节点以后不可达，则无奈达到收敛。在这种状况下，群集可能会被分区（裂脑场景），并且每个分区可能对哪些节点可拜访以及哪些节点无法访问有本人的认识。在这种状况下，分区两侧的节点可能会将本人视为可达节点的领导者。领导者在这种状况下执行的任何操作都必须以所有并发领导者得出雷同论断的形式设计（通常这是不可能的，只有在附加约束条件下才可行）。此类情况中最重要的状况是大脑裂开，须要手动或主动敞开节点以使群集复原交融。 Split Brain Resolver是该程序的内置实现。 无需收敛的另一种可能过渡是将成员标记为WeaklyUp，如下一节所述。 WeaklyUp 成员如果节点不可达，则八卦收敛是不可能的，因而大多数领导者行为是不可能的。通过启用akka.cluster.allow-weakly-up-members（默认状况下启用），即便尚未达到收敛，也能够将退出节点晋升为WeaklyUp。一旦八卦交融再次建设，领导者就会将WeaklyUp成员移至Up。 您能够订阅WeaklyUp成员资格事件以利用处于这种状态的成员，然而您应该晓得，网络分区另一侧的成员不晓得新成员的存在。例如，您不应该在法定决策中计算WeaklyUp成员。 状态图成员国状态图 用户动作join-将单个节点退出集群-如果已在配置中指定了要退出的节点，则在启动时能够是显式的或主动的 来到-通知节点失常来到集群，通常由ActorSystem或JVM通过协调敞开来敞开 down-将节点标记为down。须要执行此操作能力从群集中删除解体的节点（未“来到”）。它能够通过集群HTTP治理手动触发，也能够由诸如Split Brain Resolver之类的解体提供程序主动触发 Leader动作领导者有责任确认用户将成员移入或移出集群的操作： 退出⭢⭢弱地退出（执行此领导者操作不须要收敛，即便存在无奈达到的节点也能起作用）弱向上⭢向上（再次达到齐全收敛后）⭢来到退出⭢已删除向下⭢移除故障检测和不可达性不可拜访不是一个独自的成员状态，而是一个除状态之外的标记。监督另一个节点的每个节点上的故障检测器能够将被监督的节点标记为不可拜访，而与它的状态无关。之后，故障检测器将持续监督节点，直到它再次检测到该节点可达到并删除该标记。仅在所有监督节点都认为该节点可再次达到后，该节点才被视为可再次达到。

本文档介绍了Akka Cluster的设计概念。无关应用Akka群集的指南，请参见： 集群应用基于经典Akka API的群集应用集群成员服务介绍Akka Cluster提供了容错的、扩散的点对点集群成员服务，没有单点故障或单点瓶颈。它基于gossip协定和主动故障检测器实现。 Akka Cluster容许构建分布式应用程序，其中一个应用程序或服务逾越多个节点（实际上是多个ActorSystem）。 条款节点集群的逻辑成员。物理机上可能有多个节点。由主机名:端口:uid元组定义。 集群一组节点通过集群成员服务连贯在一起。 leader集群中的单个节点充当领导者。治理集群收敛和成员状态转换。 gossipAkka中应用的集群成员基于Amazon的Dynamo零碎，尤其是Basho的Riak分布式数据库中采纳的办法。集群集成员应用Gossip协定进行通信，该协定中群集的以后状态是通过群集随机进行的，优先传递给那些没有看到最新版本的成员。 矢量时钟矢量时钟是一种数据结构和算法，用于在分布式系统中生成事件的局部排序，检测违反因果关系。 在gossip中，咱们应用矢量时钟来协调和合并群集状态的差别。向量时钟是一组（节点，计数器）对。群集状态的每次更新都会随同矢量时钟的更新。 Gossip收敛集群在某个工夫点收敛到某个节点上。节点能够证实集群中所有其余节点都已察看到集群状态。在gossip时，通过传递一组看到以后状态版本的节点实现收敛。该信息在gossip概述中称为可见集。当所有节点都蕴含在可见汇合中时，就会收敛。 当任何节点都不可达时，gossip就不会收敛。节点须要再次可拜访，或挪动到敞开和删除状态（请参阅集群成员生命周期局部）。这只会阻止领导者执行其集群成员治理，并且不会影响在集群运行的应用程序。例如，这意味着在网络分区期间无奈向群集增加更多节点。节点能够退出，然而在分区修复或无法访问的节点已敞开之前，它们将不会移入Up状态。 故障检测Akka群集中的故障检测负责检测群集的其余部分是否无法访问该节点。为此，咱们应用了Phi应计故障检测器。为了可能应答突发异常情况（例如垃圾收集暂停、瞬态网络故障），能够轻松配置故障检测器以适应您的环境和需要。 在群集中，每个节点都由几个（默认最多5个）其余节点监控。要监控的节点是从哈希排序的节点环中的街坊中抉择的。这是为了减少跨机架和数据中心进行监督的可能性，然而在所有节点上的程序都是雷同的，这能够确保齐全笼罩。 当检测到任何节点不可达时，该数据将通过gossip流传到集群的其余部分。换句话说，只有一个节点须要将一个节点标记为不可达，以使集群的其余部分将该节点标记为不可达。 故障检测器还将检测节点是否再次可拜访。当监督不可达节点的所有节点再次将其视为可达时，在gossip流传之后，群集将认为它是可达的。 如果无奈将零碎消息传递到节点，它将被隔离，而后就无奈从无法访问的节点变为能够拜访。如果存在太多未确认的零碎音讯（例如，监控，已终止，近程actor部署，由近程父级监督的actors失败），则会产生这种状况。而后，须要将节点移至“已敞开”或“已删除”状态（请参阅集群成员生命周期），必须重新启动被隔离节点的actor零碎，而后能力再次退出集群。 更多详细信息，请参见以下内容： Phi应计故障检测器实现应用故障检测器Leader八卦收敛之后，能够确定集群的领导者。没有领导者选举过程，只有呈现八卦收敛，任何节点都能够始终确定地辨认领导者。领导者只是一个角色，任何节点都能够成为领导者，并且它能够在收敛回合之间扭转。领导者是按顺序排列的第一个节点，它能够充当领导者角色，领导者的首选成员国在这里起立并来到（无关成员国家的更多信息，请参阅集群成员资格生命周期）。 领导者的角色是将成员移入和移出群集，将加入成员更改为向上状态，或将退出成员更改为已移除状态。以后，领导者动作仅通过八卦收敛接管到新的集群状态来触发。 种子节点种子节点是退出群集的新节点的联系点。启动新节点时，它将向所有种子节点发送一条音讯，而后将联接命令发送到首先响应的种子节点。 种子节点配置值对正在运行的群集自身没有任何影响，它仅与新节点退出群集无关，因为它有助于它们找到将连贯命令发送到的联系点；新成员能够将此命令发送给集群的任何以后成员，而不仅是种子节点。 Gossip协定推挽式八卦的变体用于缩小在集群四周发送的八卦信息的数量。在推挽式八卦中，将发送摘要以示意以后版本，而不是理论值。而后，八卦的接收者能够将其具备较新版本的任何值发送回去，还能够申请其具备过期版本的值。 Akka应用带有矢量时钟的单个共享状态进行版本控制，因而Akka中应用的推挽式八卦变体利用此版本仅依据须要推送理论状态。 周期性地，默认值为每1秒一次，每个节点抉择另一个随机节点来发动一轮八卦。如果少于1/2的节点驻留在可见集中（曾经看到新状态），则群集将闲聊3次，而不是每秒一次。调整后的八卦距离是在状态更改后放慢晚期流传阶段的收敛过程的一种办法。 闲聊的节点的抉择是随机的，但偏差可能没有看到以后状态版本的节点。在每次八卦替换过程中，当尚未达到收敛时，一个节点会以很高的概率（可配置）与另一个不属于所见汇合的节点进行八卦，即可能具备较旧版本的状态。否则，它会随随便便闲聊节点。 这种有偏见的抉择是一种在状态更改后减速前期流传阶段的收敛过程的办法。 对于大于400个节点的集群（可配置，并由教训证据表明），逐步升高0.8的概率，以避免出现过多并发八卦申请的单个散乱者。八卦接收者还具备一种机制，能够通过抛弃已在邮箱中排队太长时间的音讯来爱护本人免受太多同时发的八卦音讯的侵害。 当群集处于聚合状态时，闲聊只会向所选节点发送一条蕴含闲聊版本的闲聊状态音讯。一旦集群发生变化（意味着不收敛），它将再次回到有偏差的八卦中。 八卦状态或八卦状态的接收者能够应用八卦版本（矢量时钟）来确定是否： 它具备八卦状态的新版本，在这种状况下，它会将其发送回八卦它具备过期的状态版本，在这种状况下，接收者通过回传其八卦状态版本来向闲聊者申请以后状态它的八卦版本抵触，在这种状况下，不同的版本将合并并发回如果收件人和八卦版本雷同，则不会发送或申请八卦状态。 八卦的周期性具备很好的状态变动批处理成果，例如很快将多个节点彼此连贯到一个节点将导致仅一个状态更改被流传到集群中的其余成员。 八卦音讯应用protobuf进行序列化，并且也被压缩以减小无效负载大小。