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 ](https://doc.rust-lang.org/std/clone/trait.Clone.html) \+ [ Send implementieren. ](https://doc.rust-lang.org/std/marker/trait.Send.html) 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 ](https://doc.rust-lang.org/std/sync/struct.Arc.html) 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| {
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 ](https://doc.rust-lang.org/std/sync/struct.Arc.html) 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| {
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](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) Dieses Format beinhaltet das`requestId`, sodass Logeinträge einer einzelnen Anfrage zugeordnet werden können. Weitere Informationen finden Sie unter[Implementierung der erweiterten Protokollierung mit der Tracing Crate](rust-logging.md#rust-logging-tracing).
## Kontext anfordern
Das `Context` Objekt wird direkt an jeden Handleraufruf übergeben. Wird verwendet`event.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 verwendet`event.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_runtime`bietet mit [ spawn\_graceful\_shutdown\_handler () ein Hilfsprogramm, das die Konfiguration der ordnungsgemäßen Signalverarbeitung beim Herunterfahren vereinfacht. ](https://docs.rs/lambda_runtime/latest/lambda_runtime/fn.spawn_graceful_shutdown_handler.html) Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter [Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung](lambda-runtime-environment.md).
## Versionen, die abhängig sind
Für Lambda Managed Instances ist die folgende Mindestpaketversion erforderlich:
+ `lambda_runtime`: Version 1.1.1 oder höher, mit aktivierter Funktion `concurrency-tokio`
+ Die unterstützte Mindestversion von Rust (MSRV) ist 1.84.0.