AkkaJava 2.4.16：文档详解与实战指南

需积分: 50 165 浏览量更新于2024-07-19 收藏 3.72MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

Akka Java高清pdf版是一份详细介绍了Akka框架的官方文档，由Lightbend Inc发布于2016年12月19日，适用于Java开发者。Akka是一个强大的并行和分布式计算库，特别适合构建可扩展、容错的高性能系统。这份文档深入探讨了Akka的核心概念、设计原则和使用方法。 **1. Introduction** 文档首先对Akka进行了简要介绍，它是一个轻量级的工具集，旨在简化在复杂分布式环境中构建可维护的并发应用程序。章节1.2讨论了选择Akka的原因，可能包括其支持事件驱动编程、消息传递模型以及高度模块化的设计。 **2. General** - **Terminology and Concepts**：这部分概述了术语和基本概念，如Actor系统、Actor、行为（Behaviors）、消息（Messages）等，帮助读者理解Akka的基本工作原理。 - **Actor Systems**：讲解了Actor系统的构成和运行机制，包括它们如何处理并发任务和数据共享。 - **Actors**：详细解释了Actor是Akka的核心组件，它是独立的、拥有私有状态和行为处理消息的实体。 - **Supervision and Monitoring**：阐述了Akka的监督（Supervision hierarchy）和监控机制，确保系统的稳定性和错误处理。 - **Location Transparency**：讨论了Akka如何隐藏底层通信细节，提供透明的远程调用能力。 - **Java Memory Model Compatibility**：确保Akka与Java内存模型兼容，保证多线程间的正确同步。 - **Message Delivery Reliability**：强调了Akka在确保消息可靠传递方面的机制。 **3. Actors (Java with Lambda Support)** - **Actors in Java**：这部分针对Java用户，提供了使用Akka Actor的详细指南，包括创建和管理Actors的方法。 - **Typed Actors**：介绍类型安全的Actor，增强了代码的清晰性和可维护性。 - **Fault Tolerance**：讨论了如何实现故障恢复和容错，包括恢复策略和心跳检测。 - **Dispatchers**：讲解了用于调度Actor处理任务的不同线程池（Dispatchers），优化性能和响应时间。 - **Mailboxes**：解释了邮件箱（Mailboxes）在处理并发消息时的角色。 - **Routing**：描述了如何通过路由策略将消息分发到正确的Actor。 - **Finite State Machine Actors**：演示如何构建基于状态机的Actor，用于复杂的业务逻辑处理。 - **Persistence**：阐述了Akka的持久化功能，如何保存Actor的状态以便在失败后恢复。 - **Schema Evolution**：讨论了在系统升级过程中如何管理Actor状态的数据模型变化。 - **Persistence Query**：讲解了查询已持久化数据的方法。 - **Testing Actor Systems**：给出了测试Actor系统和相关组件的最佳实践。 **4. Actors (Java with Lambda Support) (continued)** - **Actors with Lambda Support**：这部分展示了如何利用Java 8的lambda表达式简化Actor的定义。 - **Fault Tolerance with Lambda Support**：介绍了使用lambda时的故障恢复策略。 - **FSM (Java with Lambda Support)**：最后，展示了如何结合Lambda使用Java来构建和管理有限状态机（FSM）的Actor。这份Akka Java高清pdf文档提供了丰富的学习资料，涵盖了从基础概念到高级特性的全面教程，对于想要深入了解和使用Akka的Java开发者来说，是不可或缺的参考资源。

资源详情

资源推荐

Akka Java Documentation, Release 2.4.16

it ﬁnishes in a bounded number of steps. All lock-free objects are obstruction-free, but the opposite is generally

not true.

Optimistic concurrency control (OCC) methods are usually obstruction-free. The OCC approach is that every

participant tries to execute its operation on the shared object, but if a participant detects conﬂicts from others, it

rolls back the modiﬁcations, and tries again according to some schedule. If there is a point in time, where one of

the participants is the only one trying, the operation will succeed.

2.1.7 Recommended literature

• The Art of Multiprocessor Programming, M. Herlihy and N Shavit, 2008. ISBN 978-0123705914

• Java Concurrency in Practice, B. Goetz, T. Peierls, J. Bloch, J. Bowbeer, D. Holmes and D. Lea, 2006.

ISBN 978-0321349606

2.2 Actor Systems

Actors are objects which encapsulate state and behavior, they communicate exclusively by exchanging messages

which are placed into the recipient’s mailbox. In a sense, actors are the most stringent form of object-oriented

programming, but it serves better to view them as persons: while modeling a solution with actors, envision a group

of people and assign sub-tasks to them, arrange their functions into an organizational structure and think about

how to escalate failure (all with the beneﬁt of not actually dealing with people, which means that we need not

concern ourselves with their emotional state or moral issues). The result can then serve as a mental scaffolding for

building the software implementation.

Note: An ActorSystem is a heavyweight structure that will allocate 1. . . N Threads, so create one per logical

application.

2.2.1 Hierarchical Structure

Like in an economic organization, actors naturally form hierarchies. One actor, which is to oversee a certain

function in the program might want to split up its task into smaller, more manageable pieces. For this purpose it

starts child actors which it supervises. While the details of supervision are explained here, we shall concentrate on

the underlying concepts in this section. The only prerequisite is to know that each actor has exactly one supervisor,

which is the actor that created it.

The quintessential feature of actor systems is that tasks are split up and delegated until they become small enough

to be handled in one piece. In doing so, not only is the task itself clearly structured, but the resulting actors can

be reasoned about in terms of which messages they should process, how they should react normally and how

failure should be handled. If one actor does not have the means for dealing with a certain situation, it sends a

corresponding failure message to its supervisor, asking for help. The recursive structure then allows to handle

failure at the right level.

Compare this to layered software design which easily devolves into defensive programming with the aim of not

leaking any failure out: if the problem is communicated to the right person, a better solution can be found than if

trying to keep everything “under the carpet”.

Now, the difﬁculty in designing such a system is how to decide who should supervise what. There is of course no

single best solution, but there are a few guidelines which might be helpful:

• If one actor manages the work another actor is doing, e.g. by passing on sub-tasks, then the manager should

supervise the child. The reason is that the manager knows which kind of failures are expected and how to

handle them.

• If one actor carries very important data (i.e. its state shall not be lost if avoidable), this actor should source

out any possibly dangerous sub-tasks to children it supervises and handle failures of these children as ap-

propriate. Depending on the nature of the requests, it may be best to create a new child for each request,

2.2. Actor Systems 12

Akka Java Documentation, Release 2.4.16

which simpliﬁes state management for collecting the replies. This is known as the “Error Kernel Pattern”

from Erlang.

• If one actor depends on another actor for carrying out its duty, it should watch that other actor’s liveness

and act upon receiving a termination notice. This is different from supervision, as the watching party has

no inﬂuence on the supervisor strategy, and it should be noted that a functional dependency alone is not a

criterion for deciding where to place a certain child actor in the hierarchy.

There are of course always exceptions to these rules, but no matter whether you follow the rules or break them,

you should always have a reason.

2.2.2 Conﬁguration Container

The actor system as a collaborating ensemble of actors is the natural unit for managing shared facilities like

scheduling services, conﬁguration, logging, etc. Several actor systems with different conﬁguration may co-exist

within the same JVM without problems, there is no global shared state within Akka itself. Couple this with the

transparent communication between actor systems—within one node or across a network connection—to see that

actor systems themselves can be used as building blocks in a functional hierarchy.

2.2.3 Actor Best Practices

1. Actors should be like nice co-workers: do their job efﬁciently without bothering everyone else needlessly

and avoid hogging resources. Translated to programming this means to process events and generate re-

sponses (or more requests) in an event-driven manner. Actors should not block (i.e. passively wait while

occupying a Thread) on some external entity—which might be a lock, a network socket, etc.—unless it is

unavoidable; in the latter case see below.

2. Do not pass mutable objects between actors. In order to ensure that, prefer immutable messages. If the

encapsulation of actors is broken by exposing their mutable state to the outside, you are back in normal Java

concurrency land with all the drawbacks.

3. Actors are made to be containers for behavior and state, embracing this means to not routinely send behavior

within messages (which may be tempting using Scala closures). One of the risks is to accidentally share

mutable state between actors, and this violation of the actor model unfortunately breaks all the properties

which make programming in actors such a nice experience.

4. Top-level actors are the innermost part of your Error Kernel, so create them sparingly and prefer truly

hierarchical systems. This has beneﬁts with respect to fault-handling (both considering the granularity of

conﬁguration and the performance) and it also reduces the strain on the guardian actor, which is a single

point of contention if over-used.

2.2.4 Blocking Needs Careful Management

In some cases it is unavoidable to do blocking operations, i.e. to put a thread to sleep for an indeterminate

time, waiting for an external event to occur. Examples are legacy RDBMS drivers or messaging APIs, and the

underlying reason is typically that (network) I/O occurs under the covers. When facing this, you may be tempted

to just wrap the blocking call inside a Future and work with that instead, but this strategy is too simple: you are

quite likely to ﬁnd bottlenecks or run out of memory or threads when the application runs under increased load.

The non-exhaustive list of adequate solutions to the “blocking problem” includes the following suggestions:

• Do the blocking call within an actor (or a set of actors managed by a router [Java, Scala]), making sure to

conﬁgure a thread pool which is either dedicated for this purpose or sufﬁciently sized.

• Do the blocking call within a Future, ensuring an upper bound on the number of such calls at any point in

time (submitting an unbounded number of tasks of this nature will exhaust your memory or thread limits).

• Do the blocking call within a Future, providing a thread pool with an upper limit on the number of threads

which is appropriate for the hardware on which the application runs.

2.2. Actor Systems 13

Akka Java Documentation, Release 2.4.16

• Dedicate a single thread to manage a set of blocking resources (e.g. a NIO selector driving multiple chan-

nels) and dispatch events as they occur as actor messages.

The ﬁrst possibility is especially well-suited for resources which are single-threaded in nature, like database han-

dles which traditionally can only execute one outstanding query at a time and use internal synchronization to

ensure this. A common pattern is to create a router for N actors, each of which wraps a single DB connection and

handles queries as sent to the router. The number N must then be tuned for maximum throughput, which will vary

depending on which DBMS is deployed on what hardware.

Note: Conﬁguring thread pools is a task best delegated to Akka, simply conﬁgure in the application.conf

and instantiate through an ActorSystem [Java, Scala]

2.2.5 What you should not concern yourself with

An actor system manages the resources it is conﬁgured to use in order to run the actors which it contains. There

may be millions of actors within one such system, after all the mantra is to view them as abundant and they

weigh in at an overhead of only roughly 300 bytes per instance. Naturally, the exact order in which messages are

processed in large systems is not controllable by the application author, but this is also not intended. Take a step

back and relax while Akka does the heavy lifting under the hood.

2.3 What is an Actor?

The previous section about Actor Systems explained how actors form hierarchies and are the smallest unit when

building an application. This section looks at one such actor in isolation, explaining the concepts you encounter

while implementing it. For a more in depth reference with all the details please refer to Actors (Scala) and Untyped

Actors (Java).

An actor is a container for State, Behavior, a Mailbox, Child Actors and a Supervisor Strategy. All of this is

encapsulated behind an Actor Reference. One noteworthy aspect is that actors have an explicit lifecycle, they are

not automatically destroyed when no longer referenced; after having created one, it is your responsibility to make

sure that it will eventually be terminated as well—which also gives you control over how resources are released

When an Actor Terminates.

2.3.1 Actor Reference

As detailed below, an actor object needs to be shielded from the outside in order to beneﬁt from the actor model.

Therefore, actors are represented to the outside using actor references, which are objects that can be passed around

freely and without restriction. This split into inner and outer object enables transparency for all the desired

operations: restarting an actor without needing to update references elsewhere, placing the actual actor object on

remote hosts, sending messages to actors in completely different applications. But the most important aspect is

that it is not possible to look inside an actor and get hold of its state from the outside, unless the actor unwisely

publishes this information itself.

2.3.2 State

Actor objects will typically contain some variables which reﬂect possible states the actor may be in. This can be an

explicit state machine (e.g. using the fsm-scala module), or it could be a counter, set of listeners, pending requests,

etc. These data are what make an actor valuable, and they must be protected from corruption by other actors. The

good news is that Akka actors conceptually each have their own light-weight thread, which is completely shielded

from the rest of the system. This means that instead of having to synchronize access using locks you can just write

your actor code without worrying about concurrency at all.

2.3. What is an Actor? 14

Akka Java Documentation, Release 2.4.16

Behind the scenes Akka will run sets of actors on sets of real threads, where typically many actors share one

thread, and subsequent invocations of one actor may end up being processed on different threads. Akka ensures

that this implementation detail does not affect the single-threadedness of handling the actor’s state.

Because the internal state is vital to an actor’s operations, having inconsistent state is fatal. Thus, when the actor

fails and is restarted by its supervisor, the state will be created from scratch, like upon ﬁrst creating the actor. This

is to enable the ability of self-healing of the system.

Optionally, an actor’s state can be automatically recovered to the state before a restart by persisting received

messages and replaying them after restart (see persistence-scala).

2.3.3 Behavior

Every time a message is processed, it is matched against the current behavior of the actor. Behavior means a

function which deﬁnes the actions to be taken in reaction to the message at that point in time, say forward a

request if the client is authorized, deny it otherwise. This behavior may change over time, e.g. because different

clients obtain authorization over time, or because the actor may go into an “out-of-service” mode and later come

back. These changes are achieved by either encoding them in state variables which are read from the behavior

logic, or the function itself may be swapped out at runtime, see the become and unbecome operations. However,

the initial behavior deﬁned during construction of the actor object is special in the sense that a restart of the actor

will reset its behavior to this initial one.

2.3.4 Mailbox

An actor’s purpose is the processing of messages, and these messages were sent to the actor from other actors (or

from outside the actor system). The piece which connects sender and receiver is the actor’s mailbox: each actor

has exactly one mailbox to which all senders enqueue their messages. Enqueuing happens in the time-order of

send operations, which means that messages sent from different actors may not have a deﬁned order at runtime

due to the apparent randomness of distributing actors across threads. Sending multiple messages to the same target

from the same actor, on the other hand, will enqueue them in the same order.

There are different mailbox implementations to choose from, the default being a FIFO: the order of the messages

processed by the actor matches the order in which they were enqueued. This is usually a good default, but

applications may need to prioritize some messages over others. In this case, a priority mailbox will enqueue not

always at the end but at a position as given by the message priority, which might even be at the front. While using

such a queue, the order of messages processed will naturally be deﬁned by the queue’s algorithm and in general

not be FIFO.

An important feature in which Akka differs from some other actor model implementations is that the current

behavior must always handle the next dequeued message, there is no scanning the mailbox for the next matching

one. Failure to handle a message will typically be treated as a failure, unless this behavior is overridden.

2.3.5 Child Actors

Each actor is potentially a supervisor: if it creates children for delegating sub-tasks, it will automatically supervise

them. The list of children is maintained within the actor’s context and the actor has access to it. Modiﬁcations to

the list are done by creating (context.actorOf(...)) or stopping (context.stop(child)) children

and these actions are reﬂected immediately. The actual creation and termination actions happen behind the scenes

in an asynchronous way, so they do not “block” their supervisor.

2.3.6 Supervisor Strategy

The ﬁnal piece of an actor is its strategy for handling faults of its children. Fault handling is then done transparently

by Akka, applying one of the strategies described in Supervision and Monitoring for each incoming failure. As

this strategy is fundamental to how an actor system is structured, it cannot be changed once an actor has been

created.

2.3. What is an Actor? 15

Akka Java Documentation, Release 2.4.16

Considering that there is only one such strategy for each actor, this means that if different strategies apply to

the various children of an actor, the children should be grouped beneath intermediate supervisors with matching

strategies, preferring once more the structuring of actor systems according to the splitting of tasks into sub-tasks.

2.3.7 When an Actor Terminates

Once an actor terminates, i.e. fails in a way which is not handled by a restart, stops itself or is stopped by its

supervisor, it will free up its resources, draining all remaining messages from its mailbox into the system’s “dead

letter mailbox” which will forward them to the EventStream as DeadLetters. The mailbox is then replaced within

the actor reference with a system mailbox, redirecting all new messages to the EventStream as DeadLetters. This

is done on a best effort basis, though, so do not rely on it in order to construct “guaranteed delivery”.

The reason for not just silently dumping the messages was inspired by our tests: we register the TestEventLis-

tener on the event bus to which the dead letters are forwarded, and that will log a warning for every dead letter

received—this has been very helpful for deciphering test failures more quickly. It is conceivable that this feature

may also be of use for other purposes.

2.4 Supervision and Monitoring

This chapter outlines the concept behind supervision, the primitives offered and their semantics. For details on

how that translates into real code, please refer to the corresponding chapters for Scala and Java APIs.

2.4.1 What Supervision Means

As described in Actor Systems supervision describes a dependency relationship between actors: the supervisor

delegates tasks to subordinates and therefore must respond to their failures. When a subordinate detects a failure

(i.e. throws an exception), it suspends itself and all its subordinates and sends a message to its supervisor, signaling

failure. Depending on the nature of the work to be supervised and the nature of the failure, the supervisor has a

choice of the following four options:

1. Resume the subordinate, keeping its accumulated internal state

2. Restart the subordinate, clearing out its accumulated internal state

3. Stop the subordinate permanently

4. Escalate the failure, thereby failing itself

It is important to always view an actor as part of a supervision hierarchy, which explains the existence of the fourth

choice (as a supervisor also is subordinate to another supervisor higher up) and has implications on the ﬁrst three:

resuming an actor resumes all its subordinates, restarting an actor entails restarting all its subordinates (but see

below for more details), similarly terminating an actor will also terminate all its subordinates. It should be noted

that the default behavior of the preRestart hook of the Actor class is to terminate all its children before

restarting, but this hook can be overridden; the recursive restart applies to all children left after this hook has been

executed.

Each supervisor is conﬁgured with a function translating all possible failure causes (i.e. exceptions) into one of

the four choices given above; notably, this function does not take the failed actor’s identity as an input. It is quite

easy to come up with examples of structures where this might not seem ﬂexible enough, e.g. wishing for different

strategies to be applied to different subordinates. At this point it is vital to understand that supervision is about

forming a recursive fault handling structure. If you try to do too much at one level, it will become hard to reason

about, hence the recommended way in this case is to add a level of supervision.

Akka implements a speciﬁc form called “parental supervision”. Actors can only be created by other actors—where

the top-level actor is provided by the library—and each created actor is supervised by its parent. This restriction

makes the formation of actor supervision hierarchies implicit and encourages sound design decisions. It should

be noted that this also guarantees that actors cannot be orphaned or attached to supervisors from the outside,

which might otherwise catch them unawares. In addition, this yields a natural and clean shutdown procedure for

(sub-trees of) actor applications.

2.4. Supervision and Monitoring 16

剩余752页未读，继续阅读

Ice_Feng21

粉丝: 0
资源: 2

AkkaJava 2.4.16：文档详解与实战指南

Akka.in.Action.2016.9.pdf

AkkaJava.pdf

akka官方文档

akka in action pdf

akka应用模式 pdf

java如何集成使用akka

java akka 实战

java akka 如何正确的结束

akka 2.4.14.zip

用java写一个Akka应用实例

spark和akka关系

akka的配置文件

介绍下Akka Scheduler

akka 远程调用 代码实现

Akka实现分布式锁

akka websocket

akka.net中文文档

spark使用akka干嘛

spark3还使用akka吗

Flink 中akka的使用

最新资源

akka 远程调用代码实现