Asynchronous 具有持久消息/磁盘溢出的低占用空间队列/消息传递解决方案

我需要建立一个高度可扩展的系统来捕获点击流量。我希望数据以异步方式处理，以便HTTP单击请求能够快速返回。点击流量需要到达数据存储以进行报告，但不需要是实时的。我希望能够通过添加应用服务器来扩展此解决方案，根据需要添加多个应用服务器以满足需求，并由负载平衡器（可能是Amazon的弹性负载平衡器）提供支持。我想到了一些可能性（顺便说一句，平台是Java）：

将点击数据写入内存队列（例如BlockingQueue）。另一个线程将耗尽队列并插入后端数据存储。这种方法将队列大小限制为可用内存，如果节点崩溃，队列上的所有数据都将丢失。我搜索了一个BlockingQueue实现，该实现在队列达到一定大小时溢出到磁盘，但没有找到任何内容

将点击数据写入每个节点上的文件系统，文件大小为100MB左右。然后，数据将由后端进程收集并插入到数据存储中。使用这种方法，不会出现单点故障，数据丢失的可能性也很低。例如，如果某个节点出现错误，它将从负载平衡器中删除。如果后端数据存储变得不可用，它可以在数据文件再次可用时继续传输数据文件。将数据放入后端数据存储需要一些时间，但只要所有数据都在那里，这是可以接受的

使用消息传递系统，例如activemq或rabbitmq。除非安装在每个节点上，否则消息传递系统将引入单点故障，这似乎有些过分。消息传递系统将提供持久的消息，并在一定程度上保证消息在事务中只使用一次。队列的使用者将数据加载到数据存储中。消息传递系统可以在后端集群，但需要为n-app服务器提供服务器，它可能成为系统中的限制因素，影响http请求性能

---

听起来这是一个很好的任务框架。它使用actor模型，并支持远程actor。这意味着它保证每条消息只被使用一次，并允许您跨多个服务器扩展系统。它还支持基于文件的actor邮箱和actor监控，因此，如果一台服务器崩溃，系统可以恢复，未处理的消息不会丢失。有很多公司都在专业地使用它，因此它经过了彻底的战斗测试。

谢谢你的建议。我认为这可能适用于基于文件的持久邮箱，以及如何将其部署为库而不是服务器。我正在进一步研究它。我评估了Akka，在评估过程中了解到它的持久maibox不会表现为持久队列。从本质上讲，您无法将邮箱与使用者解耦，因此如果停止使用者（参与者），邮箱将死亡。此外，actorRef仍然接受到死队列的消息。这是不幸的，因为它看起来很有希望。