Akka演員和調度員

下面的例子是調度消息時的經典反模式嗎？Akka演員和調度員

class MyActor extends Actor { 

    private val scheduler = context.system.scheduler.schedule(3.seconds, 3.seconds, self, Tick) 

    def receive = { 
    case Tick => processMessage(....) 
    } 
}

爲什麼我應該遠離使用本地調度程序？

來源

2016-05-18 sparkr

我已經看到的一個問題是測試這個Actor變得困難。假設這位演員內部有相當多的邏輯，那麼我註定了，但除此之外，這被認爲是反模式？你們有什麼感想？ – sparkr

我會盡量總結爲什麼你不應該使用調度器作爲默認模式。

如果您提交的任務數量多於您處理的任務數量，那麼您的JVM可能會耗盡內存或者您的任務可能會延遲。
演員調度不是持久的，所以如果例如在17:50你安排了一個Tick消息在10分鐘內發送，但由於一些例外，你的演員被監督員17:53重新啓動，作爲默認監督的一部分政策，結果你的計劃任務將被延遲3分鐘......爲了解決這個問題，你可以使用持續的演員，它將重播所有的計劃事件，並重新安排它，如果事件時間更長，那麼當前時間你的計劃週期將是三角洲那兩個時間戳。
基於HashedWheeltimer阿卡調度哪些是最適合安排短期

在我們的項目中，我們使用的是我們從「要求演員」發送消息給其他演員「演員每請求」模式，然後是設置context.setReceiveTimeout(x seconds)。如果我們沒有收到任何x秒響應，我們認爲這個信息已經丟失，並根據我們使用「至少一次」或「最多一次」交付的模式來應用我們的邏輯。

來源

2016-05-21 20:56:47

Akka演員和調度員

回答

相關問題