对于大于堆的基于 JVM 的队列，有哪些解决方案？
我正在研究基于 JVM 的系统中队列（或者也许流是更好的描述）的可能技术选择。
一些要求：
- 必须可从 JVM/Java 访问。
- 队列必须支持大于 JVM 堆的大小，可能大于所有可用 RAM。因此，暗示支持利用磁盘（或网络）进行存储。
- 目前，队列不需要在进程生命周期之后保持持久性。
- 队列的大多数用途将有一个生产者和一个消费者。因此，任何特定队列的并发都不是问题。 （显然，队列之间的并发性很重要。）
- 队列是临时的和临时的。它们突然出现、充满、耗尽、消失。
- 小队列最好保留在内存中，然后根据资源可用性转移到较慢的存储。这个需求可以通过排队技术来满足。
我正在研究几个选项，但很好奇我缺少哪些选项？
I am looking at possible technology choices for queues (or perhaps streams are a better description) in a JVM-based system.
Some requirements:
- Must be accessible from the JVM / Java.
- Queues must support sizes larger than the JVM heap, possibly bigger than all available RAM. Thus, support for utilizing the disk (or network) for storage is implied.
- Queues do not currently need to be durable past the process lifetime.
- Most uses of the queue will have a single producer and a single consumer. Concurrency for any particular queue is thus not an issue. (Obviously concurrency is important across queues.)
- Queues are ad-hoc and temporary. They pop into existence, are filled, are drained, and go away.
- Small queues should preferably stay in memory, then shift to slower storage based on resource availability. This requirement could be met above the queuing technology.
I am examining several options but am curious what options I am missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
使用可用的 JMS 实现之一。例如来自 Jakarta 的 ActiveMQ 或 Qpid。
Use one of available JMS implementations. For example ActiveMQ or Qpid from Jakarta.
我遇到了这个 FIFO 队列，它溢出到磁盘，这很有趣，并且具有我正在寻找的一些属性：
http://code.google.com/p/ashes-queue/
I ran across this FIFO queue with spill to disk which is kind of interesting and has some of the properties I'm looking for:
http://code.google.com/p/ashes-queue/
我考虑过使用 Terracotta 的 BigMemory 作为将队列数据推送到直接内存和堆外的工具。
I have considered using Terracotta's BigMemory as a tool for pushing queue data into direct memory and off-heap.
使用Redis作为消息队列怎么样。它既支持内存中的队列，也可以在数据无法容纳RAM时将其持久化。
How about using Redis as a messaging queue.It supports both in-memory and can be made persistent once data does not fit the RAM.
HSQLDB提供了一个进程内数据库引擎，您可以使用RAM、本地磁盘或网络服务器来存储数据库。这可能会让您的船漂浮，特别是如果您想稍后无缝地迁移到网络解决方案而不是本地磁盘。从小队列过渡到大队列将涉及将数据从一个数据库移动到另一个数据库。有一些标准方法可以做到这一点，但它们可能非常慢。
我越想越觉得这不是一个很好的搭配。就其价值而言，根据我的经验，内存数据库速度非常快。
HSQLDB provides an in-process database engine where you can use RAM, the local disk or a network server to store the database. That might float your boat, especially if you want to seamlessly move to a network solution rather than the local disk later on. Transitioning from small to large queues would then involve moving data from one database to another. There are standard ways to do this, but they might be pretty slow.
There more I think about it, the more I think this is not a good match. For what it's worth, the in-memory DB is very fast in my experience.