Мы используем очереди AMAZON SQS FIFO для обработки службы бронирования встреч для нашего приложения. Как только сообщение попадает в очередь, оно запускает функцию Amazon Lambda для управления процессом бронирования. Поскольку это очередь FIFO, мы гарантируем, что если 2 человека запросят один и тот же слот, слот будет передан первому запрашивающему. Мой вопрос: есть ли способ (может быть, настройка в очередях SQS FIFO?), Который гарантирует, что одно сообщение не запускает функцию Amazon Lambda, пока предыдущее сообщение не будет ЗАВЕРШЕНО. Я просто пытаюсь избежать необходимости писать дополнительную логику (своего рода систему блокировки слотов), чтобы гарантировать, что один и тот же слот не будет нацелен на 2 последовательных сообщения до первого завершения процесса "бронирования" . Спасибо.
Поскольку jarmod говорит, что очереди FIFO не поддерживают лямбда, я предполагаю, что у вас есть лямбда-функция опроса? И вы упоминаете «очереди», а не «очередь» - сколько у вас очередей? У всех ли у них есть конкретная цель? Или любая очередь может нести какое-нибудь сообщение? IOW - 2 конфликтующих сообщения могут находиться в разных очередях друг к другу? Или они всегда будут в одной очереди?
Я думаю, что решение этой конкретной проблемы заключается не в блокировке сообщения SQS или его эквивалента, а в использовании атомарной блокировки или транзакций в вашей бизнес-логике / базе данных.





Вот как я решил проблему.
Я бы вообще не рекомендую использовать SQS, и вам не нужны никакие из этих функций, предлагаемых SQS для вашего варианта использования.
Перемещено из SQS в Kinesis Data Streams и установите размер пакета равным 1. для запуска лямбды. Это позаботится об этом. Потоки Kinesis - это FIFO. Также Кинезис очень хорошо масштабируется по сравнению с транзакционными очередями FIFO SQS.
Producer --> Kinesis Data Streams --> (Lambda Trigger [Batch Size to 1]) Lambda
Учитывая случаи ошибок,
Ошибка обработки:
Если ваша лямбда не работает при обработке данных потока, ваша контрольная точка будет продолжать повторять попытки с неограниченным количеством попыток. Вам нужно обязательно исправить свою лямбду и заставить ее двигаться вперед. Общее время повторных попыток равно общему времени, в течение которого вы настроили доступность данных в потоке.
Ошибка в Lamda:
Если у вас есть ошибка в лямбде, и вы хотите вернуться с начала потока, вы можете это сделать.
Надеюсь, это поможет.
Спасибо. Вы предлагаете интересное решение. Единственная причина, по которой я не стал бы реализовывать это решение, заключается в том, что я стараюсь сделать его простым (для этого конкретного приложения).
Используя очереди FIFO, вы уже усложнили задачу. Kinesis Data stream - самое простое решение.
Kinesis намного дороже, чем SQS, поскольку вы платите за час сегментов.
Но очереди FIFO не поддерживают триггеры лямбда-функции.