KodelokaPartisi = Unit Paralelisme
Sebuah topik dipecah menjadi beberapa partisi, dan tiap partisi adalah log terpisah yang bisa berada di broker berbeda.
Topik "pesanan" dengan 3 partisi: P0 pada broker-1: [ o1 ][ o4 ][ o7 ] P1 pada broker-2: [ o2 ][ o5 ] P2 pada broker-3: [ o3 ][ o6 ][ o8 ][ o9 ]
Tidak ada urutan global di seluruh topik. Bila Anda menulis pesanan.dibuat lalu pesanan.dibayar untuk pesanan yang sama tanpa kunci, keduanya bisa mendarat di partisi berbeda dan dikonsumsi terbalik. Bug semacam ini muncul secara acak dan sangat sulit dilacak.
Kunci Pesan Mengunci Urutan
Bila produser menyertakan kunci, Kafka menghitung hash(kunci) % jumlah_partisi sehingga semua pesan dengan kunci yang sama selalu masuk ke partisi yang sama — dan otomatis terurut relatif satu sama lain.
kirim(topik="pesanan", kunci="pesanan-123", nilai=...) → selalu P1 kirim(topik="pesanan", kunci="pesanan-124", nilai=...) → mungkin P0 Semua peristiwa milik pesanan-123 terurut. Antar pesanan, tidak dijamin — dan memang tidak perlu.
Pilih kunci berdasarkan entitas yang urutannya penting: id pesanan, id pengguna, id perangkat, nomor rekening.
Karena partisi ditentukan modulo jumlah partisi, menaikkan jumlah partisi dari 6 ke 12 membuat kunci yang sama mendarat di partisi berbeda. Pesan lama tetap di tempatnya, pesan baru pindah — sehingga jaminan urutan per kunci putus di titik perubahan. Kafka juga tidak mendukung pengurangan jumlah partisi sama sekali. Rencanakan jumlah partisi sejak awal dengan kelonggaran.
Berapa Partisi yang Tepat?
| Pertimbangan | Arah |
|---|---|
| Konsumen aktif maksimum dalam satu grup | Tidak boleh melebihi jumlah partisi — kelebihan konsumen akan menganggur |
| Throughput target | Ukur throughput satu partisi, lalu bagi target dengan angka itu |
| Waktu pemulihan saat broker mati | Terlalu banyak partisi memperlambat failover dan membebani controller |
| Beban berkas dan memori broker | Tiap partisi memakan file handle dan buffer |
Titik awal yang wajar untuk topik dengan lalu lintas sedang: 6–12 partisi. Puluhan ribu partisi dalam satu klaster masih mungkin pada KRaft, tetapi bukan sesuatu yang perlu dikejar.
Replikasi dan ISR
Tiap partisi punya satu leader dan beberapa follower. Semua penulisan dan pembacaan default melalui leader; follower menyalin data secara asinkron.
Partisi 0, replication.factor = 3 broker-1: LEADER broker-2: follower ← sinkron, masuk ISR broker-3: follower ← tertinggal jauh, DIKELUARKAN dari ISR ISR = In-Sync Replicas = replika yang cukup mengejar leader
Kombinasi tiga setelan menentukan daya tahan data:
| Setelan | Nilai produksi | Akibat |
|---|---|---|
replication.factor | 3 | Tahan kehilangan 1 broker tanpa kehilangan data |
min.insync.replicas | 2 | Penulisan ditolak bila replika sinkron kurang dari 2 |
acks (produser) | all | Commit dianggap sukses setelah semua ISR menerima |
Bila min.insync.replicas dibiarkan 1, klaster tetap menerima tulisan meski hanya leader yang hidup. Ketika leader itu kemudian mati, data yang belum tersalin hilang permanen. Tiga replika tanpa min.insync.replicas=2 memberi rasa aman yang palsu.
Sebaliknya, replication.factor=3 dengan min.insync.replicas=3 berarti satu broker mati saja membuat topik berhenti menerima tulisan. Kombinasi 3 dan 2 adalah keseimbangan yang benar.
Bila diaktifkan, replika yang tertinggal boleh diangkat menjadi leader saat tidak ada ISR yang tersedia. Klaster tetap melayani, tetapi pesan yang sudah di-commit bisa lenyap. Default modern adalah false, dan sebaiknya tetap begitu untuk data yang penting.