Actor 模型中的通信模式
作者：互联网
在 Actor 模型中所有的 Actor 之间有且只有一种通信模式，那就是 tell 的方式，也就是 fire and forget 的方式。但是在实际的开发过程中工程师们逐渐总结出了一些常用的通信模式。本文以 akka-typed(2.6.0-M8) 框架为例，介绍存在于 actor 模型中最基本的一些通信模式，讨论消息是如何在 actor 之间流动的。
Fire and Forget
我们首先看到最基础的模式 fire and forget 即发送后遗忘。这种模式是直观地尝试向一个 actor 发送一条消息后就不再关心这次通信。此处的发送消息仅保证到 fire 的发送，即消息以发出，但是可能由于网络原因被丢失。这种通信模式使用的是所谓的 at most once 送达语义。
在给出一个可运行的代码例子之前，我们简单介绍一下 akka-typed 框架这个 actor 模型的特定实现。在 akka-typed 中，消息的传输是通过 ActorRef<T> 的引用来进行的，ActorRef 是为位置透明的 actor 的引用，T 表示了 actor 能接收的消息类型。这点跟典型的 actor 模型有所不同。这是因为典型的 actor 模型是非确定性的，实现为 akka untyped 那样的框架，即任意 actor 都可以接受任意类型的信息，并且因此能够通过 become/unbecome 来改变自己的行为（behavior）。在 akka-typed 中通过带有类型标签的引用，保证调用 actorRef.tell(message) 的时候不会意外的传递错误的信息，同时类型信息有助于推理代码，而不是在一堆任意引用任意类型的 ActorRef 和 Object 类型的消息中费力的分析。一个对应的缺点就是无法实现任意灵活度的 become/unbecome，如果需要实现类似状态机的功能，需要加入额外的域并且在 Behaviors 中针对状态分别讨论，但所有能接受的消息都必定是 T 的类型。
import akka.actor.typed.ActorRef;
import akka.actor.typed.ActorSystem;
import akka.actor.typed.Behavior;
import akka.actor.typed.javadsl.Behaviors;
import java.util.concurrent.CountDownLatch;
public class FireAndForget {
public static final CountDownLatch LATCH = new CountDownLatch(2);
public static class PrintMe {
public final String message;
public PrintMe(String message) {
this.message = message;
}
}
public static final Behavior<PrintMe> printerBehavior =
Behaviors.receive((ctx, printMe) -> {
ctx.getLog().info(printMe.message);
LATCH.countDown();
return Behaviors.same();
});
public static void main(String[] args) throws Exception {
ActorSystem<Void> system = ActorSystem.create(Behaviors.setup(ctx -> {
ActorRef<PrintMe> printer = ctx.spawn(printerBehavior, "printer");
printer.tell(new PrintMe("message 1"));
printer.tell(new PrintMe("message 2"));
return Behaviors.ignore();
}), "fire-and-forget");
LATCH.await();
system.terminate();
}
}这里需要用 CountDownLatch 来同步保证消息送达后再关闭 ActorSystem，否则由于执行顺序没有保证，很有可能在看到 log 打印之前由于 ActorSystem 的关闭 printer actor 被停止，从而后续被调度的消息传递失败。由此也可以看出 fire and forget 的方式仅保证在 tell 的调用点发出消息，至于消息能不能送到，会被怎么处理，发送方就不管了。
Request-Response
请求-响应模式是另一种非常常见的通信模式，即 actor-1 向 actor-2 发送消息，actor-2 收到消息后向 actor-1 返回相应的消息。注意这里我们只提到了消息的发送，两个方向均是 fire and forget 的，actor-1 收到的 actor-2 的消息跟它收到的任何一条其他信息没有任何区别。除非 actor-2 发回的消息中携带有跟回应相关的信息，否则 actor-1 并不知道这条消息就是回应刚才发送的某一条信息的。此外，特化到 akka-typed 中，甚至由于消息中不再天然包括 sender 信息，actor-1 并不知道这条消息是 actor-2 发过来的，必须在消息中显式的包含所有需要的信息。
由于 request 和 response 是松耦合的，这和我们下面要讲到的使用 ask pattern 的模式不同，不能作为面向对象编程在 actor 模型中的投影。
import akka.actor.typed.ActorRef;
import akka.actor.typed.ActorSystem;
import akka.actor.typed.Behavior;
import akka.actor.typed.Terminated;
import akka.actor.typed.javadsl.Behaviors;
import scala.runtime.Nothing$;
@SuppressWarnings("WeakerAccess")
public class RequestResponseTypedActors {
public static final class Request {
public final String message;
public final ActorRef<Response> replyTo;
public Request(String message, ActorRef<Response> replyTo) {
this.message = message;
this.replyTo = replyTo;
}
}
public static final class Response {
public final String message;
public Response(String message) {
this.message = message;
}
}
private static final Behavior<Request> responder = Behaviors
.receiveMessage(request -> {
System.out.println("got request: " + request.message);
request.replyTo.tell(new Response("got it!"));
return Behaviors.same();
});
private static Behavior<Response> requester(ActorRef<Request> responder) {
return Behaviors
.setup(ctx -> {
responder.tell(new Request("hello", ctx.getSelf()));
return Behaviors.receiveMessage(response -> {
System.out.println("got message " + response.message);
return Behaviors.stopped();
});
});
}
public static void main(String[] args) {
ActorSystem.create(Behaviors.setup(ctx -> {
ActorRef<Request> res = ctx.spawn(responder, "responder");
ActorRef<Response> req = ctx.spawn(requester(res), "requester");
ctx.watch(req);
return Behaviors.receiveSignal((context, sig) -> {
if (sig instanceof Terminated) {
return Behaviors.stopped();
} else {
return Behaviors.unhandled();
}
});
}), "ReqResTyped");
}
}可以看到，responder 收到 requester 的消息中包含了 requester 的地址，因此可以发送回传信息。requester 之所以知道 responder 的地址是由开发者在创建 requester 的时候直接告诉它的。这样一个显然的问题就是 requester 是怎么天生地知道 responder 的地址的呢？在分布式系统中，这可以通过预配置固定地址或名称服务来达到这个目的。在 akka-typed 中，通过 ActorSelection 使用 actor 地址寻址的方式已经很难做到的（除非先用 untyped 强行获取再转回去，非常复杂而且 hacky），主要是通过 Receptionist 的名称服务来实现的。这个服务在 cluster 模式下要求必须使用 akka-cluster-typed，实在颇有些臃肿。
Query
这里提到的 Query 模式即是所谓的 ask 模式，也即发送一个消息后等待一个绑定到该消息上的回应。由于网络的滞后性和不确定性，阻塞地等待这个回应不仅会造成性能问题，更有可能由于回应消息的丢失或目标机器宕机而使得当前系统不可用。为此，我们需要解耦请求和响应的过程，将本地返回的类型从直接的结果值变为包裹在 Future 中的值。然后，请求方的业务流程提升到 Future 域中，使用变换组合字来组合后续步骤。由于 Future 盒子是立即返回的，当前线程可以继续其他工作，在 Future 值被填充后根据此前组合的步骤执行相应的逻辑。这里顺带提一句，Future 也是函数式编程中著名的概念 Monad 的一个实例，上面这种域的提升和组合的方式是函数式编程中应对状态变化的一种常用手法。
由于返回的是一个 Future，我们需要仔细的讨论这个 Future 完成的条件。首先，抽象地说，这个 Future 会在收到回复的时候完成。但是这个请求回复的双方如果是两个业务 actor 之间完成的话，业务 actor 就需要有一张表来缓存所有的 Future，并且在请求和回复中都带有 Future 的唯一标识符，以在接受到回复时自动的完成 Future。由于 Query 模式不是天生就伴随在 actor 模型里的，而是一个后期总结的设计模式，这么做会导致所有 actor 都承担这一不必要的开销。
因此在 akka 当中采用的方法是，对于一个请求回复周期，使用一个专门的 PromiseActor 来负责和远端的 actor 交互，即请求消息由 PromiseActor 发出，收到回复时也由 PromiseActor 完成其中唯一的专用的 Future。在 akka-typed 中，还额外加入了 createRequest 和 applyToResponse 参数，前者用于将 PromiseActor 的引用传入发送的消息中，后者用于接收回复后适配为上层 actor 能接受的消息类型。
import akka.actor.typed.ActorRef;
import akka.actor.typed.ActorSystem;
import akka.actor.typed.Behavior;
import akka.actor.typed.javadsl.AskPattern;
import akka.actor.typed.javadsl.Behaviors;
import java.time.Duration;
import java.util.concurrent.CompletableFuture;
public class Ask {
public static class Pong { }
public static class Ping {
public final ActorRef<Pong> replyTo;
public Ping(ActorRef<Pong> replyTo) {
this.replyTo = replyTo;
}
}
public static final Behavior<Ping> pongBehavior =
Behaviors.receiveMessage(ping -> {
ping.replyTo.tell(new Pong());
return Behaviors.stopped();
});
public static void main(String[] args) {
ActorSystem system = ActorSystem.create(Behaviors.setup(ctx -> {
ActorRef<Ping> ref = ctx.spawn(pongBehavior, "pong");
CompletableFuture<Pong> future = AskPattern.ask(
ref,
Ping::new,
Duration.ofMillis(2000L),
ctx.getSystem().scheduler()).toCompletableFuture();
future.whenComplete((pong, throwable) -> {
ctx.getLog().info("pong={}, throwable={}", pong, throwable);
ctx.getSystem().terminate();
});
return Behaviors.ignore();
}), "ask");
}
}关于 ask 模式还有一个特别需要注意的点，即如果在 actor 中使用 AskSupport 的 ask，实际上这个 ask 中会有一个 spawn 出来的 PromiseActor。这一点在上面已经提过了，但是绝对值得再强调一遍。因为当你在 actor-1 中使用 AskSupport 应用 ask 模式和 actor-2 通信时，实际通信的是 PromiseActor。因此，akka 提供的关于两个 actor 之间消息的有序性对于这第三个 actor PromiseActor 是不成立的。这有可能导致非常微妙的并发竞争。
Pipe 和 Aggregate
最后简单提及两种消息流模式 Pipe 和 Aggregate，这两种模式经常配合 ask 模式使用。
Pipe 模式将一个 Future 在完成时发送到另一个 actor 上，其基本形式为 pipe(future, replyTo)，经常用于 actor-1 向 actor-2 请求，actor-2 进而向 actor-3 请求，随后在 actor-2 中将向 actor-3 请求的 future pipe 到 actor-1 的回复中。举个例子，actor-1 是 client，actor-2 是数据库前端，actor-3 是数据库后端。
Aggregate 模式可以视为 Ask 模式的一个自然扩展。Ask 模式一次只能处理一个请求及其回应，而 Aggregate 模式简单的扩展到一个显式创建的子 actor 来处理多个请求响应，非常直观。
标签：Behaviors,typed,模型,通信,Actor,actor,message,akka,public 来源： https://www.cnblogs.com/tisonkun/p/11622304.html