1. akka-actor：RoutingActor + BusinessActor 路由模式#

核心问题：百万级任务并发汇报状态时，多线程并发会导致状态机错乱。例如按序收到以下消息：

1
msg1: Instance=100 running
2
msg2: Instance=101 running
3
msg3: Instance=102 failed
4
msg4: Instance=101 success
5
msg5: Instance=100 failed

如果用线程池并发处理，Instance=100 可能先变成 failed、最后才变成 running，导致状态机错误。而加锁又会带来性能瓶颈和死锁风险。

SchedulerX 的解决方案：

1
JobInstanceRoutingActor (路由 Actor)
2
  ├── JobInstanceActor(instanceId=100)  ← 同一 instance 的消息串行处理
3
  ├── JobInstanceActor(instanceId=101)
4
  ├── JobInstanceActor(instanceId=102)
5
  └── ...

• RoutingActor 负责消息路由，将相同 instanceId 的消息发给同一个 BusinessActor
• AKKA 保证单个 Actor 按消息接收顺序处理 → 状态机消息天然有序，无需加锁
• 不同 instance 的消息由不同 Actor 处理 → 互不阻塞，实现高并发

这个模式在 SchedulerX 中被大量复用，支撑 job、workflow、instance 等各类消息传递场景。

2. akka-eventbus：解耦的 Pub-Sub 工作流引擎#

为什么要替换 Guava EventBus？

Guava EventBus 并发消费时暴力地共用一个线程池。在调度场景中，某个高频任务会占满整个线程池，导致其他任务饿死。

SchedulerX 的方案：

定时调度器、工作流引擎、任务状态机等模块全部由 akka-eventbus 管理，每个模块内部采用 RoutingActor + BusinessActor 模型：

1
                    ┌─ 定时调度器 (RoutingActor + BusinessActors)
2
                    │
3
akka-eventbus ──────┼─ 工作流引擎 (RoutingActor + BusinessActors)
4
                    │
5
                    └─ 任务状态机 (RoutingActor + BusinessActors)

• 所有 Actor 通信只需给事件总线发消息，每个 Actor 只订阅自己关心的事件
• 避免了 Actor 之间的网状通信结构，新增模块不会漏掉通信
• 每个 Actor 拥有独立 Mailbox，相同 job 交给同一个 Actor 处理，不会阻塞其他 Actor

3. akka-remoting：极简的跨进程通信#

SchedulerX 是 Server-Worker 架构，Server ↔ Worker、Worker ↔ Worker 都需要通信。akka-remoting 是 P2P 模式，每个节点暴露远程地址，其他节点知道地址即可通信。

关键优势：远程 Actor 和本地 Actor 接口一致，保持编程模型的高度统一。

Server 端配置（akka-server.conf）：

1
akka {
2
  actor {
3
    provider = "akka.remote.RemoteActorRefProvider"
4
  }
5
  remote {
6
    enabled-transports = ["akka.remote.netty.tcp"]
7
    netty.tcp {
8
        port = 52014
9
    }
10
  }
11
}

Server 端启动 remote actor（2 行代码）：

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

Worker 端与 server 通信（2 行代码）：

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

对比 SchedulerX 1.0 使用原生 Netty 需要大量样板代码（编解码器、连接管理、线程模型、序列化等），2.0 用 akka-remoting 大幅降低了开发复杂度。

4. akka-persistence：At-Least-Once Delivery 消息可靠投递#

问题场景：AKKA 默认消息是 at-most-once（tell 失败不重发）。在调度场景中，Worker 执行成功后汇报状态时 Server 正好重启 → 汇报丢失 → 工作流下游全部卡住。

SchedulerX 的方案：继承 UntypedPersistentActorWithAtLeastOnceDelivery（为了兼容低版本 JDK，用了 AKKA 2.4.x）

这一方案结合了两个能力：

• UntypedPersistentActor：消息持久化、Actor 恢复能力
• AtLeastOnceDelivery：deliver + confirmDelivery 语义保证

完整投递流程：

1
Worker                              Server
2
  │                                   │
3
  │  deliver(request + deliveryId)    │
4
  │ ───────────────────────────────→ │
5
  │                                   │
6
  │  response(含 deliveryId)          │
7
  │ ←─────────────────────────────── │
8
  │                                   │
9
  │  confirmDelivery(deliveryId)      │
10
  │  (从 unconfirmed 列表移除)        │
11
  │                                   │
12
  // 若未确认，AtLeastOnceDelivery
13
  // 内部 timer 定期重试

1. tell 改为 deliver，自动生成 deliveryId 封装进 request
2. Server 收到后把 deliveryId 封装到 response 返回
3. Worker 收到 response 调用 confirmDelivery，从 unconfirmed 列表移除
4. 若未确认，AtLeastOnceDelivery 内部 timer 定期重试

5. Worker 端三层架构（参考 YARN）#

在 AKKA Actor 模型之上，SchedulerX Worker 端设计了类 YARN 的三层架构：

1
┌─────────────────────────────────────────────┐
2
│                  Processor                   │  业务逻辑层（不同任务类型）
3
├─────────────────────────────────────────────┤
4
│                  Container                   │  执行容器（线程/进程/Docker/Actor）
5
├─────────────────────────────────────────────┤
6
│                 TaskMaster                   │  生命周期管理 + 资源管理 + Failover
7
└─────────────────────────────────────────────┘

• TaskMaster（类似 YARN AppMaster）：管理 jobInstance 生命周期、Container 资源调度、故障转移
  • StandaloneTaskMaster（单机）
  • BroadcastTaskMaster（广播）
  • MapTaskMaster（并行计算/内存网格/网格计算）
  • MapReduceTaskMaster（MapReduce）
• Container：通过 ContainerRoutingActor → ContainerActor 执行（同样是 AKKA Router 模式的应用），支持线程/进程/Docker/Actor 多种容器
• Processor：用户实现的业务逻辑（如 MapReduceJobProcessor、JavaProcessor）

选型背景#

SchedulerX 作为分布式任务调度平台，面临的核心技术挑战：

• 百万级任务、每天上亿次调度
• 任务状态机需要严格的消息顺序性
• Server-Worker 跨进程通信
• 消息不能丢（工作流卡住 = 线上事故）
• 模块间解耦（定时器、工作流引擎、状态机互相不干扰）

这些需求可以归纳为一个核心诉求：需要一套完整的分布式并发编程基础设施。

方案一：原生 Netty（SchedulerX 1.0 的方案）#

SchedulerX 1.0 就是用 Netty 做通信的，这正是 2.0 要换掉的东西。

结论：Netty 只是网络层框架，调度平台需要的并发控制、状态机、消息可靠性等全要自己造轮子。SchedulerX 1.0 就踩了这个坑。

方案二：RxJava / Project Reactor#

结论：RxJava/Reactor 适合数据流处理（如 Web 请求的响应式管道），但没有分布式能力，也没有内置的状态管理和消息持久化。做一个分布式调度系统，还需要在它之上再搭很多东西。

方案三：gRPC#

结论：gRPC 是个优秀的 RPC 框架，但只是通信层。而且 gRPC 的请求-响应模型对调度系统内部的事件驱动模式不够友好——调度系统更多是单向通知、状态推送，而非 RPC 调用。

方案四：纯线程池 + Disruptor#

结论：单机极限性能可能更高，但分布式能力完全缺失，且共享状态的并发编程在大规模系统中极易出错。

AKKA 的决定性优势#

综合对比后，AKKA 胜出的根本原因可以用一句话概括：

AKKA 是唯一一个同时提供并发模型 + 分布式通信 + 状态持久化 + 消息可靠投递的 JVM 框架。

具体来说：

1. 一站式解决方案，而非拼积木

其他方案只解决一个问题（Netty 解决通信、RxJava 解决流处理、Disruptor 解决队列），而 SchedulerX 需要全部能力。用其他方案意味着把 Netty + RxJava + ZooKeeper + 自研状态机拼在一起，集成复杂度和维护成本极高。AKKA 一个生态就把这些都覆盖了。

2. Actor 模型天然解决状态机并发问题

百万任务并发汇报状态：线程池方案需要加锁，锁粒度不好控制，容易死锁或性能差；Actor 方案中同一个 instanceId 路由到同一个 Actor，单线程串行处理，消息天然有序，无需加锁。AKKA 官方保证：一个 Actor 按消息接收顺序处理消息。

3. 本地 Actor 和远程 Actor 接口一致

1
// 本地通信
2
actorSystem.actorOf(HelloActor.props(), "hello");
3

4
// 远程通信 — 代码模型完全一样，只是地址不同
5
context.actorSelection("akka.tcp://server@xx.xx.xx.xx:52014/user/hello");

SchedulerX 的 Worker 本地调度和跨进程通信用同一套编程模型，大幅降低复杂度。

4. 内置 At-Least-Once Delivery

其他框架要么没有（需要自己实现重试 + 持久化），要么实现起来很容易出错。AKKA 的 AtLeastOnceDelivery 把 deliver → confirm → 重试的整个机制封装好了，SchedulerX 只需要继承即可。

5. EventBus 解决模块解耦

AKKA 原生提供了基于 Actor 的 EventBus，不需要额外引入 Guava EventBus 或自己实现观察者模式。且因为是 Actor 级别的订阅，天然解决了”高频任务占满线程池”的问题——每个 Actor 有独立的 Mailbox。