

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.

# Optimieren Sie Kinesis Data Streams Streams-Produzenten
<a name="advanced-producers"></a>

Sie können Ihre Amazon Kinesis Data Streams Streams-Producer je nach dem spezifischen Verhalten, das Sie beobachten, weiter optimieren. Sehen Sie sich die folgenden Themen an, um Lösungen zu finden.

**Topics**
+ [Passen Sie KPL-Wiederholungsversuche und das Verhalten bei der Ratenbegrenzung an](kinesis-producer-adv-retries-rate-limiting.md)
+ [Wenden Sie bewährte Methoden auf die KPL-Aggregation an](kinesis-producer-adv-aggregation.md)

# Passen Sie KPL-Wiederholungsversuche und das Verhalten bei der Ratenbegrenzung an
<a name="kinesis-producer-adv-retries-rate-limiting"></a>

Wenn Sie Benutzerdatensätze der Amazon Kinesis Producer Library (KPL) mithilfe des `addUserRecord()` KPL-Vorgangs hinzufügen, erhält ein Datensatz einen Zeitstempel und wird einem Puffer hinzugefügt, dessen Frist durch den `RecordMaxBufferedTime` Konfigurationsparameter festgelegt wird. Diese stamp/deadline Zeitkombination legt die Pufferpriorität fest. Datensätze werden aufgrund der folgenden Kriterien aus dem Puffer entfernt:
+ Puffer-Priorität
+ Aggregierungskonfiguration
+ Sammlungskonfiguration

Die Parameter der Aggregierungskonfiguration und der Sammlungskonfiguration, die das Pufferverhalten beeinflussen, sind:
+ `AggregationMaxCount`
+ `AggregationMaxSize`
+ `CollectionMaxCount`
+ `CollectionMaxSize`

Die gelöschten Datensätze werden dann mithilfe eines Aufrufs der API-Operation `PutRecords` von Kinesis Data Streams als Datensätze von Amazon Kinesis Data Streams an Ihren Kinesis-Datenstrom gesendet. Die Operation `PutRecords` sendet Anfragen an Ihre Stream, die gelegentlich vollständige oder teilweise Fehlschläge zeigen. Fehlgeschlagene Datensätze werden automatisch wieder dem KPL-Puffer hinzugefügt. Die neue Frist wird auf der Grundlage des kleineren dieser beiden Werte festgelegt: 
+ Die Hälfte der aktuellen `RecordMaxBufferedTime`-Konfiguration
+ Der time-to-live Wert des Datensatzes

Mit dieser Strategie können erneut versuchte KPL-Benutzerdatensätze in nachfolgende Kinesis Data Streams Streams-API-Aufrufe aufgenommen werden, um den Durchsatz zu verbessern und die Komplexität zu reduzieren und gleichzeitig den Wert des Kinesis Data Streams Streams-Datensatzes durchzusetzen. time-to-live Es gibt keinen Backoff-Algorithmus, was dies zu einer relativ aggressiven Wiederholungsstrategie macht. Spamming aufgrund übermäßiger Wiederholungen wird durch die Quotengrenze bewirkt, die im nächsten Abschnitt erläutert wird.

## Ratenbegrenzung
<a name="kinesis-producer-adv-retries-rate-limiting-rate-limit"></a>

Das KPL enthält eine Quotenbegrenzungsfunktion, die den pro Shard von einem einzelnen Producer gesendeten Durchsatz begrenzt. Die Quotenbegrenzung wird durch einen Token-Bucket-Algorithmus mit separaten Buckets für Datensätze von Kinesis Data Streams und Bytes implementiert. Jeder erfolgreiche Schreibvorgang in einen Kinesis-Datenstrom fügt jedem Bucket ein Token (oder mehrere Token) hinzu, bis ein bestimmter Grenzwert erreicht ist. Dieser Grenzwert ist konfigurierbar, ist aber standardmäßig um 50 % höher als das tatsächliche Shard-Limit eingestellt, um die Shard-Sättigung durch einen einzelnen Produzenten zu ermöglichen. 

Sie können diesen Grenzwert herabsetzen, um Spamming durch übermäßig viele Wiederholungsversuche zu reduzieren. Die bewährte Methode besteht jedoch darin, dass jeder Produzent aggressiv einen maximalen Durchsatz durch Wiederholungen zu erzielen versucht und mit der daraus resultierenden, als übermäßig angesehenen Drosselung so umzugehen, dass die Kapazität des Streams erweitert und eine geeignete Partitionsschlüsselstrategie implementiert wird.

# Wenden Sie bewährte Methoden auf die KPL-Aggregation an
<a name="kinesis-producer-adv-aggregation"></a>

Das Sequenznummernschema der resultierenden Amazon Kinesis Data Streams Streams-Datensätze bleibt zwar gleich, aber die Aggregation führt dazu, dass die Indizierung der Benutzerdatensätze der Amazon Kinesis Producer Library (KPL), die in einem aggregierten Kinesis Data Streams Streams-Datensatz enthalten sind, bei 0 (Null) beginnt. Solange Sie sich jedoch nicht auf Sequenznummern verlassen, um Ihre KPL-Benutzerdatensätze eindeutig zu identifizieren, kann Ihr Code dies ignorieren, da die Aggregation (Ihrer KPL-Benutzerdatensätze) zu einer Kinesis Data Streams (Datensatz) und anschließende Deaggregation (eines Kinesis Data Streams-Datensatzes in Ihre KPL-Benutzerdatensätze) erledigt das automatisch für Sie. Dies gilt unabhängig davon, ob Ihr Kunde die KCL oder das AWS SDK verwendet. Um diese Aggregationsfunktion nutzen zu können, müssen Sie den Java-Teil der KPL in Ihren Build übernehmen, wenn Ihr Consumer mithilfe der im SDK bereitgestellten API geschrieben wurde. AWS 

Wenn Sie beabsichtigen, Folgenummern als einzige Kennungen Ihrer KPL-Benutzerdatensätze zu verwenden, empfehlen wir die Verwendung der vertragsgemäßen Operationen `public int hashCode()` und `public boolean equals(Object obj)` in `Record` und `UserRecord` zur Aktivierung des Vergleichs Ihrer KPL-Benutzerdatensätze. Wenn Sie zudem die Teilsequenznummer des KPL;-Benutzerdatensatzes untersuchen möchten, können Sie eine Typumwandlung in eine `UserRecord`-Instance vornehmen und deren Teilsequenznummer abrufen.

Weitere Informationen finden Sie unter [Implementieren Sie die Deaggregation für Verbraucher](kinesis-kpl-consumer-deaggregation.md).