Jumlah partisi hanya dapat ditambah, tidak pernah dikurangi. Ini merupakan batasan desain Apache Kafka, bukan keterbatasan spesifik ApsaraMQ for Kafka.
Cara penugasan partisi bekerja
Kafka menugaskan setiap message ke suatu partisi berdasarkan hash(key) % number_of_partitions. Setiap partisi menyimpan log message yang independen dan terurut. Menghapus suatu partisi menyebabkan dua masalah:
Data loss. Semua message yang disimpan di partisi tersebut hilang.
Key redistribution. Nilai modulus berubah, sehingga pemetaan hash bergeser untuk setiap kunci. Konsumen yang mengandalkan pengurutan berbasis kunci—misalnya, memproses semua event untuk satu pengguna secara berurutan—menerima message dalam urutan yang salah atau kehilangan message sepenuhnya.
Apa yang harus dilakukan sebagai gantinya
Rencanakan jumlah partisi sejak awal. Perkirakan berdasarkan throughput target dan paralelisme konsumen, lalu bulatkan ke atas. Menambah partisi di kemudian hari memang dimungkinkan, tetapi tetap mengacak penugasan kunci, jadi sediakan kapasitas lebih sejak awal.
Buat ulang topik jika Anda membutuhkan lebih sedikit partisi. Buat topik baru dengan jumlah partisi yang diinginkan, migrasikan produsen dan konsumen ke topik baru tersebut, lalu nonaktifkan topik lama setelah semua message telah dikonsumsi atau kedaluwarsa.
Batasan ketersediaan tinggi (HA) pada topik berpartisi tunggal
Dalam mode cloud storage, topik dengan satu partisi (partitionNum=1) tidak menyediakan ketersediaan tinggi (HA). Jika node yang menghosting partisi tersebut menjadi tidak tersedia—baik karena kegagalan node maupun upgrade—topik tersebut tidak dapat diakses hingga node kembali online.
Konsol Message Queue for Apache Kafka akan memberikan peringatan saat Anda mencoba membuat topik cloud storage dengan satu partisi. Topik cloud storage berpartisi tunggal tidak disarankan.
Perilaku mekanisme retry pada topik berpartisi tunggal
Mekanisme retry produsen Kafka memengaruhi topik berpartisi tunggal sebagai berikut:
Selama rolling upgrade — Saat suatu node sementara offline selama upgrade terencana, mekanisme retry dapat mengurangi dampak gangguan tersebut. Produsen dapat mencoba mengirim ulang message dan melanjutkan pengiriman setelah node pulih. Hal ini mengurangi (namun tidak menghilangkan sepenuhnya) kehilangan message selama maintenance terencana.
Saat terjadi kegagalan node tak terduga — Retry tidak dapat mencegah kehilangan data ketika node gagal secara tak terduga. Jika node tidak pulih dalam jendela retry, message dalam antrian retry mungkin tetap hilang. Kebijakan retry tidak dapat menggantikan HA.
Untuk memastikan ketersediaan tinggi pada beban kerja produksi, konfigurasikan topik Anda dengan minimal dua partisi. Dengan multiple partisi, Message Queue for Apache Kafka tetap dapat melayani permintaan baca dan tulis dari partisi replika pada node yang sehat meskipun satu node gagal.
Apa risiko mengubah jumlah partisi pada topik internal Kafka?
Kafka menggunakan topik internal (seperti __consumer_offsets) untuk pencatatan internal dan manajemen state. Meskipun klien Kafka umumnya dapat mendeteksi perubahan jumlah partisi secara otomatis, mengubah secara manual jumlah partisi pada topik internal (misalnya, menambah dari 1 menjadi 12) membawa risiko signifikan:
Permasalahan pengurutan message — Mengubah jumlah partisi mengubah cara message dirutekan ke partisi. Message yang sebelumnya ditugaskan ke satu partisi kini mungkin dipetakan ke partisi berbeda, menyebabkan message diproses tidak sesuai urutan.
Ketidakkonsistenan state — Topik internal menyimpan data state kritis seperti offset kelompok konsumen. Memodifikasi jumlah partisinya dapat merusak state tersebut, yang berujung pada perilaku konsumen tak terduga, kegagalan penyeimbangan ulang, atau ketidakstabilan kluster.
Jangan ubah secara manual jumlah partisi pada topik internal. Jika Anda merasa perlu melakukan perubahan, hubungi dukungan teknis Alibaba Cloud untuk mengevaluasi risikonya sebelum melanjutkan.