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