akka学习之actor系统介绍

actor系统

      前面讲过actor其实是封装了状态和行为的对象，actor之间唯一的通信方式是通过接收者的邮箱交换信息。为了更好的了解actor系统，可能把它类比为人群会更好理解些。在使用actor来对解决方案建模时，把actor想象成一群人，把子任务分配给他们，将他们的功能整理成一个有组织的结构，同时考虑将失败情况向上级汇报。这样的就可以在脑中形成进行软件实现的框架。actor系统是一个可分配N个线程的重量级的结构，因此在一个逻辑应用中只创建一个actor系统。

层级结构

      一个actor可能会把任务拆分成更细粒度的子任务，并且管理他们。actor系统一个典型的特点就是把任务尽量拆得足够小，然后为这些小任务定义和创建actor。在任务拆分的时候，每个子任务要结构明确，功能紧凑，这样才能根据任务去构建actor处理消息的方法，正常的消息交互，以及如何处理错误。如果一个actor没有处理某个状况的方法，那么它会发送相应的错误消息给它的监护者，如果监护者不能处理，则递交给监护者的监护者处理，这种递归结构基本能保证错误在合适的层次上被处理掉。相比于传统的在可能出错的地方去穷举可能的错误，并进行处理，以防止错误泄露出去，akka的这种把错误统一交给合适的人去处理会是一个更加好的解决办法。

     这样的错误处理方案好是好，但是问题的难点是哪个actor应该监管什么，这个没有一个最好的解决方案，需要根据系统的实际情况来设计，下面是几条在实际应用中可能有帮助的建议：

1.如果一个actor需要管理另外一个actor要做的工作，比如传递子任务等，这时候管理者应该监控子actor。因为管理者可能预期得到子actor会遇到什么样的错误，并知道如何去处理。

2.如果一个actor带有非常重要的信息，这个actor应该把可能的危险任务交给他监管的子任务去处理，然后处理子actor可能出现的错误。视请求的性质，可能最好是为每一个请求创建一个子actor，这样能简化收集回应时的状态管理。这在Erlang中被称为“Error Kernel Pattern”。

3.如果一个actor依赖于其他actor来执行自己的任务，它必须监控所依赖的actor的生命周期，对依赖的actor发送过来的终止消息作出响应。在这里监管(supervision)和监控(watching)有不同的含义，监控方不影响监管策略。同时必须注意的是，仅仅是功能上的依赖不能决定一个子actor在整个系统中处于哪个层次。

 

配置容器

      actor系统是一个由许多actor对象组成的系统，这个系统管理着所有actor共享的基础设施，比如定时服务，配置，日志等等。使用不同的配置的多个actor系统可以在同一个jvm中共存而不会发生问题。akka本身没有全局共享的状态。将这与actor系统之间的透明通讯（在同一节点上或者跨网络连接的多个节点）结合，可以看到actor系统本身可以被作为功能层次中的积木构件。

 

actor最佳实践

1.actor应该就像最好的同事那样：大家各自高效地做自己的事情，而不会干扰其他人的工作，同时也尽量避免占用资源，比如cpu，线程，内存等等。更具体的编程来说，就是通过事件驱动的方式来处理任务和产生响应。actor处理任务的时候尽量不应该被某些外部实体阻塞，比如锁，网络socket等等。

2.actor之间的传递消息时不要用可变对象，最好定义不可变类型的消息（比如String类型）。如果把actor对象内部的可变状态传递给了外部，那么你又回到了传统的java并发编程模式，陷入无休止的锁，同步等等的泥潭中。

3.actor是封装了行为和状态的容器，因此不要在消息中把actor的行为传递出去，如果这样做，就有可能把actor的可变状态共享出去了，同时actor模型的隔离性也被打破了。

4.顶层actor是错误内核中最重要的一部分，因此需要谨慎的设计顶层系统，最好使用真正的分层设计的方式来设计他。这有助于实现错误处理，同时减少守护actor的压力。

 

阻塞需要谨慎地处理

在上面第一条中说过要尽量避免阻塞，但是在某些操作中阻塞是不可避免的。比如在不确定的时间让现场休眠，并等待外部事件的发生。比较普遍的阻塞场景主要有数据库操作，消息API，网络IO等。当面对这种场景的时间，你可能会尝试把阻塞调用封装在Future中，但是这种策略稍嫌简单了些，而且会引发潜在的问题：可能很快就遇到了性能瓶颈，或者当阻塞严重时会load升高时，同时无限的创建线程，并最终导致OOM。下面给出几种常见的处理阻塞问题的建议：

1.使用actor来做阻塞调用，并通过配置线程池以及线程池的大小来处理actor。

2.使用Future来做阻塞调用，但是要确保并发线程数的上限，如果没有限制，可能会导致OOM或者超过系统的线程上限。或者也使用线程池来处理Future。

3.创建一个管理线程来管理阻塞资源，并且分派事件，就像NIO的selector管理多channel一样。

     最好通过akka提供的application.conf文件来配置线程池。