Akka 是一个用于在 JVM 上构建高并发、分布式和容错的事件驱动应用程序的运行时工具包。Akka 既可以用于 Java，也可以用于 Scala。本指南通过描述 Java 版本的Hello World示例来介绍 Akka。如果你喜欢将 Akka 与 Scala 结合使用，请切换到「快速入门 Akka Scala 指南」。
Akka 的邮箱中保存着发给 Actor 的信息。通常，每个 Actor 都有自己的邮箱，但也有例外，如使用BalancingPool，则所有路由器（routees）将共享一个邮箱实例。
ActorNormal重写createReceive函数，然后使用receiveBuilder构造一个接收器Receive，然后使用Receive的Match函数，对不同类型的请求进行分别处理；在处理内部可以使用 sender().tell发送返回值给请求者。
对于Flink中各个组件（JobMaster、TaskManager、Dispatcher等），其底层RPC框架基于Akka实现，本文着重分析Flink中的Rpc框架实现机制及梳理其通信流程。
Akka 是 JVM 平台上构建高并发、分布式和容错应用的工具包和运行时环境。Akka用Scala 语言编写，同时提供了 Scala 、JAVA 的开发接口。
本篇作为scala快速入门系列的第四十篇博客，为大家带来的是关于Akka的内容。
模拟实现基于文本界面的《客户信息管理软件》。 该软件 scala 能够实现对客户对象的插入、修改、删除、显示、查询（用 ArrayBuffer 或者 ListBuffer 实现），并能够打印客户明细表。
「Actor Model」为编写并发和分布式系统提供了更高级别的抽象。它减少了开发人员必须处理显式锁和线程管理的问题，使编写正确的并发和并行系统变得更容易。1973 年卡尔·休伊特（Carl Hewitt）在论文中定义了 Actors，然后通过 Erlang 语言所普及，并且在爱立信（Ericsson）成功地建立了高度并发和可靠的电信系统。
官网：https://guobinhit.github.io/akka-guide/
近日常有同学来问我如何阅读代码，关于这个问题的一般性答案我特别提了一个问题并自问自答。出于提供一个实际的例子的考量，正好此前综合地阅读 Spark 的 RPC 实现、Flink 基于 Akka 的 RPC 实现和 Actor Model 的通信模型，写成本文分享我阅读分布式计算系统 Spark 和 Flink 中的 RPC 实现的过程和思考。
flink-release-1.7.2/flink-runtime/src/main/java/org/apache/flink/runtime/rpc/RpcService.java
akka 2.6.x正式发布以来已经有好一段时间了。核心变化是typed-actor的正式启用，当然persistence,cluster等模块也有较大变化。一开始从名称估摸就是把传统any类型的消息改成强类型消息，所以想拖一段时间看看到底能对我们现有基于akka-classic的应用软件有什么深层次的影响。不过最近考虑的一些系统架构逼的我不得不立即开始akka-typed的调研，也就是说akka-classic已经无法或者很困难去实现新的系统架构，且听我道来：最近在考虑一个微服务中台。作为后台数据服务调用的唯一入口，平台应该是个分布式软件，那么采用akka-cluster目前是唯一的选择，毕竟前期搞过很多基于akka-cluster的应用软件。但是，akka-cluster-sharding只能支持一种entity actor。毕竟，由于akka-classic的消息是没有类型的，只能在收到消息后再通过类型模式匹配的方式确定应该运行的代码。所以，这个actor必须包括所有的业务逻辑处理运算。也就是说对于一个大型应用来说这就是一块巨型代码。还有，如果涉及到维护actor状态的话，比如persistenceActor，或者综合类型业务运算，那么又需要多少种类的数据结构，又怎样去维护、管理这些结构呢？对我来说这基本上是mission-impossible。实际上logom应该正符合这个中台的要求：cluster-sharding, CQRS... 抱着一种好奇的心态了解了一下lagom源码，忽然恍然大悟：这个东西是基于akka-typed的！想想看也是：如果我们可以把actor和消息类型绑在一起，那么我们就可以通过消息类型对应到某种actor。也就是说基于akka-typed，我们可以把综合性的业务划分成多个actor模块，然后我们可以指定那种actor做那些事情。当然，经过了功能细分，actor的设计也简单了许多。现在这个新的中台可以实现前台应用直接调用对应的actor处理业务了。不用多想了，这注定就是akka应用的将来，还等什么呢？
使用 Akka 可以让你从为 Actor 系统创建基础设施和编写控制基本行为所需的初级（low-level）代码中解脱出来。为了理解这一点，让我们看看你在代码中创建的 Actors 与 Akka 在内部为你创建和管理的 Actor 之间的关系，Actor 的生命周期和失败处理。
随着对 Actor 层次结构和行为的理解，剩下的问题是如何将物联网（IoT）系统的顶级组件映射到 Actor。让代表设备和仪表盘的 Actor 处于顶层是很有吸引力的。相反，我们建议创建一个表示整个应用程序的显式组件。换句话说，我们的物联网系统中只有一个顶级的 Actor。创建和管理设备和仪表板的组件将是此 Actor 的子 Actor。这允许我们将示例用例的体系结构图重构为 Actor 树：
为了使用集群客户端（Cluster Client），你需要将以下依赖添加到你的项目中：
该文摘要总结：本文介绍了如何利用Akka和Scala实现一个分布式计算系统，用于执行并行计算任务。具体来说，文章介绍了如何利用Akka的Actor模型和Scala的并发编程库来实现一个分布式计算系统，该系统能够执行多个计算任务，并将结果返回给调用者。同时，文章还探讨了如何利用Akka的Identify消息处理Actor的死亡，从而避免Actor的丢失，并提高系统的可用性。
前言 在Spark集群 + Akka + Kafka + Scala 开发(1) : 配置开发环境中，我们已经部署好了一个Spark的开发环境。 在Spark集群 + Akka + Kafka + Scala 开发(2) : 开发一个Spark应用中，我们已经写好了一个Spark的应用。 本文的目标是写一个基于akka的scala工程，在一个spark standalone的集群环境中运行。 akka是什么？ akka的作用 akka的名字是action kernel的回文。根据官方定义：akka用于r
Akka 是一个用 Scala 编写的库，用于简化编写容错的、高可伸缩性的 Java 和 Scala 的 Actor 模型应用。
akka-typed的actor从创建、启用、状态转换、停用、监视等生命周期管理方式和akka-classic还是有一定的不同之处。这篇我们就介绍一下akka-typed的actor生命周期管理。
关注“一猿小讲”公众号的小伙伴都清楚，上次《技术再深入一点又何妨？一脸懵B的聊Actor》，我们在“懵 B”的状态下，聊了聊 Actor 模型的理论知识。稍微再补充两句，如上图所示在 Actor 模型系统中，主要有互不依赖的 Actor 组成（图中圆圈），Actor 之间的通信是通过消息来实现的，其中每个 Actor 都有一个 MailBox 来存储接收到的消息，每个 Actor 都维护着自己的状态。
从Scala的2.11.0版本开始，Scala的Actors库已经过时了。早在Scala2.10.0的时候，默认的actor库即是Akka。
在高并发场景解决方案中，多从线程角度出发，以解决线程安全问题，锁范围又需要多业务场景考虑，何时上锁，何时解锁，何时自动过期等，而事件驱动是从执行什么操作驱动的，在软件系统的设计层面，两者关联性不大，一个强调安全，一个强调策略，那么有没有两者结合解决并发编程难的事件驱动解决方案呢？带着场景解决方案我们走进Akka。
👋 你好，我是 Lorin 洛林，一位 Java 后端技术开发者！座右铭：Technology has the power to make the world a better place.
容错（fault tolerance）概念与 Actor 相关，为了使用这些概念，需要在项目中添加如下依赖：
akka系统是一个分布式的消息驱动系统。akka应用由一群负责不同运算工作的actor组成，每个actor都是被动等待外界的某种消息来驱动自己的作业。所以，通俗点描述：akka应用就是一群actor相互之间发送消息的系统，每个actor接收到消息后开始自己负责的工作。对于akka-typed来说，typed-actor只能接收指定类型的消息，所以actor之间的消息交流需要按照消息类型来进行，即需要协议来规范消息交流机制。想想看，如果用户需要一个actor做某件事，他必须用这个actor明白的消息类型来发送消息，这就是一种交流协议。
调度器（Dispatchers）是 Akka 核心的一部分，这意味着它们也是akka-actor依赖的一部分：
这种方案是采用MQ作为中间的媒介，在服务端采用线程池异步处理任务，处理完成之后将结果发送到MQ中，客户端采用侦听的方式得到结果继续进行处理。
Flink基于Akka来实现内部各组件(ResourceManager、Dispatcher、JobMaster、TaskExecutor等)间的RPC通信。本篇着重分析Flink的RPC设计，如何封装Actor模型，RPC的创建和调用流程。
本章描述如何在可能的分布式 Actor 系统中标识和定位 Actor。它与这样一个核心理念紧密相连：「Actor 系统」形成了内在的监督层次结构，并且 Actor 之间的通信在跨多个网络节点的位置方面是透明的。
Akka是由各种角色和功能的Actor组成的，工作的主要原理是把一项大的计算任务分割成小环节，再按各环节的要求构建相应功能的Actor，然后把各环节的运算托付给相应的Actor去独立完成。Akka
在数据流应用的现实场景中常常会遇到与外界系统对接的需求。这些外部系统可能是Actor系统又或者是一些其它类型的系统。与这些外界系统对接的意思是在另一个线程中运行的数据流可以接收外部系统推送的事件
在《企业应用集成模式》一书中，定义了许多与消息处理有关的模式，其中运用最为广泛的模式为Publisher-Subscriber模式，尤其是在异步处理场景下。 基于Publisher-Subscriber模式，还可以根据不同的场景衍生出特殊的模式，例如针对一个Publisher和多个Subscriber，演化为Broadcast模式和Message Router模式。前者会将消息同时发送给所有的Subscriber，实现分布式的并行处理。例如针对订单处理的场景，当顾客下订单后，既需要生成订单，又需要通知库存准
ConcurrentLinkedQueue是一个基于链接节点的无界线程安全队列，它采用先进先出的规则对节点进行排序，当我们添加一个元素的时候，它会添加到队列的尾部，当我们获取一个元素时，它会返回队列头部的元素。
客户端不是运行时和程序执行的一部分，但用于准备数据流并将其发送到JobManager。之后，客户端可以断开连接(分离模式 detached mode)，或者保持连接以接收进度报告(附加模式 attached mode)。客户机可以作为触发执行的Java/Scala程序的一部分运行，也可以在命令行使用./bin/flink run...开启进程中运行。
为了使用集群单例（Cluster Singleton），你必须在项目中添加如下依赖：
在上篇讨论里我们主要介绍了Akka-Cluster的基本原理。同时我们也确认了几个使用Akka-Cluster的重点：首先，Akka-Cluster集群构建与Actor编程没有直接的关联。集群构建是
在上一篇讨论中我们谈到了监管：在Akka中就是一种直属父子监管树结构，父级Actor负责处理直属子级Actor产生的异常。当时我们把BackoffSupervisor作为父子监管方式的其中一种
在现实应用中akka-stream往往需要集成其它的外部系统形成完整的应用。这些外部系统可能是akka系列系统或者其它类型的系统。所以，akka-stream必须提供一些函数和方法来实现与各种不
akka-cluster对每个节点的每种状态变化都会在系统消息队列里发布相关的事件。通过订阅有关节点状态变化的消息就可以获取每个节点的状态。这部分已经在之前关于akka-cluster的讨论里介绍过了。由于akka-typed里采用了新的消息交流协议，而系统消息的发布和订阅也算是消息交换，也受交流协议约束。所以想通过重写以前示范的ClusterMemberStatus来了解一下akka-typed环境下节点状态变化消息监听的一些机制。
简单来说，Actor通过消息传递的方式与外界通信，而且消息传递是异步的。每个Actor都有一个邮箱，邮箱接收并缓存其他Actor发过来的消息，通过邮箱队列mail queue来处理消息。Actor一次只能同步处理一个消息，处理消息过程中，除了可以接收消息外不能做任何其他操作。
已经很多天没有写文章了，直到我今天在飞机上看了一本书《如何成为一个不完美主义者》，让我重新认识了“完美主义”这四个字。
上期说道：http/2还属于一种不算普及的技术协议，可能目前只适合用于内部系统集成，现在开始大面积介入可能为时尚早。不过有些项目需求不等人，需要使用这项技术，所以研究了一下akka-grpc，写了一篇介绍。本想到此为止，继续其它项目。想想这样做法有点不负责任，像是草草收场。毕竟用akka-grpc做了些事情，想想还是再写这篇跟大家分享使用kka-grpc的过程。
为了使用有限状态机（Finite State Machine）Actor，你需要将以下依赖添加到你的项目中：
任何类型的实例作为消息在两端独立系统的机器之间进行传递时必须经过序列化/反序列化serialize/deserialize处理过程。假设以下场景：在一个网络里有两台连接的服务器，它们分别部署了独立的akka系统。如果我们需要在这两台服务器的akka系统之间进行消息交换的话，所有消息都必须经过序列化/反序列化处理。akka系统对于用户自定义消息类型的默认序列化处理是以java-object serialization 方式进行的。我们上次提过：由于java-object-serialization会把
首先来介绍下，今天的主角“傻白甜”（SBT:Simple Build Tools）， 其功能与 Maven 和 Gradle 类似。其是由 Scala 编写，对于新手入门不是太友好，如果只是写纯 Java 的 Bug ，大可不必和自己过不去，但是如果你经常使用 Spark 等大数据工具，还是有点必要学学使用的。而且 Sbt 默认会从一些奇奇怪怪的地方下载依赖，相信大家的第一次，都不会很美好（ Sbt 的项目构建异常缓慢，而且还经常会失败），笔者也不例外，所以有了这篇文章，希望对你有些帮助。
在开始讨论Akka中对Actor的生命周期管理前，我们先探讨一下所谓的Actor编程模式。对比起我们习惯的行令式（imperative）编程模式，Actor编程模式更接近现实中的应用场景和功能测试
为了使用分布式数据（Distributed Data），你需要将以下依赖添加到你的项目中：
所以我从一个简单的Java程序开始，运行一个while循环直到EOF，然后进行JDBC调用来存储值。这是需要花一个小时才完成了，但后来我意识到程序的运行时比创建程序花费的时间更长。因此，任务并不像看起来那么容易。那可以做些什么呢？当然，我意识到我需要并行完成任务。
2、Master收到各Worker的注册信息后，会回复Worker已注册成功的信息
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
