Какой механизм использует SQS.FIFO для чтения первых 20 000 сообщений?
Вот пример для некоторого контекста:
В очереди FIFO у нас есть группы сообщений:
| Group | Number of messages |
| A | 50,000 |
| B | 100 |
| C | 5 |
Время поступления сообщений в очередь:
Group A added at a rate of 100 per second from 11:00:00 onwards
Group B added at a rate of 10 per second from 11:00:01 onwards
Group C added at 11:05:00
Ни к одному из сообщений не применяются задержки доставки. Очередь настроена с тайм-аутом видимости, чтобы соответствовать лямбда-потребителю, который будет добавлен позже. Очередь пока ничем не обрабатывается.
Позже лямбда-функция настраивается с указанной выше очередью в качестве источника событий с 3 максимальным размером пакета 5 и длительным опросом 2 секунды. Лямбда-функция обрабатывает события за 1 минуту.
Что будут содержать первые несколько партий?
| batch | messages | consumer |
| 1 | AAAAA | lambda1 |
| 2 | AAAAA | lambda1 |
| 3 | AAAAA | lambda1 |
| 4 | BBBBB | lambda2 ? |
Приведенная выше модель — это то, что я ожидаю увидеть, если SQS.FIFO прочитает сообщения, упорядоченные по времени во всех группах сообщений. Альтернативой является то, что SQS.FIFO продолжает чтение из группы сообщений A до тех пор, пока общее количество сообщений в очереди не уменьшится до <20 000.
Может ли кто-нибудь пролить свет на механизм чтения?
Как указано в документах:
Очередь AWS SQS.FIFO просматривает первые 20 тыс. сообщений, чтобы определить доступные группы сообщений. Это означает, что если у вас есть отставание сообщения в одной группе сообщений, вы не можете использовать сообщения из другие группы сообщений, которые были отправлены в очередь позже, пока вы успешно используете сообщения из невыполненной работы.
Я согласен, время кажется разумной мерой порядка, однако мы запускаем SQS.FIFO в производственной среде, и всякий раз, когда одна группа сообщений перегружается, мы видим значительное снижение параллелизма на лямбда-потребителях и задержки в обработке остальные группы сообщений. Опять же, использование времени в качестве упорядочения в этом не имеет смысла.
Это интересно. Схема прибытия на самом деле такая же, как вы описали в своем посте? Вы уже подняли вопрос о поддержке с AWS или это будет шагом в будущем, если это необходимо?
В пакете из 10 сообщений большая часть сообщений относится к группе перегруженных сообщений, а случайные сообщения из других групп сообщений смешаны с пакетом. Это несколько соответствует этой статье: aws.amazon.com/blogs/compute/… Мы подняли этот вопрос с AWS, ждем от них ответа.
После воссоздания поведения в контролируемой среде я понял, насколько эффективен SQS.FIFO при приеме сообщений. Это объясняет, как одной чрезвычайно большой группе сообщений удалось блокировать обработку остальных групп сообщений в течение длительного периода времени из-за огромного количества сообщений, которые она накопила за короткий период времени, когда никакие другие группы сообщений не обрабатывались. населенный.
SQS.FIFO считывает первые 20 000 сообщений во всех группах сообщений, упорядоченных по времени получения.
Я создал эксперимент с 3 группами сообщений, добавив соответственно 21 КБ, 1 КБ и 21 КБ в каждую и отправив их в порядке, указанном выше. Очередь была обработана лямбда-функцией с максимальным размером пакета 10 сообщений. Я ввел задержку в 1 с для лямбда-функции.
Общий размер очереди доступных сообщений составил 42 КБ. Из первых 1000 сообщений в очереди находилось только 10 сообщений. Затем, когда очередь упала до <41k, я увидел 20 сообщений в полете. Так продолжалось до тех пор, пока очередь не опустела. Вот моя мысленная модель того, что произошло в этой очереди. Три группы сообщений представлены синими, зелеными и красными полосами.
Мы не знаем внутреннюю реализацию, но я предполагаю, что ваша первоначальная интерпретация верна, а время прибытия сообщения в очередь является ключевым фактором. Не на 100% понятно, почему предложенная вами альтернатива вообще жизнеспособна, тбх.