02_actor系统

2 actor系统

Actor是封装状态和行为的对象，他们的唯一通讯方式是交换消息，交换的消息存放在接收方的邮箱里。从某种意义上来说，actor是面向对象的最严格的形式，但是最后把它们看成一些人：在使用actor来对解决方案建模时，把actor想象成一群人，把子任务分配给他们，将他们的功能整理成一个有组织的结构，考虑如何将失败逐级上传（好在我们并不需要真正跟人打交道，这样我们就不需要关心他们的情绪状态和道德问题）。这样的结果就可以在脑中形成进行软件实现的框架。

2.1树形结构

像一个经济学组织一样，actor自然会形成树形结构。程序中负责某一个功能的actor可能需要把它的任务分拆成更小的、更易管理的部分。为此它启动子Actor并监管它们。虽然监督机制的细节将在这里解释，我们在这一节里将集中讲述其中的基础概念，唯一的前提是要知道每个actor有且仅有一个监管者，就是创建它的那个actor.

Actor系统的精髓在于任务被分拆开来并进行委托，直到任务小到可以被完整地进行处理。这样做不仅使任务本身被清晰地划分出结构，而且最终的actor也能按照它们“应该处理的消息类型”，“如何完成正常流程的处理”以及“失败流程应如何处理”来进行解析。如果一个actor对某种状况无法进行处理，它会发送相应的失败消息给它的监管者请求帮助。这样的递归结构使得失败能够在正确的层次进行处理。

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

现在，设计这种系统的难度在于如何决定谁应该监管什么。这当然没有一个唯一的最佳方案，但是有一些可能会有帮助的原则：
如果一个actor管理另一个actor所做的工作，如分配一个子任务，那么父actor应该监督子actor，原因是父actor知道可能会出现哪些失败情况，
知道如何处理它们。
如果一个actor携带着重要数据（i.e. 它的状态要尽可能地不被丢失），这个actor应该将任何可能的危险子任务分配给它所监管的子actor，并酌情处理子任务的失败。视请求的性质，可能最好是为每一个请求创建一个子actor，这样能简化收集回应时的状态管理。这在Erlang中被称为“Error Kernel Pattern”。
如果actor A需要依赖actor B才能完成它的任务，A应该观测B的存活状态并对收到B的终止提醒消息进行响应。这与监管机制不同，因为观测方
对监管机制没有影响，需要指出的是，仅仅是功能上的依赖并不足以用来决定是否在树形监管体系中添加子actor.
当然以上的规则都会有例外，但是无论你遵循这些规则或者打破它们，都需要有足够的理由。

2.2配置容器

多个actor协作的actor系统是管理如日程计划服务、配置文件、日志等共享设施的自然单元。使用不同的配置的多个actor系统可以在同一个jvm中共存。Akka自身没有全局共享的状态。将这与actor系统之间的透明通讯（在同一节点上或者跨网络连接的多个节点）结合，可以看到actor系统本身可以被作为
功能层次中的积木构件。

2.3Actor最佳实践

• Actor们应该被视为非常友好的同事：高效地完成他们的工作而不会无必要地打扰其它人，也不会争抢资源。转换到编程里这意味着以事件驱动的方式来处理事件并生成响应（或更多的请求）。Actor不应该因为某一个外部实体而阻塞（i.e.占据一个线程又被动等待），这个外部实体可能是一个锁、一个网络socket等等。阻塞操作应该在某些特殊的线程里完成，这个线程发送消息给可处理这些消息的actor们。
• 不要在actor之间传递可变对象。为了保证这一点，尽量使用不变量消息。如果actor将他们的可变状态暴露给外界，打破了封装，你又回到了普通的Java并发领域并遭遇所有其缺点。
• Actor是行为和状态的容器，接受这一点意味着不要在消息中传递行为（例如在消息中使用scala闭包）。有一个风险是意外地在actor之间共享了可变状态，
  而与actor模型的这种冲突将破坏使actor编程成为良好体验的所有属性。

2.4 你不应该担心的事

一个actor系统管理它所配置使用的资源，运行它所包含的actor. 在一个系统中可能有上百万个actor，不用担心，内存一定是够用的，因为每个actor实例仅占差不多300个字节。自然地，一个大系统中消息的处理顺序是不受应用的开发者控制的，但这并不是有意为之。放松些，让Akka去做幕后的繁重事务吧。

转自http://www.gtan.com/akka_doc/general/actor-systems.html