[翻译]AKKA笔记 - CHILD ACTORS与ACTORPATH -6

简介: 原文:http://rerun.me/2014/10/21/akka-notes-child-actors-and-path/Actor是完全的继承结构。

原文:http://rerun.me/2014/10/21/akka-notes-child-actors-and-path/

Actor是完全的继承结构。你创建的任何Actor肯定都是一个其他Actor的child。
让我们分析下:

PATH

我们用ActorSystem.actorof创建一个ActorRef并打印出他的path

val actorSystem=ActorSystem("SupervisionActorSystem")  
val actorRef=actorSystem.actorOf(Props[BasicLifecycleLoggingTeacherActor])  
println (actorRef.path) // (prints) akka://SupervisionActorSystem/user/$a  

可以看到,一个path看起来很像是文件系统中的一个文件路径。

  1. 这里的akka是固定的,因为这些都是Akka Actor的地址 - 与file://http://前缀差不多(跟协议没啥关系)

  2. SupervisionActorSystem就是你创建的ActorSystem的名字。

  3. user我们下节再说。

  4. $a是系统为你生成出来的Actor的名字。你对操作系统给你随机生成的文件名怎么看?很明显是人都不喜欢,因为你之后还要用这个名字。所以,让我们给他一个有意义的名字:

val actorRef=actorSystem.actorOf(Props[BasicLifecycleLoggingTeacherActor], "teacherActor")  
println (actorRef.path)     // (prints) akka://SupervisionActorSystem/user/teacherActor

现在这个路径(path)看起来差不多了。

这里写图片描述

CHILD ACTORS

跟从ActorSystem里面创建的顶级actor类似,我们也可以给ActorContext创建child actor。事实上, Actor的容错能力很大程度上就是靠使用Actor的继承层次和一个parent管理child actor的生命周期的方式。

现在假设你又一个TeacherSupervisor并且你打算创建一个TeacherActor来作为Supervisor的child,可以用ActorContext.actorof来代替使用ActorSystem.actorof:

class TeacherSupervisor extends Actor with ActorLogging {  
  val teacherActor=context.actorOf(Props[TeacherActor], "teacherActor")
...
...

基本上,在任何应用里,不像顶层actor,你会创建一堆的child actor - 这意思就是与调用actorSystem.actorof不同,你会调用一堆actorContext.actor
这里写图片描述

你会注意到child actor的path是akka://SupervisionActorSystem/user/teacherSupervisor/teacherActor,看起来跟给父目录创建一个子目录是一样的。

你什么时候开始创建子Actor?

在你的任务是由子任务或多个子任务组成的时候你就应该创建一个子actor了。在你执行的子任务是一个易错的时候,你想要隔离他(这样如果错了,你能恢复他)的时候你也需要创建一个子actor。当task之间没有父子关系时,你千万别创建子actor。

并且,还可以让子actor创建自己的子actor来代理他们自己的子任务。Actor的创建成本很低但产出却很高(我们在谈supervision的时候可以看到这个)

现在那个PATH中的USER是什么?

作为一个对比,我把ActorSystem比拟成一个Unix文件系统 - 有一个/root目录,还有其他的/etc,/usr,/bin和其他目录。

ActorSystem跟那个差不多。他创建一些顶层Actor - 最重要根Actor就是根目录/, user Actor就是/usrr目录,一个system Actor就是一个/system目录。(还有一个/deadLetters来代表DeadLetterActorRef。我们在上一篇里面看到过)

ActorSystem内组合了三个Actor(从ActorRefProvider)。他们是ActorSystem创建的所有actor的根actor。

  1. systemGuardian actor - 所有在/system下的actor的根
  2. guardian actor - 所有/user下actor的根
  3. rootGuardian Actor - systemGuardian和**userGuardian**actor
    的根
  /**
   * Reference to the supervisor of guardian and systemGuardian; ....
   */
  def rootGuardian: InternalActorRef

  /**
   * Reference to the supervisor used for all top-level user actors.
   */
  def guardian: LocalActorRef

  /**
   * Reference to the supervisor used for all top-level system actors.
   */
  def systemGuardian: LocalActorRef

这里写图片描述
/user(aka) user guardian

任何你在自己程序中像StudentActorTeacherActorActorSystemactof方法来创建的Actor都直接在/user。这就是之前teacherActor的路径是/user/teacherActor的原因。

/system(aka) system guardian

userGuardian死的时候system guardian会将自己关闭。当userGuardian关闭时这是合乎常理的, 他下面所有的业务actor都停掉了所以所有的管理员actor都需要一样停掉。

我们能看到System Actor被创建在两个地方 - 意思是在*/system继承关系下的actor。

  1. 像我们之前看到的,所有发给一个已经终结掉的Actor的消息都会被转发给一个内部Actor(DeadLetterActor)的邮箱。DeadLetter Actor把每个消息包装成DeadLetter*然后发送给EventStream。另一个叫**DeadLetterListener的Actor消费所有的DeadLetter并且将其作为一个日志消息发送出去。现在,DeadLetterListener是一个在/system/deadLetterListener下的system Actor。

  2. 想想我们之前写的订阅了EventStream的日志消息的TestEventListener?他们也是System actor。事实上,所有的akka.logger都是作为System actor来创建的。

class TeacherTest extends TestKit(ActorSystem("UniversityMessageSystem", ConfigFactory.parseString("""akka.loggers = ["akka.testkit.TestEventListener"]""")))  
...
...

这个文档提到所有用配置文件配置的Actor都会在启动的时候被创建并部署到ActorSystem,躲在/system的保护伞下。当我找到有趣的地方再更新下这个。

/(aka)root guardian
像我们之前看到的,/下的Actor是user和system guardian的父 actor。


杂七杂八

技术上来讲,root actor也有个父actor。这个actor的唯一任务就是当root actor失败是关闭整个ActorSystem。因此他没有被算在Actor的继承结构里, Akka项目组叫他:

  private[akka] val theOneWhoWalksTheBubblesOfSpaceTime: InternalActorRef = new MinimalActorRef {
...

文章来自微信平台「麦芽面包」(微信扫描二维码关注)。未经允许,禁止转载。

这里写图片描述

目录
相关文章
|
存储 算法 安全
CHAP:PPP 质询握手认证协议
点对点协议 (Point-to-Point Protocol,PPP) [1] 提供了一种通过点对点链路传输多协议数据报的标准方法。
787 0
CHAP:PPP 质询握手认证协议
|
4天前
|
弹性计算 关系型数据库 微服务
基于 Docker 与 Kubernetes(K3s)的微服务:阿里云生产环境扩容实践
在微服务架构中,如何实现“稳定扩容”与“成本可控”是企业面临的核心挑战。本文结合 Python FastAPI 微服务实战,详解如何基于阿里云基础设施,利用 Docker 封装服务、K3s 实现容器编排,构建生产级微服务架构。内容涵盖容器构建、集群部署、自动扩缩容、可观测性等关键环节,适配阿里云资源特性与服务生态,助力企业打造低成本、高可靠、易扩展的微服务解决方案。
1106 0
|
3天前
|
机器学习/深度学习 人工智能 前端开发
通义DeepResearch全面开源!同步分享可落地的高阶Agent构建方法论
通义研究团队开源发布通义 DeepResearch —— 首个在性能上可与 OpenAI DeepResearch 相媲美、并在多项权威基准测试中取得领先表现的全开源 Web Agent。
511 10
|
13天前
|
人工智能 运维 安全
|
12天前
|
人工智能 测试技术 API
智能体(AI Agent)搭建全攻略:从概念到实践的终极指南
在人工智能浪潮中,智能体(AI Agent)正成为变革性技术。它们具备自主决策、环境感知、任务执行等能力,广泛应用于日常任务与商业流程。本文详解智能体概念、架构及七步搭建指南,助你打造专属智能体,迎接智能自动化新时代。
|
4天前
|
弹性计算 Kubernetes jenkins
如何在 ECS/EKS 集群中有效使用 Jenkins
本文探讨了如何将 Jenkins 与 AWS ECS 和 EKS 集群集成,以构建高效、灵活且具备自动扩缩容能力的 CI/CD 流水线,提升软件交付效率并优化资源成本。
301 0
|
11天前
|
人工智能 异构计算
敬请锁定《C位面对面》,洞察通用计算如何在AI时代持续赋能企业创新,助力业务发展!
敬请锁定《C位面对面》,洞察通用计算如何在AI时代持续赋能企业创新,助力业务发展!
|
12天前
|
机器学习/深度学习 人工智能 自然语言处理
B站开源IndexTTS2,用极致表现力颠覆听觉体验
在语音合成技术不断演进的背景下,早期版本的IndexTTS虽然在多场景应用中展现出良好的表现,但在情感表达的细腻度与时长控制的精准性方面仍存在提升空间。为了解决这些问题,并进一步推动零样本语音合成在实际场景中的落地能力,B站语音团队对模型架构与训练策略进行了深度优化,推出了全新一代语音合成模型——IndexTTS2 。
803 23