Какие решения существуют для очереди на основе JVM, размер которой превышает размер кучи?

Question

Я смотрю на возможные варианты технологий для очередей (или, возможно, потоковое описание лучше) в системе на основе JVM.

Некоторые требования:

• Должен быть доступен из JVM / Java.
• Очереди должны поддерживать размеры больше, чем куча JVM, возможно, больше, чем вся доступная оперативная память. Таким образом, подразумевается поддержка использования диска (или сети) для хранения.
• В настоящее время очереди не должны быть долговечными после срока службы процесса.
• В большинстве случаев использование очереди будет иметь одного производителя и одного потребителя. Таким образом, параллелизм для любой конкретной очереди не является проблемой. (Очевидно, что параллелизм важен для всех очередей.)
• Очереди являются специальными и временными. Они появляются, наполняются, истощаются и уходят.
• Небольшие очереди предпочтительно должны оставаться в памяти, а затем переключаться на более медленное хранилище в зависимости от доступности ресурсов. Это требование может быть выполнено выше технологии очередей.

Я изучаю несколько вариантов, но мне любопытно, какие варианты мне не хватает?

Answer 1

Я рассмотрел возможность использования терракотовой BigMemory в качестве инструмента для передачи данных очереди в прямую память и вне кучи.

Answer 2

Я наткнулся на эту очередь FIFO с разливом на диск, что довольно интересно и имеет некоторые свойства, которые я ищу:

http://code.google.com/p/ashes-queue/

Answer 3

Используйте одну из доступных реализаций JMS. Например, ActiveMQ или Qpid из Джакарты.

Answer 4

HSQLDB предоставляет внутрипроцессное ядро ​​базы данных, где вы можете использовать оперативную память, локальный диск или сетевой сервер для хранения базы данных. Это может привести к плаванию, особенно если вы хотите перейти к сетевому решению, а не к локальному диску в дальнейшем. Переход от малых к большим очередям будет включать перемещение данных из одной базы данных в другую. Есть стандартные способы сделать это, но они могут быть довольно медленными.

Чем больше я думаю об этом, тем больше думаю, что это не очень хороший матч. По моему мнению, БД в памяти очень быстро работает в моем опыте.

Answer 5

Как насчет использования Redis в качестве очереди сообщений. Он поддерживает как оперативную память, так и может быть сохранен, если данные не помещаются в ОЗУ.