Menangani catatan duplikat

Ada dua alasan utama mengapa catatan dapat dikirimkan lebih dari satu kali ke aplikasi Amazon Kinesis Data Streams Anda: percobaan ulang produsen dan percobaan ulang konsumen. Aplikasi Anda harus mengantisipasi dan menangani pemrosesan catatan individual dengan tepat beberapa kali.

Produsen mencoba lagi

Pertimbangkan produser yang mengalami batas waktu terkait jaringan setelah melakukan panggilanPutRecord, tetapi sebelum dapat menerima pengakuan dari Amazon Kinesis Data Streams. Produser tidak dapat memastikan apakah rekaman dikirim ke Kinesis Data Streams. Dengan asumsi bahwa setiap catatan penting untuk aplikasi, produser akan ditulis untuk mencoba lagi panggilan dengan data yang sama. Jika kedua PutRecord panggilan pada data yang sama berhasil dilakukan ke Kinesis Data Streams, maka akan ada dua catatan Kinesis Data Streams. Meskipun kedua catatan memiliki data yang identik, mereka juga memiliki nomor urut yang unik. Aplikasi yang membutuhkan jaminan ketat harus menyematkan kunci utama dalam catatan untuk menghapus duplikat nanti saat memproses. Perhatikan bahwa jumlah duplikat karena percobaan ulang produsen biasanya rendah dibandingkan dengan jumlah duplikat karena percobaan ulang konsumen.

catatan

Jika Anda menggunakan AWS SDKPutRecord, pelajari perilaku SDK Coba lagi di panduan pengguna AWS SDKs dan Alat.

Coba ulang konsumen

Percobaan ulang konsumen (aplikasi pemrosesan data) terjadi ketika prosesor rekaman dimulai ulang. Rekam prosesor untuk restart shard yang sama dalam kasus berikut:

1. Seorang pekerja berhenti secara tak terduga

2. Contoh pekerja ditambahkan atau dihapus

3. Pecahan digabungkan atau dibagi

4. Aplikasi ini digunakan

Dalam semua kasus ini, pemetaan shards-to-worker-to -record-processor terus diperbarui untuk pemrosesan keseimbangan beban. Prosesor shard yang dimigrasikan ke instance lain memulai ulang catatan pemrosesan dari pos pemeriksaan terakhir. Ini menghasilkan pemrosesan rekaman duplikat seperti yang ditunjukkan pada contoh di bawah ini. Untuk informasi selengkapnya tentang load-balancing, lihat. Gunakan resharding, scaling, dan parallel processing untuk mengubah jumlah pecahan

Contoh: Percobaan ulang konsumen menghasilkan catatan yang dikirim ulang

Dalam contoh ini, Anda memiliki aplikasi yang terus membaca catatan dari aliran, menggabungkan catatan ke dalam file lokal, dan mengunggah file ke Amazon S3. Untuk mempermudah, asumsikan hanya ada 1 pecahan dan 1 pekerja yang memproses pecahan. Perhatikan contoh urutan peristiwa berikut, dengan asumsi bahwa pos pemeriksaan terakhir berada pada nomor rekor 10000:

1. Seorang pekerja membaca kumpulan catatan berikutnya dari pecahan, mencatat 10001 hingga 20000.

2. Pekerja kemudian meneruskan batch catatan ke prosesor rekaman terkait.

3. Prosesor rekaman mengumpulkan data, membuat file Amazon S3, dan mengunggah file ke Amazon S3 dengan sukses.

4. Pekerja berhenti secara tak terduga sebelum pos pemeriksaan baru dapat terjadi.

5. Aplikasi, pekerja, dan prosesor rekaman restart.

6. Pekerja sekarang mulai membaca dari pos pemeriksaan terakhir yang berhasil, dalam hal ini 10001.

Dengan demikian, catatan 10001-20000 dikonsumsi lebih dari satu kali.

Menjadi tangguh terhadap percobaan ulang konsumen

Meskipun catatan dapat diproses lebih dari satu kali, aplikasi Anda mungkin ingin menyajikan efek samping seolah-olah catatan diproses hanya satu kali (pemrosesan idempoten). Solusi untuk masalah ini bervariasi dalam kompleksitas dan akurasi. Jika tujuan data akhir dapat menangani duplikat dengan baik, kami sarankan untuk mengandalkan tujuan akhir untuk mencapai pemrosesan idempoten. Misalnya, dengan Opensearch Anda dapat menggunakan kombinasi versi dan unik IDs untuk mencegah pemrosesan duplikat.

Dalam contoh aplikasi di bagian sebelumnya, ia terus membaca catatan dari aliran, menggabungkan catatan ke dalam file lokal, dan mengunggah file ke Amazon S3. Seperti yang diilustrasikan, catatan 10001 -20000 dikonsumsi lebih dari satu kali sehingga menghasilkan beberapa file Amazon S3 dengan data yang sama. Salah satu cara untuk mengurangi duplikat dari contoh ini adalah memastikan bahwa langkah 3 menggunakan skema berikut:

1. Record Processor menggunakan jumlah catatan tetap per file Amazon S3, seperti 5000.

2. Nama file menggunakan skema ini: awalan Amazon S3, shard-id, dan file. First-Sequence-Num Dalam hal ini, bisa jadi sepertisample-shard000001-10001.

3. Setelah Anda mengunggah file Amazon S3, periksa dengan menentukan. Last-Sequence-Num Dalam hal ini, Anda akan memeriksa di nomor rekor 15000.

Dengan skema ini, bahkan jika catatan diproses lebih dari satu kali, file Amazon S3 yang dihasilkan memiliki nama yang sama dan memiliki data yang sama. Percobaan ulang hanya menghasilkan penulisan data yang sama ke file yang sama lebih dari satu kali.

Dalam kasus operasi reshard, jumlah catatan yang tersisa di pecahan mungkin kurang dari jumlah tetap yang Anda inginkan yang diperlukan. Dalam hal ini, shutdown() metode Anda harus menyiram file ke Amazon S3 dan pos pemeriksaan pada nomor urut terakhir. Skema di atas juga kompatibel dengan operasi reshard.