【问题标题】:Java FIFO Queue with spill-over to disk溢出到磁盘的 Java FIFO 队列
【发布时间】:2012-01-31 08:30:11
【问题描述】:

我正在开发/准备一个基于生产者/消费者模型的应用程序。在我的例子中,会有一个生产者生成数个百万(非平凡的)任务,并且会有可配置数量的消费者。

生产者和消费者之间的通信基本上是基于队列的。但是我担心内存消耗:可以想象,任务的数量会超过 JVM 的可用内存。所以我想要一个队列实现,它只在内存中保留“top-X”数量的队列项目,并将其余的存储在磁盘上。这不必具有弹性,因为它不需要在程序重新启动后仍然存在。

我四处搜索,但找不到似乎被广泛使用的队列实现(似乎确实有一些,我称之为概念验证实现,但我担心未来支持/继续开发这些实现)。我还查看了外部消息队列应用程序,但是(1)我不想运行第二个外部进程,(2)甚至在同一个 JVM 进程中嵌入消息代理对于这个要求来说似乎有点“头重脚轻” .

是否有人知道任何提供此功能且受良好支持的面向未来的库?

Rgds

【问题讨论】:

  • 您有没有为您的问题找到可靠的解决方案。我正在寻找解决相同的情况。谢谢!

标签: java queue disk persistent fifo


【解决方案1】:

嗯,JMS 似乎是显而易见的解决方案。我认为您不会找到可靠的方法来解决这个问题,因为 JMS 解决了这个问题并且是一个标准解决方案。

但是请注意,Java 也有 BoundedQueues 来解决这个问题:确定队列的大小以确保当队列已满时它不会因 OOME 而失败,并且生产者在尝试将消息放入完整的有界时会被阻止排队,直到某个消费者从队列中删除某些任务。

【讨论】:

  • 没错,我考虑过使用 BoundedQueue(但仍未排除)。让生产者阻塞听起来太低效了。
  • 顺便说一句。我不同意这样的假设,即由于 JMS 存在并解决了这个问题,因此没有其他解决方案/实现的空间。对于这样的事情,JMS 实在是太过分了。例如,这种“内存受限队列”可能是嵌入式系统的要求,在该系统中,JMS 消息代理没有空间/资源。
  • 如果生产者对消费者来说太快,让生产者阻塞将允许消费者有更多的 CPU 时间(或带宽)分配给他们,因此生产和消费大量任务所花费的总时间可能与磁盘支持的队列相同(甚至更低,因为您避免了从磁盘读取和写入的需要)
  • 对我来说,如果队列这么快就填满了,可能是生产者数量与消费者数量的比例不合适。队列有一定的灵活性很有用,但它的目标是调节节奏,而不仅仅是存储任务。
  • 没错,让生产者阻塞可能比使用溢出到磁盘的队列更好/更快地解决我的问题。但是,如果不进行测试,我们将永远无法确定;)
【解决方案2】:

当有足够多的任务要消耗时让生产者阻塞通常比让队列增长并消耗更多内存更有效。例如如果您的队列适合队列,则它可能比不适合的队列快几倍。

【讨论】:

    猜你喜欢
    • 2016-12-20
    • 2021-06-15
    • 2015-05-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-05-01
    • 2017-05-30
    • 1970-01-01
    相关资源
    最近更新 更多