Akka并发编程：构建多核世界可靠软件指南

5星 · 超过95%的资源需积分: 9 15 浏览量更新于2024-07-25 2 收藏 7.41MB PDF 举报

"Artima.Akka.Concurrency" 《Artima.Akka.Concurrency》是一本专注于在Java虚拟机上构建高效并发软件的书籍，它借助Akka工具包简化了多核心、多处理器甚至分布式环境下的编程挑战。本书旨在帮助读者理解和掌握如何利用Akka设计和编写软件，使开发者能够更专注于软件的核心业务，而不是被并发性问题所困扰。书中不仅补充了Akka官方文档的内容，还深入探讨了Akka的工作原理和应用方式，从而提升应用程序的可扩展性、响应性和性能。 Akka是一个基于actor模型的开源框架，由Lightbend公司维护，适用于Java和Scala语言。Actor模型是一种并发计算模型，它将并发处理细分为独立的、交互的实体——actor。每个actor都有自己的状态，并通过消息传递与其他actor通信，这种方式避免了共享状态，减少了竞态条件和死锁等问题，从而提高了软件的可靠性。在《Akka Concurrency》中，作者Derek Wyatt详细介绍了如何利用Akka的特性来构建可靠的多核世界中的软件。书中可能会涵盖以下主题： 1. **Actor系统**：解释Akka中的核心概念，如Actor系统的层次结构、Actor的创建和生命周期管理。 2. **消息传递**：讨论actor间的异步通信机制，包括消息队列和消息模式，如请求-响应、发布-订阅等。 3. **容错与持久化**：介绍如何利用Akka的容错机制（如Supervision和Watch）以及持久化特性（如Event Sourcing和CQRS）来构建健壮的应用程序。 4. **集群与分布式**：探讨如何利用Akka的集群功能实现跨节点的actor通信和负载均衡，以及如何搭建分布式系统。 5. **调度与并行性**：讲解Akka的调度器如何管理actor的执行，以及如何优化并行处理以提高性能。 6. **监控与调试**：介绍如何监控Akka应用的运行状况，以及如何进行有效的故障排查和性能调优。 7. **最佳实践与案例研究**：提供实际场景下的应用示例，展示如何在项目中有效运用Akka。作为PrePrint™版本的购买者，读者可以获取到书本的最新进展，随着书本内容的不断完善，可以下载更新版，并有机会参与到书本的改进过程中，通过提交错误报告和改进建议来对书本的最终形态产生影响。《Artima.Akka.Concurrency》是针对Java和Scala开发者的一份宝贵的资源，它将帮助读者深入理解Akka并发编程，从而在分布式环境中构建出更加高效、可靠且易于扩展的软件系统。

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

Download from Wow! eBook <www.wowebook.com>

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

Download from Wow! eBook <www.wowebook.com>

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

Download from Wow! eBook <www.wowebook.com>

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 if

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

Download from Wow! eBook <www.wowebook.com>

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

Download from Wow! eBook <www.wowebook.com>

剩余480页未读，继续阅读

mainframecce

粉丝: 2
资源: 40

Akka并发编程：构建多核世界可靠软件指南

Artima.Actors.in.Scala.Mar.2011

FlexMonkey5.0

Scala编程（第三版）中英文.zip

将Java编译成JavaScript——Artima对话Google工程师Scott Blum.pdf

包含 com.borland.jbcl.layout.jar +sun.net.jnin.jar+apsche

Programming in Scala

C++世界最权威的观点

Artima SuiteRunner-开源

MATLAB实现基于SVM-RFE-BP多输入单输出回归预测（含完整的程序和代码详解）

rhino grasshoper 景观椅（附视频）.gh

最新资源