分布式技术原理与算法解析
聂鹏程
智载云帆CTO,前华为分布式Lab资深技术专家
立即订阅
5969 人已学习
课程目录
已更新 36 讲 / 共 34 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 四纵四横,带你透彻理解分布式技术
免费
01 | 分布式缘何而起:从单兵,到游击队,到集团军
02 | 分布式系统的指标:啥是分布式的三围
第一站:分布式协调与同步 (6讲)
03 | 分布式互斥:有你没我,有我没你
04 | 分布式选举:国不可一日无君
05 | 分布式共识:存异求同
06 | 分布式事务:All or nothing
07 | 分布式锁:关键重地,非请勿入
08 | 分布式技术是如何引爆人工智能的?
第二站:分布式资源管理与负载调度 (6讲)
09 | 分布式体系结构之集中式结构:一人在上,万人在下
10 | 分布式体系结构之非集中式结构:众生平等
11 | 分布式调度架构之单体调度:物质文明、精神文明一手抓
12 | 分布式调度架构之两层调度:物质文明、精神文明两手抓
13 | 分布式调度架构之共享状态调度:物质文明、精神文明多手协商抓
14 | 答疑篇:分布式事务与分布式锁相关问题
第三站:分布式计算技术 (4讲)
15 | 分布式计算模式之MR:一门同流合污的艺术
16 | 分布式计算模式之Stream:一门背锅的艺术
17 | 分布式计算模式之Actor:一门甩锅的艺术
18 | 分布式计算模式之流水线:你方唱罢我登场
第四站:分布式通信技术 (4讲)
19 | 分布式通信之远程调用:我是你的千里眼
20 | 分布式通信之发布订阅:送货上门
21 | 分布式通信之消息队列:货物自取
22 | 答疑篇:分布式体系架构与分布式计算相关问题
第五站:分布式数据存储 (5讲)
23 | CAP理论:这顶帽子我不想要
24 | 分布式数据存储系统之三要素:顾客、导购与货架
25 | 数据分布方式之哈希与一致性哈希:“掐指一算”与“掐指两算”的事
26 | 分布式数据复制技术:分身有术
27 | 分布式数据之缓存技术:“身手钥钱”随身带
特别放送 (3讲)
特别放送 | 分布式下的一致性杂谈
特别放送 | 徐志强:学习这件事儿,不到长城非好汉
特别放送 | 那些你不能错过的分布式系统论文
第六站:分布式高可靠 (5讲)
28 | 分布式高可靠之负载均衡:不患寡,而患不均
29 | 分布式高可靠之流量控制:大禹治水,在疏不在堵
30 | 分布式高可用之故障隔离:当断不断,反受其乱
31 | 分布式高可用之故障恢复:知错能改,善莫大焉
32 | 答疑篇:如何判断并解决网络分区问题?
分布式技术原理与算法解析
登录|注册

17 | 分布式计算模式之Actor:一门甩锅的艺术

聂鹏程 2019-10-30
你好,我是聂鹏程。今天,我来继续带你打卡分布式核心技术。
我在前两篇文章中,带你一起学习了 MapReduce 和 Stream 计算模式,相信你对批处理和流计算也有了一定的了解。虽然这两种计算模式对数据的处理方式不同,但都是以特定数据类型(分别对应静态数据和动态数据)作为计算维度。
在接下来两篇文章中,我将从计算过程或处理过程的维度,与你介绍另外两种分布式计算模式,即 Actor 和流水线。分布式计算的本质就是在分布式环境下,多个进程协同完成一件复杂的事情,但每个进程各司其职,完成自己的工作后,再交给其他进程去完成其他工作。当然,对于没有依赖的工作,进程间是可以并行执行的。
你是不是想说,分布式进程那么多,如果需要开发者自己去维护每个进程之间的数据、状态等信息,这个开发量可不是一般得大,而且特别容易出错。那么,有没有什么办法可以让开发者只关注自己的逻辑呢?
答案是肯定的,Actor 计算模式就能满足你的需求。也就是说,你可以把数据、状态等都扔给 Actor。这是不是“一门甩锅的艺术”呢?
接下来,我们就一起打卡分布式计算模式中的 Actor 模式。

什么是 Actor?

在第 10 篇文章“分布式体系结构之非集中式结构:众生平等”中,我曾提到 Akka 框架基于 Actor 模型,提供了一个用于构建可扩展的、弹性的、快速响应的应用程序的平台。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《分布式技术原理与算法解析》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(12)

  • LDxy
    Actor 模型不适用于对消息处理顺序有严格要求的系统。因为在 Actor 模型中,消息均为异步消息,无法确定每个消息的执行顺序。虽然可以通过阻塞 Actor 去解决顺序问题,但显然,会严重影响 Actor 模型的任务处理效率。
    2019-10-30
    5
  • 胖虎
    阻塞则需要锁,actor本来的目的就是去锁化,与初衷背道而驰。
    2019-12-09
  • _______Harvey凝枫😗
    全程都是在通信呢,跟计算有啥关系?
    为什么这个算是计算模式的内容,而不是通信技术
    2019-11-16
  • 一毛钱
    如果使用阻塞的形式,各个actor会发生雪崩的现象,导致整个系统不可用
    2019-11-14
  • Ethan Liu
    为什么认为Actor模式是计算模式呢?感觉更属于通信模式啊
    2019-11-11
  • starnavy
    我觉得如果要保证消息处理顺序不一定要阻塞actor吧。每个actor都是单线程,只要每个actor都只有一个instance,那即便是异步处理也能保证消息处理顺序。这就像是消息队列,只要保证一个partition只有一个consumer在consume消息,这个partition的消息就可以保证顺序。
    而且这个时候阻塞actor也没有用,因为下游的actor不会给一个response来确认消息已被成功处理。因为actor model里面本来大家都是异步的,是没有response机制的。
    2019-11-10
  • Geek_21afdb
    参考zeromq,一样能够实现同步调用,虽然阻塞,但可以通过异步时间模型
    2019-11-09
  • 随心而至
    我理解得是,Actor用mailbox(队列)就是方便存放暂时无法处理的消息;如果变成阻塞的这个mailbox元素个数就始终为1,那么这个mailbox还有存在的必要吗。

    用JUC做类比,有ThreadPoolExecutor,用线程池加队列来高效处理任务;也有Exchanger这样一个线程生成一个消息,另一个才可以消费消息。

    总之,利用合适的工具做合适的事,不能拿着锤子,看着什么都是钉子。
    2019-11-02
  • 阿卡牛
    没接触过分布式的相关知识,看完有点不明觉厉
    2019-10-31
    1
  • tt
    是不是如果采用阻塞方式的话,比如有一个Actor发生阻塞,那与之关联的其它Actor为了等待任务的完成也会发生阻塞。因为Actor组成的网络结构是动态的,并没有一个预定的结构,因此会导致两个结果:

    1、为了完成任务,被动阻塞的Actor新建Actor导致网络野蛮生长。

    2、或者Actor的阻塞发生链式反应,最终导致整个系统可用性大幅下降。

    异步方式就是为了解耦各个Actor,如果采用阻塞的模型,就与这个初衷南辕北辙了吧。

    另外,感觉Actor模型和高并发网络编程中的reactor模型很像,虽然reactor模型不是分布式的,但是思路很像。
    2019-10-30
  • Jackey
    简单思考了一下,Actor采用阻塞方式执行的话,很有可能出现多个Actor向一个Actor发消息,如果某个Actor发送的消息较大,或执行计算时被阻塞,后面的Actor再发送消息都会被阻塞,系统可用性就大大降低。
    ps:跟着老师不仅能学分布式知识,还可以学到程序员必备技能—甩锅😂
    2019-10-30
  • xingoo
    有点抓不住问题的关键点,感觉问的很模糊。

    阻塞执行没啥不可以吧,效率低点而已,比如每个actor多线程调用队列中的任务,然后阻塞等待其他的actor,(不知道有没有这种用法)跟普通的分布式没啥区别。

    不过actor得目标就是快速分布式计算,如果阻塞导致整体任务卡死,那就不如不要用他了。
    2019-10-30
收起评论
12
返回
顶部