在使用akka-typed的过程中发现有很多地方都简化了不少，变得更方便了，包括：Supervision，只要用Behaviors.supervise()把Behavior包住，很容易就可以实现这个actor的SupervisorStrategy.restartWithBackoff策略了。然后集群化的group router使用起来也很方便，再就是集群分片cluster-sharding了。下面我们就通过一个例子来介绍cluster-sharding的具体使用方法。
akka-typed的actor从创建、启用、状态转换、停用、监视等生命周期管理方式和akka-classic还是有一定的不同之处。这篇我们就介绍一下akka-typed的actor生命周期管理。
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-typed的router actor。route 分pool router, group router两类。我们先看看pool-router的使用示范：
在讨论lagom之前，先从遇到的需求开始介绍：现代企业的it系统变得越来越多元化、复杂化了。线上、线下各种系统必须用某种方式集成在一起。从各种it系统的基本共性分析：最明显的特征应该是后台数据库的角色了，起码，大家都需要使用数据。另外，每个系统都可能具备大量实时在线用户、海量数据特性，代表着对数据处理能力有极大的要求，预示系统只有通过分布式处理方式才能有效运行。
在前面的的讨论里已经介绍了CQRS读写分离模式的一些原理和在akka-typed应用中的实现方式。通过一段时间akka-typed的具体使用对一些经典akka应用的迁移升级，感觉最深的是EvenSourcedBehavior和akka-cluster-sharding了。前者是经典akka中persistenceActor的替换，后者是在原有组件基础上在使用方面的升级版。两者都在使用便捷性方面提供了大幅度的提升。在我看来，cluster-sharding是分布式应用的核心，如果能够比较容易掌握，对开发正确的分布式系统有着莫大的裨益。但这篇讨论的重点将会集中在EventSourcedBehavior上，因为它是实现CQRS的关键。而CQRS又是大数据应用数据采集（输入）管理最新的一个重要模式。
akka-cluster对每个节点的每种状态变化都会在系统消息队列里发布相关的事件。通过订阅有关节点状态变化的消息就可以获取每个节点的状态。这部分已经在之前关于akka-cluster的讨论里介绍过了。由于akka-typed里采用了新的消息交流协议，而系统消息的发布和订阅也算是消息交换，也受交流协议约束。所以想通过重写以前示范的ClusterMemberStatus来了解一下akka-typed环境下节点状态变化消息监听的一些机制。
前面提到过，akka-typed中较重要的改变是加入了EventSourcedBehavior。也就是说增加了一种专门负责EventSource模式的actor, 最终和其它种类的actor一道可以完美实现CQRS。新的actor，我还是把它称为persistentActor，还是一种能维护和维持运行状态的actor。即，actor内部状态可以存放在数据库里，然后通过一组功能函数来提供对状态的处理转变，即持续化处理persistence。当然作为一种具备EventSourcedBehavior的actor, 普遍应有的actor属性、方法、消息处理协议、监管什么的都还必须存在。在这篇讨论里我们就通过案例和源码来说明一下EventSourcedBehavior是如何维护内部状态及作为一种actor又应该怎么去使用它。
关于grpc，在前面的scalaPB讨论里已经做了详细的介绍：google gRPC是一种全新的RPC框架，在开源前一直是google内部使用的集成工具。gRPC支持通过http/2实现protobuf格式数据交换。protobuf即protocol buffer，是google发明的一套全新的序列化传输协议serialization-protocol，是二进制编码binary-encoded的，相对java-object，XML，Json等在空间上占有优势，所以数据传输效率更高。由于gRPC支持http/2协议，可以实现双向通讯duplex-communication，解决了独立request/response交互模式在软件编程中的诸多局限。这是在系统集成编程方面相对akka-http占优的一个亮点。protobuf格式数据可以很方便的转换成 json格式数据，支持对外部系统的的开放协议数据交换。这也是一些人决定选择gRPC作为大型系统微服务集成开发工具的主要原因。更重要的是：用protobuf和gRPC进行client/server交互不涉及任何http对象包括httprequest,httpresponse，很容易上手使用，而且又有在google等大公司内部的成功使用经验，用起来会更加放心。
akka-typed中已经没有PersistentActor了。取而代之的是带有EventSourcedBehavior的actor，也就是一种专门支持EventSource模式的actor。EventSource的原理和作用在之前的博客里已经有了比较详细的介绍，这里就不再重复了。本篇直接从EventsourcedBehavior actor的具体应用开始介绍。支持EventSource应用的基本数据类型包括 指令Command, 事件Event，状态State。EventSourcing其实就是一个有限状态机fsm finite-state-machine，执行Command，产生Event，改变State，终而复始。下面是一个简单的EventSource类型定义：
akka系统是一个分布式的消息驱动系统。akka应用由一群负责不同运算工作的actor组成，每个actor都是被动等待外界的某种消息来驱动自己的作业。所以，通俗点描述：akka应用就是一群actor相互之间发送消息的系统，每个actor接收到消息后开始自己负责的工作。对于akka-typed来说，typed-actor只能接收指定类型的消息，所以actor之间的消息交流需要按照消息类型来进行，即需要协议来规范消息交流机制。想想看，如果用户需要一个actor做某件事，他必须用这个actor明白的消息类型来发送消息，这就是一种交流协议。
在以前的博文中我们介绍了Slick，它是一种FRM（Functional Relation Mapper）。有别于ORM，FRM的特点是函数式的语法可以支持灵活的对象组合（Query Compos
上面这段文字摘抄自 Akka 官网（akka.io），翻译成中文也就是：“Akka 是一个为 Java 和 Scala 构建高并发、分布式和弹性消息驱动应用程序的工具包”。而 Akka 具有的一切特性，其实都源自于一个用于处理并发计算问题的模型——Actor 模型。
近日常有同学来问我如何阅读代码，关于这个问题的一般性答案我特别提了一个问题并自问自答。出于提供一个实际的例子的考量，正好此前综合地阅读 Spark 的 RPC 实现、Flink 基于 Akka 的 RPC 实现和 Actor Model 的通信模型，写成本文分享我阅读分布式计算系统 Spark 和 Flink 中的 RPC 实现的过程和思考。
在实际应用中，集群环境里共用一些数据是不可避免的。我的意思是有些数据可以在任何节点进行共享同步读写，困难的是如何解决更改冲突问题。本来可以通过分布式数据库来实现这样的功能，但使用和维护成本又过高，不值得。分布式数据类型distributed-data （ddata）正是为解决这样的困局而设计的。akka提供了一组CRDT（ConflictFreeReplicatedDataType 免冲突可复制数据类型）和一套管理方法来实现分布式数据在集群中的免冲突共享共用。
前面介绍了事件源（EventSource）和集群（cluster），现在到了讨论CQRS的时候了。CQRS即读写分离模式，由独立的写方程序和读方程序组成，具体原理在以前的博客里介绍过了。akka-typed应该自然支持CQRS模式，最起码本身提供了对写方编程的支持，这点从EventSourcedBehavior 可以知道。akka-typed提供了新的EventSourcedBehavior-Actor，极大方便了对persistentActor的应用开发，但同时也给编程者造成了一些限制。如手工改变状态会更困难了、EventSourcedBehavior不支持多层式的persist，也就是说通过persist某些特定的event然后在event-handler程序里进行状态处理是不可能的了。我这里有个例子，是个购物车应用：当完成支付后需要取个快照(snapshot)，下面是这个snapshot的代码：
原文地址：https://dzone.com/articles/elasticmq-070-long-polling-non
KillSwitch是Akka中用于实现多播和流处理的工具。它通过将多个数据流共享一个单一的KillSwitch来控制多个数据流的终止。使用KillSwitch时，多个数据流可以共享一个单一的KillSwitch，并通过调用KillSwitch的shutdown()方法来同时终止所有数据流的执行。此外，KillSwitch还可以通过调用abort()方法来终止数据流的执行，并抛出异常。在Akka中，使用KillSwitch可以有效地管理多个数据流，并确保所有数据流都按照预期执行。
故障可能发生在网络连接级别（进程之间的消息丢失或传递缓慢），也可能发生在进程级别（进程崩溃或运行缓慢），并且延迟始终不能与故障区分开。这意味着在错误地将活动过程怀疑为已死（产生假阳性）与延迟将无响应过程标记为已死之间进行权衡，这给了它怀疑的好处并期望它最终做出响应（产生假阴性）。
Open XML SDK 是属于 .Net 基金会的一个项目，本文将简要介绍该项目相关的信息。
当我初接触akka-cluster的时候，我有一个梦想，希望能充分利用actor自由分布、独立运行的特性实现某种分布式程序。这种程序的计算任务可以进行人为的分割后再把细分的任务分派给分布在多个服务器上的actor上去运算。这些服务器都处于同一集群环境里，它们都是akka-cluster中的节点（node）。akka-cluster的节点数量只需要通过系统配置方式按照计算能力要求随意增减，在集群上运行的分布式程序可以在不修改软件的情况下自动调整actors在各节点上的分布，重新平衡程序运算负载，不受任何影响继续运行。
本文介绍了Akka在Spark中的使用，包括Akka的主要特性和架构。首先介绍了Akka的入门知识，然后详细阐述了Akka在Spark中的使用，包括如何使用Akka进行RPC调用、如何使用Akka异步处理消息和如何使用Akka进行并行计算。最后，本文总结了Akka在Spark中的使用，并介绍了另一种基于Netty的RPC实现。
前言 在Spark集群 + Akka + Kafka + Scala 开发(1) : 配置开发环境中，我们已经部署好了一个Spark的开发环境。 在Spark集群 + Akka + Kafka + Scala 开发(2) : 开发一个Spark应用中，我们已经写好了一个Spark的应用。 本文的目标是写一个基于akka的scala工程，在一个spark standalone的集群环境中运行。 akka是什么？ akka的作用 akka的名字是action kernel的回文。根据官方定义：akka用于r
在很多应用场景中都会出现在系统中需要某类Actor的唯一实例（only instance）。这个实例在集群环境中可能在任何一个节点上，但保证它是唯一的。Akka的Cluster-Singleton
Akka-Cluster可以在一部物理机或一组网络连接的服务器上搭建部署。用Akka开发同一版本的分布式程序可以在任何硬件环境中运行,这样我们就可以确定以Akka分布式程序作为标准的编程方式了。
Akka 是一个用于在 JVM 上构建高并发、分布式和容错的事件驱动应用程序的运行时工具包。Akka 既可以用于 Java，也可以用于 Scala。本指南通过描述 Java 版本的Hello World示例来介绍 Akka。如果你喜欢将 Akka 与 Scala 结合使用，请切换到「快速入门 Akka Scala 指南」。
目标 配置一个spark standalone集群 + akka + kafka + scala的开发环境。 创建一个基于spark的scala工程，并在spark standalone的集群环境中运行。 创建一个基于spark+akka的scala工程，并在spark standalone的集群环境中运行。 创建一个基于spark+kafka的scala工程，并在spark standalone的集群环境中运行。 集群框架图 本图主要是说明各个组件可以发布到不同的逻辑机器上。 image.png 本
从Scala的2.11.0版本开始，Scala的Actors库已经过时了。早在Scala2.10.0的时候，默认的actor库即是Akka。
上一篇讨论里我们介绍了几种任务分配（Routing）模式。Akka提供的几种现成智能化Routing模式大多数是通过对用户屏蔽具体的运算Routee选择方式来简化Router使用，提高智能程度
欢迎来到 Akka，它是一组用于设计跨越处理器和网络的可扩展、弹性系统的开源库。Akka 允许你专注于满足业务需求，而不是编写初级代码来提供可靠的行为、容错性和高性能。
关于cluster-singleton我在前面的博文已经介绍过，在这篇我想回顾一下它的作用和使用方法。首先，cluster-singleton就是集群某个节点上的一个actor。任何时间在集群内保证只会有一个这种actor的实例。它可以是在任何节点上，具体位置由akka-cluster系统的leader节点根据一定规则选定。当cluster-singleton所处的节点停止运作时leader会选择另一个节点，然后系统会将cluster-singleton迁移到新的节点上来保证集群中一定有一个活着的cluster-singleton实例，不过值得注意的是迁移的actor会丢失它的内部状态。在编程实践中常常会需要保证一项程序功能只能由唯一的actor来运行的情况，比如我们需要保证某种运算的顺序，这时在集群环境里就可以使用cluster-singleton了。下面是cluster-singleton可能的一些使用场景：
ActorNormal重写createReceive函数，然后使用receiveBuilder构造一个接收器Receive，然后使用Receive的Match函数，对不同类型的请求进行分别处理；在处理内部可以使用 sender().tell发送返回值给请求者。
为了使用集群指标扩展（Cluster Metrics Extension），你需要将以下依赖添加到你的项目中：
你的朋友正在使用键盘输入他的名字 name。偶尔，在键入字符 c 时，按键可能会被长按，而字符可能被输入 1 次或多次。
当我们把Akka-http作为数据库数据交换工具时，数据是以Source[ROW,_]形式存放在Entity里的。很多时候除数据之外我们可能需要进行一些附加的信息传递如对数据的具体处理方式等。我
本文主要讲解Scala的并发（并行）编程，那么为什么题目概称geotrellis使用（六）呢，主要因为本系列讲解如何使用Geotrellis，具体前几篇博文已经介绍过了。我觉得干任何一件事情基础很重要，就像当年参加高考或者各种考试一样，老师都会强调基础，这是很有道理的。使用Geotrellis框架的基础就是Scala和Spark，所以本篇文章先来介绍一下Scala编程语言，同样要想搞明白Scala并发（并行）编程，Scala基础也很重要，没有Scala语言基础就谈不上Scala并发编程也就更谈不
力扣题目链接：https://leetcode-cn.com/problems/long-pressed-name
通过一段时间的学习了解，加深了一些对Akka的认识，特别是对于Akka在实际编程中的用途方面。我的想法，或者我希望利用Akka来达到的目的是这样的：作为传统方式编程的老兵，我们已经习惯了直线流程
任何类型的实例作为消息在两端独立系统的机器之间进行传递时必须经过序列化/反序列化serialize/deserialize处理过程。假设以下场景：在一个网络里有两台连接的服务器，它们分别部署了独立的akka系统。如果我们需要在这两台服务器的akka系统之间进行消息交换的话，所有消息都必须经过序列化/反序列化处理。akka系统对于用户自定义消息类型的默认序列化处理是以java-object serialization 方式进行的。我们上次提过：由于java-object-serialization会把
该文介绍了如何使用Akka HTTP和Slick在Scala中实现基于HTTP的流式数据传输。通过使用Akka HTTP和Slick，可以方便地处理HTTP请求和响应，以及从数据库中获取数据并将其传输到客户端。该文还介绍了如何使用Akka流式处理技术来实现HTTP服务，并处理响应数据。
在上篇讨论里我们主要介绍了Akka-Cluster的基本原理。同时我们也确认了几个使用Akka-Cluster的重点：首先，Akka-Cluster集群构建与Actor编程没有直接的关联。集群构建是
该文摘要总结：本文介绍了如何利用Akka和Scala实现一个分布式计算系统，用于执行并行计算任务。具体来说，文章介绍了如何利用Akka的Actor模型和Scala的并发编程库来实现一个分布式计算系统，该系统能够执行多个计算任务，并将结果返回给调用者。同时，文章还探讨了如何利用Akka的Identify消息处理Actor的死亡，从而避免Actor的丢失，并提高系统的可用性。
随着对 Actor 层次结构和行为的理解，剩下的问题是如何将物联网（IoT）系统的顶级组件映射到 Actor。让代表设备和仪表盘的 Actor 处于顶层是很有吸引力的。相反，我们建议创建一个表示整个应用程序的显式组件。换句话说，我们的物联网系统中只有一个顶级的 Actor。创建和管理设备和仪表板的组件将是此 Actor 的子 Actor。这允许我们将示例用例的体系结构图重构为 Actor 树：
通过上一篇文章，我们已经大致了解怎么使用 Akka，期待细致用法。这篇文章将介绍如何用 Akka-testkit 对 Akka 程序进行测试。 并行程序是最难调试的程序类型之一，因此做好测
Akka 的邮箱中保存着发给 Actor 的信息。通常，每个 Actor 都有自己的邮箱，但也有例外，如使用BalancingPool，则所有路由器（routees）将共享一个邮箱实例。
当前社会，人们越来越享受互联网带来的种种便利，同时也对互联网产品有了更高的要求，比如更快的响应速度和更稳定的服务；另一方面，互联网产品在不断发展的过程中也面临着非常多的技术挑战，比如服务化、分布式、并行计算等，那么，Akka在其中的哪些领域可以一展身手呢？
Akka 集群的核心是集群成员（cluster membership），以跟踪哪些节点是集群的一部分以及它们的健康状况。
在前面一篇讨论里我们介绍了通过http进行文件的交换。因为文件内容是以一堆bytes来表示的，而http消息的数据部分也是byte类型的，所以我们可以直接用Source[ByteString,_]
Akka 是 JVM 平台上构建高并发、分布式和容错应用的工具包和运行时环境。Akka用Scala 语言编写，同时提供了 Scala 、JAVA 的开发接口。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
