并发，如何创建高效的actor设置？

Question

好吧，我以前从来没有做过这样的密集并发操作，这个算法有三个主要部分。

这一切都始于大约 100 万个项目的向量。 每个项目都在 3 个主要阶段进行处理。

任务 1：发出 HTTP 请求，将接收到的数据转换为大约 50 个条目的映射。 任务 2：接收地图并根据地图中找到的信息进行一些计算以生成类实例。 任务 3：接收类并生成/添加到多个输出文件。

我最初是通过在 64 个线程（每个线程 1024 个条目）上同时运行具有 64K 个条目的任务 1 开始的。在 for 循环中生成线程。

这运行良好且相对较快，但我不断听到有关 Actor 以及它们如何比基本 Java 线程/线程池更好的堆。我已经创建了一些演员等。但不知道从哪里开始。

基本上： 1. Actor 是否是为这组特定任务实现快速并发的正确方法。或者我应该有另一种方法。 2.你怎么知道有多少线程/参与者太多了，特别是在任务一中，你怎么知道同时连接数的限制是多少（我在mac上）。有没有一条黄金法则可以遵循？多少个线程与每个线程池有多大？和演员等价物？ 3. 有没有我可以查看的以类似方式实现演员的代码？我看到的所有代码要么是让演员打印 hello world，要么是超级复杂的东西。

Answer 1

1) Actor 是设计组件之间复杂交互的好选择，因为它们与“现实生活”非常相似。您可以将它们视为不同的人相互发送请求，对交互进行建模是很自然的。但是，当您想要管理应用程序中不断变化的状态时，它们最强大，而您似乎并非如此。您可以在没有参与者的情况下实现快速并发。由你决定。

2) 如果您的任何操作都没有阻塞，那么最好的规则是线程数量 = CPU 数量。如果您在编写输出文件时使用非阻塞 HTTP 客户端和 NIO，那么您应该在 IO 上完全非阻塞，并且可以安全地将应用程序的线程数设置为您机器上的 CPU 数。

3) http://akka.io 上的文档非常好和全面。如果您不知道如何使用演员模型，我建议您买一本书——不一定是关于 Akka。

Answer 2

1) 听起来您的大多数步骤都不是有状态的，在这种情况下，参与者会增加复杂性而没有真正的好处。如果您需要以可变的方式协调多个任务（例如，用于生成输出文件），那么 Actor 非常适合该部分。但是 HTTP 获取可能应该只是调用一些非阻塞 HTTP 库（例如 spray-client - 实际上会在“幕后”使用演员，但不会向您公开状态）。

2) 对于阻塞线程，您几乎必须进行试验，看看您可以在不消耗太多资源的情况下运行多少。担心远程系统可以处理多少同时连接，而不是在您自己的机器上达到任何“连接限制”（您可能会达到文件描述符限制，但如果是这样，最好的做法就是增加它）。弄清楚这一点后，线程数超过您想要建立的同时连接数就没有任何价值了。

正如其他人所说，对于非阻塞所有内容，您可能应该只拥有与 CPU 内核数量相似的线程数（我也听说过“2x number of CPUs + 1”，理由是这样可以确保当 CPU 空闲时始终是可用的线程）。

有了演员，我就不用担心演员太多了。它们非常轻巧。

Answer 3

如果您真的没有 Akka 经验，请尝试从简单的事情开始，例如对代码进行一对一的 actor-thread 重写。这将更容易掌握 akka 中的工作原理。

在开始时旋转两个actor，一个用于接收请求，一个用于写入输出文件。然后，当接收到请求时，在请求接收者 Actor 中创建一个 Actor，该 Actor 将进行计算并将结果发送给编写 Actor。