real-time - Akka - 拉模式与耐用邮箱

Question

我一直致力于我的一个项目，使用 Akka 创建一个实时处理系统，该系统接收 Twitter 流(目前)并使用参与者以各种方式处理所述消息。我一直在阅读其他人使用 Akka 构建的类似架构，这篇特别的博客文章引起了我的注意:

http://blog.goconspire.com/post/64901258135/akka-at-conspire-part-5-the-importance-of-pulling

在这里，他们解释了将工作(即消息)推送给参与者与让参与者拉动工作时出现的不同问题。换句话说，通过推送消息，没有内置的方法可以知道哪个工作人员收到了哪些工作单元，也无法可靠地进行跟踪。此外，如果一个工作人员突然收到大量消息，其中每条消息都非常大，您可能最终不堪重负并且机器可能会耗尽内存。或者，如果处理是 CPU 密集型的，您可能会由于 CPU 抖动而使您的节点无响应。此外，如果 jvm 崩溃，您将丢失参与者在其邮箱中的所有消息。

拉取消息在很大程度上消除了这些问题。由于特定的参与者必须从协调者那里拉取工作，所以协调者总是知道每个 worker 有哪个工作单元；如果一个 worker 死了，协调员知道要重新处理哪个工作单元。消息也不在工作人员的邮箱中(因为它会拉取一条消息并在拉取另一条消息之前对其进行处理)，因此如果 actor 崩溃，这些邮箱的丢失不是问题。此外，由于每个工作人员在完成当前任务后只会请求更多工作，因此无需担心工作人员接收或开始的工作超过其可以同时处理的工作量。显然，此解决方案也存在问题，例如当协调器本身崩溃时会发生什么，但现在让我们假设这不是问题。也可以在博客引用的“Let It Crash”网站上找到有关此拉动模式的更多信息:

http://letitcrash.com/post/29044669086/balancing-workload-across-nodes-with-akka-2

这让我想到了一种可能的替代方案来执行这种拉取模式，即使用持久邮箱进行推送。我想到的一个例子是实现一个使用 RabbitMQ 的邮箱(其他数据存储，如 Redis、MongoDB、Kafka 等也可以在这里工作)，然后让每个参与者路由器(所有这些都用于相同的目的)共享相同的消息队列(或相同的数据库/集合/等...取决于所使用的数据存储)。换句话说，每个路由器在 RabbitMQ 中都有自己的队列作为邮箱。这样，如果其中一个路由发生故障，那些仍在运行的路由可以简单地继续从 RabbitMQ 检索，而不必太担心队列会溢出，因为它们不再使用典型的内存中邮箱。此外，由于他们的邮箱不是在内存中实现的，如果路由崩溃，它可能丢失的最多消息将只是它在崩溃前正在处理的一条消息。如果整个路由器出现故障，那么您可以期望 RabbitMQ(或正在使用的任何数据存储)处理增加的负载，直到路由器能够恢复并再次开始处理消息。

在持久邮箱方面，似乎早在 2.0 版中，Akka 就倾向于更积极地支持这些邮箱，因为他们已经实现了一些可以与 MongoDB、ZooKeeper 等一起工作的邮箱。然而，无论出于何种原因，它们似乎在某些时候放弃了这个想法，因为最新版本(撰写本文时为 2.3.2)没有提及它们。您仍然可以通过实现 MessageQueue 接口(interface)来实现您自己的邮箱，该接口(interface)为您提供诸如 enqueue()、dequeue() 等方法……因此制作一个适用于 RabbitMQ、MongoDB、Redis 等的邮箱似乎并不成为一个问题。

无论如何，我只是想听听你们的 friend 们对此有何看法。这看起来像是拉动的可行替代方案吗？

Answer 1

这个问题还在 akka-user 上产生了一个相当长且信息丰富的线程.总之，最好显式管理要由(持久的)actor 处理的工作项，可变数量的 worker actor 从中提取新工作，因为这允许更好的资源管理和显式控制要处理的内容以及如何处理重试.