Actor层次结构

Riker中的Actor形成一个层次结构,每个actor都可以通过路径寻址。 actor在层次结构中的位置由其父级的位置决定。 让我们看一下actorsystem启动后的actor层次结构:

my-app
└─ user
└─ system
   └─ logger
   └─ event_stream
   └─ dead_letters
   └─ event_store
   └─ default_stream
   └─ io_manager
      └─ tcp
   └─ dl_logger
└─ temp

我们可以看到,如果没有开始任何 actor,我们已经有很多 actor在跑。 在层次结构的基础上是我们的应用程序根,它具有在system启动时提供的名称:ActorSystem :: new(“my-app”)。

然后是三个根 actorusersystemtemp actor。 也许最重要的是user,因为作为应用程序的一部分创建的大多数 actor都是在这个分支中创建的。

如果我们使用system.actor_of(props,“my-actor”)启动一个actor,我们可以在user下看到它添加:

my-app
└─ user
   └─ my-actor      <-- our new actor is added
└─ system
   └─ logger
   └─ event_stream
   └─ dead_letters
   └─ event_store
   └─ default_stream
   └─ io_manager
      └─ tcp
   └─ dl_logger
└─ temp

在这种情况下,新创建的my-actor有一个/ user / my-actor路径。 由于它是在ActorSystem上使用actor_of启动的,因此它被认为是顶级actor

让我们看看当另一个actor启动时层次结构如何变化,这次是使用Context.actor_of/ user / my-actorreceive方法中。

impl Actor for MyActor {
    type Msg = String;

    fn receive(&mut self,
                ctx: &Context<Self::Msg>,
                msg: Self::Msg,
                sender: ActorRef<Self::Msg>) {

        ctx.actor_of(MyActor::props(), "my-child").unwrap();
    }
}

这里MyActor将启动另一个actor,它也是MyActor的一个实例。

my-app
└─ user
   └─ my-actor      
      └─ my-child   <-- our new actor is added
└─ system
   └─ logger
   └─ event_stream
   └─ dead_letters
   └─ event_store
   └─ default_stream
   └─ io_manager
      └─ tcp
   └─ dl_logger
└─ temp

由于新 actor是使用my-actor的上下文开始的,因此它会作为my-actor的子节点添加到层次结构中。 我子Actor的路径变为/ user / my-actor / my-child

让我们继续下一节,在构建弹性应用程序时,明确了 actor层次结构实现监督的重要性。

上次更新: 1/7/2019, 12:55:17 PM