【Akka笔记】0. Actor介绍

任何过去做过多线程开发的开发人员都知道管理多线程应用有多么困难，多么痛苦。这儿说的是“管理”，因为多线程开始开发还是蛮简单，并且看到有性能提升时还是蛮有趣的一件事。但是当你没有简单方式能够从子任务中的错误中恢复，或者你发现的僵尸Bug很难重现，或者分析工具显示线程在写共享状态上阻塞太多时间还是很都疼的事。
我不想谈论Java的并发API和集合框架如何让这个过程更好更简单，既然你在看这篇文章，你肯定想在子任务上有更强的控制，或者你不喜欢写锁和同步块，更希望有一些更高层次的抽象。

什么是ACTOR?

Akka的Actor符合Actor Model
把Actor当做是人，他们之间并不直接跟彼此交流，而是通过邮件进行，下面详细说一下

1. 消息传递

这基本概括了Actor模型里消息传递的基本逻辑

考虑一下两个人，一个老师和一个学生。每天早晨学生都向老师发一封邮件，老师也向学生回复一个封。

需要注意的是：

学生发送邮件，一旦发送，邮件就不能再编辑了。这叫自然不变性
老师在想查看邮件时采取检查信箱
老师会向学生回复一封（也是不可变的）
学生也会在需要的时候去查看邮箱
学生不会一直等待老师的回信（非阻塞）

这基本概括了Actor模型里消息传递的基本逻辑



模型里消息传递的基本逻辑

2. 并发

现在，我们想象一下有三个老师，三个学生，每个学生都向三个老师发送邮件。会发生什么呢？实际上什么都没变，每个人都有自己的邮箱。需要注意的是：默认情况下，信箱中的邮件都是按照收到的顺序被读取或处理的。其实，内部默认是 ConcurrentLinkedQueue.
由于没人会等待邮件被处理，所以其实就是一个非阻塞消息（其实有很多内置的信箱，包括有边界的以及基于优先级的。事实上，我们自己也是可以实现一个的）。



3. 容错

想象一下这三个老师来自不同的部门：历史，地理和哲学。

历史老师回复关于历史的邮件，地理老师回复关于地理的邮件等等。每个学生发送给每个老师的消息都会得到回复。学生不关心是哪个部门的老师回复的消息。一旦有一天，一个老师生病了，在这个部门中至少应该有一个老师负责处理邮件。这种情况下，部门中的另一个老师进来，回复学生的邮件。



需要注意的点：

这里边可能有很多Actor，并且他们做的都是不同的事

Actor执行过程中可能引起异常，但是并不能自我恢复。这种情况下，新的Actor会被创建出来去替换掉老的Actor。另外，Actor还可以仅仅忽略一个特殊的消息，进而去处理剩下的消息，这叫做Directives，后边会详细讨论。

4. 多任务

我们假设当学生向老师问考试得分时，这些老师也是可以通过这些邮件来给他们发送考试分数的。同样Actor也可以方便的处理多种类型的消息。

5. 链接

如果学生只想获取一个统一的消息而不是三个呢。

我们也是可以通过Actor来实现类似的需求。我们可以把老师链接起来形成层级结构。后边我们谈及Supervisor的时候回重新细谈这部分内容。

Actor Model：



这里学生和老师就是我们的Actor。收件箱里的邮件就是Mailbox组件。请求和回复都是不可修改的，他们都是immutable对象。最后，Actor中的MessageDispatcher组件来管理mailbox和路由消息到对应的mailbox。

好了，看些代码吧

（翻译自：AKKA NOTES - INTRODUCING ACTORS）