文档章节

Akka in Schedulerx2.0

阿里云云栖社区
 阿里云云栖社区
发布于 07/22 12:22
字数 1774
阅读 8
收藏 0

1. 前言

Schedulerx2.0是阿里中间件自研的基于akka架构的新一代分布式任务调度平台,提供定时、任务编排、分布式跑批等功能,具有高可靠、海量任务、秒级调度等能力。

本篇文章以Schedulerx2.0为例子,介绍akka的应用场景,希望能给同样从事分布式系统开发的同学一些启发。这里不详细介绍akka,初学者可以直接阅读官方文档(https://doc.akka.io/docs/akka/current/index.html?language=java)。

2. Reactive

说到近几年火热的反应式编程,谁都能说几句“异步、并发、非阻塞、高性能”等等,说到有代表性的项目,大家都知道RxJava、Akka、Reactor。

Why Reactive?
——因为Schedulerx2.0作为任务调度平台,支持海量任务调度,提供任务状态机感知任务状态变化,需要Reactive的特性。

Why Akka?
——首先akka很简单,每个actor只需要实现一个onReceive方法。其次,Akka真的非常强大!我们可以看下官方文档(https://doc.akka.io/docs/akka/current/index.html?language=java),Akka几乎提供了一整套解决方案,使用akka可以很方便的实现一套高可靠、高并发、高性能的分布式系统。Schedulerx2.0也只用到了akka生态圈里的一小部分功能:

  • akka-actor
  • akka-eventbus:实现高性能工作流引擎
  • akka-remoting:实现进程间通信
  • akka-persistence:实现消息的At-Least-Once Delivery

3. Akka-actor in Schedulerx2.0

Schedulerx2.0支持百万级别任务,一天上亿次调度,从架构上来说,主要是
server无状态,可水平扩展
基于akka-actor模型,单机性能高

Schedulerx2.0提供任务状态机,如下图

当有海量任务汇报任务状态,单线程肯定是处理不过来的。如果用线程池又会遇到并发问题,比如当前按顺序收到如下消息:
msg1: Instance=100 running
msg2: Instance=101 running
msg3: Instance=102 failed
msg4: Instance=101 success
msg5: Instance=100 failed
有可能instance=100先变成failed,最后变成running,导致状态机错误。

通过Akka-actor架构的模型,可以很容易处理这种场景:

如上图所示,JobInstanceRoutingActor作为路由actor,用来转发消息。下面挂载了很多jobInstanceActor,用来真实处理消息。
所有instance状态的消息都发给JobInstanceRoutingActor,路由actor会把同一个instanceId的消息发给同一个jobInstanceActor,akka能保证一个actor按照消息接收的顺序来处理消息,以此又能保证整个状态机消息的顺序性。

Schedulerx2.0中,大量采用了上面这种模型,来支撑job/workflow/instance等消息的传递。

4. 基于Akka-eventbus的Pub-Sub模式

在异步处理场景中,当然少不了Pub-Sub模式。相信很多人都用过guava的eventbus,可以很简单很优雅的实现一套基于事件驱动的解决方案。通过@Subscribe注解就能注册要订阅的事件,通过@AllowConcurrentEvents注解还能设置并发消费事件。但是guava-eventbus在实现并发消费事件的时候非常暴力,公用一个线程池。这在Schedulerx2.0的应用场景中不太合适,比如某个job触发频率特别高,可能整个线程池都被他占满了,造成其他job饿死。

在项目中大量使用actor模型之后,如果使用原生的actor通信会发现很困难,因为得知道actor的地址才能和他通信。如果有些actor要给多个actor发送消息,你的项目就会变成一个网状的结构,新增一个actor经常会漏掉一些通信。这个时候我们就会想到Pub-Sub模式,所有actor通信只需要给事件总线发送消息,每个actor只需要订阅自己的事件就好了。

如上图所示,定时调度器、工作流引擎、任务状态机等大部分模块,都由akka-eventbus进行管理,每个模块都是第四节定义的路由actor+业务actor的模型。通过该模型,相同的job交给同一个actor处理,不会堵塞其他actor,同样解决了上文提到的guava-eventbus公用线程池的问题。实现类图如下:

5. 两行代码实现进程间通信

Schedulerx2.0是Server-Worker的架构,server和worker,worker和worker都需要进行通信,使用akka-remoting可以很容易实现任意2个进程之间的通信。

Akka-remoting是peer-to-peer的通信方式,每个节点都会暴露一个远程地址,其他节点只要知道地址,就能进行远程通信。Akka-remoting也抽象成一个actor,会让你的程序保持高度的一致,只不过这个actor的地址是远程的地址而已。Akka-remoting支持多种协议,使用起来非常简单,以netty-tcp为例,首先我们在server端定义一个配置文件akka-server.conf

akka {
  actor {
    provider = "akka.remote.RemoteActorRefProvider"
  }
  remote {
    enabled-transports = ["akka.remote.netty.tcp"]
    netty.tcp {
        port = 52014
    }
  }
}

Server只需要2行代码就可以起一个remote actor

ActorSystem actorSystem = ActorSystem.create("server", akkaConfig);
actorSystem.actorOf(HelloActor.props(), "hello");

Worker也只需要2行代码就能实现和server通信

ActorSelection helloSelection = context.actorSelection("akka.tcp://server@xx.xx.xx.xx:52014/user/hello");
helloSelection.tell("hello",getSelf());

对比Schedulerx1.0使用原生netty框架通信需要如下这么多代码

怎么样,使用akka进行远程通信,是不是非常简单和优雅^^

6. 消息At-Least-Once Delivery

Akka默认的消息传递是最多传递一次,即通过tell,如果发送失败,不会重发。At-Least-Once Delivery,提供了一个消息至少传递一次的语义,即保证不丢!这在Schedulerx2.0中很多场景是非常需要的,比如某个实例在worker执行成功了,汇报成功的时候server正好重启了导致汇报失败,会造成工作流下游都卡住没法继续执行。

使用At-Least-Once Delivery要继承UntypedPersistentActorWithAtLeastOnceDelivery(akka-2.4.x)或者AbstractPersistentActorWithAtLeastOnceDelivery(akka-2.5.x)。Akka在2.5.x为了拥抱函数式编程,只支持java8,并用了很多stream的接口,所以接口和2.4.x已经大大不一样了。在Schedulerx2.0中,worker主要是给用户用的,为了兼容低版本的jdk,所以用了2.4.x版本的UntypedPersistentActorWithAtLeastOnceDelivery。

UntypedPersistentActorWithAtLeastOnceDelivery继承UntypedPersistentActor和AtLeastOnceDelivery。

  • UntypedPersistentActor:提供了持久化的actor,对消息持久化、恢复等能力。
  • AtLeastOnceDelivery:主要是deliver、confirmDelivery(long deliveryId)两个接口。

AtLeastOnceDelivery的原理非常简单,worker向server汇报状态的时候,tell改为deliver,deliver会自动生成一个deliveryId,封装进request发送给server,server需要实现把deliveryId封装到response中并返回给worker,worker收到response的时候调用confiremDelivery,会从unconfirmed列表中移除这个deliveryId的request,否则AtLeastOnceDelivery会有一个timer,定期重试这条request。如下图

 


本文作者:黄晓萌

原文链接

本文为云栖社区原创内容,未经允许不得转载。

© 著作权归作者所有

阿里云云栖社区
粉丝 434
博文 1558
码字总数 3823668
作品 0
朝阳
私信 提问
Akka in Schedulerx2.0

1. 前言 Schedulerx2.0是阿里中间件自研的基于akka架构的新一代分布式任务调度平台,提供定时、任务编排、分布式跑批等功能,具有高可靠、海量任务、秒级调度等能力。 本篇文章以Schedulerx2...

黄晓萌
07/19
0
0
Schedulerx2.0支持MapReduce模型

1. 前言 Schedulerx2.0提供了map模型,通过一个map方法就能将海量数据分布式到多台机器上分布式执行,随着业务方的深入使用,又提出了更多的需求,比如: 监听所有子任务完成的事件 处理所有...

黄晓萌
06/28
0
0
Schedulerx2.0分布式计算原理&最佳实践

1. 前言 Schedulerx2.0的客户端提供分布式执行、多种任务类型、统一日志等框架,用户只要依赖schedulerx-worker这个jar包,通过schedulerx2.0提供的编程模型,简单几行代码就能实现一套高可靠...

黄晓萌
05/30
0
0
如何保证在ActorSystem关闭的时候,所有的ActorRef任务都能执行完?

做过一个实验,把要处理的任务sleep 100ms,然后循环tell10次,也就是onReceiver那里会比较耗时,然后循环tell完之后。立即关闭ActorSystem,会报错,只执行了第一次的任务,后来的几次都没执...

ChangeZ
2017/09/10
481
2
Akka 2.4 M2 发布,Actor 开发模型库

Akka 2.4 M2 发布,此版本包括一些 2.4-M1 的改进: incorporate Patrik’s akka-data-replication under the new module name akka-distributed-data-experimental (see akka-data-replica......

oschina
2015/06/27
1K
4

没有更多内容

加载失败,请刷新页面

加载更多

作为一个(IT)程序员!聊天没有话题?试试这十二种技巧

首先呢?我是一名程序员,经常性和同事没话题。 因为每天都会有自己的任务要做,程序员对于其他行业来说;是相对来说比较忙的。你会经常看到程序员在发呆、调试密密麻麻代码、红色报错发呆;...

小英子wep
今天
15
0
【SpringBoot】产生背景及简介

一、SpringBoot介绍 Spring Boot 是由 Pivotal 团队提供的全新框架,其设计目的是用来简化新 Spring 应用的初始搭建以及开发过程,该框架使用了特定的方式来进行配置,从而使开发人员不再需要...

zw965
今天
5
0
简述并发编程分为三个核心问题:分工、同步、互斥。

总的来说,并发编程可以总结为三个核心问题:分工、同步、互斥。 所谓分工指的是如何高效地拆解任务并分配给线程,而同步指的是线程之间如何协作,互斥则是保证同一时刻只允许一个线程访问共...

dust8080
今天
6
0
OSChina 周四乱弹 —— 当你简历注水但还是找到了工作

Osc乱弹歌单(2019)请戳(这里) 【今日歌曲】 @花间小酌 :#今日歌曲推荐# 分享成龙的单曲《男儿当自强》。 《男儿当自强》- 成龙 手机党少年们想听歌,请使劲儿戳(这里) @hxg2016 :刚在...

小小编辑
今天
3.4K
22
靠写代码赚钱的一些门路

作者 @mezod 译者 @josephchang10 如今,通过自己的代码去赚钱变得越来越简单,不过对很多人来说依然还是很难,因为他们不知道有哪些门路。 今天给大家分享一个精彩的 GitHub 库,这个库整理...

高级农民工
昨天
10
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部