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.

Rust-Unterstützung für Lambda Managed Instances

Konfiguration der Parallelität

Die maximale Anzahl gleichzeitiger Anforderungen, die Lambda an jede Ausführungsumgebung sendet, wird durch die PerExecutionEnvironmentMaxConcurrency Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert für Rust ist 8 gleichzeitige Anforderungen pro vCPU, oder Sie können Ihren eigenen Wert konfigurieren. Dieser Wert bestimmt die Anzahl der Tokio-Aufgaben, die von der Laufzeit ausgelöst werden, und ist für die gesamte Lebensdauer der Ausführungsumgebung statisch. Jeder Worker verarbeitet jeweils genau eine Inflight-Anfrage, ohne dass ein Multiplexing pro Worker erforderlich ist. Lambda passt die Anzahl der gleichzeitigen Anforderungen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität der einzelnen Ausführungsumgebungen, diese Anforderungen zu verarbeiten.

Erstellung von Funktionen für Mehrfachparallelität

Sie sollten bei der Verwendung von Lambda Managed Instances dieselben Thread-Sicherheitspraktiken anwenden wie in jeder anderen Multithread-Umgebung. Da das Handler-Objekt von allen Worker-Threads gemeinsam genutzt wird, muss jeder veränderbare Status threadsicher sein. Dazu gehören Sammlungen, Datenbankverbindungen und alle statischen Objekte, die während der Anforderungsverarbeitung geändert werden.

Um die gleichzeitige Bearbeitung von Anfragen zu ermöglichen, fügen Sie Ihrer Cargo.toml Datei das concurrency-tokio Feature-Flag hinzu.

[dependencies]  
lambda_runtime = { version = "1", features = ["concurrency-tokio"] }

Der lambda_runtime::run_concurrent(…) Einstiegspunkt muss innerhalb einer Tokio-Laufzeit aufgerufen werden, was in der Regel durch das #[tokio::main] Attribut Ihrer Hauptfunktion bereitgestellt wird. Ihr Handler-Closure muss Clone + Send implementieren. Dadurch kann das Framework Ihren Handler sicher für mehrere asynchrone Aufgaben gemeinsam nutzen. Wenn diese Grenzen nicht eingehalten werden, wird Ihr Code nicht kompiliert.

Wenn Sie einen gemeinsamen Status für alle Aufrufe benötigen (ein Datenbankpool, eine Konfigurationsstruktur), packen Sie ihn in Arc ein und klonen Sie ihn Arc in jeden Aufruf.

Alle AWS SDK für Rust-Clients sind gleichzeitig sicher und erfordern keine besondere Behandlung.

Beispiel: AWS SDK-Client

Das folgende Beispiel verwendet einen S3-Client, um bei jedem Aufruf ein Objekt hochzuladen. Der Client wird direkt in die Closure geklont, ohne: Arc

let config = aws_config::load_defaults(BehaviorVersion::latest()).await;  
let s3_client = aws_sdk_s3::Client::new(&config);  
  
run_concurrent(service_fn(move |event: LambdaEvent<Request>| {  
    let s3_client = s3_client.clone(); // cheap clone, no Arc needed  
    async move {  
        s3_client.put_object()  
            .bucket(&event.payload.bucket)  
            .key(&event.payload.key)  
            .body(event.payload.body.into_bytes().into())  
            .send()  
            .await?;  
        Ok(Response { message: "uploaded".into() })  
    }  
}))  
.await

Beispiel: Datenbank-Verbindungspools

Wenn Ihr Handler Zugriff auf einen gemeinsamen Status wie einen Client und eine Konfiguration benötigt, packen Sie ihn in Arc ein und klonen Sie den Arc bei jedem Aufruf:

#[derive(Debug)]  
struct AppState {  
    dynamodb_client: DynamoDbClient,  
    table_name: String,  
    cache_ttl: Duration,  
}  
  
let config = aws_config::load_defaults(BehaviorVersion::latest()).await;  
let state = Arc::new(AppState {  
    dynamodb_client: DynamoDbClient::new(&config),  
    table_name: std::env::var("TABLE_NAME").expect("TABLE_NAME must be set"),  
    cache_ttl: Duration::from_secs(300),  
});  
  
run_concurrent(service_fn(move |event: LambdaEvent<Request>| {  
    let state = state.clone();  
    async move { handle(event, state).await }  
}))  
.await

Gemeinsames /tmp-Verzeichnis

Das /tmp Verzeichnis wird von allen gleichzeitigen Aufrufen in derselben Ausführungsumgebung gemeinsam genutzt. Verwenden Sie eindeutige Dateinamen pro Aufruf (schließen Sie beispielsweise die Anforderungs-ID ein) oder implementieren Sie explizite Dateisperren, um Datenbeschädigungen zu vermeiden.

Protokollierung

Das Verschachteln von Protokollen (die Verschachtelung von Protokolleinträgen aus verschiedenen Anfragen in Protokollen) ist in Systemen mit mehreren parallelen Vorgängen normal. Funktionen, die Lambda Managed Instances verwenden, unterstützen das strukturierte JSON-Protokollformat mithilfe der fortschrittlichen Protokollierungssteuerungen von Lambda. Konfigurieren erweiterter Protokollierungsoptionen für Lambda-Funktionen Dieses Format beinhaltet dasrequestId, sodass Logeinträge einer einzelnen Anfrage zugeordnet werden können. Weitere Informationen finden Sie unterImplementierung der erweiterten Protokollierung mit der Tracing Crate.

Kontext anfordern

Das Context Objekt wird direkt an jeden Handleraufruf übergeben. Wird verwendetevent.context.request_id, um auf die Anforderungs-ID für die aktuelle Anfrage zuzugreifen.

Wird event.context.xray_trace_id für den Zugriff auf die X-Ray Trace-ID verwendet. Lambda unterstützt die _X_AMZN_TRACE_ID Umgebungsvariable mit Lambda Managed Instances nicht. Die X-Ray Trace-ID wird automatisch weitergegeben, wenn Sie das AWS SDK für Rust verwenden.

Wird verwendetevent.context.deadline, um Timeouts zu erkennen — sie enthält die Frist für den Aufruf in Millisekunden.

Initialisierung und Herunterfahren

Die Funktionsinitialisierung erfolgt einmal pro Ausführungsumgebung. Objekte, die während der Initialisierung erstellt wurden, werden von allen Anfragen gemeinsam genutzt.

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_runtimebietet mit spawn_graceful_shutdown_handler () ein Hilfsprogramm, das die Konfiguration der ordnungsgemäßen Signalverarbeitung beim Herunterfahren vereinfacht. Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung.

Versionen, die abhängig sind

Für Lambda Managed Instances ist die folgende Mindestpaketversion erforderlich: