Akka 阿克卡：问还是说

我读完了杰米·艾伦写的《有效的阿克卡》一书。我是阿克卡的新手，我真的不明白为什么在某个时候他会说：

然而，有两件事并不理想。 首先，它利用未来要求其他参与者做出回应， 这会为在邮件后面发送的每条邮件创建一个新的PromiseActorRef 场景。这是浪费资源。最好有我们的 演员以一种“火和忘记”的方式发送消息并收集结果 异步地集成到一个参与者中

---

一般来说，用问代替说似乎更昂贵。使用拉而不是推要贵多少？此外，为什么说出来比问出来更可取呢？

使用

说出来更可取，因为：

无阻塞等待消息。这提供了最佳的并发性和可伸缩性特征

使用ask会对性能产生影响，因为需要一些东西
要跟踪它何时超时，需要有
将承诺连接到ActorRef，并且它也需要可访问
通过远程处理。所以，总是更喜欢说绩效，而只是问
如果你必须的话

如果有这样一种情况，你在一个本可以使用
tell
的地方使用
ask
，那么你就浪费了资源。如果您不关心响应，那么为什么要浪费开销（或资源）让系统返回响应呢
 我是《有效的阿卡》的作者。我关于使用Ask的观点是，你正在使用未来。如果将多个请求聚合到一个响应中，则会为请求后面的每个未来创建多个超时。在小剂量的情况下，这并不是一个可怕的大问题，但在大剂量的情况下，它会对性能造成额外的拖累

请注意，这本书写于2013年，虽然大部分内容仍然相关，但Akka Streams和反应流的背压方法否定了关于在推和拉之间选择的一些讨论。在生产商或消费者可能不知所措的任何情况下，Akka Streams绝对是一种更好的方法

谢谢你阅读这本书，希望对你有所帮助
 这就是我试图理解的。为什么他会说“这是在浪费资源”？你好，杰米，谢谢，或者回答-是的，最佳实践部分仍然很有趣。你认为还有其他的模式吗？我有，尽管我更喜欢浮雕模式。任何时候，当您在JVM上创建匿名的东西时，您都会失去对它进行推理的能力。Lambdas、Java接口的匿名实现等都以这种方式相似。拥有显式类型总是更干净、更易于维护。另外，当我有三个或更多的服务需要呼叫时，我喜欢聚合来自多个服务的响应。这使我能够针对可能发生的各种故障情况构建特定于域的行为（3个响应中的2个返回，重试第三个几次，如果不起作用则失败，等等）。谢谢