Реализация очереди на основе файлов
У меня есть в памяти ограниченная очередь, в которой несколько потоков помещают объекты в очередь. Обычно очередь должна быть очищена одним потоком чтения, который обрабатывает элементы в очереди.
Однако существует вероятность, что очередь заполнена. В таком случае я хотел бы сохранить любые дополнительные элементы на диске, которые будут обработаны другим фоновым потоком чтения, который сканирует каталог для таких файлов и обрабатывает записи в файлах. Я знаком с активом MQ, но предпочитают более легкое решение. Это нормально, если "FIFO" не строго соблюдается (так как сохраненные записи могут быть обработаны не по порядку).
Существуют ли какие-либо решения с открытым исходным кодом? Я не нашел ни одного, но подумал, что буду проверять этот список на наличие предложений, прежде чем сам приступлю к реализации.
Спасибо!
7 ответов:
Взгляните на http://square.github.io/tape/, и его впечатляющий файл очереди.
(Спасибо Брайану Маккаллистеру из "сокровищницы длинного хвоста" за то, что он указал мне на это).
Почему очередь ограничена? Почему бы не использовать динамически расширяемую структуру данных? Это кажется гораздо проще, чем задействовать диск.
Редактировать: Трудно ответить на ваш вопрос без более подробного контекста.
Не могли бы вы пояснить, что вы подразумеваете под"исчерпанием памяти"? Насколько велика очередь? Сколько у тебя памяти?Вы находитесь на встроенной системе с очень малой памятью? Или у вас есть 2 ГБ или больше материала в очереди?
Если то или другое верно, вы действительно либо использовать "на ходу" структуры данных, как дерево. Реализация одного себя для одной очереди кажется излишеством. Я бы просто использовал встроенную базу данных, такую как SQL lite.
Если ни один из них не является истинным, то просто используйте вектор или связанный список.
Правка 2: Вам, вероятно, не нужно BTree или база данных. Вы можете просто использовать связанный список страниц. Но опять же, Я должен спросить: это необходимо?
Или, если вы хотите обрабатывать вещи несерьезно, почему бы не иметь несколько потоков чтения все время?
В конечном счете, хотя я не думаю, что ваше предложение-это путь.
Вы можете встроить berkley db java edition для хранения элементов очереди в файлах.
Вы можете посмотреть на рабочий пример здесь: http://sysgears.com/articles/lightweight-fast-persistent-queue-in-java-using-berkley-db
Надеюсь, это поможет
Самое эффективное и удобное для GC решение, которое я нашел на данный момент, - это Chronicle Queue. Он имеет чрезвычайно низкую задержку записи, порядка десятков наносекунд, на несколько классов величины ниже, чем MapDB или SQLite.
MapDB предоставляет параллельные карты, наборы и очереди, поддерживаемые дисковым хранилищем или встроенной памятью. Это быстрый и простой в использовании встроенный движок баз данных Java.