《Akka应用模式：分布式应用程序设计实践指南》读书笔记

作者属于Scala、Akka技术爱好者，但苦于Akka没有关于设计模式的文章，偶尔搜到《Akka应用模式》一书，如获至宝。现整理一些读书笔记和自己的感悟，以供参考。

Actor模型

Actor模型感觉还是很给力的，要是按我以前学习actor模型，绝对会对他嗤之以鼻，这玩儿意能干啥。哈哈哈，只能说当时年轻气盛吧。

现实是最终一致的。

作者举了一个例子说明了一下，Actor模型的设计哲学：世界不同信息的交流是异步的。那为啥不基于现实世界来建模，尝试使用异步事件来构造软件系统呢？相信这对于大部分人来说，提供了另一种解决问题的思路。当然，全部都异步毕竟还是很困难的。

结构Actor模型

Actor模型的概念，很早就有了，各个语言都有各自的实现方式。但Actor模型需要遵循以下几个基本规则： * 所有的计算都是在actor中执行的 * actor之间只能通过消息进行通信交流 * 为了响应消息，actor可以进行下列操作 * 更改状态或行为 * 发消息给其他actor * 创建有限数量的子actor

第一点其实还是很好理解的，毕竟把状态和行为封装起来是OOP的设计哲学。但第二点说明了两者的根本区别。在OOP中一个对象与另一个对象的交互是通过对象公开的函数进行的，例如A调用B对象的某个方法就可以改变B对象的状态。但在actor世界中，只能通过消息进行交流。这一点是不是很像现实世界，就好像我跟你说一句话，总不能进入你的脑袋中去告诉听觉系统一样。 神奇的是第三点，为啥神奇呢？因为它没有说明对消息如何响应！如果一个actor只能更改自己的状态或行为、发消息给其他actor、创建有限数量的子actor，那要他有何用呢？哈哈哈，这也是我刚学的时候特别不理解的事情。

actor之间只能通过消息进行通信

这一点在上一节中已经说过了。每个actor都有一个邮箱（类似于消息队列一样），消息被投递到某个actor的邮箱后，actor就可以接收并处理这些消息，但是每次只能接收处理一条消息。what？！这听上去是不是很扯，一次只能处理一个消息，请问如何保持多线程时的效率！这个问题后面再聊，我们先看看他的好处。如果一次只能处理一个消息，那就意味着actor中单线程可以很完美的工作。actor可以自由、任意的修改自己的内部状态，完美的规避了并发的问题。看上去是不是也很扯？只是我刚学的时候也是这样认为的。 其实很多时候，线程、锁、并发无形中增加了系统的复杂性。而大部分程序员不一定能完美解决这个问题，要不然就不会有那么多关于解决死锁的文章了。actor缺消除了这一问题，当然这需要某种机制来保证。这一点后面再说。

actor可以创建子actor

这一点也跟OOP的对象不同。其实我对这一点的理解是，actor的并发问题垂直向下解决了。并发往往意味着多个线程并行执行，即在水平方向上的并发。然后actor可以创建子actor，那么意味着actor之间可以有一定的层级关系，有层级关系就意味着可以相互通信、父actor可以管理子actor（毕竟子actor都是它创建的）。而这种层级关系在故障恢复时非常有用。

actor可以改变自己的状态或行为

这一点跟OOP差不多。actor收到某条消息时可改变自己内部的状态或行为，但OOP中经常会改变状态，行为比较少改变。actor的这种特性在构造FSM时非常有用。

一切都是actor

其实这一点刚开始我理解的不是很清楚。怎么一切都是actor呢？一切都是actor是不是意味着行为也可以是actor呢？Actor基本规则中没有描述对消息的响应在哪里处理，只是说可以发消息给其他actor、创建子actor。这里又说一切都是actor，难道把行为也看成actor，由子actor去处理？嗯，这往往是一种很好的设计模式：某个子actor只接受一个或少量类型的消息，然后做应答，应答后立即销毁自身actor。既然可以创建有限数量的子actor，那就意味着可以并发的处理同类型的很多消息。这是不是把并发的问题垂直化处理了呢。

Actor模型的使用

actor看上去很完美，但也有其使用的场景。使用时需要考虑其使用的基本规范和场景。

定义清晰的边界。

这跟OOP一样，都需要定义清晰的边界。清晰的边界意味着对象或actor封装的足够好，实例之间只能通过接口或者消息进行通信，也就是高内聚低耦合。无论从业务上还是技术上，都会是一件完美的事情。

何时使用Actor模型

• 对高并发有严格要求的同时又需要维护某种状态。毕竟维持并发状态是Actor模型里面最基本的属性。

• 构建有限状态机

• 需要高并发，同时也需要很小心的管理并发。

上面是书籍作者列举的三种情况，但并不限于此。其实简单点来说，需要处理高并发，又需要正确的维护某种状态时，就可以用actor。当然了对于我来说，那就是用actor解决一切高并发的问题，如果不能解决，那就是我的actor设计的不够好。哈哈哈，我相信以目前的工作内容来看，并发的问题全都可以用actor解决。

本文转载自异步社区

原文链接：https://www.epubit.com/articleDetails?id=N69305dec-89f2-411c-aa82-8208a0eeaef0