Akka 文档: Actor 是什么?

翻译自:http://doc.akka.io/docs/akka/2.3.8/general/actors.html

Actor 是什么?

前一章节关于 Actor 系统 解释了 actors 如何组成层级,且是构建应用的最小单元。这章只关注这样的 actor,解释你在实现它时会遇到的概念。更多深入细节的参考见 Actors(Scala) 和 Untyped Actors(Java) 。

一个Actor是一个容器,它包含了 状态,行为,一个 邮箱,子Actors 和一个 督导策略。所有这些封装在一个 Actor 引用 后面。当 Actor 终止时,会发生 这个。

Actor 引用

一个 actor 对象需要与外界隔离开才能从 actor 模型中获益。所以 actor 是以 actor 引用的形式展现给外界的,actor 引用可以被自由的无限制地传来传去。内部对象和外部对象的这种划分使得所有想要的操作能够透明:重启 actor 而不需要更新别处的引用,将实际 actor 对象放置到远程主机上,向另外一个完全不同的应用程序的 actors 发送消息。但最重要的方面是从外界不可能访问到 actor 对象的内部状态,除非这个 actor 非常不明智地将信息(内部状态)公布出去。

继续阅读 →

Akka 文档:Actor 系统

翻译自:http://doc.akka.io/docs/akka/2.3.8/general/actor-systems.html

Actor 系统

Actor 是封装状态和行为的对象,他们的唯一通讯方式是交换消息,交换的消息存放在接收方的邮箱里。从某种意义上来说,actor 是面向对象编程的最严格的形式,但是最好把它们看作一些人:在使用 actor 来建模解决方案时,把 actor 想象成一群人,把子任务分配给他们,将他们的功能整理成一个有组织的结构,考虑如何将失败逐级上传(受益于不实际与人交互,意思是我们不需要担心他们的情绪状态或精神问题)。这样的结果就可以在脑中形成进行软件实现的框架。这个结果可以作为构建软件实现的脚手架。

注意:一个 ActorSystem 是一个重量级结构,会分配 1....N 个线程,所以每个逻辑应用创建一个即可。

分层的结构

像在一个经济组织里,actors 天生地形成层级。一个 actor,整天上看是程序的一个功能,可能想把它的任务分割成更小的,更容易管理的分块。为了这个目的,它启动由它督导(supervise)的子 actors。督导的细节将在这里 解释,我们先专注于本章的底层概念。唯一的先决条件是知道每个 actor 有且只有一个督导者,也就是创建它的 actor。

actor 系统的精髓是任务被分割和委托,直到足够小可以完整地处理。按这样做,不止任务本身被清晰地分出结构,而且使 actors 对它们应该处理什么消息、如何响应(react)和如何处理失败 更合理(译注:按这个三个角度来组织)。如果一个 actor 没法处理某个特定情况,它可以发送一个对应的失败消息给它的督导者,寻求帮助。递归的结构允许在正确的层级处理失败。

可以将这与分层的设计方法进行比较。分层的设计方法最终很容易形成防护性编程,以防止任何失败被泄露出来。把问题交由正确的人处理会是比将所有的事情“藏在深处”更好的解决方案。

继续阅读 →

Akka 文档:术语、概念

翻译自:http://doc.akka.io/docs/akka/2.3.8/general/terminology.html

术语、概念

在本章,我们尝试建立一个通用的术语来定义一个坚固的基础,用于沟通 Akka 致力于的关于并发、分布式系统。请注意,对于很多这些术语,没有单一的认同的定义。我们仅仅试图给出在这篇 Akka 文档范围内使用的可行定义。

并发 vs. 并行

并发和并行是相关的概念,但他们有细微的不同。并发意味着两个或多个任务在取得进展,即使它们可能不是同时执行。例如通过时间分片来实现,任务的不同部分顺序地执行,混杂着其他任务的部分。并行在另一方面是 在真正地同时执行时出现。

异步 vs. 同步

如果调用者在方法返回一个值或抛出异常前不能取得进展,则个方法调用被认为是同步的。在另一方面,一个异步调用允许调用者取得进展,在一个有限数量的步骤后,并且方法完成后会收到通知,通过额外的机制(可以是注册一个回调、一个 Future 或 一个消息)。

一个同步的 API 可能使用阻塞来实现同步,但不是必须的。一个 CPU 敏感的任务可能表现出类似阻塞的行为。一般情况下,倾向于使用异步的 API,因为它们保证系统可以取得进展。Actors 天生是异步的:一个 actor 在发出消息后可以继续取得进展,不需要等待实际的发送(delivery)发生。

非阻塞 vs. 阻塞

如果一个线程能够无限延迟其他一些线程,我们认为是阻塞的。一个好的例子是,资源可以被一个线程通过互斥独占地使用。如果某个线程无限地(例如意外地跑入一个死循环)持有资源,其他在等待资源的线程将不能取得进展。与此相反,非阻塞意味着没有线程能够无限地延迟其他线程。

非阻塞操作优于阻塞的,因为,当包含阻塞操作时系统的整体进展没法保证。

继续阅读 →

Akka TypedActor

Akka 中的有类型 Actor 是 Active Objects 模式的一种实现,将异步的调用执行逻辑封装在一个方法内,在代码层面保证了的顺序执行思维。

Active Objects 设计模式

来自维基百科 Active Objects 。

该设计模式包含了六种元素:

  • 代理:提供了面向客户端的带有公开方法的接口。
  • 接口:定义了到 active object 的请求方法(业务代码提供)。
  • 来自客户端的一序列等待请求。
  • 调度器:决定接下来执行哪个请求。
  • active object 方法的实现类(业务代码提供)。
  • 一个回调或变量,用以让客户端接收结果。

上述六个元素中,除了标记(业务代码提供)的,其余都是由该模式的实现提供的,在本篇也就是 Akka。

Akka 是通过 JDK 的 java.lang.reflect.Proxy 来自实现 active object 模式的。

继续阅读 →

Akka Actor 生命周期

本文主要展示 Akka Actor 的生命周期管理和默认的监管策略。基于 Akka 2.3.4,Scala 2.11。

Akka Actor 生命周期钩子

Actor 实例化后就由 Actor 运行时调度执行。

Akka Actor 定义了下列的生命周期回调钩子:

  • preStart:在 actor 实例化后执行,重启时不会执行。
  • postStop:在 actor 正常终止后执行,异常重启时不会执行。
  • preRestart:在 actor 异常重启前保存当前状态。
  • postRestart:在 actor 异常重启后恢复重启前保存的状态。

继续阅读 →

Akka Actor 4个核心操作

来自:http://markusjura.github.io/akka-intro-slides/ 的笔记

  1. create:创建新的Actor。
    每个 Actor 表示为一个 ActorRef;
    没法访问 Actor 实例;
    一个Actor引用允许你发送消息到一个 Actor。

  2. send:发送消息到其他 Actor。
    需要一个 Actor 引用;
    异步和非阻塞(fire-and-forget);
    注意:消息必须是不可变的。
    最佳实践:
    使用 object 和/或 case 类;
    在 actor的伴生对象里定义消息协议。

  3. Become:为处理下一个消息改变行为。
    动态定义Actor的行为;
    通过接收消息触发;
    将对它接收到的消息作出不同的反应。

    用途:
    实现有限状态机;
    让高度竞争的Actor自适应地转换他自己为 Actor 池或路由Router;
    实现优雅的降级;
    派生出通用的工作者Actor,成为管理者当前需要的。

  4. Supervise:管理其他 Actor 的失败。
    监管策略:

      每个Actor有一个默认的监管策略:
           ActorInitializationException → Stop
           ActorKilledException → Stop
           Exception → Restart
           Throwable → Escalate
           Otherwise → Escalate
    
      策略可以被覆写;
    

欢迎关注我的微信公众号: coderbee笔记,可以更及时回复你的讨论。

《Java 虚拟机并发编程》笔记

并发

线程数 = CPU可用核心数 / ( 1 – 阻塞系数 )
阻塞系数的取值在 0 - 1 之间,计算密集型任务的阻塞系数是 0,IO 密集型任务的阻塞系数接近于 1。

构建计算密集型并发应用程序的几点经验:
* 子任务的划分数不少于处理器核心数;
* 线程数多于处理器核心数对性能提升毫无帮助;
* 在子任务划分超过一定数量之后,再增加子任务划分数对于性能的提升将十分有限。

保持一个合理的划分数,并使所有处理器核心都有足够的工作量才是关键。

应该尽可能地提供共享不可变性,否则就应该遵循隔离可变性原则,即保证总是只有一个线程访问可变变量。

开多少个线程以及如何拆分问题都会影响到你的并发应用程序的性能,还要权衡每个子任务的工作负载和划分开销。

继续阅读 →