Scala Akka:构建高可靠多线程应用的Actor模型指南

需积分: 0 123 浏览量更新于2024-07-23 收藏 3.34MB PDF 举报

Akka Concurrency 是一本专注于多线程并发编程的指南，由 Artima 出版，特别关注的是 Akka 这个用 Scala 编写的框架。Akka 是一种强大的工具，旨在帮助开发者构建高可靠性和可扩展性极强的 Java 和 Scala 应用程序，特别是在多核心系统中。它的核心是Actor模型，这是一种异步、无阻塞和消息驱动的编程范式，非常适合于分布式计算和并发环境。在本书中，作者 Derek Wyatt 针对现代软件开发面临的挑战，提供了全面的覆盖范围，从 Akka 的基础概念到高级主题，包括并发控制、错误处理、以及如何利用 Akka 构建复杂系统。读者可以预期的内容可能包括： 1. **Actor模型介绍**：解释什么是Actor，它如何工作，以及为什么在并发编程中如此重要，包括其生命周期管理、通信机制和行为设计原则。 2. **Akka Concurrency API**：深入剖析 Akka 提供的库函数和工具，如 `ActorSystem`、`Props` 和 `Receive`，以及如何创建和管理 Actor。 3. **并发与同步**：探讨如何在 Akka 中实现线程安全和避免死锁，以及利用 Akka 的 Futures 和 Promises 实现异步编程。 4. **容错和恢复**：讲解 Akka 的错误处理机制，如Supervision Trees 和 DeadLetters，以及如何设计具有自我修复能力的系统。 5. **集群和分布计算**：介绍 Akka Clustering 和 Remote Actors，如何在分布式环境中扩展应用，并确保数据一致性。 6. **案例研究和最佳实践**：通过实际案例展示如何将 Akka 应用于生产级应用程序，分享优化性能和提高效率的实用策略。 7. **持续集成与测试**：讨论如何在 Akka 开发过程中实施有效的测试和CI/CD流程，确保代码质量。 8. **未来趋势和发展**：对于Akka 及其在并发编程领域的最新进展和潜在发展方向的见解。作为 PrePrint™ 版本的购买者，读者不仅能获取到最新的草稿内容，还能参与书的完善过程，提交反馈并预览最终的 PDF 版本。这是一次独特的机会，能紧跟 Akka Concurrency 的最新发展，并在实际项目中应用所学知识，提升自己的技能。

List of Figures xvi

4.14 Grouping a set of matrices to be multiplied into two groups:

Group A can be multiplied together at the same time as group

B. Once both results have been obtained, we can multiply the

result into a ﬁnal, single matrix. . . . . . . . . . . . . . . . 80

4.15 When you give work to a set of Actors, they will complete it at

non-deterministic intervals. This means that response messages

will come back in what is effectively random order. . . . . . 81

4.16 Akka’s Future implementation allows us to take a list of Futures

and convert them to a Future that contains a list of their results,

and it maintains the same sequence as the original Futures. . 82

4.17 Futures can tacitly bind themselves to Actors by representing

themselves as the “sender” of the request message. Assuming

the Actor responds to the sender, the response will go back to the

Future. This entire interplay between the Actor and the Future

is non-blocking. . . . . . . . . . . . . . . . . . . . . . . . . 85

4.18 The conceptual difference between Futures and dataﬂow: Fu-

tures are non-blocking and can execute full functions in par-

allel, whereas dataﬂow creates concurrency that’s more of an

intra-function type of concept. Each algorithm, represented by

the individual boxes, is either waiting for (while not blocking a

thread) or is populating a piece of data. Between any two points

of contention, things run concurrently, b u t they rendezvous on

the shared data. . . . . . . . . . . . . . . . . . . . . . . . . 87

5.1 Shows us the parts of the Actor that concern us as programmers.

All of these components together facilitate the execution of mes-

sage processing in your Actor’s code. Note that everything b u t

the ActorRef and the message is internal. Someone in the out-

side world constructs a message, and he can only send it to the

ActorRef. He can’t send it to the Actor directly. . . . . . . . 93

5.2 Programming with Actors is more like hanging out with a bunch

of people at the ofﬁce than it is about sequences and algorithms.

Jill’s not interested in who gets her coffee for her, just so long as

she gets it. . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.3 When an Actor has a lot to do, blocking on a response from it

can be more painful than you might otherwise be used to. . . 101

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

List of Figures xvii

5.4 This is what our Plane currently looks like, from the view of the

avionics-driving

main, which we depict as the Outside World.

Solid lines indicate a physical binding—i.e., the ActorSystem

owns the Plane and the Plane owns the Altimeter and Control-

Surfaces, whereas the dotted lines indicate a reference relation-

ship for message sending. . . . . . . . . . . . . . . . . . . . 118

5.5 Three different representations of how message sending works.

Every time a message is sent, the message gets a passenger—a

reference to the sender. If ! is called from within an Actor, then

that Actor becomes the sender, or it’s the Dead Letter Ofﬁce if

you’re not inside an Actor. When forwarding, we propagate the

original sender with the message in order to implement standard

forwarding semantics. . . . . . . . . . . . . . . . . . . . . . 123

6.1 When we test our Altimeter, we are technically testing every one

of its components. . . . . . . . . . . . . . . . . . . . . . . . 128

6.2 Normally, the EventSource Actor is unavailable to our runtime

code because Akka hides it behind an ActorRef. The TestKit’s

TestActorRef gives us access to the Actor’s internals so we can

poke and prod it directly. . . . . . . . . . . . . . . . . . . . 131

7.1 Here, we see the key players in the ActorSystem that interest us

most of the time, including three Actors (Dead Letter, System,

and User) as well as three other key entities (Scheduler, Event

Stream, and Settings). These ActorSystem elements, with the

exception of the System Guardian, regularly pop up in Actor

programming. . . . . . . . . . . . . . . . . . . . . . . . . . 151

7.2 The Plane’s hierarchy, including the sub-hierarchy of the Flight

Attendants. Note that the path requirements are determined en-

tirely by the parent/child relationships between the Actors. . 162

7.3 The structure of the Plane after everyone’s in place . . . . . 171

7.4 How we relate the Actor to its context, its ActorRef, and the

path. It’s the context that holds the relationships together, and

those point to the ActorRefs (not the Actors or the ActorCon-

texts). From the ActorRef, we can retrieve the ActorPath object,

which we can interrogate as we please. . . . . . . . . . . . . 172

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

List of Figures xviii

8.1 Actor supervision is a recursive deﬁnition. The Actor system’s

hierarchical nature provides a simple deﬁnition of supervision

such that the question of “what to do?” can be asked at any

level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

8.2 The Actor life cycle, including code examples that can get us

to each point as well as certain overrideable callbacks that are

available to hook into the life cycle. . . . . . . . . . . . . . 177

8.3 T w o hooks exist for restart processing in the Actor. It’s impor-

tant to understand that the

preRestart() method is executed

on the Actor that processed the failing message, whereas the

postRestart() method is executed on the freshly instantiated

Actor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

8.4 W e wouldn’t necessarily want to restart all of the children when

the Actor that failed is a great, great, great, great, great, great,

great grandfather to 5,000 descendants. . . . . . . . . . . . 183

8.5 The Actor that restarts passes through the restart life cycle, b u t

its children are a different story. The children are speciﬁcally

stopped and re-created. With each Actor restart, the children are

stopped and a new generation replaces them. If the Actor has

DeathWatch on them, then it will get

Terminated() messages

for each one on every restart. . . . . . . . . . . . . . . . . . 188

8.6 Actor restarts are not visible to the outside world and thus all of

the guys that have an ActorRef to it are unaffected. However,

it’s a different story for those that might have references to that

Actor’s children. Since the children will by default stop and

then get re-created, those old references send all messages to the

Dead Letter Ofﬁce. . . . . . . . . . . . . . . . . . . . . . . 191

8.7 The outline of the structure we’re going for when building our

Plane. Actor systems inevitably become a tree in the real world

and our Plane is starting to get that wa y. . . . . . . . . . . . 193

8.8 The slice of the Plane’s hierarchy after

startControls() com-

pletes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

8.9 The slice of the Plane’s hierarchy after

startPeople() com-

pletes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

List of Figures xix

8.10 Risk is generally pushed down the tree. The higher up you go,

the less risk you’re willing to take on, and the lower you go,

the more risky you become. Guys that live at the bottom are

the ones you want to send on the brutal missions where they’re

not guaranteed to survive, b u t the guys at the top don’t get their

hands dirty at all. . . . . . . . . . . . . . . . . . . . . . . . 208

8.11 The simple hierarchy we need in order to test the CoPilot . . 213

8.12 The AutoPilot’s test doesn’t need to have any special parenting.

Its parent can simply be the test ActorSystem’s User Guardian. 217

9.1 The state transitions are easily deduced from the code due to the

static usage of the

become() method. . . . . . . . . . . . . 224

9.2 Our state stack’s condition after a whole load of

become()s

without a single

unbecome(). If you’re not careful in your o w n

(more complex) code, you could end up with a stack that e v e n -

tually blows up. Y o u just need to accumulate more pushes than

pops over a long enough period of time and you have the exact

same problem. . . . . . . . . . . . . . . . . . . . . . . . . . 225

9.3 The FlightAttendant changes its behavioural state when certain

messages are received in certain states. One nice effect of know-

ing you are in a particular state is that you can simply hard-code

values rather than having to check what state you’re in with an

statement. Here, we illustrate that the response to the Busy\_?

message is determined by the state in which the FlightAttendant

ﬁnds itself. . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

9.4 The Pilot receives information about how he feels from the drink-

ing behaviour Actor, which allows him to alter his ﬂying be-

haviour accordingly. . . . . . . . . . . . . . . . . . . . . . . 249

10.1 Messages are routed to the composed Actors in a round-robin

fashion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

10.2 In this case, the SmallestMailboxRouter will choose Actor 3 as

the recipient of Message 1, since its Mailbox is clearly the small-

est. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

List of Figures xx

10.3 The PassengerSupervisor’s structure houses an IsolatedStopSu-

pervisor to manage its Passengers and uses the default supervi-

sion strategy for its immediate children. The BroadcastRouter

will be created after the IsolatedStopSupervisor is completely

instantiated. . . . . . . . . . . . . . . . . . . . . . . . . . . 275

10.4 The non-blocking, asynchronous algorithm we use to obtain the

BroadcastRouter of the children of the PassengerSupervisor’s

embedded Stop Supervisor. . . . . . . . . . . . . . . . . . . 278

10.5 In this layout for the SectionSpeciﬁcAttendantRouter test, the

mocked pieces and messages are geared toward getting enough

information into the

testActor so we can verify what we expect

to route where. . . . . . . . . . . . . . . . . . . . . . . . . 286

11.1 The conceptual view of the Event-Based Dispatcher with respect

to its Actors and the Mailboxes that contain their messages . 292

11.2 The conceptual view of the BalancingDispatcher with respect to

its Actors and the Mailbox that contains the messages for all of

them . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

11.3 By changing the

throughput value in the Dispatcher conﬁgura-

tion, we can alter how quickly these Mailboxes will drain. . 295

11.4 A simple diagram of the PressureQueue: The Actor holds the

“put” lock as long as the pressure algorithm demands. This

length of time is a factor of the current queue size. The “take”

lock releases immediately so that the queue’s consumer can empty

it as quickly as possible. . . . . . . . . . . . . . . . . . . . 300

12.1 A simple depiction of using a Future to synchronize an asyn-

chronous API into pre-existing sequential code . . . . . . . 305

12.2 Futures are fulﬁlled by a Promise, which is held by a servant

that gives the Future to the requester. This creates the conduit

through which the servant and requester communicate. . . . 308

12.3 There’s a pretty clear difference between

flatMapping pre-existing

Futures and creating them on the ﬂy. . . . . . . . . . . . . . 312

13.1 The Telnet Server routes all incoming data to the appropriate

Sub-Server Actor that has been instantiated to handle a speciﬁc

client. It also instantiates that Sub-Server Actor when a new

client connects, and clears it out when it disconnects. . . . . 346

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

剩余480页未读，继续阅读

leilove321

粉丝: 1
资源: 9

Scala Akka:构建高可靠多线程应用的Actor模型指南

AKKA concurrency

Akka Concurrency Framework

Artima.Akka.Concurrency

Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams

scala-concurrency-abstractions-slides:关于 Scala 中的 Concurrency Abstractions with concurrent.Future[T]、Akka 中的 actor 和 RxScala 中的 Observable 的幻灯片

Akka Essentials

akka.net：.NET的Akka参与者端口

akka 2.0 文档

akka电子书合集

java餐饮管理源码-akka:使用gradle搭建akkademo，语言是scala

最新资源