Введение
Недопустимое задание заказа завершается ошибкой при каждой обработке. Вы ограничите число попыток, сохраните его в отдельной очереди для исследования и подтвердите, что исправные заказы по-прежнему завершаются.
Сначала выполните Работу с тайм-аутом видимости и повторной доставкой и её предварительные пошаговые работы. Эта независимая VM предоставляет обработчик и пустую таблицу заказов; очереди, сообщения и подключение потребителя — ваша работа.
Связь с сертификацией
Эта лабораторная работа помогает на практике изучить следующие темы экзаменов.
- Solutions Architect – Associate (SAA-C03) · Задача 2.1: Ограниченная обработка сообщений и изоляция неудачных заданий.
- Developer – Associate (DVA-C02) · Задача 1.1: Ограниченная обработка сообщений и изоляция неудачных заданий.
- DevOps Engineer – Professional (DOP-C02) · Задача 5.1: Базовая практика: Ограниченная обработка сообщений и изоляция неудачных заданий.
- Solutions Architect – Professional (SAP-C02) · Задача 2.4: Базовая практика: Ограниченная обработка сообщений и изоляция неудачных заданий.
Подключение исходной очереди к очереди недоставленных сообщений
На этом шаге создайте две пустые очереди Standard и настройте ограниченное перенаправление в исходной очереди.
Очередь недоставленных сообщений (DLQ) сохраняет задания, превысившие предел получений исходной очереди. Используйте AWS View рядом с Terminal, чтобы сравнивать обе очереди, реальные попытки и сохранённые заказы; сохраняйте эталонные данные.
cd /home/labex/project
Создайте место назначения неудачных заданий и сохраните адрес очереди:
DEAD_URL=$(aws sqs create-queue --queue-name labex-q03-dead --query QueueUrl --output text)
Политика перенаправления ссылается на ARN места назначения, его идентификатор ресурса сервиса, а не на URL очереди. Выберите этот ARN:
DEAD_ARN=$(aws sqs get-queue-attributes --queue-url "$DEAD_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
Запишите небольшую политику 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)
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)
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)
Прочитайте подключение:
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 вместо третьего вызова обработчика.
Проблемное сообщение (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 без бизнес-записи, затем удалили своё сопоставление, очереди, результат и журналы, сохранив предоставленные ресурсы.
