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