Как спроектировать систему, которая ставит в очередь запросы и обрабатывает их партиями?

Question

В моем распоряжении есть служба REST, которая принимает JSON-массив URL-адресов изображений и возвращает масштабированные эскизы.

Задача

Я хочу объединить URL-адреса изображений, отправленные одновременными клиентами, перед вызовом службы REST. Очевидно, что если я получу 1 изображение, я должен подождать некоторое время, в случае, если другие изображения поступают. Я остановился на партии из 5 изображений. Но вопрос в том, как мне спроектировать его так, чтобы он позаботился о следующих сценариях:

1. Если я получу x изображений, например, x <5, как мне прекратить время ожидания, если в ближайшие несколько минут не появятся новые изображения. </li>
2. Если я использую очередь для буферизации входящих URL-адресов изображений, мне, вероятно, потребуется заблокировать ее, чтобы предотвратить одновременную запись клиентов, пока я занят чтением своих пакетов из 5. Какая структура данных подходит для этого? BlockingQueue?

Answer 1

Структура данных - это не то, чего не хватает. Чего не хватает, так это сущности - задачи «Таймер», я бы сказал, которую вы останавливаете и перезапускаете каждый раз, когда отправляете пакет изображений в службу. Вы делаете это независимо от того, отправляете ли вы их, потому что у вас было 5 (кстати, я предполагаю, что 5 - это только ваш начальный номер, и он будет настраиваться вместе с вашим временем ожидания), или же потому, что задание тайм-аута сработало.

Итак, работают две сущности: основной поток, который получает запросы, ставит их в очередь, проверяет глубину очереди и, если она равна 5 или более, отправляет самую старую 5 в службу (и перезапускает задачу таймера); и задача таймера, которая собирает неполные партии и отправляет их.

Примечание: у этого основного потока, похоже, есть несколько обязанностей, поэтому возможна некоторая декомпозиция.

Answer 2

1- Например, если ваше веб-приложение на Java работает в Google AppEngine, вы можете написать каждый запрос клиента в хранилище данных, выполнить задание cron (т. Е. Запланированное задание на языке GAE), прочитать хранилище данных, создать пакет и отправить его .

2 - Что касается аспекта параллелизма / блокировки, то опять же вы можете положиться на хранилище данных GAE для обеспечения атомарности.

Конечно, не стесняйтесь игнорировать мое предложение, если GAE не вариант.

Answer 3

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

Если у вас несколько клиентов и вы знаете количество клиентов, вы всегда можете подсчитать количество индикаторов в очереди, чтобы проверить, все ли клиенты завершены.