Akka 2.1.0官方文档：详解Actor模型与Java API

4星 · 超过85%的资源需积分: 10 47 浏览量更新于2024-07-26 1 收藏 1.85MB PDF 举报

Akka是一个强大的、开源的Actor模型实现，由Typesafe Inc开发，主要用于构建可扩展、容错的并发应用程序。本文档是Akka 2.1.0版本的官方说明文档，旨在提供对Akka核心概念、设计模式以及Java API的详细介绍。 1. **介绍**： - Akka的主要目标是帮助开发者构建高可用性和可维护性的分布式应用，利用Actor模型来处理并发任务，它强调消息传递和松耦合的组件间交互。 - 为什么选择Akka？因为它提供了轻量级的线程模型，支持异步编程和故障恢复，有助于减少系统瓶颈，提高性能，并简化复杂性。 2. **通用概念**： - **Actor系统**：是Akka的核心组成部分，它由一组相互作用的Actor组成，每个Actor负责处理特定的任务并通过发送消息进行通信。 - **Actor**：是独立运行的实体，拥有自己的状态和行为。它们通过发送消息进行通信，遵循单一职责原则，使得代码更易于理解和维护。 - **监督与监控**：Akka的Actor可以通过层次结构进行组织，上级Actor可以监督下级，提供错误处理和恢复机制。 - **Actor引用、路径和地址**：用于标识和定位Actor，使它们能够在分布式环境中找到彼此。 - **位置透明性**：允许在没有硬编码连接信息的情况下创建和通信Actor，增加了系统的灵活性和可扩展性。 3. **常用工具和功能**： - **持续时间（Duration）**：用于处理时间和延迟操作。 - **断路器（Circuit Breaker）**：防止雪崩效应，当系统异常时自动隔离故障部分。 - **Java API**：详尽地覆盖了Actor的创建、消息传递、日志记录、事件总线、调度、未来执行、故障 tolerance、调度器、远程通信、序列化、软事务内存、代理、交易者、有限状态机Actor、扩展点以及与ZeroMQ集成等关键功能。 4. **Java API深度剖析**： - **Java Actor API**：提供了创建和管理Actor的基本工具，包括派生、接收消息和发送回复。 - **类型化Actor**：增强了Actor的类型安全性，使得编译器能够检测潜在的错误。 - **Java日志**：集成日志记录框架，方便追踪和调试。 - **Java EventBus**：用于发布/订阅模式，实现组件间的通信。 - **Java Scheduler**：管理定时任务和并发执行。文档深入探讨了Akka如何处理并发、分布式环境中的可靠性和容错，以及如何有效地利用其提供的工具来简化开发过程。对于任何希望在Java环境中使用Actor模型构建高性能、可伸缩应用的开发人员来说，这份文档是不可或缺的参考资料。

Akka Documentation, Release 2.1.0

2.3.2 The Top-Level Supervisors

An actor system will during its creation start at least three actors, shown in the image above. For more information

about the consequences for actor paths see Top-Level Scopes for Actor Paths.

/user: The Guardian Actor

The actor which is probably most interacted with is the parent of all user-created actors, the guardian named

"/user". Actors created using system.actorOf() are children of this actor. This means that when this

guardian terminates, all normal actors in the system will be shutdown, too. It also means that this guardian’s

supervisor strategy determines how the top-level normal actors are supervised. Since Akka 2.1 it is possible to

conﬁgure this using the setting akka.actor.guardian-supervisor-strategy, which takes the fully-

qualiﬁed class-name of a SupervisorStrategyConfigurator. When the guardian escalates a failure, the

root guardian’s response will be to terminate the guardian, which in effect will shut down the whole actor system.

/system: The System Guardian

This special guardian has been introduced in order to achieve an orderly shut-down sequence where logging re-

mains active while all normal actors terminate, even though logging itself is implemented using actors. This

is realized by having the system guardian watch the user guardian and initiate its own shut-down upon re-

ception of the Terminated message. The top-level system actors are supervised using a strategy which

will restart indeﬁnitely upon all types of Exception except for ActorInitializationException and

ActorKilledException, which will terminate the child in question. All other throwables are escalated,

which will shut down the whole actor system.

/: The Root Guardian

The root guardian is the grand-parent of all so-called “top-level” actors and supervises all the special actors

mentioned in Top-Level Scopes for Actor Paths using the SupervisorStrategy.stoppingStrategy,

whose purpose is to terminate the child upon any type of Exception. All other throwables will be escalated

. . . but to whom? Since every real actor has a supervisor, the supervisor of the root guardian cannot be a real

actor. And because this means that it is “outside of the bubble”, it is called the “bubble-walker”. This is a

synthetic ActorRef which in effect stops its child upon the ﬁrst sign of trouble and sets the actor system’s

isTerminated status to true as soon as the root guardian is fully terminated (all children recursively stopped).

2.3. Supervision and Monitoring 13

Akka Documentation, Release 2.1.0

2.3.3 What Restarting Means

When presented with an actor which failed while processing a certain message, causes for the failure fall into three

categories:

• Systematic (i.e. programming) error for the speciﬁc message received

• (Transient) failure of some external resource used during processing the message

• Corrupt internal state of the actor

Unless the failure is speciﬁcally recognizable, the third cause cannot be ruled out, which leads to the conclusion

that the internal state needs to be cleared out. If the supervisor decides that its other children or itself is not

affected by the corruption—e.g. because of conscious application of the error kernel pattern—it is therefore best

to restart the child. This is carried out by creating a new instance of the underlying Actor class and replacing

the failed instance with the fresh one inside the child’s ActorRef; the ability to do this is one of the reasons for

encapsulating actors within special references. The new actor then resumes processing its mailbox, meaning that

the restart is not visible outside of the actor itself with the notable exception that the message during which the

failure occurred is not re-processed.

The precise sequence of events during a restart is the following:

1. suspend the actor (which means that it will not process normal messages until resumed), and recursively

suspend all children

2. call the old instance’s preRestart hook (defaults to sending termination requests to all children and

calling postStop)

3. wait for all children which were requested to terminate (using context.stop()) during preRestart

to actually terminate; this—like all actor operations—is non-blocking, the termination notice from the last

killed child will effect the progression to the next step

4. create new actor instance by invoking the originally provided factory again

5. invoke postRestart on the new instance (which by default also calls preStart)

6. send restart request to all children which were not killed in step 3; restarted children will follow the same

process recursively, from step 2

7. resume the actor

2.3.4 What Lifecycle Monitoring Means

Note: Lifecycle Monitoring in Akka is usually referred to as DeathWatch

In contrast to the special relationship between parent and child described above, each actor may monitor any other

actor. Since actors emerge from creation fully alive and restarts are not visible outside of the affected supervisors,

the only state change available for monitoring is the transition from alive to dead. Monitoring is thus used to tie

one actor to another so that it may react to the other actor’s termination, in contrast to supervision which reacts to

failure.

Lifecycle monitoring is implemented using a Terminated message to be received by the monitoring actor,

where the default behavior is to throw a special DeathPactException if not otherwise handled. In order to

start listening for Terminated messages is to use ActorContext.watch(targetActorRef) and then

ActorContext.unwatch(targetActorRef) to stop listening for that. One important property is that the

message will be delivered irrespective of the order in which the monitoring request and target’s termination occur,

i.e. you still get the message even if at the time of registration the target is already dead.

Monitoring is particularly useful if a supervisor cannot simply restart its children and has to terminate them, e.g.

in case of errors during actor initialization. In that case it should monitor those children and re-create them or

schedule itself to retry this at a later time.

2.3. Supervision and Monitoring 14

Akka Documentation, Release 2.1.0

Another common use case is that an actor needs to fail in the absence of an external resource, which may also be

one of its own children. If a third party terminates a child by way of the system.stop(child) method or

sending a PoisonPill, the supervisor might well be affected.

Warning: DeathWatch for Akka Remote does not (yet) get triggered by connection failures – which means

that if the parent node or the network goes down, nobody will get notiﬁed. This feature may be added in a

future release of Akka Remoting. Akka Cluster, however, has such functionality.

2.3.5 One-For-One Strategy vs. All-For-One Strategy

There are two classes of supervision strategies which come with Akka: OneForOneStrategy and

AllForOneStrategy. Both are conﬁgured with a mapping from exception type to supervision directive (see

above) and limits on how often a child is allowed to fail before terminating it. The difference between them is that

the former applies the obtained directive only to the failed child, whereas the latter applies it to all siblings as well.

Normally, you should use the OneForOneStrategy, which also is the default if none is speciﬁed explicitly.

The AllForOneStrategy is applicable in cases where the ensemble of children has so tight dependencies

among them, that a failure of one child affects the function of the others, i.e. they are intricably linked. Since

a restart does not clear out the mailbox, it often is best to terminate the children upon failure and re-create them

explicitly from the supervisor (by watching the children’s lifecycle); otherwise you have to make sure that it is no

problem for any of the actors to receive a message which was queued before the restart but processed afterwards.

Normally stopping a child (i.e. not in response to a failure) will not automatically terminate the other children

in an all-for-one strategy, that can easily be done by watching their lifecycle: if the Terminated message is

not handled by the supervisor, it will throw a DeathPactException which (depending on its supervisor) will

restart it, and the default preRestart action will terminate all children. Of course this can be handled explicitly

as well.

Please note that creating one-off actors from an all-for-one supervisor entails that failures escalated by the tempo-

rary actor will affect all the permanent ones. If this is not desired, install an intermediate supervisor; this can very

easily be done by declaring a router of size 1 for the worker, see Routing (Scala) or Routing (Java).

2.4 Actor References, Paths and Addresses

This chapter describes how actors are identiﬁed and located within a possibly distributed actor system. It ties into

the central idea that Actor Systems form intrinsic supervision hierarchies as well as that communication between

actors is transparent with respect to their placement across multiple network nodes.

2.4. Actor References, Paths and Addresses 15

Akka Documentation, Release 2.1.0

The above image displays the relationship between the most important entities within an actor system, please read

on for the details.

2.4.1 What is an Actor Reference?

An actor reference is a subtype of ActorRef, whose foremost purpose is to support sending messages to the

actor it represents. Each actor has access to its canonical (local) reference through the self ﬁeld; this reference

is also included as sender reference by default for all messages sent to other actors. Conversely, during message

processing the actor has access to a reference representing the sender of the current message through the sender

ﬁeld.

There are several different types of actor references that are supported depending on the conﬁguration of the actor

system:

• Purely local actor references are used by actor systems which are not conﬁgured to support networking

functions. These actor references cannot ever be sent across a network connection while retaining their

functionality.

• Local actor references when remoting is enabled are used by actor systems which support networking func-

tions for those references which represent actors within the same JVM. In order to be recognizable also

when sent to other network nodes, these references include protocol and remote addressing information.

• There is a subtype of local actor references which is used for routers (i.e. actors mixing in the Router

trait). Its logical structure is the same as for the aforementioned local references, but sending a message to

them dispatches to one of their children directly instead.

• Remote actor references represent actors which are reachable using remote communication, i.e. sending

messages to them will serialize the messages transparently and send them to the other JVM.

• There are several special types of actor references which behave like local actor references for all practical

purposes:

– PromiseActorRef is the special representation of a Promise for the purpose of being completed

by the response from an actor; it is created by the ActorRef.ask invocation.

– DeadLetterActorRef is the default implementation of the dead letters service, where all mes-

sages are re-routed whose routees are shut down or non-existent.

– EmptyLocalActorRef is what is returned when looking up a non-existing local actor path: it is

equivalent to a DeadLetterActorRef, but it retains its path so that it can be sent over the network

and compared to other existing actor refs for that path, some of which might have been obtained before

the actor stopped existing.

• And then there are some one-off internal implementations which you should never really see:

– There is an actor reference which does not represent an actor but acts only as a pseudo-supervisor for

the root guardian, we call it “the one who walks the bubbles of space-time”.

– The ﬁrst logging service started before actually ﬁring up actor creation facilities is a fake

actor reference which accepts log events and prints them directly to standard output; it is

Logging.StandardOutLogger.

• (Future Extension) Cluster actor references represent clustered actor services which may be replicated,

migrated or load-balanced across multiple cluster nodes. As such they are virtual names which the cluster

service translates into local or remote actor references as appropriate.

2.4.2 What is an Actor Path?

Since actors are created in a strictly hierarchical fashion, there exists a unique sequence of actor names given by

recursively following the supervision links between child and parent down towards the root of the actor system.

This sequence can be seen as enclosing folders in a ﬁle system, hence we adopted the name “path” to refer to

it. As in some real ﬁle-systems there also are “symbolic links”, i.e. one actor may be reachable using more than

2.4. Actor References, Paths and Addresses 16

Akka Documentation, Release 2.1.0

one path, where all but one involve some translation which decouples part of the path from the actor’s actual

supervision ancestor line; these specialities are described in the sub-sections to follow.

An actor path consists of an anchor, which identiﬁes the actor system, followed by the concatenation of the path

elements, from root guardian to the designated actor; the path elements are the names of the traversed actors and

are separated by slashes.

Actor Path Anchors

Each actor path has an address component, describing the protocol and location by which the corresponding actor

is reachable, followed by the names of the actors in the hierarchy from the root up. Examples are:

"akka://my-sys/user/service-a/worker1" // purely local

"akka://my-sys@host.example.com:5678/user/service-b" // local or remote

"cluster://my-cluster/service-c" // clustered (Future Extension)

Here, akka is the default remote protocol for the 2.0 release, and others are pluggable. The interpretation of the

host & port part (i.e. serv.example.com:5678 in the example) depends on the transport mechanism used,

but it must abide by the URI structural rules.

Logical Actor Paths

The unique path obtained by following the parental supervision links towards the root guardian is called the logical

actor path. This path matches exactly the creation ancestry of an actor, so it is completely deterministic as soon as

the actor system’s remoting conﬁguration (and with it the address component of the path) is set.

Physical Actor Paths

While the logical actor path describes the functional location within one actor system, conﬁguration-based remote

deployment means that an actor may be created on a different network host as its parent, i.e. within a different

actor system. In this case, following the actor path from the root guardian up entails traversing the network, which

is a costly operation. Therefore, each actor also has a physical path, starting at the root guardian of the actor

system where the actual actor object resides. Using this path as sender reference when querying other actors will

let them reply directly to this actor, minimizing delays incurred by routing.

One important aspect is that a physical actor path never spans multiple actor systems or JVMs. This means that

the logical path (supervision hierarchy) and the physical path (actor deployment) of an actor may diverge if one

of its ancestors is remotely supervised.

Virtual Actor Paths (Future Extension)

In order to be able to replicate and migrate actors across a cluster of Akka nodes, another level of indirection has to

be introduced. The cluster component therefore provides a translation from virtual paths to physical paths which

may change in reaction to node failures, cluster rebalancing, etc.

This area is still under active development, expect updates in this section for the 2.1 release.

2.4.3 How are Actor References obtained?

There are two general categories to how actor references may be obtained: by creating actors or by looking them

up, where the latter functionality comes in the two ﬂavours of creating actor references from concrete actor paths

and querying the logical actor hierarchy.

While local and remote actor references and their paths work in the same way concerning the facilities men-

tioned below, the exact semantics of clustered actor references and their paths—while certainly as similar as

possible—may differ in certain aspects, owing to the virtual nature of those paths. Expect updates for the 2.1

release.

2.4. Actor References, Paths and Addresses 17

剩余426页未读，继续阅读

copy202

粉丝: 9
资源: 2

Akka 2.1.0官方文档：详解Actor模型与Java API

akka-actor-2.11-2.5.19-API文档-中文版.zip

akka-stream_2.11-2.5.21-API文档-中英对照版.zip

akka-actor_2.11-2.5.19-API文档-中英对照版.zip

akka.net中文文档

akka stream官方中文文档

Flink 中akka的使用

akka 远程调用 代码实现

akka in action pdf

akka 2.4.14.zip

akka的配置文件

最新资源

akka 远程调用代码实现