Introdução
Uma tarefa de pedido inválida falha sempre que o consumidor a processa. Você limitará suas tentativas, manterá a tarefa em uma fila separada para investigação e confirmará que pedidos válidos continuam sendo concluídos.
Conclua primeiro Gerencie o Tempo Limite de Visibilidade e a Nova Entrega e seus pré-requisitos guiados. Esta VM independente fornece um consumidor e uma tabela de pedidos vazia; as filas, as mensagens e a conexão do consumidor são seu trabalho.
Relação com as certificações
Este laboratório oferece prática nos seguintes tópicos de exame.
- Solutions Architect – Associate (SAA-C03) · Tarefa 2.1: Processamento limitado de mensagens e isolamento de trabalhos com falha.
- Developer – Associate (DVA-C02) · Tarefa 1.1: Processamento limitado de mensagens e isolamento de trabalhos com falha.
- DevOps Engineer – Professional (DOP-C02) · Tarefa 5.1: Prática dos fundamentos: Processamento limitado de mensagens e isolamento de trabalhos com falha.
- Solutions Architect – Professional (SAP-C02) · Tarefa 2.4: Prática dos fundamentos: Processamento limitado de mensagens e isolamento de trabalhos com falha.
Conecte uma Fila de Origem a uma Fila de Mensagens Mortas
Nesta etapa, crie duas filas Standard vazias e configure o redirecionamento com um limite de recebimentos na fila de origem.
Uma fila de mensagens mortas (DLQ) mantém tarefas que excedem o limite de recebimentos de uma fila de origem. Use AWS View ao lado do Terminal para comparar as duas filas, as tentativas reais e os pedidos armazenados; preserve os dados de referência.
cd /home/labex/project
Crie o destino para tarefas com falha e salve o endereço da fila:
DEAD_URL=$(aws sqs create-queue --queue-name labex-q03-dead --query QueueUrl --output text)
A política de redirecionamento referencia o ARN do destino, seu identificador de recurso no serviço, em vez da URL da fila. Selecione esse ARN:
DEAD_ARN=$(aws sqs get-queue-attributes --queue-url "$DEAD_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
Escreva uma pequena política JSON. O shell insere seu ARN de destino em $DEAD_ARN; maxReceiveCount permite duas tentativas de entrega antes que um recebimento posterior mova a mensagem para a DLQ.
cat > redrive-policy.json <<EOF
{
"deadLetterTargetArn": "$DEAD_ARN",
"maxReceiveCount": 2
}
EOF
Os atributos de fila do SQS representam a política de redirecionamento como uma string JSON dentro de outro documento JSON. --rawfile lê o arquivo da política como essa string; > grava o arquivo de atributos.
jq -n --rawfile policy redrive-policy.json '{VisibilityTimeout:"30",RedrivePolicy:$policy}' > queue-attributes.json
Crie a fila de origem com esses atributos:
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
Espere o tempo limite de visibilidade 30, uma política apontando para labex-q03-dead e o limite de recebimentos 2. Salve o ARN de origem para a conexão do consumidor:
QUEUE_ARN=$(aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
AWS View mostra as duas filas vazias, nenhuma execução do consumidor e nenhum pedido. Uma política de redirecionamento não processa mensagens por si só; o recebimento deve ocorrer por meio de um consumidor.
Conecte o Consumidor e Comprove o Processamento de uma Tarefa Válida
Nesta etapa, conecte um mapeamento de origem de eventos do Lambda e verifique o processamento real de uma tarefa válida.
O mapeamento consulta a fila e invoca o consumidor; o processamento bem-sucedido permite confirmar a mensagem.
Um mapeamento de origem de eventos conecta a fila de origem a um consumidor Lambda. Ele consulta mensagens, passa-as como um evento SQS Records e exclui as mensagens tratadas com sucesso. A função de execução fornecida tem apenas permissões de recebimento e exclusão na fila de origem, gravação na tabela de pedidos e registro de logs. O consumidor rejeita quantidades fora de 1–10. Seu código e suas permissões são recursos de apoio fornecidos; sua tarefa é conectar a fila e isolar falhas.
Crie um mapeamento com tamanho de lote um para que cada tentativa tenha uma tarefa a inspecionar:
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)
Leia a conexão:
aws lambda get-event-source-mapping --uuid "$MAPPING_ID" --query '{Source:EventSourceArn,Function:FunctionArn,Batch:BatchSize,State:State}'
Espere o ARN de origem de labex-q03-jobs, a função labex-q03-worker, o tamanho de lote 1 e o estado Enabled. A existência do mapeamento comprova a configuração; um pedido real armazenado comprovará o processamento.
Envie uma tarefa válida:
aws sqs send-message --queue-url "$QUEUE_URL" --message-body '{"id":"good-order","quantity":2}'
Observe AWS View até o consumidor retornar um resultado e a tabela de pedidos mostrar good-order. O processamento é assíncrono; aguarde um breve intervalo pelo consumidor em vez de receber essa mensagem manualmente. Depois, leia o pedido:
aws dynamodb get-item --table-name labex-q03-orders --key '{"id":{"S":"good-order"}}' --consistent-read --query Item
Espere quantidade 2 e total 600. Verifique as duas filas:
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
As duas filas devem estar vazias: o consumidor concluiu a gravação de negócio e confirmou a tarefa bem-sucedida. Uma mensagem válida não deve ir para a DLQ.
Observe Tentativas Limitadas e o Isolamento de Falhas
Nesta etapa, envie uma tarefa inválida e observe tentativas reais de processamento com falha antes que o redirecionamento nativo a coloque na DLQ.
Com o limite de dois recebimentos deste laboratório, um recebimento posterior move a tarefa com falha para a DLQ em vez de invocar o consumidor uma terceira vez.
Uma mensagem problemática (poison message) falha repetidamente por causa de seus dados ou da lógica de tratamento. Envie uma quantidade sintética inválida de zero:
aws sqs send-message --queue-url "$QUEUE_URL" --message-body '{"id":"poison-order","quantity":0}'
AWS View mostra a tentativa com falha do consumidor. A mensagem permanece em processamento até sua visibilidade expirar; depois, o consumidor pode recebê-la novamente. Observe as tentativas e as contagens das filas até a DLQ ter uma tarefa disponível. Com essa janela de 30 segundos e duas tentativas, aguarde aproximadamente um minuto mais o tempo de processamento. Não receba nem exclua a tarefa manualmente enquanto o consumidor estiver em execução; isso alteraria as contagens de recebimentos e o experimento.
As duas tentativas com falha têm o mesmo ID de mensagem e contagens de recebimentos 1 e 2. Nenhum pedido armazenado aparece para poison-order. Após atingir o limite de recebimentos, um recebimento nativo subsequente move a mensagem para fora da fila de origem em vez de invocar a função uma terceira vez.
Confirme o estado das filas pela 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
Espere que a origem tenha zero tarefas disponíveis e zero em processamento, com uma tarefa disponível na DLQ. AWS View exibe seu corpo original. Inspecione os logs reais do consumidor para ver a quantidade inválida e a falha:
aws logs filter-log-events --log-group-name /aws/lambda/labex-q03-worker --query 'events[].message'
Leia todos os itens de pedidos:
aws dynamodb scan --table-name labex-q03-orders --query Items
Apenas good-order/2/600 permanece. A falha foi isolada sem descartar sua mensagem nem gravar um pedido inválido. Mover para uma DLQ não é uma correção nem um resultado de negócio bem-sucedido; a recuperação de tarefas e a proteção contra duplicatas vêm em unidades posteriores e no desafio de projeto.
Remova a Conexão e os Recursos que Você Criou
Nesta etapa, interrompa sua conexão do consumidor antes de excluir as filas e os resultados.
Remova primeiro o mapeamento de origem de eventos:
aws lambda delete-event-source-mapping --uuid "$MAPPING_ID" --query UUID --output text
Exclua as duas filas descartáveis. Isso também descarta a tarefa problemática sintética mantida na DLQ:
aws sqs delete-queue --queue-url "$QUEUE_URL"
aws sqs delete-queue --queue-url "$DEAD_URL"
Remova o pedido válido e os logs de execução deste laboratório:
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
Verifique a ausência dos recursos e a preservação da referência com respostas bem-sucedidas da 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
As listas de mapeamentos e pedidos estão vazias, nenhuma URL de fila permanece e o item de referência ainda diz keep unchanged. O consumidor fornecido e as estruturas das tabelas permanecem. AWS View mostra o mesmo estado dos recursos. Falhas de autenticação ou de rede não comprovam a exclusão.
Remova os arquivos locais comuns de política:
rm -f redrive-policy.json queue-attributes.json
Execute a verificação da limpeza antes de encerrar o ambiente.
Resumo
Você conectou uma fila de origem SQS a uma DLQ com um limite de recebimentos, anexou um consumidor Lambda e verificou um pedido válido armazenado. Você observou uma tarefa inválida falhar duas vezes e ir para a DLQ sem uma gravação de negócio e, depois, removeu seu mapeamento, suas filas, seu resultado e seus logs, preservando os recursos fornecidos.
