鉴于：
某种外部源的数据导入。可以按定义大小的块读取数据。例如一次 10 个项目。例如电子邮件。
现在每个块都必须通过一些步骤来转换数据、过滤项目等等。
块或块的项目之间没有关系。处理顺序也不重要
问题
现在我正在考虑如果我使用 akka 来实现最佳的并行化和性能，什么样的结构才是正确的。
1.) 我是否更有可能将所有演员创建为一连串的孩子。所以 importActor 有一个 Child，这是第一步。第一步有第二步作为孩子等等。
或者更有可能有一个 ImportActor 具有所有步骤并在另一个之后调用？
2.) 现在一个actor一次只能处理一条消息。为了使导入过程并行化，我考虑使用PipeTo机制。这是一个好主意吗？有更好的选择吗？
3.) 我会为每个块创建一个像“Import_ Chunk1 _Actor”这样的演员，还是将所有消息推送到单个“ImportActor”？
如果您在 SO 的其他任何地方问这样的问题，您会受到打击。它有点模糊，容易自以为是，所以会尽量客观
我说只需尝试几种方法，而无需花费时间在完成工作的代码上。做脚手架风格的工作真的很快。
1）根据您的描述，您将有一个输入，然后是一些代表“一次 10 个项目”的演员，尽管这些可能只是在路由器后面。因此，在开发过程中，您不必担心有 10 个，只需为一个做，然后使用配置和微小的调整来扩大规模 - 正如您建议的那样，如果您使用任务，您可能只有 1 个演员来完成所有工作。然后在每一个中，我将拥有同一级别的流程。这在很大程度上取决于您此时是否有任何状态。您可以使用 become 语义将参与者锁定到特定的工作流程中，您可以只处理在任务中启动下一个状态的消息，继续告诉参与者执行下一阶段。我认为你对儿童演员的建议是最没有吸引力的。
Actor 一次只处理一条消息，因此如果您希望它具有高吞吐量，则可以减少它处理的时间。您可以通过任务或传递给另一个参与者（例如工人或聚合器）来执行此操作。PipeTo 在任务中产生消息的事物正在产生正确类型的消息以发送给另一个参与者并且您不想对它做任何事情的情况下很有用。它只是一个延续。没有错，演员系统中你最终会做一些工作的部分，你可能会打包到一个任务中，如果你有能力，那就使用它。某种形式的延续比演员阻塞要好——但如果演员一次只做一件事，这有关系吗？被阻塞的线程是被阻塞的线程。
当你达到这一点时，这将是显而易见的。如果您有多个参与者，您可能会使用路由器 - 或者如果您开始启动大量任务，您可能可以使用 1-2 个参与者和多个消息链来完成大部分任务。至于哪个更好——我知道有 3 个使用演员系统的人可以整天争论相对优点。如果您消除一个演员中的所有状态，您可以只使用 1 个演员来处理消息并触发任务。你可能有 2-3 层，你可能有一些东西来聚合 3 个任务和/或 10 个工人。世界是你的牡蛎
关键是这一切都取决于未说明的要求。