Akka actor 在等待新消息时仍在工作?

发布于 2024-12-23 11:41:15 字数 902 浏览 1 评论 0原文

我是 Akka 新手,如果这是一个基本问题,我提前道歉。我不确定如何使用参与者来实现以下场景,或者是否可能(或可取)。

  • 我有许多参与者(即生产者)负责同时维护某些状态,所有这些状态在发生更改时都会通知另一个参与者(即消费者)。
  • 消费者要重复运行某个任务,该任务需要所有生产者的状态才能启动。当它收到来自生产者的消息时,它还必须响应状态的变化。

在考虑 Akka 之前,我有点推出了自己的简单 Actor 模型,每个 Actor 都在自己的线程中运行。 run() 方法将监视事件队列,因此我可以让使用者不断执行类似的操作:

while not done
    poll the event queue
    if something was polled
        process the event
    if all state is available
        do one step of the long running task

事件队列的连续轮询不太适合我,但它至少在长时间运行的任务上取得了进展事件之间。

有没有最好的方法来使用 Akka 演员来实现这个?我可以实现一个“心跳”,它向消费者发送一条消息(或者自己在内部发送给消费者)来执行另一个步骤长时间运行的任务,但我不喜欢安排它的想法,因为长时间运行的任务中的步骤在持续时间上并不统一。我不想对迭代进行排队,这会让迭代变得太忙,从而无法快速响应来自生产者的消息。但我也不想太频繁地安排它,所以当它可以取得进展时它就处于闲置状态...

或者为此使用并发的数据流模型是否更合适(我只知道准备好了吗? 在状态全部绑定之前,消费者无法启动,因此根据数据流变量定义流程似乎很自然。但是,如果数据流变量只能绑定一次,那么从消费者那里获取重复的状态更新似乎并不合适。

I'm new to Akka, and I apologize in advance if this is a basic question. I'm not sure how to use actors to implement the following scenario, or if it's even possible (or desirable).

  • I have a number of actors (i.e. producers) responsible for maintaining certain pieces of state concurrently, all of which notify another actor (i.e. consumer) when changes occur.
  • The consumer is to run a certain task repeatedly, a task that requires state from all producers just to start. It must also respond to changes in the state when it receives messages from the producers.

Before considering Akka, I'd kind of rolled my own simple actor model, with each actor running in its own thread. The run() methods would monitor an event queue, so I could have the consumer continually do something similar to this:

while not done
    poll the event queue
    if something was polled
        process the event
    if all state is available
        do one step of the long running task

The continual polling of the event queue didn't sit well with me, but it at least made progress on the long running task between events.

Is there a best way to use Akka actors to implement this? I could implement a "heartbeat" which sends a message to the consumer (or sent internally to the consumer by itself) to do another step of the long running task, but I don't like the thought of having it be scheduled since the steps in the long running task aren't uniform in duration. I don't want to queue up iterations which keep it too busy so not to quickly respond to messages from the producer. But I also don't want to schedule it too infrequently, so it's sitting idle when it could be making progress...

Or would it be more appropriate to use a Dataflow model of concurrency for this (something I've only ready about)? The consumer can't start until the state is all bound, so it seems natural to define the process in terms of Dataflow variables. But if Dataflow variables can only be bound once, it doesn't seem appropriate for getting repeated updates in state from the consumers.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

手心的温暖 2024-12-30 11:41:15

您可以让产品将更改发布到 Akka EventBus,并让消费者注册来侦听这些事件,然后当它拥有所需的所有数据时,它可以处理完整的块,或者生成一个处理完整块的新参与者。

You can have the produces publish the changes to an Akka EventBus, and have the consumer register to listen for these events, then when it has all it needs, it can process the full chunk, or spawn a new actor that processes the full chunks.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文