Подтвердить что ты не робот

Реализация очереди на основе файлов

У меня есть ограниченная память в очереди, в которой несколько потоков обходят объекты. Обычно очередь должна быть опустошена одним потоком чтения, который обрабатывает элементы в очереди.

Однако есть вероятность, что очередь заполнена. В таком случае я хотел бы сохранить любые дополнительные элементы на диске, которые будут обрабатываться другим потоком чтения фонов, который сканирует каталог для таких файлов и обрабатывает записи в файлах. Я знаком с Active MQ, но предпочитаю более легкое решение. Это нормально, если "FIFO" строго не соблюдается (поскольку сохраненные записи могут быть обработаны не в порядке).

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

Спасибо!

4b9b3361

Ответ 1

Вы можете использовать что-то вроде SQLLite для хранения объектов.

Ответ 2

Взгляните на http://square.github.io/tape/ и впечатляющий QueueFile.

(спасибо Брайану Маккаллистеру "Долгое сокровище за хвост", чтобы указать на меня).

Ответ 3

EHCache может переполняться на диск. Он также очень параллелен, хотя вам действительно не нужно, чтобы

Ответ 4

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

Edit: Трудно ответить на ваш вопрос с большим контекстом.

Можете ли вы уточнить, что вы подразумеваете под "исчерпанием памяти"? Насколько велика очередь? Сколько у вас памяти?

Есть ли у вас встроенная система с очень маленькой памятью? Или у вас есть 2 ГБ или больше вещей в очереди?

Если значение true, вам действительно нужно использовать "заменяемую" структуру данных, такую ​​как BTree. Реализация одного из вас для одной очереди кажется излишним. Я бы просто использовал встроенную базу данных, такую ​​как SQL lite.

Если ни один из них не является истинным, просто используйте вектор или связанный список.

Изменить 2: Вам, вероятно, не нужен БТРИ или база данных. Вы можете просто использовать связанный список страниц. Но опять же, Я должен спросить: это необходимо?

Или, если вы готовы обрабатывать вещи не последовательно, почему бы не иметь несколько потоков чтения все время?

В конечном счете, хотя я не думаю, что ваше предложение - путь.

Ответ 6

Самое эффективное и дружественное к GC решение, которое я нашел к настоящему времени, Chronicle Queue. Он имеет чрезвычайно низкую задержку записи, порядка десятков наносекунд, несколько марок ниже, чем MapDB или SQLite.

Ответ 7

MapDB предоставляет параллельные Карты, Наборы и Очереди, поддерживаемые дисковой памятью или памятью без памяти. Это быстрый и простой в использовании встроенный механизм базы данных Java.

https://github.com/jankotek/MapDB

http://www.mapdb.org/