Pertanyaan dan Kapan Ini Berlaku
Sebuah platform menggunakan Kafka untuk aliran event (event streams) dan antrean tugas. Consumer Group tradisional menetapkan setiap partisi ke satu anggota, sementara tim ingin menggunakan Kafka 4.1 Share Group untuk konkurensi yang lebih menyerupai antrean. Tentukan beban kerja mana yang cocok dan bagaimana mengendalikan risiko fitur preview.
Apa yang Dinilai Pewawancara
- Membedakan pemrosesan stream terpartisi dari semantik pengiriman antrean bersama (shared-queue).
- Menjelaskan batas akuisisi (acquisition limits), pengakuan (acknowledgment), pengiriman ulang saat gagal (failure redelivery), dan pengurutan.
- Menggabungkan keadilan multi-tenant, lag, idempotensi, dan observabilitas dalam satu desain.
- Menetapkan gerbang kompatibilitas, canary, pemutaran ulang (replay), dan rollback untuk fitur preview.
Pertanyaan Klarifikasi Sebelum Anda Menjawab
- Apakah beban kerja memerlukan pengurutan berdasarkan kunci dan state lokal partisi, atau hanya pemrosesan akhir (eventual processing) dari setiap record?
- Apakah record yang gagal harus dicoba ulang segera, nanti, atau melalui antrean dead-letter (dead-letter queue)?
- Apakah tenant berbagi topic dan kapasitas konsumen, serta apakah terdapat identitas tenant yang stabil?
- Apakah efek samping downstream bersifat idempoten, dan bisakah pemrosesan dilakukan secara bersamaan atau terduplikasi?
- Apakah versi Kafka, klien, alat admin, dan platform terkelola mendukung Share Group?
Kerangka Jawaban 30 Detik
Consumer Group menggunakan partisi sebagai batas paralelisme dan pengurutan, cocok untuk agregat streaming dan state berdasarkan kunci. Share Group lebih menyerupai antrean bersama: beberapa konsumen dapat mengakuisisi record yang berbeda dari satu partisi topic, sementara klaster membatasi berapa banyak record yang dapat diakuisisi per partisi. Saya akan mengklasifikasikan berdasarkan semantik bisnis, memvalidasi acknowledgment, pengiriman ulang, idempotensi, dan keadilan, lalu melakukan canary pada fitur preview sambil mempertahankan jalur rollback ke Consumer Group.
Pembahasan Mendalam Langkah demi Langkah
Langkah 1: Mulai dengan semantik pemrosesan, bukan nama API
Jika pemrosesan bergantung pada urutan partisi, state jendela (window state), atau agregasi berdasarkan kunci, penetapan Consumer Group lebih mudah dipahami. Jika tugas bersifat independen, membutuhkan lebih banyak konkurensi, dan menerima acknowledgment bergaya antrean, Share Group adalah kandidat yang baik. Jangan bermigrasi hanya karena tolok ukur (benchmark) menjanjikan throughput yang lebih tinggi.
Langkah 2: Bandingkan batas konkurensi dan akuisisi
Paralelisme grup tradisional terutama dibatasi oleh jumlah partisi; satu anggota menangani satu partisi pada satu waktu. Share Group memungkinkan beberapa konsumen mengakuisisi record dari satu partisi topic, tetapi klaster tetap membatasi jumlah yang diakuisisi per partisi. Ukur hasil kali dari ukuran batch, waktu pemrosesan, dan kapasitas downstream.
Langkah 3: Tentukan acknowledgment, kegagalan, dan pengiriman ulang
Sebelum migrasi, tentukan kapan sebuah record dianggap berhasil, apakah kegagalan membuatnya tersedia untuk konsumen lain, dan apakah pengiriman ulang dapat tumpang tindih dengan pekerjaan lama. Gunakan kunci idempotensi, tabel deduplikasi, atau transaksi yang dapat diulang untuk penulisan eksternal. Kirim kegagalan yang tidak dapat dipulihkan ke dead-letter queue beserta alasan, tenant, dan jumlah percobaan.
Langkah 4: Tangani pengurutan dan state
Semantik antrean bersama dapat membatalkan asumsi tentang urutan partisi. Pertahankan pekerjaan berurutan berdasarkan kunci di Consumer Group, atau terapkan serialisasi tingkat kunci dan pemeriksaan versi dalam aplikasi. Penyimpanan state harus mencatat versi event, pemroses, dan status percobaan ulang agar pembaruan konkuren tidak saling menimpa secara diam-diam.
Langkah 5: Bangun keadilan tenant dan backpressure
Lonjakan trafik tenant pada topic bersama dapat menciptakan masalah noisy neighbor. Sertakan identitas tenant yang stabil dan amati waktu tunggu, throughput, serta tingkat kegagalan berdasarkan tenant. Tambahkan kuota aplikasi, batas akuisisi per batch, pemisahan topic, atau bulkhead downstream jika diperlukan. Basis data dan API eksternal membutuhkan batas konkurensi mereka sendiri.
Langkah 6: Validasi jalur preview dan operasional
Dokumentasi Kafka melabeli Share Group sebagai preview dan tidak diaktifkan secara default. Verifikasi kompatibilitas broker, klien, alat admin, metrik, pemulihan kegagalan, dan peningkatan versi (upgrade) terlebih dahulu. Gunakan event sintetis untuk menguji mulai ulang (restarts), pengurangan konsumen, acknowledgment duplikat, perubahan broker, lag, dan dead-letter.
Langkah 7: Rancang migrasi dan rollback
Pertama, cerminkan (mirror) beban kerja kecil yang tidak kritis ke dalam Share Group. Bandingkan throughput, waktu tunggu p99, duplikat, pengiriman ulang, keadilan tenant, dan kesalahan downstream. Pertahankan topic asli atau batas offset yang dapat diputar ulang. Jika pengurutan, efek samping duplikat, atau komponen preview mengalami kemunduran (regress), jeda lalu lintas baru dan beralih kembali ke Consumer Group.
Contoh Jawaban Berkualitas Tinggi
Saya akan membaginya berdasarkan semantik. Event yang membutuhkan urutan partisi, window state, atau agregasi berdasarkan kunci tetap berada di Consumer Group; tugas yang independen, konkuren, dan idempoten dapat menjadi kandidat untuk Share Group. Grup tradisional menggunakan partisi sebagai batas paralelisme, dengan satu anggota menanganinya; Share Group berperilaku lebih seperti antrean bersama, memungkinkan beberapa konsumen mengakuisisi record yang berbeda dari satu partisi topic sambil mempertahankan batas akuisisi per partisi. Sebelum migrasi, saya akan menentukan acknowledgment dan pengiriman ulang, kunci idempotensi, dead-letter, dan metrik keadilan tenant, disertai bulkhead downstream. Karena Share Group berstatus preview dalam dokumentasi Kafka 4.1, saya akan memverifikasi kompatibilitas versi dan operasi, melakukan canary pada tenant non-kritis, serta membandingkan waktu tunggu, duplikat, lag, pengiriman ulang, throughput per-tenant, dan kesalahan downstream. Saya akan mempertahankan data yang dapat diputar ulang dan jalur rollback Consumer Group; setiap regresi pengurutan atau efek samping akan memicu penghentian dan pengembalian ke kondisi semula.
Kesalahan Umum
- Memperlakukan Share Group hanya sebagai "penambahan konsumen" dan mengabaikan semantik pengiriman serta acknowledgment.
- Memindahkan stream stateful yang terurut berdasarkan partisi langsung ke antrean bersama.
- Menerima pengiriman ulang dan pemrosesan konkuren tanpa idempotensi.
- Memantau total throughput tetapi mengabaikan waktu tunggu tenant, duplikat, dan saturasi downstream.
- Mengabaikan kompatibilitas preview di seluruh klien, alat, dan upgrade.
- Menghapus data asli setelah migrasi sehingga kehilangan kemampuan replay dan rollback.
Pertanyaan Lanjutan dan Tanggapan
Pertanyaan Lanjutan 1: Apakah Share Group menghilangkan partisi?
Tidak. Partisi topic tetap menjadi batas penyimpanan dan replikasi. Perubahannya adalah beberapa anggota share group dapat mengakuisisi record yang berbeda dari satu partisi, sesuai dengan batas akuisisi klaster.
Pertanyaan Lanjutan 2: Bisakah kunci yang sama tetap terurut?
Jangan menganggap demikian. Pertahankan pekerjaan yang bergantung pada urutan di Consumer Group, atau lakukan serialisasi berdasarkan kunci di aplikasi dan gunakan pemeriksaan versi untuk memastikan pembaruan konkuren tidak saling menimpa.
Pertanyaan Lanjutan 3: Apa yang terjadi pada record yang gagal?
Konfirmasikan dari implementasi dan konfigurasi apakah record tersebut tersedia kembali, ditunda, atau dapat dikirim ulang secara konkuren. Lindungi efek samping dengan kunci idempotensi, jumlah percobaan, dan alasan dead-letter.
Pertanyaan Lanjutan 4: Bagaimana cara mencegah lonjakan tenant menghabiskan kapasitas?
Bawa identitas tenant, amati waktu tunggu dan throughput per-tenant, lalu kombinasikan kuota aplikasi, batas akuisisi, pemisahan topic, atau bulkhead downstream. Ubah keadilan menjadi target yang dapat memicu peringatan (alert).
Pertanyaan Lanjutan 5: Mengapa tidak memigrasikan semuanya?
Beban kerja stream dan antrean membutuhkan jaminan pengurutan, state, percobaan ulang, dan operasional yang berbeda. Fitur preview menambah risiko versi dan kegagalan, jadi klasifikasikan beban kerja alih-alih memaksakan satu model.
Pertanyaan Lanjutan 6: Bagaimana cara melakukan rollback record yang sudah diproses?
Simpan event yang dapat diputar ulang dan versi pemrosesan, hentikan trafik Share Group baru, dan lanjutkan dari batas Consumer Group. Kompensasikan atau rekonsiliasikan efek samping eksternal secara idempoten; jangan menulis ulang secara membabi buta.