Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Laufzeit von Node.js für verwaltete Lambda-Instanzen

Für Laufzeiten von Node.js verwendet Lambda Managed Instances Worker-Threads mitasync/await-basierter Ausführung, um gleichzeitige Anfragen zu verarbeiten. Die Funktionsinitialisierung erfolgt einmal pro Worker-Thread. Gleichzeitige Aufrufe werden in zwei Dimensionen verarbeitet: Worker-Threads sorgen für Parallelität in VCPUs, und asynchrone Ausführung sorgt für Parallelität innerhalb jedes Threads. Jede gleichzeitige Anforderung, die von demselben Worker-Thread bearbeitet wird, verwendet dasselbe Handler-Objekt und denselben globalen Status, sodass eine sichere Behandlung bei mehreren gleichzeitigen Anfragen erforderlich ist.

Maximale Parallelität

Die maximale Anzahl gleichzeitiger Anfragen, die Lambda an jede Ausführungsumgebung sendet, wird durch die PerExecutionEnvironmentMaxConcurrency Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert variiert je nach Laufzeit. Für Laufzeiten von Node.js sind standardmäßig 64 gleichzeitige Anfragen pro vCPU festgelegt, oder Sie können Ihren eigenen Wert konfigurieren. Lambda passt die Anzahl der gleichzeitigen Anfragen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität jeder Ausführungsumgebung, um diese Anfragen aufzunehmen.

Bei Node.js wird die Anzahl der gleichzeitigen Anfragen, die jede Ausführungsumgebung verarbeiten kann, durch die Anzahl der Worker-Threads und die Kapazität jedes Worker-Threads bestimmt, gleichzeitige Anfragen asynchron zu verarbeiten. Die Standardanzahl von Worker-Threads wird durch die Anzahl der CPUs verfügbaren V bestimmt. Sie können die Anzahl der Worker-Threads auch konfigurieren, indem Sie die AWS_LAMBDA_NODEJS_WORKER_COUNT Umgebungsvariable festlegen. Wir empfehlen die Verwendung von asynchronen Funktionshandlern, da dies die Verarbeitung mehrerer Anfragen pro Worker-Thread ermöglicht. Wenn Ihr Funktionshandler synchron ist, kann jeder Worker-Thread jeweils nur eine einzelne Anfrage verarbeiten.

Funktionen für Mehrfachparallelität erstellen

Mit einem asynchronen Funktionshandler verarbeitet jeder Runtime-Worker mehrere Anfragen gleichzeitig. Globale Objekte werden von mehreren gleichzeitigen Anfragen gemeinsam genutzt. Vermeiden Sie bei veränderlichen Objekten die Verwendung von global state or use. AsyncLocalStorage

AWS SDK-Clients sind asynchron-sicher und erfordern keine besondere Behandlung.

Beispiel: Globaler Status

Der folgende Code verwendet ein globales Objekt, das innerhalb des Funktionshandlers mutiert ist. Das ist nicht asynchron-sicher.

let state = {
    currentUser: null,
    requestData: null
};

export const handler = async (event, context) => {
    state.currentUser = event.userId;
    state.requestData = event.data;

    await processData(state.requestData);

    // state.currentUser might now belong to a different request
    return { user: state.currentUser };
};

Durch die Initialisierung des state Objekts innerhalb des Funktionshandlers wird ein gemeinsamer globaler Status vermieden.

export const handler = async (event, context) => {
    let state = {
        currentUser: event.userId,
        requestData: event.data
    };
    
    await processData(state.requestData);

    return { user: state.currentUser };
};

Beispiel: Datenbankverbindungen

Der folgende Code verwendet ein gemeinsames Client-Objekt, das von mehreren Aufrufen gemeinsam genutzt wird. Je nach verwendeter Verbindungsbibliothek ist dies möglicherweise nicht sicher für Parallelität.

const { Client } = require('pg');

// Single connection created at init time
const client = new Client({
  host: process.env.DB_HOST,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD
});

// Connect once during cold start
client.connect();

exports.handler = async (event) => {
  // Multiple parallel invocations share this single connection = BAD
  // With multi-concurrent Lambda, queries will collide
  const result = await client.query('SELECT * FROM users WHERE id = $1', [event.userId]);
  
  return {
    statusCode: 200,
    body: JSON.stringify(result.rows[0])
  };
};

Ein Ansatz, der die Parallelität sicherstellt, besteht darin, einen Verbindungspool zu verwenden. Der Pool verwendet für jede gleichzeitige Datenbankabfrage eine separate Verbindung.

const { Pool } = require('pg');

// Connection pool created at init time
const pool = new Pool({
  host: process.env.DB_HOST,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  max: 20,  // Max connections in pool
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 2000
});

exports.handler = async (event) => {
  // Pool gives each parallel invocation its own connection
  const result = await pool.query('SELECT * FROM users WHERE id = $1', [event.userId]);
  
  return {
    statusCode: 200,
    body: JSON.stringify(result.rows[0])
  };
};

Node.js 22 Callback-basierte Handler

Wenn Sie Node.js 22 verwenden, können Sie keinen Callback-basierten Funktionshandler mit Lambda Managed Instances verwenden. Callback-basierte Handler werden nur für Lambda-Funktionen (Standard) unterstützt. Für Laufzeiten von Node.js 24 und höher sind Callback-basierte Funktionshandler sowohl für Lambda (Standard) als auch für Lambda Managed Instances veraltet.

Verwenden Sie stattdessen einen async Funktionshandler, wenn Sie Lambda Managed Instances verwenden. Weitere Informationen finden Sie unter Definieren des Lambda-Funktionshandlers in Node.js.

Gemeinsames /tmp-Verzeichnis

Das /tmp Verzeichnis wird von allen gleichzeitigen Anfragen in der Ausführungsumgebung gemeinsam genutzt. Gleichzeitige Schreibvorgänge in dieselbe Datei können zu Datenbeschädigungen führen, z. B. wenn ein anderer Prozess die Datei überschreibt. Um dieses Problem zu lösen, implementieren Sie entweder Dateisperren für gemeinsam genutzte Dateien oder verwenden Sie eindeutige Dateinamen pro Anfrage, um Konflikte zu vermeiden. Denken Sie daran, nicht benötigte Dateien zu bereinigen, um zu vermeiden, dass der verfügbare Speicherplatz aufgebraucht wird.

Protokollierung

Das Verschachteln von Protokollen (Protokolleinträge verschiedener Anfragen, die in Protokollen verschachtelt werden) ist bei Systemen mit mehreren gleichzeitigen Vorgängen normal. Funktionen, die Lambda Managed Instances verwenden, verwenden immer das strukturierte JSON-Protokollformat, das mit erweiterten Protokollierungssteuerungen eingeführt wurde. Dieses Format beinhaltet dierequestId, sodass Protokolleinträge mit einer einzigen Anfrage korreliert werden können. Wenn Sie den console Logger verwenden, requestId ist er automatisch in jedem Protokolleintrag enthalten. Weitere Informationen finden Sie unter Erweiterte Lambda-Protokollierungssteuerelemente mit Node.js verwenden.

Beliebte Protokollierungsbibliotheken von Drittanbietern, wie Winston, unterstützen in der Regel die Verwendung der Konsole für die Protokollausgabe.

Kontext anfordern

context.awsRequestIdDie Verwendung ermöglicht einen asynchronen Zugriff auf die Anforderungs-ID für die aktuelle Anfrage.

Wird verwendetcontext.xRayTraceId, um auf die X-Ray-Trace-ID zuzugreifen. Dies ermöglicht einen parallelen Zugriff auf die Trace-ID für die aktuelle Anfrage. Lambda unterstützt die _X_AMZN_TRACE_ID Umgebungsvariable bei Lambda Managed Instances nicht. Die X-Ray-Trace-ID wird bei Verwendung des AWS SDK automatisch weitergegeben.

Initialisierung und Herunterfahren

Die Funktionsinitialisierung erfolgt einmal pro Worker-Thread. Möglicherweise werden Protokolleinträge wiederholt, wenn Ihre Funktion während der Initialisierung Protokolle ausgibt.

Bei Lambda-Funktionen mit Erweiterungen gibt die Ausführungsumgebung beim Herunterfahren ein SIGTERM-Signal aus. Dieses Signal wird von Erweiterungen verwendet, um Bereinigungsaufgaben wie das Leeren von Puffern auszulösen. Lambda-Funktionen (Standard) mit Erweiterungen können das SIGTERM-Signal auch abonnieren, indem process.on() Dies wird für Funktionen, die Lambda Managed Instances verwenden, nicht unterstützt, da es process.on() nicht mit Worker-Threads verwendet werden kann. Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter Grundlegendes zum Lebenszyklus der Lambda-Ausführungsumgebung.

Versionen von Abhängigkeiten

Für Lambda Managed Instances sind die folgenden Mindestpaketversionen erforderlich:

Elektrowerkzeuge für AWS Lambda () TypeScript

Powertools for AWS Lambda (TypeScript) ist mit Lambda Managed Instances kompatibel und bietet Dienstprogramme für Logging, Tracing, Metriken und mehr. Weitere Informationen finden Sie unter Powertools for AWS Lambda () TypeScript.

Nächste Schritte