问题
From what I've gathered, the "ask" pattern is considered a bad practice and should be avoided. Instead, the recommended pattern is the "actor per request" model. However, this doesn't make sense to me, as the "ask" pattern does exactly this - it creates a lightweight actor per request. So why is this then considered bad, especially when futures are far more composable and are able to more elegantly handle the collation of multiple send/receives?
回答1:
From Akka docs:
"There are performance implications of using ask since something needs to keep track of when it times out, there needs to be something that bridges a Promise into an ActorRef and it also needs to be reachable through remoting. So always prefer tell for performance, and only ask if you must."
But sometimes you want to send a message from outside of an actor in which case you can use ask. Using ask will guarantee that you get a response within the specified timeout and sometimes that's what you want. However, when you use ask pattern you should ask yourself a question whether you could just use Futures instead.
There is a place for ask but it should have very limited use due to the aforementioned reasons.
You don't have to use actor per request. Some actors are meant to be long lived and some not. If an actor performs a potentially dangerous or blocking operation you might want to create one per request. Whatever fits your application logic.
来源：https://stackoverflow.com/questions/28863014/why-is-the-actor-ask-pattern-considered-an-anti-pattern-or-code-smell