Одним из возможных решений является использование запланированной лямбды (может быть настолько частой или разреженной, насколько вы хотите, основываясь на вашем трафике), которая извлекает события из очереди SQS, заполненной событиями S3 put. Предполагается, что вы сосредоточены на пакетной обработке n
файлов за раз, и порядок не имеет значения (с учетом имени uuid).
Для создания этого рабочего процесса было бы что-то вроде этого:
- Создать очередь SQS для хранения событий S3 PUT
- Добавить триггер к корзине S3 на PUT, чтобы создать событие в очереди SQS из 1.
- Создать лямбду с переменными env (для корзины и очереди)
- Лямбда должна проверить очередь, если есть какие-либо сообщения в полете и использовать только ведро
- Если есть, остановить запуск (чтобы предотвратить многократную обработку файла)
- Если в полете нет сообщений, перечислите объекты из S3 с пределом
n
(размер вашей партии)
- Запустить логику процесса, если возвращено достаточно объектов (может быть меньше
n
)
- Удалить файлы
- Создать правило CloudWatch для запуска лямбды каждые
n
секунд / минут / часов
Некоторые другие вещи, которые следует учитывать, исходя из особенностей вашей ситуации:
- Если быстро отправляется много файлов, а
n
значительно меньше, обработка с одним отслеживанием (шаг 3.2 приведет к длительному времени обработки). Это также зависит от продолжительности обработки, могут ли данные обрабатываться несколько раз и т. Д.
ListObjectsV2
может вернуть меньше параметра MaxKeys
, если это проблема, может иметь большее значение MaxKeys
и просто обработать первый n
.