询问模式是否适用于 Akka IO 演员？答案

【问题标题】：Does the ask pattern work with Akka IO actors?询问模式是否适用于 Akka IO 演员？
【发布时间】：2014-05-09 16:04:02
【问题描述】：

假设我有一个 IO Actor connection 能够通过 TCP 发送和接收消息。在我的演员中，我要求连接的另一端做出回应：

 connection.ask(ByteString("stuff")).collect {
    case Received(response) => log.debug(response.utf8String)
 }

似乎使用此代码，未来的询问超时，而是包含演员在询问模式之外接收原始消息。

你可以对 Akka IO Actor 使用 ask 模式吗？如果没有，为什么不呢？

【问题讨论】：

标签： scala akka

【解决方案1】：

我不详细了解架构，但我会向自己解释：

Akka IO 连接器actor 的问题在于它们不能以请求-响应的方式工作。如果您考虑一下 - 这是有道理的，因为 TCP 不是请求-响应协议。 TCP 甚至没有message 的概念。从程序员的角度来看，TCP 连接只是一对连续的字节流——每个方向一个。就是这样。

Akka IO 是网络协议之上的最小参与者层，因此它模仿这种行为也就不足为奇了。当 TCP actor 从网络接收到一些数据时，它只知道一件事 - 它应该向最初发送 Connect 消息的 actor 发送一个 Received 消息。就这样。它不知道它从网络接收到的数据与你之前发送的数据有某种关联。

除此之外，ask 模式仅在以下假设下工作em> 消息A。正如我们已经知道的那样，TCP actor 不会这样做 - 它只是将所有内容发送给原始 Connect 消息的发送者。

之所以需要这个假设是因为ask 模式实际上创建了某种“幻像”actor，它被设置为使用ask 发送的消息的发送者。然后这个“幻影”actor 将接收响应并调用在Future 上注册的所有回调。作为旁注 - 请注意，这些回调是完全独立于发送参与者调用的，即它们可能会同时运行！

所以，我最终会得出结论，像这样使用的ask 模式不适用于 Akka IO，因为对于这样的抽象来说，它的级别太低了。如果您仍然想要它，您需要在 Akka IO 之上创建自己的抽象层，例如一些简单的中间角色，涵盖 TCP 连接器角色并实现请求-响应行为。

【讨论】：

【解决方案2】：

作为对@ghik 回答的额外参考，以下是我创建中间actor 以在我的其余actor 上启用 IO 询问模式的大致方法。

class IOAskHandlerActor(address: InetSocketAddress) extends Actor {
   override def receive = {
      // Connection setup code omitted    
      case Connected(remote, local) =>
         // other code omitted
         context become latch(sender())
   }

   def latch(connection: ActorRef): Receive = {
      case outgoing =>
         context become receiving(connection, sender())
         connection ! MySerializer.write(outgoing)
   }

   def receiving(connection: ActorRef, asker: ActorRef): Receive = {
      case Received(incoming) =>
         context become latch(connection)
         asker ! MySerializer.read(incoming)
   }
}

此类的实例可以asked 以获取响应。请注意，我只对一个同时提问者（这是我的用例）进行了测试，这可能不适用于多个提问者。

【讨论】：