Akka实战指南：构建高可用分布式系统

5星 · 超过95%的资源需积分: 10 58 浏览量更新于2024-07-23 6 收藏 14.91MB PDF 举报

"Akka in Action" 是一本深入讲解使用Akka构建消息驱动系统的实战教程，由Manning Early Access Program出版，适用于第13版。本书专为Scala开发者设计，旨在简化开发并发分布式应用的过程。Akka的核心是Actor模型，它基于独立执行的进程通过消息传递进行通信，从而实现高度容错的应用，即使单个Actor失败也不会导致整个系统崩溃。Akka特别适合处理高流量、需要快速扩展的场景，无论是多核处理器还是服务器节点都能提供高效的可伸缩解决方案。书中的章节结构详细且实用，分为17部分： 1. **入门**：介绍Akka的基本概念和原理，帮助读者建立起对Actor模型的理解。 2. **上手操作**：引导读者通过实践快速掌握Akka，每个新概念都配以实例演示，包括代码实现和单元测试。 3. **测试与Actor系统**：学习如何测试和部署Actor系统，以及如何利用Akka的故障 tolerance特性。 4. **Futures**：探索异步编程在Akka中的应用，理解如何利用Futures处理并发任务。 5. **首个分布式应用**：搭建和扩展第一个分布式Akka应用。 6. **配置、日志和部署**：讲解如何设置和管理Akka的配置，以及日志记录和部署策略。 7. **系统架构**：探讨系统组织结构和组件之间的交互。 8. **路由**：理解如何在大型系统中有效地路由消息。 9. **消息通道**：深入研究不同类型的消息通道和其在系统中的作用。 10. **有限状态机和代理**：学习如何使用这些抽象来设计复杂的行为。 11. **事务处理**：理解事务在Actor模型中的应用，确保数据一致性。 12. **集成**：探讨与其他技术的集成，如数据库和APIs。 13. **集群**：实现Akka集群，提高系统的可用性和可扩展性。 14. **Akka Persistence**：了解持久化机制，确保数据持久化和恢复。 15. **性能分析与调优**：学习如何分析和优化Akka应用的性能。阅读这本书，读者不仅能掌握Akka的实战技能，还能学习到如何设计健壮的事件驱动系统，以及如何在实践中应用如Event Sourcing和CQRS等模式。此外，书中还提供了版权信息和读者评论渠道，鼓励反馈以提升书籍质量。通过本书，读者将建立起坚实的Akka开发基础，并有能力构建高效、弹性、可扩展的分布式应用。

So are there no concurrency primitives like locks used in Akka? Well, ofat all

course there are, it's just that don't have to deal with them . Everythingyou directly

still eventually runs on threads and low level concurrency primitives. Akka uses

the java.util.concurrent library to coordinate message processing and takes great

care to minimize the number of locks used to an absolute bare minimum. It uses

lock free and wait free algorithms where possible, for example compare-and-swap

(CAS) techniques, which are beyond the scope of this book. And because nothing

can be shared between actors, the shared locks that you would normally have

between objects are not present at all. But as we will see later, we can still get into

some trouble if we accidentally share state.

We also saw that in the message passing approach we needed to find a way to

redistribute the tickets. We had to model the application differently, which is what

you would probably expect, no such thing as a free lunch. But the advantage is that

we have traded unknown, perhaps vast amounts of work in scaling and preventing

disasters, for a few amendments to the interactions of the core collaborators, in this

case, simply distributing the load (as tickets to be sold). Later in the book, we will

see that having load accommodations in the domain layer will be beneficial when

we want to scale, as we have already provided a means of spreading the work

around to make use of additional resources.

There are other benefits that stem from the message passing approach that Akka

uses, which we will discuss in the next sections. We have touched on them briefly

already:

Even in this first, simple example, the message passing approach is clearly more fault

tolerant, averting catastrophic failure if one component (no matter how key) fails.

The shared mutable state is always in one place in the example (in one JVM if it is kept

entirely in memory). If you need to scale beyond this constraint, you will have to

(re)distribute the data somehow. Since the message passing style uses addresses, looking

ahead, you can see that if local and remote addresses were interchangeable, scaling out

would be possible without code changes of any kind.

So again, we have paid a small price in terms of more explicit cooperation, but

reaped a clear long-term benefit.

©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and

other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders.

http://www.manning-sandbox.com/forum.jspa?forumID=835

Licensed to Konstantinos Pouliasis <konstantinos.pouliasis@gmail.com>

We just touched on how quickly and easily we were granted a significant measure

of fault tolerance in our example; let's take a moment to go into that a bit more

here. (Fault tolerance is going to be discussed in more detail in chapter 3.) The

Ticketing Example mentioned that the message passing approach allows the

system to keep functioning even when part of it is waiting forever and not

functioning at all. One reason for this is isolation, the actors do not talk to each

other directly. An actor can never block or wait forever because it sent another

actor a message. Because the message is delivered to a mailbox, the sender is

immediately free to go do other work. Maybe the message will never reach its

intended actor, or maybe it will never get processed, but the sending actor at least

will never fail trying to send a message to an address. The same cannot be said for

objects and calling methods. Once you call a method, you are all-in. Figure 1.7

shows the difference in this regard between actors and objects.

Figure 1.7 Message Passing vs. Function Calling

This isolation also offers another opportunity. What if an actor crashes, and is

replaced by another actor, reachable at the same address? Any message sent to the

address will just reach the new actor, as long as the crashed actor is replaced

properly. The fault is contained in the misbehaving actor and any consequent

message could be handled by a new actor. (For this to work, the erroneous actor

should not be allowed to continue to process messages at an exception. It should

just crash and burn, never to be seen again.) Where frameworks like Spring

1.1.2 Fault Tolerance

©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and

other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders.

http://www.manning-sandbox.com/forum.jspa?forumID=835

Licensed to Konstantinos Pouliasis <konstantinos.pouliasis@gmail.com>

The message in the mailbox that was processed by the crashed printing office can

be passed to the new printing office (when it's been determined that it was not

handled). The agents don't notice any problem and the system just continues to sell

tickets. This scenario is one example of a fault tolerance strategy that Akka

provides, which is called the Restart strategy. Other strategies that can be used are

Resume, Stop and Escalate. These strategies are explained in more detail in chapter

4. Akka provides a way to select strategies for specific exceptions that can occur in

Actors. Since Akka controls how all messages between Actors are processed and

knows all the addresses of the Actors, it can stop processing messages for an Actor

that throws an exception, check which strategy should be used for the specific

exception and take the required action. (This is kind of a Cool Hand Luke

Universe: the only failures, are failures of communication.)

Fault tolerant does not mean that every possible fault is caught and recovered

from completely. A fault tolerant system is a system that can at least contain and

isolate faults in specific parts of the system, averting a full system crash. The goal

is to keep the system running, as was achieved by restarting the printing office.

Different faults require different corrective strategies. Some faults are solved by

restarting a part of the system, other faults might not be solvable at the point of

detection and may need to be handled at a higher level, as part of a larger

subsystem. We'll see how Akka provides for such cases with its notion of

Supervision later in the book.

As you would probably expect, replacing malfunctioning objects in a shared

mutable state approach is almost impossible to do, unless you are prepared to build

a framework of your own to support it. And this is not limited to malfunctioning

objects, what if you just wanted to replace the behavior of a particular object? (As

we will see later, Akka also provides functionality to hot swap the behavior of an

Actor.) Since you do not have control over how methods are called, nor possess the

ability to suspend a method and redirect it to another new object, the flexibility that

is offered by the message passing approach is unmatched.

Without going into a lot of detail, let's look briefly at exception handling.

Exceptions in standard, non-concurrent code are thrown up the call hierarchy. An

object needs to handle the exception, or rethrow it. Whenever an exception occurs

you need to stop the regular business that you are doing and fallback to error

handling, to immediately continue where you left off after the error has been dealt

with. Since this is quite hard, most developers prefer to just throw an error all the

way up the stack, leaving it up for some type of framework to handle, aborting the

©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and

other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders.

http://www.manning-sandbox.com/forum.jspa?forumID=835

Licensed to Konstantinos Pouliasis <konstantinos.pouliasis@gmail.com>

process at the first sign of an error. In Java, the situation is made murkier by the

fact that there are two types of exceptions (checked and runtime), and confusion

about the applicability of each has made it more likely that the default impulse is

just going to be to punt and hope someone else handles it.

And that's just talking about non-concurrent exception handling. Exceptions are

almost impossible to share between threads out of the box, unless you are prepared

to build a lot of infrastructure to handle this. Exceptions cannot automatically be

passed outside of the thread group that the thread is part of, which means you

would have to find some other way to communicate exceptions amongst threads in

different thread groups. In most cases if a thread encounters some kind of

exception the choice is made to ignore the error and continue, or stop execution

completely, which is the simplest solution. You might find some evidence in a log

that a thread crashed or stopped, but communicating this back to other parts of the

system is not easy. Restarting the thread and providing the state it needs to function

is very hard to do manually. Things become an order of magnitude harder when

these threads are distributed across several machines. Akka provides one model for

handling errors, for both actors on one machine, as scaled out across many, as we

will see later in chapter 3. Hopefully, you can see in the midst of these contrasted

approaches to core problems, that Akka is not just a solution to concurrency issues;

the fault tolerance advantages can, in many cases, be just as great a lure.

In this section we are going to briefly look at how a message passing style provides

some benefits for scaling up and out. In our Ticketing example, scaling up would

mean getting more TicketingAgents running on our one server, scaling out would

be bringing up TicketingAgents on a number of machines.

Without explicitly stating it, so far we have looked at the agents and printing office

example on one machine, and one JVM. So how do we scale out to many

machines?

The message passing style uses addresses to communicate, so all we need to

change is how the addresses are linked to actors. If the toolkit takes care of the fact

that an address can be local or remote, we can scale the solution just by configuring

how the addresses are resolved. Figure 1.9 shows how the Akka toolkit solves this

for us.

1.1.3 Scale Up and Out

SCALE OUT

other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders.

http://www.manning-sandbox.com/forum.jspa?forumID=835

Licensed to Konstantinos Pouliasis <konstantinos.pouliasis@gmail.com>

剩余393页未读，继续阅读

麻团

粉丝: 5
资源: 83

Akka实战指南：构建高可用分布式系统

Akka 实战 akka in action v13 2014版本

Akka.in.Action.2016.9.pdf

akka in action中文版

akka in action.zip

Akka in Action：构建消息驱动系统的实战教程

Akka in Action：高并发与实时流处理实战指南

akka in action pdf

向上运行：Akka in Action第2章“向上运行”

akka-in-action

akka-in-action中文版

最新资源