从 QA 角度看 Akka 系统答案

【问题标题】：Akka system from a QA perspective从 QA 角度看 Akka 系统
【发布时间】：2015-05-27 14:55:55
【问题描述】：

我已经测试了一个基于 Akka 的应用程序一个多月了。但是，如果我反思一下，我有以下结论：

单独的 Akka Actor 可以实现大量并发。我已经达到了超过 100,000 条消息/秒。这很好，只是消息传递。
现在，如果一端有用于连接的 netty 层，或者您最终让 akka actor 最终执行 DB 调用、REST 调用、写入文件，那么整个系统就不再有意义了。演员的邮箱已满，他们的吞吐量（这里是每秒接收消息的能力）变慢。
从 QA 的角度来看，这就像有一个巨大的管道，您可以在其中强行抽取大量水并且它可以处理。但是，如果输入软管不好，或者端点无法承受压力，那么这个巨大的管道就没有用了。

我需要以下问题的答案，以便在系统中提出建议或验证：

像 DB 调用、REST 调用这样的阻塞调用应该由参与者处理吗？还是它们只适用于消息传递？
可以这样说，假设您需要将数百万个 android/ios 设备持久连接到您的 akka 系统。代替套接字（如此不可靠）等，远程参与者可以实现为持久连接吗？
可以在演员的handleMessage() 中进行任何类型的计算吗？比如数据库调用等。

我会要求编辑通过这篇文章。我不能单独问所有这些。

【问题讨论】：

我认为你应该认真看看 netflix 的 hystrix 库。您不必使用该库，但可以使用它的技术。但是我相信你可以将这个库与 akka 结合起来，但考虑到两者都想管理线程，它可能会很混乱。

标签： java scala concurrency akka distributed-computing

【解决方案1】：

1) 是的，他们可以。但是这个操作应该在单独的（worker）actor中完成，它在阻塞代码周围使用fork-join-pool和scala.concurrent.blocking，它需要它来防止线程饥饿。如果目标系统（DB、REST 等）支持多个并发连接，您可以为此使用 akka 的路由器（在池中为每个连接创建一个参与者）。您还可以为多个不同的表（资源、队列等）生成多个参与者，具体取决于您的事务隔离和存储的一致性要求。

另一种处理方法是使用带有确认的异步请求而不是阻塞。您也可以将阻塞操作放在某个单独的未来（线程、工作者）中，这将在操作结束时发送确认消息。

2) 是的，actor 可以实现为持久连接。它将只是一个参与者，它持有连接的状态（因为参与者是有状态的）。使用Akka Persistence 可能会更可靠，可以节省一些存储的连接。

3) 您可以在 actor 的 receive 内进行任何非阻塞计算（akka 中没有 handleMessage 方法）。 Akka Supervising 将自动管理故障（例如没有连接到 DB）。阻塞代码见1。

附：关于“巨大的管道”。后端应用程序本身是一个管道（使用 akka 变得越来越大），因此如果环境无法处理它，没有什么可以帮助您提高性能 - 这个世界上没有泵。但是akka也是一个“水箱”，也就是说外压可能比内压强。顺便说一句，这意味着开发人员应该小心邮箱 - 因为“太多水”可能会导致 OutOfMemory，防止这种情况的方法是组织 back pressure。可以通过不确认传入消息（或简单地阻止端点的处理程序）直到它由 akka 处理来完成。

【讨论】：

感谢您的直截了当的回答。我会看看工人演员，如果他们被实施。一个后续问题：当你说 Actors 可以用作持久连接时，你的意思是，我们需要将 akka 与移动应用程序捆绑在一起吗？我想知道演员是否可以用 Websockets 代替。
我不知道actor如何替换某些协议。它只能实现它。当然假设 akka-io/spray 用于与套接字交互。关于将 Akka 与移动应用程序捆绑在一起 - 如果您通过套接字进行通信，则客户端不需要 Akka - 它只需要支持套接字（或任何基于套接字的高级协议，如 http、web-sockets 等）。这里的套接字只是一个端点——它也可以是 jms 或任何其他传输。 Akka只负责处理，不负责通信

【解决方案2】：

我不确定我能理解你的所有问题，但总的来说演员也适合慢速工作：

1) 是的，它们非常好。只需为每个请求创建/分配 1 个参与者（可能在 akka 路由器后面进行负载平衡），一旦完成，它可以将自己标记为“免费进行新工作”或自行终止。记住以后执行慢代码。就个人而言，由于隐式超时和异常吞咽，我喜欢避免 ask/pipe 模式，只需使用带有请求 id 的 tell，但如果您的延迟和错误率很低，请使用 ask/pipe。

2) 可以，但在这种情况下，我建议建立一个连接池，而不是按请求生成它们，因为这需要更长的时间。如果你能提供更多细节，我也许可以改进这个答案。

3) 是的，但请考虑一下：演员很便宜。创造数以百万计的他们，每次有一个阻塞部分，它应该是一个不同的，专门的演员。将单一职责发挥到极致。如果你有几个阻塞演员，你就会失去所有的好处。

【讨论】：