akka基础 : 理解Actor 系统

Actors 是一些包含状态和行为的一些对象。它们通过显式的传递消息来进行通信，这些消息会被发送到它们收件箱中（消息队列）。某种意义上来说，actor 是面向对象编程中最严格的实现形式。为了更好的理解它们，我们可以把这些actors看做一群人。想象一下，我们把一些子任务分给一群人，这些人根据其不同的职能划分为不同的组织机构。（这样的好处就是我们不用与实际的人去打交道，而是直接面对部门整体。也不用花心思去考虑某一个人的情绪因素和职业道德了）。我们在构建软件的时候其实也可以借鉴这种方式。

注意：一个actorSystem 是一个重量级的结构。它会分配N个线程。所以对于每一个应用来说只用创建一个ActorSystem

树形结构

actors以树形结构组织起来，类似一个生态系统。例如，一个actor可能会把自己的任务划分成更多更小的、利于管理的子任务。为了这个目的，它会开启自己的子actor，并负责监督这些子actor。关于监督的具体细节就不在这里讨论了。我们只要知道一点，就是每一个actor都会有一个监督者，那就是创建这些actor的那个actor。

如下图：

actor系统的精华就是任务的分解。任务要被分割的要足够小，每个分片都会被委托给子actor。这里用到的思想很明显就是“分而治之”，万变不离其宗啊！要想做好这一切，不仅仅要把任务组织的非常清晰（利于分解），也要对处理任务的最终actor在以下方面进行考虑：哪些消息需要处理、如何正常的回应、如何处理失败等等。如果一个处理特定任务的actor失败了，它会向它的监督者发出响应错误的消息去寻求错误处理的方法。这种递归式（监督者也有自己的监督者）的结构可以保证错误在合适的级别上进行处理。

设计这样一种系统的难点在于如何去确定“谁来监督 ” 和“监督什么"。这两个问题虽然没有最佳解决方案，但是还是有一些有用的指导规则。

• 如果一个actor管理工作，拎一个actor来执行工作。例如，http://my.oschina.net/clopopo/admin/edit-blog?draft=11345把子任务发送给工作actor。管理actor需要监督工作actor。因为管理actor知道会出现哪种错误，并且应该如何去处理它们。

• 如果一个actor持有非常重要的数据（它的状态值尽量不能丢失），它应该把子任务分给自己监督的子actor。这样它就能根据情况来处理这些子actor失败。根据任务请求的性质，最好为每一个任务分配一个新的子actor，这样会简化收集子actor相应时的状态管理。

• 如果一个actor依赖另一个actor才能完成自己的任务，它应该监控那个actor的活动状态，并且对那个actor的关闭事件做出响应。这个和监督还是不同的，监控的一方对监督策略没有任何影响。

可配置容器

Actor system 可以看做多个actors 的协作整体。这些actors可以通过这个整体单元来共享一些通用组件。例如调度服务、配置、日志服务等等。配置不同的Actor system可以共存在同一个jvm中，这是没有任何问题的。Akka 自己没有什么全局的状态值，这个可以通过不同的Actor system之间的通讯来达到目的。从更大的尺度来讲，Actor system 在一个功能层级中作为构造的一部分。可以看出一个更大尺度上的actor。

Actor 最佳实践

• actors 应该像一个优秀团队一样：高效地做着自己的工作，除了必要的交互外互不打扰，并且尽量少的占用资源。对应技术上来说就是：以事件驱动的方式去处理事件和发出请求。除非万不得已，actors不应该在一些外部请求上阻塞，例如锁、一个网络socket等等。

• actors之间不要传递可变对象。这意味着传递的消息对象最好是不可变对象。否则，一旦你把actor的内部状态封装到消息中并发送给另一个actor，如果消息是个可变对象。这个actor的内部状态就有被多个actor同时修改的危险。我们又陷入了共享内存带来的并发危险中。actor模型也变得没有意义了。

• actor是包含状态和行为的容器对象。绝对不能将actor自己的状态暴露给其它的actor。否则会出现上面一条出现的危险。

转载于:https://my.oschina.net/clopopo/blog/141984