快速生产者的 Java "Tiered Queue"实现，慢速消费者

Question

我有一个生产者-消费者场景，其中生产者生产的速度比消费者消费的速度快得多。通常，解决方案是让生产者阻塞，因为生产者/消费者场景的运行速度与最慢的组件一样快。限制或阻止生产者不是一个好的解决方案，因为我们的应用程序为消费者提供了足够的时间来稍后 catch 。

这是一个图表，描述了我们应用程序中的完整“阶段”与更常见的场景:

      Our Application                 Common Scenario
 2N +--------+--------+
    |PPPPPPPP|oooooooo|                                         P = Producer
    |PPPPPPPP|oooooooo|                                         C = Consumer
  N +--------+--------+      N +--------+--------+--------+     o = Other Work
    |CPCPCPCP|CCCCCCCC|        |CPCPCPCP|CPCPCPCP|oooooooo|     N = number of tasks
    |CPCPCPCP|CCCCCCCC|        |CPCPCPCP|CPCPCPCP|oooooooo|
    -------------------        ----------------------------
    0       T/2       T        0       T/2       T      3T/2

这个想法是通过不抑制生产者来最大化吞吐量。

我们的任务操作的数据很容易序列化，所以我计划实现一个文件系统解决方案来溢出所有不能立即满足的任务。

我将 Java 的 ThreadPoolExecutor 与具有最大容量的 BlockingQueue 一起使用，以确保我们不会耗尽内存。问题在于实现这样一个“分层”队列，其中可以在内存中排队的任务会立即完成，否则数据会在磁盘上排队。

我想出了两个可能的解决方案:

1. 使用LinkedBlockingQueue 或ArrayBlockingQueue 实现作为引用，从头开始实现BlockingQueue。这可能就像复制标准库中的实现并添加文件系统读/写一样简单。
2. 继续使用标准的 BlockingQueue 实现，实现一个单独的 FilesystemQueue 来存储我的数据，并使用一个或多个线程使文件出列，创建 Runnable 并使用 ThreadPoolExecutor 将它们排入队列。

这些是否合理，是否有可能有更好的方法？

Answer 1

在寻求更复杂的解决方案之前，您是否真的确信使用有界 BlockingQueue 会破坏您的交易？事实证明，增加堆大小和预分配足够大的容量对您来说仍然可以。它将让您避免复杂性和性能不确定性，而 GC 暂停的代价恰好在您的舒适范围内。

不过，如果您的工作负载如此不平衡，以至于它可以利用持久化内存无法容纳的大量消息(与经过验证的 MPMC 阻塞队列相比)，听起来您需要一个更简单、更小的版本 ActiveMQ 或它的 Apollo 分支。根据您的应用程序，您可能会发现 ActiveMQ 的其他功能很有用，在这种情况下您可以直接使用它。如果没有，您最好搜索 JMS 空间，如 bowmore 所建议的那样。