Akka Stream流量描述中的实时资源

Question

akka-stream docs中有这样的说明如下：

  

...可重用的流描述不能绑定到“实时”资源，这些资源的任何连接或分配必须推迟到实现时间。 “实时”资源的示例是已经存在的TCP连接，多播发布者等; ......

我对这个说明有几个问题：

• 除了这两个例子之外，还有什么其他资源可以作为直播？
  • 任何无法安全（深入）复制的内容？像Thread一样？
  • 我是否还应该避免分享任何不是线程安全的东西？
• ActorRef使用的ActorSystem中存在ActorFlowMaterializer怎么样？
• 如何推迟分配直到实现时间？例如，在PushPullStage的构造函数中分配它而不是FlowGraph的创建函数中是否安全？

Answer 1

如果我们考虑Web服务，RMI连接或任何其他通信协议，这里的问题是一个常见问题。总是建议共享“原始”值然后引用，因为编组/解组或序列化/反序列化总是令人头痛。还要考虑不同类型的环境相互通信。共享可靠的价值是解决沟通的安全方式。

Akka本身就是“微服务”彼此沟通的好例子。当我阅读Akka的文档时，一个好词很好地定义了Akka演员。 Actor就像邮箱客户端，你可以想到每个客户端都有一个邮箱。传递变量时，就像你收到一封新邮件一样。

长篇故事的短暂结果，避免在从另一个演员读取之前共享可能无效的“依赖”对象。此外，如果您的系统动态命名为actorRefs，请避免通过其引用调用它们。

“实现”在akka-streams的文档中进行了解释。

  

实现过程可以参数化，例如实例化处理TCP连接数据的蓝图，其中包含有关连接地址和端口信息的特定信息。此外，实现通常会创建特定对象，这些对象在处理引擎运行后与处理引擎交互时非常有用，例如用于关闭处理引擎或提取指标。这意味着实现功能从外部获取一组参数，并产生一组结果。组合性要求这两个集合不能交互，因为这会建立一个隐蔽的通道，不同的部分可以通过这个通道进行通信，从而导致初始化顺序和难以理解的运行时故障问题。

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

推迟实时资源并不是一个很重要的想法。这意味着如果您为所有系统使用一个连接，则应始终保持活动状态。或者当你在actor-1中创建一个事务并将它发送给actor-2时，你不应该终止actor-1中的事务，直到actor-2用事务完成它的作业。

然后你怎么理解？然后使用“Future”和“offer（）”。

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