Petunjuk dan konteks
Pertanyaan ini menguji pemindahan kepemilikan terdistribusi daripada sekadar menghafal pengaturan Kafka. Eager rebalancing mencabut semua partisi terlebih dahulu, sedangkan cooperative rebalancing memungkinkan anggota mempertahankan partisi yang tidak perlu dipindahkan dan hanya mencabut set migrasi. Jawaban yang lengkap mencakup versi anggota, protokol assignor, commit offset, jendela kegagalan, dan telemetri.
Hal yang dievaluasi pewawancara
- Apakah Anda menjelaskan perbedaan pencabutan (revoke) dan serah terima (handoff) antara protokol eager dan cooperative.
- Apakah Anda merencanakan urutan rolling yang kompatibel alih-alih berasumsi bahwa satu anggota dapat beralih sendiri.
- Apakah kepemilikan, offset, pekerjaan yang sedang berjalan (in-flight work), dan waktu commit selaras.
- Apakah crash, batas waktu (timeouts), duplikat, rollback, dan batas kapasitas ditangani.
Pertanyaan klarifikasi
Konfirmasikan versi klien, daftar assignor saat ini, keanggotaan statis, waktu pemrosesan per pesan, jendela duplikasi yang dapat diterima, dan batas latensi rebalance. Tanyakan apakah pemrosesan bersifat idempoten, apakah tujuan akhir (sink) mendukung deduplikasi, dan apakah peluncuran dapat dilakukan secara bertahap dan di-rollback. Tentukan lonjakan penskalaan puncak, jumlah partisi, dan ambang batas peringatan.
Garis besar jawaban 30 detik
Pertama, tingkatkan setiap anggota ke versi yang mendukung protokol cooperative sambil tetap mempertahankan daftar assignor yang kompatibel. Setelah dukungan protokol seragam, luncurkan CooperativeStickyAssignor sebagai strategi utama dan hapus strategi lama. Setiap rebalance hanya mencabut partisi yang berpindah; konsumen berhenti mengambil data dari partisi tersebut, melakukan commit pada offset yang telah selesai, dan pemilik baru melanjutkan dari offset yang telah di-commit. Pantau jumlah rebalance, partisi yang dicabut, latensi pemrosesan, dan duplikasi. Kondisi crash mengandalkan session timeout dan pemulihan offset; rollback memulihkan konfigurasi lama yang kompatibel melalui perubahan bertahap lainnya.
Solusi langkah demi langkah
1. Tentukan matriks kompatibilitas protokol
Assignor dinegosiasikan pada tingkat grup, sehingga mengubah satu instance saja tidaklah cukup. Tingkatkan semua klien ke versi yang memahami cooperative rebalancing sebelum mengandalkannya. Pertahankan entri kompatibilitas selama fase pertama, lalu utamakan cooperative dan hapus strategi lama setelah grup siap:
partition.assignment.strategy=\
org.apache.kafka.clients.consumer.CooperativeStickyAssignor,\
org.apache.kafka.clients.consumer.RangeAssignorValidasi protokol dan penugasan yang dinegosiasikan oleh grup setelah setiap fase; memeriksa file konfigurasi saja bukanlah bukti bahwa grup yang sedang berjalan telah beralih.
2. Rancang pencabutan dan serah terima partisi
Set pencabutan kooperatif hanya berisi partisi yang harus dipindahkan. Saat pencabutan terjadi, hentikan pengambilan dari partisi tersebut, selesaikan atau batalkan batch aman saat ini, dan commit offset yang telah selesai. Lanjutkan pemrosesan partisi yang tidak dicabut. Pemilik baru memulai dari offset yang telah di-commit, sehingga kunci idempotensi bisnis atau deduplikasi sink akan menangani duplikat.
3. Selaraskan offset dengan pekerjaan yang sedang berjalan
Lakukan commit setelah efek samping bisnis selesai, jangan pernah sebelumnya. Jika pencabutan tiba di tengah-tengah pemrosesan batch, pasang bendera henti dan selesaikan pada titik aman; jika mencapai batas waktu, hentikan pengambilan dan catat batch yang belum selesai. Pemrosesan asinkron memerlukan pelacakan urutan per partisi sehingga hanya awalan (prefix) yang selesai secara berurutan yang di-commit.
4. Rencanakan peluncuran bertahap (rolling rollout)
Pengontrol peluncuran me-restart anggota dalam batch kecil dan menunggu stabilitas grup serta pemulihan lag setelah setiap batch. Catat baseline, tingkatkan klien, amati protokol, alihkan ke assignor utama, uji coba perubahan skala, dan baru setelah itu tingkatkan ukuran batch. Jeda jika terjadi rebalance storm atau pelanggaran latensi alih-alih mengubah session timeout dan max poll interval secara bersamaan.
5. Rancang perilaku crash dan rollback
Setelah anggota mengalami crash, koordinator akan mengalokasikan kembali partisinya saat session timeout berakhir. Anggota pengganti melanjutkan dari offset terakhir yang di-commit, sehingga efek samping sebelum crash dapat terulang. Rollback memulihkan assignor lama dalam daftar kompatibilitas dan menggunakan urutan rolling yang sama; jangan menghapus anggota baru yang masih berjalan secara paksa. Catat generasi, ID anggota, set pencabutan, dan kegagalan commit untuk mendiagnosis race condition.
6. Tambahkan pembatas kapasitas dan telemetri
Lacak frekuensi dan durasi rebalance, jumlah partisi yang dicabut, consumer lag, interval poll, latensi commit, tingkat duplikasi, dan anggota yang tidak terhubung. Uji restart simultan, partisi panas (hot partitions), pemrosesan yang melebihi max.poll.interval, gangguan jaringan (jitter), dan jumlah partisi yang mendekati jumlah anggota. Jika kapasitas terbatas, kurangi ukuran batch peluncuran atau tambahkan konsumen sebelum melanjutkan.
Contoh jawaban berkualitas tinggi
Saya akan memverifikasi bahwa setiap klien mendukung penugasan cooperative, kemudian menggunakan konfigurasi rolling dua fase: mempertahankan assignor yang kompatibel saat meningkatkan versi, dan hanya setelah itu mengutamakan CooperativeStickyAssignor serta menghapus strategi lama. Callback pencabutan hanya menghentikan partisi yang berpindah, menyelesaikan titik aman, dan melakukan commit pada offset yang berurutan; partisi yang dipertahankan tetap berjalan. Pemilik baru melanjutkan dari offset yang telah di-commit, dengan idempotensi yang menangani duplikasi. Pengontrol batch kecil memantau rebalance, lag, interval poll, kegagalan commit, dan tingkat duplikasi. Crash dipulihkan melalui session timeout dan offset, sementara rollback mengikuti urutan rolling kompatibel yang sama alih-alih menghapus anggota yang aktif secara paksa.
Kesalahan umum
- Mengubah satu konsumen dan mengabaikan negosiasi assignor tingkat grup.
- Menganggap cooperative rebalancing sebagai penghentian nol detik (zero pause) padahal partisi yang berpindah tetap memerlukan serah terima.
- Melakukan commit offset sebelum efek samping bisnis selesai.
- Mengambil data setelah pencabutan atau melakukan commit pada hasil asinkron yang tidak berurutan.
- Mengubah beberapa pengaturan timeout secara bersamaan sehingga kehilangan bukti penyebab.
- Hanya memantau lag sambil mengabaikan frekuensi rebalance, set pencabutan, dan duplikat.
Pertanyaan lanjutan
Apakah cooperative rebalancing menjamin nol duplikasi?
Tidak. Crash, percobaan ulang commit, dan batas pencabutan dapat mengulangi pekerjaan. Tujuannya adalah untuk mengurangi jeda seluruh grup dan membatasi jendela duplikasi; sink tetap memerlukan idempotensi atau deduplikasi.
Mengapa setiap anggota harus mendukung penugasan cooperative?
Protokol assignor dinegosiasikan oleh grup. Anggota yang tidak dapat mengurai atau mengeksekusi semantik cooperative dapat menyebabkan negosiasi gagal atau memaksakan perilaku eager, sehingga versi yang kompatibel harus diluncurkan terlebih dahulu.
Bagaimana jika pemrosesan melebihi max.poll.interval?
Gunakan batch yang lebih kecil, kumpulan asinkron yang terkontrol, atau perubahan parameter yang ditinjau secara cermat sambil menjaga panggilan poll tepat waktu. Hanya meningkatkan batas waktu dapat menunda deteksi kegagalan dan memperpanjang kepemilikan partisi.
Bagaimana Anda memvalidasi keamanan rollback?
Injeksi crash pada anggota, jitter jaringan, dan kegagalan commit di grup staging. Catat generasi, offset, set pencabutan, dan efek samping yang terdeduplikasi. Verifikasi bahwa assignor lama stabil dalam matriks kompatibilitas tanpa melewatkan offset yang belum di-commit.