【问题标题】:Accumulating and Ordering Child Actor Responses?累积和排序子角色响应?
【发布时间】:2014-11-21 20:43:39
【问题描述】:

我是 Scala 和 Akka 的新手,我一直在阅读有关 Akka 的书。对于我认为使用 Actors 的常见用例,我找不到合理的解决方案。

假设您有一个父 Actor 接收到对大量工作的请求(假设您需要去网络下载 100 个文件),因此父 Actor 将工作拆分并将其路由给 10 个孩子,因此我们一次下载多个文件。

不知何故,我需要将所有文件按顺序返回给父演员。这样做的好的设计模式是什么?

I found a link 在我的搜索中,他们似乎想出了一个很好的方法来实现这一点,但是因为博客实际上并没有展示如何使用这个例子(因为他们只是提供了一个代码 sn-p),而且我是 scala noob,我不明白如何将其付诸实践: http://www.ccri.com/2014/01/22/accumulating-responses-from-child-actors-and-transitive-message-ordering/

【问题讨论】:

    标签: scala akka


    【解决方案1】:

    可以通过akka futures 完成。来自您的父演员:

    1. 创建一个包含 100 个期货的数组,每个期货提取一个文件
    2. 使用Future.sequence.traverse 将future 数组映射到文件数组的future
    3. 将其映射到.pipe 以将数组发送回父actor

    如果获取每个文件最适合某个演员而不是未来,则每个未来都可能是 ask 到子演员池的结果。

    【讨论】:

    • 这可以通过用.reduce.andThen 替换步骤2 来改进,以便在每个任务完成时按顺序遍历数组,并pipeing 结果(单次下载,或错误)完成后返回给父actor。因此,父母可以按顺序单独处理。我稍后会尝试获得一个sn-p..
    • 嗯,基本上所有文件都需要一次放在一个地方。将每个文件单独发送回父级并不好,除非我将它们保存在 actor 中,如果那个 actor 接收到多个请求,我就无法做到这一点。
    • 我提到的博客文章似乎提到使用 ask 是一种不好的处理方式:“但还有额外的好处,我认为人们可能更普遍地对此感兴趣:我们已删除使用 ask 模式!而不是询问——它隐式地设置了它自己的临时演员,从一般的写法来看会招致某些性能损失——我们编写自己的 Promise 并自己实现它。我们也确切地知道临时演员什么时候可以关闭自己,让 ActorContext 干净地处理它。”
    • ask 确实为每个任务创建了额外的参与者;虽然对于下载文件等重量级任务,我认为这是一个合理的开销。另外,我原来的 sol'n 不使用 ask(),只使用期货。
    • 我原来的 sol'n 提供了所有文件的数组;但是如果数组可以在收到结果时增量处理,那么在父actor中累积状态(数组)是可以接受的。
    猜你喜欢
    • 1970-01-01
    • 2022-11-02
    • 1970-01-01
    • 1970-01-01
    • 2022-08-18
    • 1970-01-01
    • 2014-09-29
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多