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

  1. 云栖社区>
  2. 博客>
  3. 正文

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

gabrywu 2018-06-05 09:34:00 浏览790

 

作者属于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解决。