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. 阻塞

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

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

继续阅读 →

Oracle hint

公司的DBA要求把他们固化的执行计划改用 Oracle hint 来实现,正好了解下平时没注意去用的 hint。

优化方式

Oracle的优化器有两种优化方式:

  • 基于规则的优化方式(Rule-Based Optimization,简称为RBO) :优化器在分析 SQL 语句时,所遵循的是 Oracle 内部预定的一些规则。比如我们常见的,当一个 where 子句中的一列有索引时去走索引。

  • 基于代价的优化方式(Cost-Based Optimization,简称为CBO) ;它是看语句的代价(Cost),这里的代价主要指Cpu和内存。优化器在判断是否用这种方式时,主要参照的是表及索引的统计信息。统计信息给出表的大小、有少行、每行的长度等信息。这些统计信息起初在库内是没有的,是做 analyze 后才出现的,很多的时侯过期统计信息会令优化器做出一个错误的执行计划,因些应及时更新这些信息。

hint 也不例外,除了 /*+ rule */ 其他的都是 CBO 优化方式 。

优化模式

优化模式包括 Rule、Choose、First rows、All rows 四种方式:

  • Rule:基于规则的方式。
  • Choolse:默认的情况下 Oracle 用的便是这种方式。指的是当一个表或或索引有统计信息,则走 CBO 的方式,如果表或索引没统计信息,表又不是特别的小,而且相应的列有索引时,那么就走索引,走 RBO 的方式。
  • First Rows:它与 Choose 方式是类似的,所不同的是当一个表有统计信息时,它将是以最快的方式返回查询的最先的几行,从总体上减少了响应时间。
  • All Rows:也就是我们所说的 Cost 的方式,当一个表有统计信息时,它将以最快的方式返回表的所有的行,从总体上提高查询的吞吐量。没有统计信息则走 RBO 的方式。

hint

hint 语法

: {DELETE|INSERT|SELECT|UPDATE} /*+ hint [text] [hint[text]]... */
多个hint之间需要用空格分开,如果没有指定正确的hint,oracle讲忽视该hint,没有任何错误提示。

我们可以使用注释(comment)来为一个语句添加 hints,一个语句块只能有一个注释,而且注释只能放在 SELECT,UPDATE 或 DELETE 关键字的后面。

继续阅读 →

oracle 表连接类型 join type

Join 是一种试图将两个表结合在一起的谓词,一次只能连接 2 个表,表连接也可以被称为表关联。Join 过程的各个步骤经常是串行操作,即使相关的 row source 可以被并行访问,但是在将表中符合限制条件的数据读入到内存形成 row source 后,join 的其它步骤一般是串行的。

row source (表)之间的连接顺序对于查询的效率有非常大的影响。通过首先存取特定的表,即将该表作为驱动表,这样可以先应用某些限制条件,从而得到一个较小的 row source,使连接的效率较高,这也就是我们常说的要先执行限制条件的原因。一般是在将表读入内存时,应用 where 子句中对该表的限制条件。

根据 2 个 row source 的连接条件的中操作符的不同,可以将连接分为等值连接(如 WHERE A.COL1 = B.COL2)、非等值连接(WHERE A.COL1> B.COL2)、外连接(WHERE A.COL1= B.COL2+))。

继续阅读 →