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

简介:  作者属于Scala、Akka技术爱好者,但苦于Akka没有关于设计模式的文章,偶尔搜到《Akka应用模式》一书,如获至宝。现整理一些读书笔记和自己的感悟,以供参考。Actor模型Actor模型感觉还是很给力的,要是按我以前学习actor模型,绝对会对他嗤之以鼻,这玩儿意能干啥。

 

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

目录
相关文章
|
1月前
|
安全 大数据 Go
Go语言在分布式系统中的应用
【2月更文挑战第20天】Go语言,以其独特的语言特性和出色的性能,逐渐成为分布式系统开发领域的热门选择。本文将深入探讨Go语言在分布式系统中的应用,分析其优势及实际应用案例,旨在为开发人员提供有价值的参考与启示。
|
4月前
|
缓存 NoSQL 算法
认真学习分布式应用中的分布式锁
认真学习分布式应用中的分布式锁
43 0
|
4月前
|
消息中间件 Java 应用服务中间件
聊聊分布式高并发应用中的高可用性
聊聊分布式高并发应用中的高可用性
28 0
|
4月前
|
负载均衡 算法 NoSQL
聊聊分布式应用中负载均衡技术和Session一致性
聊聊分布式应用中负载均衡技术和Session一致性
40 0
|
4月前
|
缓存 NoSQL Java
聊聊分布式应用中的缓存方案(一)
聊聊分布式应用中的缓存方案(一)
37 0
|
3月前
|
存储 安全 JavaScript
【分布式技术专题】「授权认证体系」深度解析OAuth2.0协议的原理和流程框架实现指南(授权流程和模式)
在传统的客户端-服务器身份验证模式中,客户端请求服务器上访问受限的资源(受保护的资源)时,需要使用资源所有者的凭据在服务器上进行身份验证。资源所有者为了给第三方应用提供受限资源的访问权限,需要与第三方共享它的凭据。这就导致一些问题和局限:
373 2
【分布式技术专题】「授权认证体系」深度解析OAuth2.0协议的原理和流程框架实现指南(授权流程和模式)
|
2月前
|
Java 数据库连接 API
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)
57 0
|
开发框架 Java 数据库连接
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)(下)
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)
37 0
|
数据库 微服务
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)(上)
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)
41 0
|
15天前
|
存储 分布式数据库
GaussDB分布式与单机模式的比较
【4月更文挑战第7天】GaussDB分布式与单机模式的比较
1612 5

热门文章

最新文章