Изоляция неудачных заданий в очереди недоставленных сообщений

Введение

Недопустимое задание заказа завершается ошибкой при каждой обработке. Вы ограничите число попыток, сохраните его в отдельной очереди для исследования и подтвердите, что исправные заказы по-прежнему завершаются.

Сначала выполните Работу с тайм-аутом видимости и повторной доставкой и её предварительные пошаговые работы. Эта независимая VM предоставляет обработчик и пустую таблицу заказов; очереди, сообщения и подключение потребителя — ваша работа.

Связь с сертификацией

Обзор лабораторной работы

Подключение исходной очереди к очереди недоставленных сообщений

На этом шаге создайте две пустые очереди Standard и настройте ограниченное перенаправление в исходной очереди.

Очередь недоставленных сообщений (DLQ) сохраняет задания, превысившие предел получений исходной очереди. Используйте AWS View вверху, чтобы сравнивать обе очереди, реальные попытки и сохранённые заказы; сохраняйте эталонные данные.

cd /home/labex/project

Создайте место назначения неудачных заданий и сохраните адрес очереди:

DEAD_URL=$(aws sqs create-queue \
  --queue-name labex-q03-dead \
  --query QueueUrl \
  --output text)
echo "$DEAD_URL"

Политика перенаправления ссылается на ARN места назначения, его идентификатор ресурса сервиса, а не на URL очереди. Выберите этот ARN:

DEAD_ARN=$(aws sqs get-queue-attributes \
  --queue-url "$DEAD_URL" \
  --attribute-names QueueArn \
  --query Attributes.QueueArn \
  --output text)
echo "$DEAD_ARN"

Запишите небольшую политику JSON. Оболочка подставляет ARN места назначения в $DEAD_ARN; maxReceiveCount допускает две попытки доставки, после которых дальнейшее получение переносит сообщение в DLQ.

cat > redrive-policy.json <<EOF
{
  "deadLetterTargetArn": "$DEAD_ARN",
  "maxReceiveCount": 2
}
EOF

Атрибуты очереди SQS представляют политику перенаправления как строку JSON внутри другого документа JSON. --rawfile читает файл политики как эту строку; > записывает файл атрибутов.

jq -n --rawfile policy redrive-policy.json '{VisibilityTimeout:"30",RedrivePolicy:$policy}' > queue-attributes.json

Создайте исходную очередь с этими атрибутами:

QUEUE_URL=$(aws sqs create-queue \
  --queue-name labex-q03-jobs \
  --attributes file://queue-attributes.json \
  --query QueueUrl \
  --output text)
echo "$QUEUE_URL"

aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names QueueArn VisibilityTimeout RedrivePolicy

Ожидайте тайм-аут видимости 30, политику, указывающую на labex-q03-dead, и предел получений 2. Сохраните ARN источника для подключения потребителя:

QUEUE_ARN=$(aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names QueueArn \
  --query Attributes.QueueArn \
  --output text)
echo "$QUEUE_ARN"

AWS View показывает обе пустые очереди, отсутствие выполнения обработчика и заказа. Сама политика перенаправления не обрабатывает сообщения; получение должно происходить через потребителя.

Подключение потребителя и подтверждение исправной обработки

На этом шаге подключите сопоставление источника событий Lambda и проверьте реальную обработку допустимого задания.

Сопоставление опрашивает очередь и вызывает обработчик; успешная обработка позволяет подтвердить сообщение.

Сопоставление источника событий подключает исходную очередь к потребителю Lambda. Оно опрашивает сообщения, передаёт их как событие SQS Records и удаляет успешно обработанные сообщения. Предоставленная роль выполнения имеет только разрешения получения и удаления исходной очереди, записи в таблицу заказов и журналирования. Обработчик отклоняет количества вне диапазона 1–10. Его код и разрешения подготовлены; ваша задача — подключение очереди и изоляция ошибок.

Создайте сопоставление с размером пакета один, чтобы каждая попытка содержала одно задание для проверки:

MAPPING_ID=$(aws lambda create-event-source-mapping \
  --function-name labex-q03-worker \
  --event-source-arn "$QUEUE_ARN" \
  --batch-size 1 \
  --enabled \
  --query UUID \
  --output text)
echo "$MAPPING_ID"

Прочитайте подключение:

aws lambda get-event-source-mapping \
  --uuid "$MAPPING_ID" \
  --query '{Source:EventSourceArn,Function:FunctionArn,Batch:BatchSize,State:State}'

Ожидайте ARN источника labex-q03-jobs, функцию labex-q03-worker, размер пакета 1 и состояние Enabled. Наличие сопоставления — свидетельство конфигурации; реальный сохранённый заказ докажет обработку.

Отправьте исправное задание:

aws sqs send-message \
  --queue-url "$QUEUE_URL" \
  --message-body '{"id":"good-order","quantity":2}'

Наблюдайте AWS View, пока обработчик не вернёт результат и таблица заказов не покажет good-order. Обработка асинхронна; дайте потребителю небольшой интервал, не получая это сообщение вручную. Затем прочитайте заказ:

aws dynamodb get-item \
  --table-name labex-q03-orders \
  --key '{"id":{"S":"good-order"}}' \
  --consistent-read \
  --query Item

Ожидайте количество 2 и сумму 600. Проверьте обе очереди:

aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

aws sqs get-queue-attributes \
  --queue-url "$DEAD_URL" \
  --attribute-names ApproximateNumberOfMessages

Обе очереди должны быть пустыми: обработчик завершил бизнес-запись, а потребитель подтвердил успешное задание. Исправное сообщение не должно попадать в DLQ.

Наблюдение ограниченных повторных попыток и изоляции ошибок

На этом шаге отправьте недопустимое задание и наблюдайте реальные неудачные попытки обработки до того, как перенаправление самого сервиса поместит его в DLQ.

Повторные попытки помогают при временной недоступности зависимости, но ожидание не сделает нулевое количество допустимым. Лимит получений предотвращает бесконечные попытки и сохраняет исходное тело для диагностики. DLQ служит местом расследования; успешная обработка, изоляция сбоя и последующее восстановление — отдельные результаты.

При пределе получений два в этой работе последующее получение переносит неудачное задание в DLQ вместо третьего вызова обработчика.

Проблемное сообщение (poison message) повторно завершается ошибкой из-за своих данных или логики обработки. Отправьте синтетическое недопустимое количество ноль:

aws sqs send-message \
  --queue-url "$QUEUE_URL" \
  --message-body '{"id":"poison-order","quantity":0}'

AWS View показывает неудачную попытку обработчика. Сообщение остаётся в обработке до истечения видимости, затем потребитель может получить его снова. Наблюдайте попытки и счётчики очередей, пока в DLQ не появится одно доступное задание. С этим окном 30 секунд и двумя попытками дайте примерно минуту плюс время обработки. Не получайте и не удаляйте задание вручную во время работы потребителя; это изменило бы число получений и эксперимент.

Две неудачные попытки имеют один идентификатор сообщения и числа получений 1 и 2. Сохранённого заказа для poison-order не появляется. После достижения предела получений последующее получение средствами сервиса переносит сообщение из исходной очереди вместо третьего вызова функции.

Подтвердите состояние очередей через CLI:

aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

aws sqs get-queue-attributes \
  --queue-url "$DEAD_URL" \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

Ожидайте ноль доступных и ноль обрабатываемых заданий в источнике и одно доступное задание в DLQ. AWS View отображает его исходное тело. Проверьте реальные журналы обработчика на недопустимое количество и ошибку:

aws logs filter-log-events \
  --log-group-name /aws/lambda/labex-q03-worker \
  --query 'events[].message'

Прочитайте все записи заказов:

aws dynamodb scan --table-name labex-q03-orders --query Items

Остаётся только good-order/2/600. Ошибка изолирована без отбрасывания сообщения или записи недопустимого заказа. Перемещение в DLQ не является исправлением или успешным бизнес-результатом; восстановление и устранение повторных эффектов заданий изучаются в последующих работах и проектном вызове.

Удаление подключения и ресурсов упражнения

На этом шаге остановите своё подключение потребителя перед удалением очередей и результатов.

Сначала удалите сопоставление источника событий:

aws lambda delete-event-source-mapping --uuid "$MAPPING_ID" --query UUID --output text

Удалите обе временные очереди. Это также отбрасывает синтетическое проблемное задание, сохранённое в DLQ:

aws sqs delete-queue --queue-url "$QUEUE_URL"

aws sqs delete-queue --queue-url "$DEAD_URL"

Удалите исправный заказ и журналы выполнения этой работы:

aws dynamodb delete-item --table-name labex-q03-orders --key '{"id":{"S":"good-order"}}'

aws logs delete-log-group --log-group-name /aws/lambda/labex-q03-worker

Проверьте отсутствие ресурсов и сохранность эталона успешными ответами API:

aws lambda list-event-source-mappings \
  --function-name labex-q03-worker \
  --query EventSourceMappings

aws sqs list-queues

aws dynamodb scan --table-name labex-q03-orders --query Items

aws dynamodb scan --table-name labex-q03-reference --query Items

Списки сопоставлений и заказов пусты, URL очередей не остаётся, а эталонная запись по-прежнему содержит keep unchanged. Предоставленный обработчик и структуры таблиц остаются. AWS View показывает то же состояние ресурсов. Ошибка аутентификации или сети не может доказать удаление.

Удалите обычные локальные файлы политики:

rm -f redrive-policy.json queue-attributes.json

Выполните проверку очистки перед завершением среды.

Резюме

Вы подключили исходную очередь SQS к DLQ с ограниченным числом получений, подключили потребителя Lambda и проверили исправный сохранённый заказ. Вы увидели, как недопустимое задание дважды завершилось ошибкой и перешло в DLQ без бизнес-записи, затем удалили своё сопоставление, очереди, результат и журналы, сохранив предоставленные ресурсы.

Подробнее см. в документации AWS: Очереди недоставленных сообщений и пределы получения; Опрос очередей Lambda, подтверждение и повторная обработка.