假设我有一个演员,它X
每秒处理请求。平均来说还可以,但有时会出现突发事件Y > X
,客户端每秒发送请求。还假设所有请求都有超时,因此它们不能永远在队列中等待。
假设我们在 Scala 中编程,Akka
让演员处理这些突发事件的最佳实践/设计模式是什么?是否有处理突发的代码示例?
假设我有一个演员,它X
每秒处理请求。平均来说还可以,但有时会出现突发事件Y > X
,客户端每秒发送请求。还假设所有请求都有超时,因此它们不能永远在队列中等待。
假设我们在 Scala 中编程,Akka
让演员处理这些突发事件的最佳实践/设计模式是什么?是否有处理突发的代码示例?
只要您的机器可以处理增加的负载(即有足够的 CPU),那么我建议Actor
使用Router
. 从您的示例中听起来,动态调整大小的路由器可能是最合适的,但即使是标准的循环或最小邮箱也可能就足够了。下面是 Akka 文档中路由器部分的链接。我希望这有帮助。
http://doc.akka.io/docs/akka/2.1.2/scala/routing.html
您还可以考虑将参与者分布在多个节点上,但这对于您的场景来说可能是多余的。如果您对这种方法感兴趣,请告诉我,我可以发布更多关于这样做的背景信息。
现在,当你汇集演员但系统仍然积压时该怎么做,这真的取决于你,但这里有一些选择。如果您可以处理由于突发导致的偶尔增加的延迟,那么什么也不做。演员的邮箱只会得到一点备份,但一旦爆发缓解,它们就会清除。如果没有,那么问题是当参与者积压时如何处理传入的消息。如果您想在这种情况下快速失败并且不接受您可能希望使用有界邮箱(http://doc.akka.io/docs/akka/2.1.2/scala/dispatchers.html )查看的消息)。当邮箱达到它的大小限制并且不能再对消息进行排队时,调用者将发送消息失败(我认为)。不是很棒,但至少会导致系统更快地稳定下来。
我假设你正在做ask (?)
(即请求/响应),所以当你这样做时,你会得到一个Future
. 如果它Future
没有及时收到响应,它将超时(使用隐式定义的超时值),因此在突发期间,附加到对积压参与者的调用的 Futures 将开始超时;他们不会永远被困在那里。