java - Akka Stream 中直播资源流程说明

Question

在 akka-stream docs 中有这个注释说明如下:

… a reusable flow description cannot be bound to “live” resources, any connection to or allocation of such resources must be deferred until materialization time. Examples of “live” resources are already existing TCP connections, a multicast Publisher, etc.; …

我有几个关于笔记的问题:

• 除了这两个例子，还有哪些资源可以算作直播？
  • 有什么不能安全(深度)复制的吗？像一个线程？
  • 我还应该避免共享任何非线程安全的东西吗？
• ActorFlowMaterializer 使用的 ActorSystem 中存在的 ActorRef 怎么样？
• 如何将分配推迟到实现时间？例如，在 PushPullStage 的构造函数中而不是在 FlowGraph 的创建函数中分配它是否安全？

Answer 1

如果我们考虑 web 服务、RMI 连接或任何其他通信协议(protocol)，这里的问题是一个常见问题。始终建议共享“原始”值然后引用，因为编码/解码或序列化/反序列化总是令人头疼。还要考虑相互通信的不同类型的环境。分享坚实的值(value)观是解决沟通的安全方法。

Akka 本身就是“微服务”相互通信的一个很好的例子。当我阅读 Akka 的文档时，一个好词很好地定义了 Akka actors。 Actor 就像邮箱客户端，您可以认为每个客户端都有一个邮箱。当你传递一个变量时，就好像你收到了一封新邮件。

长话短说，避免共享“依赖”对象，这些对象在从其他参与者读取之前可能会失效。此外，如果您的系统动态命名 actorRefs，请避免通过引用调用它们。

“物化”在 akka-streams 的文档中有解释。

The process of materialization may be parameterized, e.g. instantiating a blueprint for handling a TCP connection’s data with specific information about the connection’s address and port information. Additionally, materialization will often create specific objects that are useful to interact with the processing engine once it is running, for example for shutting it down or for extracting metrics. This means that the materialization function takes a set of parameters from the outside and it produces a set of results. Compositionality demands that these two sets cannot interact, because that would establish a covert channel by which different pieces could communicate, leading to problems of initialization order and inscrutable runtime failures.

所以使用参数而不是传递“连接”本身。

推迟直播资源并不是什么大事。这意味着如果您为所有系统使用一个连接，您应该始终保持它处于 Activity 状态。或者当您在 actor-1 中创建一个事务并将其发送给 actor-2 时，您不应该在 actor-2 完成其事务工作之前终止 actor-1 中的事务。

那怎么理解呢？然后你使用“Future”和“offer()”。

希望我理解你的问题并希望我能表达自己的意思。