AWS SQS.FIFO считывает первые 20 000 сообщений, чтобы определить группы сообщений. Каков порядок чтения?

Какой механизм использует 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 тыс. сообщений, чтобы определить доступные группы сообщений. Это означает, что если у вас есть отставание сообщения в одной группе сообщений, вы не можете использовать сообщения из другие группы сообщений, которые были отправлены в очередь позже, пока вы успешно используете сообщения из невыполненной работы.

Мы не знаем внутреннюю реализацию, но я предполагаю, что ваша первоначальная интерпретация верна, а время прибытия сообщения в очередь является ключевым фактором. Не на 100% понятно, почему предложенная вами альтернатива вообще жизнеспособна, тбх.

jarmod 07.02.2023 13:25

Я согласен, время кажется разумной мерой порядка, однако мы запускаем SQS.FIFO в производственной среде, и всякий раз, когда одна группа сообщений перегружается, мы видим значительное снижение параллелизма на лямбда-потребителях и задержки в обработке остальные группы сообщений. Опять же, использование времени в качестве упорядочения в этом не имеет смысла.

nnedoklanov 07.02.2023 14:30

Это интересно. Схема прибытия на самом деле такая же, как вы описали в своем посте? Вы уже подняли вопрос о поддержке с AWS или это будет шагом в будущем, если это необходимо?

jarmod 07.02.2023 16:06

В пакете из 10 сообщений большая часть сообщений относится к группе перегруженных сообщений, а случайные сообщения из других групп сообщений смешаны с пакетом. Это несколько соответствует этой статье: aws.amazon.com/blogs/compute/… Мы подняли этот вопрос с AWS, ждем от них ответа.

nnedoklanov 07.02.2023 16:12

После воссоздания поведения в контролируемой среде я понял, насколько эффективен SQS.FIFO при приеме сообщений. Это объясняет, как одной чрезвычайно большой группе сообщений удалось блокировать обработку остальных групп сообщений в течение длительного периода времени из-за огромного количества сообщений, которые она накопила за короткий период времени, когда никакие другие группы сообщений не обрабатывались. населенный.

nnedoklanov 09.02.2023 22:51
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
2
5
57
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

SQS.FIFO считывает первые 20 000 сообщений во всех группах сообщений, упорядоченных по времени получения.

Я создал эксперимент с 3 группами сообщений, добавив соответственно 21 КБ, 1 КБ и 21 КБ в каждую и отправив их в порядке, указанном выше. Очередь была обработана лямбда-функцией с максимальным размером пакета 10 сообщений. Я ввел задержку в 1 с для лямбда-функции.

Общий размер очереди доступных сообщений составил 42 КБ. Из первых 1000 сообщений в очереди находилось только 10 сообщений. Затем, когда очередь упала до <41k, я увидел 20 сообщений в полете. Так продолжалось до тех пор, пока очередь не опустела. Вот моя мысленная модель того, что произошло в этой очереди. Три группы сообщений представлены синими, зелеными и красными полосами.

Другие вопросы по теме