2.3 什么是角色？
前面角色系统一节介绍了一群角色如何形成一个层次结构，并且介绍了角色是构建应用程序的最小单位。本节我们将角色拿出来单独介绍，解释一些你在使用它的过程中可能遇到的概念。对于一些更深入的细节，将会在后面的章节中详细介绍。
你可以将角色想象成一个容器，它其中包括状态，行为，一个信箱，子角色以及一个监管策略。所有这些都封装在一个角色引用中。本节的最后介绍一个角色什么时候终结。
2.3.1 角色引用
如下所述，为了更好的发挥角色模式的优势，一个角色对象需要与外部隔离。因此，在外部通过一个角色引用来表示角色对象，这些角色对象引用可以自由的传递而不受约束。这种将对象划分为内部对象和外部引用的好处是可以使下列操作透明化：重启一个角色不需要更新角色引用，角色可以在远程机器上，可以通过完全不同的应用来给角色发消息。并且这样做最重要的好处是，外部的对象永远无法得到角色内部的状态，除非角色不明智的公开了它的信息。
2.3.2 状态
角色对象通常都包含一些变量来表明它当下处于哪个状态。这些变量可以是显示的状态机（例如，使用fsm-scala模型），也可以是一个计数器，一组监听器，甚至等待挂起等。正是这些状态数据使得角色有价值，因此必须保护它们不被其他的角色破坏。好消息是从概念上来讲每个Akka角色对象都有它自己的轻量级线程，而这个线程是与系统的其他部分完全隔离的。这也就意味着你可以放心大胆的写你的角色代码而不用考虑并发的同步问题。
在后台Akka会有一系列的真实线程来运行这一系列的角色，如有些情况下多个角色会共用一个线程。因而一个角色在接下来的调用中可能会被另一个不同的线程所处理。但是无论实现细节是怎么样的，Akka都能确保同时只有一个线程去改变角色的状态。
角色的内部状态对它的行为是至关重要的，如果出现状态不一致将会产生致命的错误。因而，当一个角色失败并被它的监管程序重启时，它的状态将被重新初始化。而这一点也使得系统有了自动恢复的能力。
可选择地，一个角色也可以在重启后通过重新处理那些老的消息来恢复到它重启之前的状态(参考 persisitence-scala)。
2.3.3 行为
每次消息的处理都会与角色当前的行为所匹配。行为指的是一个函数定义的在当前状态下对一条消息所要采取的行动。例如如果这个客户端是经过认证的则转发它的请求，否则拒绝。并且行为可能随着时间的不同而变化，例如，某些客户端可能在后来获得了认证，或者角色先在“不在服务状态”的模式后来又恢复服务了等等。这些变化可能是因为状态变量的变化引起的，也可能是函数在运行时被换出引起的，参考become 和unbecome操作。然而，角色对象重启后都会恢复到构造函数中初始化的行为。
2.3.4 信箱
角色的任务是处理来自其他角色（或者角色系统之外）发来的消息。连通消息发送者和接受着的对象就是信箱：每个角色都有一个信箱，发送者将消息发送到该信箱。消息以发送者发送消息的时间顺序入队，这也就意味着由于发送者在线程上分布的随机性，来自不同角色的消息在运行时没有一个确定的入队顺序。但是同一个发送者发送的消息顺序是一定的。
这里有很多不同的信箱实现方式可供选择，默认的方式是FIFO:消息被处理的顺序和消息入队的顺序相同。通常我们都选择默认的实现方式，但是有些应用程序可能需要对一些消息优先处理。在这种情况下，消息入队的时候就不一定是插在队尾了，而是根据它的优先级插入到对应的位置，优先级特别高甚至可能直接插在队头。当使用这种队列时，消息被处理的顺序决定于该队列的实现算法，并且通常不是FIFO.
Akka不同于其他角色模型实现的一个重要特征是当前的行为必须挨个处理队列里的下一个消息，它并不会去扫描信箱以得到一个匹配的消息。无法处理消息就会被认为是失败，除非当前的行为是忽略此消息。
2.3.5 子角色
每个角色都是一个潜在的监督员：一旦它创建了子角色并且赋予了它一个子任务，那么它将自动监管这些子角色。角色在它的上下文环境(context)中维持着一个子角色列表，以便随时访问它们。角色通过创建(context.actorOF(…))或停止(context.stop(child))命令来修改这个列表。并且这个修改立马就会生效。这个创建和终止命令是以异步的方式实现的，所以它不会阻塞监督者。
2.3.6 监督者策略
角色最后一个功能是处理子角色的故障。故障处理对于用户来说是透明的，对于发生的故障Akka都会自动的通过对应策略处理（监管和监测章节介绍）。 因为这些策略是构成角色系统的基础，所以一旦角色被创建那么这些故障处理策略将不可改变。
由于每个角色都只有一类故障处理策略，这也就意味着不同的子角色将会应用不同的策略。角色根据子角色所使用的故障处理策略将它们分组。根据任务被切分的子任务性质系统会不断的重复这个分组过程。
2.3.7 什么时候角色终止
一旦角色终止，如失败后无法重启，自己停止或者被监督者停止，那么它将释放它占有的所有资源，并将它信箱中没处理的消息发送到“死信件信箱”里，然后“死信件信箱”将会把他们以DeadLetters的形式传递给EventStream. Actor引用中的信箱将会被一个系统信箱所取代，然后将所有消息以DeadLetters的形式转发给EventStream。虽然系统会尽最大努力来实现该消息传递，但是我们不能依赖它来实现“有保证的传递”。
为什么不选择悄悄的将所有消息倾倒出来，是基于我们下面的测试结果考虑：我们在事件总线（BUS）上注册了测试事件监听器(TestEventListener)。这里事件总线即死信件被发送到的地方。该监听器将会对收到的每条死信件记录一条警告日志——这个可以帮助我们更快的检测失败。所以我们有理由相信这个特征还将可以应用于其他目的。
译者注：本人正在翻译AKKA官网文档，本篇是文档第二章，欢迎有兴趣的同学加入一起翻译。更多内容请读这里：https://tower.im/projects/ac49db18a6a24ae4b340a5fa22d930dc/todos/640e53d6e8c149ab95c47cd333b91073/
（全文完）如果您喜欢此文请点赞，分享，评论。