Einführung
Ein Bestelldienst muss einen Auftrag jetzt annehmen und später verarbeiten können. Du erstellst eine Warteschlange, empfängst einen Auftrag, führst einen bereitgestellten Worker aus und bestätigst die gespeicherte Bestellung, bevor du die Nachricht bestätigst.
Schließe zuerst DynamoDB aus Lambda lesen und schreiben und dessen angeleitete Voraussetzungen ab. Diese unabhängige VM stellt einen Worker, seine begrenzte Rolle, eine leere Bestelltabelle und Referenzdaten bereit; es ist keine Warteschlange und kein Auftrag vorbereitet.
Bezug zu Zertifizierungen
Dieses Lab bietet praktische Übungen zu den folgenden Prüfungsthemen.
- Cloud Practitioner (CLF-C02) · Aufgabe 3.8: SQS-Nachrichtenzustellung, Verarbeitung und Bestätigung.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 2.1: SQS-Nachrichtenzustellung, Verarbeitung und Bestätigung.
- Developer – Associate (DVA-C02) · Aufgabe 1.1: SQS-Nachrichtenzustellung, Verarbeitung und Bestätigung.
- DevOps Engineer – Professional (DOP-C02) · Aufgabe 5.1: Grundlagenübung: SQS-Nachrichtenzustellung, Verarbeitung und Bestätigung.
- Solutions Architect – Professional (SAP-C02) · Aufgabe 2.4: Grundlagenübung: SQS-Nachrichtenzustellung, Verarbeitung und Bestätigung.
Eine unabhängige Auftragswarteschlange erstellen
Erstelle in diesem Schritt eine leere Warteschlange und untersuche den bereitgestellten Worker, bevor ein Auftrag gesendet wird.
Verwende AWS View neben Terminal, um aktuelle Warteschlangen, Worker-Ergebnisse und gespeicherte Bestellungen zu vergleichen. Erhalte die unbeteiligten Referenzdaten.
Amazon Simple Queue Service (SQS) speichert Aufträge als Nachrichten für einen Verbraucher. Ein Produzent sendet Aufträge, und ein Verbraucher verarbeitet sie. Eine Warteschlange trennt ihre zeitlichen Abläufe: Der Produzent muss nicht warten, bis der Verbraucher fertig ist. Eine Standardwarteschlange kann eine Nachricht mehrmals zustellen; Empfang und Bestätigung sind separate Operationen.
Beginne im vorbereiteten Arbeitsbereich:
cd /home/labex/project
Untersuche den bereitgestellten Worker und die leere Bestelltabelle. Der Worker berechnet 250 Cent pro Artikel plus eine Gebühr von 100 Cent. Seine Ausführungsrolle kann nur in die Bestelltabelle schreiben; die Referenztabelle enthält unbeteiligte Daten, die erhalten bleiben müssen.
aws lambda get-function-configuration --function-name labex-q01-worker --query '{Name:FunctionName,Role:Role,Runtime:Runtime}'
aws dynamodb scan --table-name labex-q01-orders --query Items
Erwarte eine leere Elementliste. Erstelle deine eigene Warteschlange. --query QueueUrl --output text wählt ihre Adresse als Klartext aus; $(...) speichert diese Ausgabe in der Shellvariable QUEUE_URL für spätere Befehle.
QUEUE_URL=$(aws sqs create-queue --queue-name labex-q01-jobs --attributes VisibilityTimeout=300 --query QueueUrl --output text)
Das Sichtbarkeitszeitlimit gibt einem Verbraucher 300 Sekunden, bevor eine empfangene Nachricht wieder verfügbar werden kann. Es verbirgt die Nachricht vorübergehend und löscht sie nicht. Ablauf und erneute Zustellung untersuchen wir im nächsten Lab.
Untersuche die Identität der Warteschlange und die aktuellen Zähler:
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names QueueArn VisibilityTimeout ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Erwarte 300 für VisibilityTimeout und 0 für beide Nachrichtenzähler. Die Zähler sind ungefähre Betriebssignale, keine Garantie für den Abschluss der Geschäftsverarbeitung. In AWS View erscheint deine Warteschlange mit null verfügbaren und null in Bearbeitung befindlichen Aufträgen; die bereitgestellte Lambda-Funktion hat keine Ausführungen, und die Bestelltabelle ist weiterhin leer.
Die offizielle Console zeigt denselben Warteschlangennamen, Typ, URL und ARN, die du mit der CLI untersuchst. Dies sind Beispielwerte; fahre mit deiner eigenen QUEUE_URL fort. Verwende AWS View, um die Ressourcen dieses Labs zu beobachten.
Quelle: AWS SQS.
Einen Bestellauftrag senden und empfangen
Sende in diesem Schritt einen Auftrag und empfange ihn, um den Unterschied zwischen verfügbaren und in Bearbeitung befindlichen Nachrichten zu beobachten.
Empfangen, verarbeiten und dann bestätigen: Lösche die Warteschlangennachricht erst nach Bestätigung der gespeicherten Bestellung und verwende dabei die aktuelle Empfangskennung.
Ein Nachrichteninhalt (Body) besteht aus Anwendungsdaten. SQS hält das JSON als Text vor; dein Verbraucher muss es interpretieren. Sende einen kleinen fiktiven Bestellauftrag:
aws sqs send-message --queue-url "$QUEUE_URL" --message-body '{"id":"queue-order","quantity":2}'
Die Antwort enthält eine MessageId und MD5OfMessageBody. Die Nachrichten-ID bezeichnet die Nachricht; der MD5-Wert fasst die Inhaltsbytes zusammen. Dies bestätigt die Annahme durch die Warteschlange, keine abgeschlossene Bestellung. AWS View zeigt jetzt einen verfügbaren Auftrag, während die Bestelltabelle leer bleibt.
Empfange eine Nachricht und speichere die Antwort. > leitet die Ausgabe in received.json um, statt sie anzuzeigen. --wait-time-seconds 5 ermöglicht eine kurze Long-Polling-Wartezeit, wenn nicht sofort ein Auftrag verfügbar ist.
aws sqs receive-message --queue-url "$QUEUE_URL" --max-number-of-messages 1 --wait-time-seconds 5 --message-system-attribute-names ApproximateReceiveCount --output json > received.json
Lies den sicheren Anwendungsinhalt und die Empfangsanzahl mit jq, das Felder aus JSON auswählt:
jq '.Messages[0] | {MessageId,Body,Attributes}' received.json
Erwarte einen Inhalt mit queue-order und der Menge 2, mit Empfangsanzahl 1 beim ersten Empfang. Die vollständige Antwort enthält außerdem eine Empfangskennung (Receipt Handle): einen Wert für genau diesen Zustellversuch. Du verwendest die neueste Kennung, wenn du diese Nachricht bestätigst.
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Erwarte 0 verfügbare und 1 nicht sichtbare Nachricht. In AWS View ist der Auftrag in Bearbeitung, aber es gibt weiterhin keine Bestellung. Sein Empfang hat ihn weder verarbeitet noch gelöscht. Fahre innerhalb von 300 Sekunden mit dem nächsten Schritt fort. Wenn du länger liest, empfange ihn erneut in dieselbe Datei, um vor Verarbeitung und Löschung seine neueste Empfangskennung zu erhalten.
Dieses tatsächliche Beispiel zeigt die Zustellung vor der Verarbeitung. Nachrichten-IDs unterscheiden sich in deinem Arbeitsbereich.
Den Auftrag vor seiner Bestätigung verarbeiten
Verarbeite in diesem Schritt den empfangenen Inhalt, prüfe die dauerhaft gespeicherte Bestellung und bestätige dann die Nachricht.
Verwende den tatsächlich empfangenen Inhalt als Eingabe für den Worker. fromjson wandelt die JSON-Zeichenfolge innerhalb der SQS-Antwort in ein JSON-Objekt um; die Umleitung schreibt dieses Objekt in job.json.
jq '.Messages[0].Body | fromjson' received.json > job.json
Die bereitgestellte Lambda-Funktion nimmt dieses Bestellobjekt an. Wie im Lambda-Kurs sendet fileb://job.json die Dateibytes, und der abschließende Dateiname nimmt die Antwort der Funktion auf. Rufe den Worker auf:
aws lambda invoke --function-name labex-q01-worker --payload fileb://job.json worker-response.json
Ein erfolgreicher Status der Invoke-API allein belegt keine erfolgreiche Verarbeitung. Untersuche den Antwortinhalt:
cat worker-response.json
Erwarte processed: true, die Menge 2 und total_cents: 600. Lies dann das gespeicherte Element, statt dich nur auf die zurückgegebene Meldung der Funktion zu verlassen:
aws dynamodb get-item --table-name labex-q01-orders --key '{"id":{"S":"queue-order"}}' --consistent-read --query Item
Erwarte queue-order, die Menge 2 und den Gesamtbetrag 600. AWS View zeigt die tatsächliche Worker-Eingabe und das Ergebnis sowie dieselbe dauerhaft gespeicherte Bestellung. Der Auftrag bleibt in Bearbeitung, bis du ihn bestätigst. Wenn entweder die Worker-Antwort oder das gespeicherte Element falsch ist, behalte die Nachricht zur Diagnose, statt sie zu löschen.
Wähle nach Bestätigung der Bestellung die aktuelle Empfangskennung als Klartext aus und lösche diese Zustellung aus der Warteschlange:
RECEIPT_HANDLE=$(jq -r '.Messages[0].ReceiptHandle' received.json)
aws sqs delete-message --queue-url "$QUEUE_URL" --receipt-handle "$RECEIPT_HANDLE"
Eine erfolgreiche Löschung gibt normalerweise nichts aus. Lies die Zähler erneut:
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Beide Zähler sollten 0 sein. AWS View zeigt eine leere Warteschlange und eine gespeicherte Bestellung. Du hast Warteschlangenannahme, vorübergehende Zustellung, Geschäftsverarbeitung und Bestätigung voneinander getrennt. Eine Standardwarteschlange kann in tatsächlichen Anwendungen weiterhin Nachrichten erneut zustellen; diese Abfolge ist keine durchgängige Genau-einmal-Garantie. Spätere Einheiten vermitteln einen dauerhaften Duplikatschutz.
Nur deine Warteschlange und Ergebnisse bereinigen
Entferne in diesem Schritt deine Warteschlange, dein Ergebnis und deine Logs und erhalte dabei die bereitgestellten Ressourcen.
Entferne die Warteschlange und die Bestellung, die du erstellt hast, und erhalte dabei den bereitgestellten Worker, die Tabellenstrukturen und die Referenzdaten. Das Löschen der Warteschlange verwirft alle verbleibenden Aufträge. Bestätige daher zuerst, dass der vorherige Schritt erfolgreich abgeschlossen wurde.
aws sqs delete-queue --queue-url "$QUEUE_URL"
aws dynamodb delete-item --table-name labex-q01-orders --key '{"id":{"S":"queue-order"}}'
Die Worker-Ausführung hat eine CloudWatch-Logs-Gruppe erstellt. Lösche die Ausführungslogs dieses Labs im Rahmen der Bereinigung:
aws logs delete-log-group --log-group-name /aws/lambda/labex-q01-worker
Prüfe den Ressourcenzustand mit erfolgreichen Dienstabfragen:
aws sqs list-queues
aws dynamodb scan --table-name labex-q01-orders --query Items
aws dynamodb scan --table-name labex-q01-reference --query Items
Es sollten keine Warteschlangen-URLs mehr vorhanden sein, die Elementliste der Bestellungen sollte leer sein, und das Referenzelement muss weiterhin keep unchanged enthalten. AWS View zeigt keine Warteschlangen, Bestellungen oder Ausführungslogs, während bereitgestellter Worker und Referenz weiterhin vorhanden sind. Ein Authentifizierungs- oder Netzwerkfehler ist kein Beleg für eine erfolgreiche Löschung.
Entferne die gewöhnlichen Antwortdateien nach der Prüfung der Ressourcen:
rm -f received.json job.json worker-response.json
Führe die Schrittprüfung aus, bevor du deine Umgebung beendest.
Zusammenfassung
Du hast eine SQS-Standardwarteschlange erstellt, einen JSON-Bestellauftrag gesendet und empfangen, die tatsächliche Lambda-Verarbeitung und das dauerhaft gespeicherte DynamoDB-Element geprüft und die Nachricht mit ihrer Empfangskennung bestätigt. Du hast Annahme, laufende Zustellung und Geschäftsabschluss unterschieden und anschließend deine Warteschlange, Bestellung und Ausführungslogs entfernt, während die bereitgestellten Ressourcen erhalten blieben.
