任何以前做过多线程的人都不会否认管理多线程程序是困难并且痛苦的。 我说管理是因为它开始很容易而且当你看到性能提升时会很兴奋。但是，当你看到你没法从子线程的错误中恢复 或者 这些僵尸bug很难重现 或者 当用性能剖析器时你发现你的线程在更新一个共享状态时阻塞了很长时间时，那真的很痛苦。
我倾向于不说Java的并发API和集合把并发编程变的更轻松和容易了，因为如果你看到这，你肯定渴望对子线程任务有更多控制或者希望更简单但又不愿意去写一堆的锁和同步代码块，而且希望对这种模式有更高层的抽象。
着这个Akka笔记里，我们会将Akka的例子过一遍并且看看这个工具箱里的各种特性。
什么是Actors
直接把Actors想象成人，人与人之间不直接说话，人们通过邮件来交流。
下面展开说。
1.消息 MESSAGING
想象有两个人 - 一个有智慧的老师和一个学生。 学生每天早上发邮件给老师，老师则回复一条妙语。
要点：
1.学生发一个邮件。一旦发出，邮件不能被编辑。这叫做不可变性。
2.老师在任何他喜欢的时间检查邮箱。
3.老师会发回一个邮件（也是不可变的）。
4.学生自由的检查自己的邮箱。
5.学生不会等待回复（没有阻塞）。
以上基本上解释了Actor模型的最基本模块 - 传递消息。 
2. 并发 CONCURRENCY
现在，想象有三个老师和三个学生 -每个学生都给每位老师发邮件。那现在有什么事情发生了呢？没啥变化。每个人都有他们自己的邮箱。有一点需要记一下：
默认规则是邮箱里的邮件是按照接收的顺序来阅读/处理
内部实现默认是用ConcurrentLinkedQueue。并且因为没有人等待捡邮箱里的邮件，这是一个简单的非阻塞消息。（有很多内置的邮箱，事实上我们甚至能自己实现一个）
3.故障转移 FAILOVER
想象三个老师来自不同的系 - 历史系，地理系和哲学系
历史老师会对过去的事情进行回复，地理老师会发出一个有趣的地方，哲学老师回复一个格言。每个学生会给每个老师发邮件（消息）并且得到回复。学生并不关心是系里的哪个老师发的回复。如果某一天老师生病了呢？必须至少有一个系里的老师来处理这些邮件（消息）。这时，必须有另一个老师顶替上来处理邮件。
需要注意的：
需要有一个能做各种不同事情的Actor的后备池。
一个Actor有可能在处理消息时出现问题。他也不能进行自我恢复。这种情况发生时会有一个新的Actor被创建并且取代老的Actor。一个可选的做法是，Actor可以忽略那个有问题的消息并且直接处理其他还没处理的消息。这种方式叫Directives，我们稍后再说。
4.多任务 MULTITASKING
我们假设老师还会在学生询问的时候用邮件回复考试分数。同样的，Actor可以处理多种类型（type）的消息。
5.串联 CHAINING
如果学生希望拿到一个完整的将三份消息串在一起的邮件而不是三份邮件呢？
我们的Actor仍然可以这么做。我们可以把老师串成一个继承的层次结构。当我们谈到Supervisor和Future时我们还是回到这里。
现在让我们用Actor模型来类推一下这个组件。
学生和老师就是我们的Actors。邮箱就是Mailbox组件。请求和回复都不能被更改。他们是不可变（immutable）对象。最后，Actor中的MessageDispatcher组件是用来管理邮箱并且把消息路由到目标邮箱。
这是我翻译的文章，原文在http://rerun.me/2014/09/11/introducing-actors-akka-notes-part-1/
文章来自微信平台「麦芽面包」,微信号「darkjune_think」。转载请注明。
