Actor Model

以下内容翻译自Akka文档，以及网上摘录，并加上自己的理解，可能对于Actor的理解带有片面性，仅作为学习之用。

Actor System

Actors可以理解为状态和行为的封装体，他们通过交换消息来进行沟通，而这些消息存放在接收者的邮箱中。

当使用Actor System作为某个问题的解决方案的时候，就可以将整个系统理解为一个团队，系统中的每个Actor都是团队中的一个人，每个Actor作为执行任务的最小单元。他们之间相互协调，任务从上级开始向下分发，他们之间通过消息进行交流，而这个消息就好像我们平时用到的邮件，消息的内容可以包括收件人，发件人，任务等。Actor就可以根据消息中的任务来执行相应的操作，根据收件人和发件人决定消息的转发。

当一个任务分到某个人的时候，他进行预估如果这个任务比较庞大，自己完成需要太多的时间

1）他就可以将任务分解成多个小任务，分配给他的下属（已经存在的其他Actor）。

2）而如果此时他的下属人手不够，就需要从其他部门调人或者招人（产生新的Actor）。

3）而如果他自己因为太忙了，在接受了这个消息后不愿意处理其他消息了，就可以设置自动回复等告诉他人自己不再接受任务（指定接收到下一个消息的策略）。

上面三条策略分别对应下图的三定则：（图片来自邓草原：AKKa分片集群的实现-以spray-socktio为例）

Actor System可以理解为一个树状的组织结构，这个组织中的每一个节点都可以和其他节点进行交流（包括他的父节点和他的子节点）。而一个人可能有多个上级，可能在一段时间内有多人给他安排了任务，这个人将这些任务记录在了自己的本子（邮箱机制）上，然后逐个任务进行完成（异步机制），每完成一个任务就将其从本子上划去，也就是从邮箱中移除，然后将任务的结果等发送给适当的人，有可能是给他布置任务的人，也有可能是给他布置任务的人所指定的某个人。这样子消息不停的传递下去，直到所有消息被处理完成，这个任务结束。

正是因为任务都是由一个Actor分给其他Actor的，所以这个Actor对于其他Actor有监管作用，就像是领导安排了任务给下属，他需要实时的关注任务的进度，如果某个人因为某些问题不能完成任务，他需要采取一定的措施来弥补。这就是所谓的容错性，比如Hadoop的心跳机制，datanode定期发送心跳到namenode，如果namenode长期没有收到某个datanode的消息，则表示该节点挂了，需要进行相应的处理。

Actor系统中的任何一个Actor相对于其他Actor都是独立的，他们之间互不干扰，不共享资源，也就是说他们不需要采用加锁等同步方式来协调某些资源的竞争。举个例子来说：就好像一个公司的人都分布在全国各地的不同地方，他们都在自己的家里进行远程办公，他们不需要进行卫生间的争夺，因为他们的家中都有属于自己的专属卫生间。而如果他们在同一个地方进行办公，而人数较多的时候，一个人占用卫生间的时候，其他人必须等待，这就是资源竞争导致的问题。需要知道的是无论是本地锁还是分布式锁所消耗的资源都是不容忽视的。

如同下图所示，

上面图的最后一个例子，可以看到每个Actor都拥有自己的State，State的改变通过message的处理，而不会被其他线程所直接改变。这就是为什么最开始提到的Actor是状态和行为的封装体。

因此每个Actor都是线程安全的。

Best Practice

来自AKKA文档

1. Actors should be like nice co-workers: do their job efficiently without bothering everyone else needlessly and avoid hogging resources. Translated to programming this means to process events and generate responses (or more requests) in an event-driven manner. Actors should not block (i.e. passively wait while occupying a Thread) on some external entity—which might be a lock, a network socket, etc.—unless it is unavoidable; in the latter case see below.
2. Do not pass mutable objects between actors. In order to ensure that, prefer immutable messages. If the encapsulation of actors is broken by exposing their mutable state to the outside, you are back in normal Java concurrency land with all the drawbacks.
3. Actors are made to be containers for behavior and state, embracing this means to not routinely send behavior within messages (which may be tempting using Scala closures). One of the risks is to accidentally share mutable state between actors, and this violation of the actor model unfortunately breaks all the properties
which make programming in actors such a nice experience.
4. Top-level actors are the innermost part of your Error Kernel, so create them sparingly and prefer truly hierarchical systems.This has benefits with respect to fault-handling (both considering the granularity of configuration and the performance) and it also reduces the strain on the guardian actor, which is a single point of contention if over-used.

参考：

http://www.jdon.com/45728

http://wenku.it168.com/d_001436603.shtml

http://www.douban.com/note/250537324/

http://www.jdon.com/45516

http://blog.jeoygin.org/2011/10/actor-model.html

http://bbs.chinaunix.net/thread-4025325-1-1.html

AKKA文档

A Model of Concurrent Computation in Distributed Systems