Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Optimalkan produsen Kinesis Data Streams
<a name="advanced-producers"></a>

Anda dapat mengoptimalkan lebih lanjut produsen Amazon Kinesis Data Streams tergantung pada perilaku tertentu yang Anda lihat. Tinjau topik berikut untuk mengidentifikasi solusi.

**Topics**
+ [Kustomisasi percobaan ulang KPL dan perilaku batas nilai](kinesis-producer-adv-retries-rate-limiting.md)
+ [Menerapkan praktik terbaik untuk agregasi KPL](kinesis-producer-adv-aggregation.md)

# Kustomisasi percobaan ulang KPL dan perilaku batas nilai
<a name="kinesis-producer-adv-retries-rate-limiting"></a>

Saat Anda menambahkan data pengguna Amazon Kinesis Producer Library (KPL) menggunakan `addUserRecord()` operasi KPL, catatan akan diberikan stempel waktu dan ditambahkan ke buffer dengan tenggat waktu yang ditetapkan oleh parameter konfigurasi. `RecordMaxBufferedTime` stamp/deadline Kombinasi kali ini menetapkan prioritas buffer. Rekaman dikeluarkan dari buffer berdasarkan kriteria berikut:
+ Prioritas penyangga
+ Konfigurasi agregasi
+ Konfigurasi koleksi

Parameter konfigurasi agregasi dan koleksi yang memengaruhi perilaku buffer adalah sebagai berikut:
+ `AggregationMaxCount`
+ `AggregationMaxSize`
+ `CollectionMaxCount`
+ `CollectionMaxSize`

Rekaman yang di-flush kemudian dikirim ke aliran data Kinesis Anda saat Amazon Kinesis Data Streams merekam menggunakan panggilan ke operasi API Kinesis Data Streams. `PutRecords` `PutRecords`Operasi mengirimkan permintaan ke aliran Anda yang terkadang menunjukkan kegagalan penuh atau sebagian. Catatan yang gagal secara otomatis ditambahkan kembali ke buffer KPL. Batas waktu baru ditetapkan berdasarkan minimum dari dua nilai ini: 
+ Setengah dari `RecordMaxBufferedTime` konfigurasi saat ini
+  time-to-liveNilai catatan

Strategi ini memungkinkan data pengguna KPL yang dicoba ulang untuk dimasukkan dalam panggilan API Kinesis Data Streams berikutnya, untuk meningkatkan throughput dan mengurangi kompleksitas sambil menerapkan nilai rekaman Kinesis Data Streams. time-to-live Tidak ada algoritma backoff, menjadikannya strategi coba lagi yang relatif agresif. Spamming karena percobaan ulang yang berlebihan dicegah dengan pembatasan tarif, dibahas di bagian selanjutnya.

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

KPL mencakup fitur pembatas laju, yang membatasi throughput per shard yang dikirim dari satu produsen. Pembatasan laju diimplementasikan menggunakan algoritma token bucket dengan bucket terpisah untuk catatan Kinesis Data Streams dan byte. Setiap penulisan yang berhasil ke aliran data Kinesis menambahkan token (atau beberapa token) ke setiap bucket, hingga ambang batas tertentu. Ambang batas ini dapat dikonfigurasi tetapi secara default ditetapkan 50 persen lebih tinggi dari batas pecahan yang sebenarnya, untuk memungkinkan saturasi pecahan dari satu produsen. 

Anda dapat menurunkan batas ini untuk mengurangi spam karena percobaan ulang yang berlebihan. Namun, praktik terbaik adalah bagi setiap produsen untuk mencoba lagi untuk throughput maksimum secara agresif dan untuk menangani setiap pelambatan yang dihasilkan ditentukan sebagai berlebihan dengan memperluas kapasitas aliran dan menerapkan strategi kunci partisi yang sesuai.

# Menerapkan praktik terbaik untuk agregasi KPL
<a name="kinesis-producer-adv-aggregation"></a>

Meskipun skema nomor urut dari catatan Amazon Kinesis Data Streams yang dihasilkan tetap sama, agregasi menyebabkan pengindeksan data pengguna Amazon Kinesis Producer Library (KPL) yang terkandung dalam rekaman Aliran Data Kinesis agregat dimulai dari 0 (nol); namun, selama Anda tidak bergantung pada nomor urut untuk mengidentifikasi catatan pengguna KPL Anda secara unik, catatan pengguna KPL Anda kode dapat mengabaikan ini, sebagai agregasi (catatan pengguna KPL Anda ke dalam catatan Kinesis Data Streams) dan de-agregasi berikutnya (dari catatan Kinesis Data Streams ke dalam catatan pengguna KPL Anda) secara otomatis mengurus ini untuk Anda. Ini berlaku apakah konsumen Anda menggunakan KCL atau AWS SDK. Untuk menggunakan fungsionalitas agregasi ini, Anda harus menarik bagian Java dari KPL ke dalam build jika konsumen Anda ditulis menggunakan API yang disediakan di SDK. AWS 

Jika Anda bermaksud menggunakan nomor urut sebagai pengidentifikasi unik untuk catatan pengguna KPL Anda, kami sarankan Anda menggunakan patuh kontrak `public int hashCode()` dan `public boolean equals(Object obj)` operasi yang disediakan dalam `Record` dan `UserRecord` untuk memungkinkan perbandingan catatan pengguna KPL Anda. Selain itu, jika Anda ingin memeriksa nomor urutan catatan pengguna KPL Anda, Anda dapat mentransmisikannya ke sebuah `UserRecord` instance dan mengambil nomor urutannya.

Lihat informasi yang lebih lengkap di [Menerapkan de-agregasi konsumen](kinesis-kpl-consumer-deaggregation.md).