Pendahuluan

Pendahuluan awal mengenai Kafka dilihat di Kafka - Part 1 ?

Kenapa harus memakai Kafka bisa dilihat di Kafka - Part 2

Infrastruktur di Kafka - Part 3 ?

Infratruktur Kafka itu bisa kita bagi 2 :

  1. Infrastruktur Fisik, dijelaskan di Kafka - Part 3 ?
  2. Infrastruktur Logik.

Setelah sebelumnya kita bahas infrastruktur Fisik, maka sekarang kita akan bahas infrastruktur logik.

2. Infrastruktur Logik

Infrastruktur Logik artinya infrastruktur Kafka yang kita sebenarnya tidak peduli dengan letak hardware atau server/broker nya dimana

Yang penting kita tau bahwa barangnya ada, dan digunakan dalam proses yang rumit dalam Kafka.

Infrastruktur Logic itu ada :

  • topic
  • consumer
  • consumer group
  • producer

Topic

Topic adalah konsep logic paling penting di Kafka.

konsep Topic inilah yang menghubungkan antara Kafka Client dan Kafka Server.

Topic dapat dianggap semisal dengan antrian saja.

Semirip dengan antrian di sebuah supermarket.

Tempat yang menghubungkan antara pembeli dengan supermarket melalui pembayaran barang.

Hal yang sama yang akan kita temui di platform messaging lain seperti ActiveMq, RabbitMq, dll.

“Lagi antri di pembayaran nih”, begitu kata kita kalau ditanya sedang ngapain di supermarket.

Dan kita tidak peduli antrinya di loket kasir yang mana, yang penting antri di supermarket tersebut.

Dan begitu pula Topic di Kafka, kita cuma tahu kalau data/message kita lagi ngantri di topic nya kafka, tanpa peduli ngantrinya dimana.

Topic di Kafka ini menganut konsep paralelisme, artinya konsep antrian ini bisa di bagi-bagi menjadi antrian-antrian kecil yang bisa diproses terpisah-pisah.

Antrian-antrian kecil tersebut disebut Partition yang berupa tempat penyimpanan seperti array di banyak server brokernya Kafka.

Mirip dengan banyaknya loket-loket kasir untuk antrian di supermarket.

Mengenai Partition ini juga telah kita bahas di bagian sebelumnya.

Topic yang terdiri dari banyak Partition ini, partitionnya ini bisa berada di broker/server yang berbeda.

Dan biasanya memang akan ditaruh di server/broker yang berbeda.

Pemisalan di sebuah supermarket, adalah antrian kasir di supermarket yang mempunyai 3 lantai.

Antrian bisa saja di bagi-bagi ke banyak loket-loket kasir yang berada di lantai 1, lantai 2, dan lantai 3.

Dan secara umum, antriannya akan dibagi secara merata ke lantai 1, lantai 2, dan lantai 3 sesuai dengan desain awalnya.

Kafka akan berusaha mendistribusikan secara merata semua partition yang ada untuk sebuah topic, ke semua server/broker yang tersedia.

Bisa saja kita melakukan konfigurasi partitionnya mau ditaruh di broker/server mana saja.

Misalnya kita ingin semua partitionnya di 3 broker saja dari total 5 broker/server yang tersedia, bisa saja. Akan tetapi hal ini merupakan pembahasan lanjutan.


Consumer

Consumer adalah instance/program yang membaca message/event dari sebuah topic.

Consumer disebut juga sebagai salah satu dari Kafka client, selain dari Produser

Kalau kita mau memisalkan, semirip dengan petugas kasir di sebuah antrian di supermarket.

Di Kafka, representasi Consumer ini dalam sebuah program adalah dalam bentuk class Listener yang akan membaca message/event dari sebuah topic.

Kafka server akan mengassign Consumer tersebut ke sebuah Partition di broker tertentu, khusus untuk membaca message/event yang masuk ke Partition itu.

Kalau kita berbicara tentang Consumer ini, maka kita menganggapnya selalu berada dalam context Consumer Group yang sama yaa.

Sabaar., masalah Consumer Group akan kita lihat di artikel berikutnya.

Consumer bisa diassign ke banyak Partition, kalau ternyata jumlah Partition lebih banyak dari jumlah Consumer.

Hal ini logis, karena kita ingin semua message/event bisa diproses semuanya, di partition mana saja, oleh instance/program yang tersedia.

Pemisalan di dunia nyata, seorang kasir bisa saja diassign untuk banyak loket pembayaran, karena kita tidak ingin satu orangpun pembeli yang tidak dilayani.

Kembali ke persoalan Kafka.

Misalnya di Kafka Server kita punya 5 Partition untuk Topic A, sementara instance/consumer yang membaca topic ini cuma ada 2 intance/consumer.

Maka bisa saja akan terjadi mapping sbb :

  • Partition 1 dan 2 akan di consume oleh instance 1
  • Partition 3, 4, da n 5 akan di consume oleh instance 2

Sehingga mengalokasikan banyak Partition untuk sebuah Consumer adalah hal yang wajar.

Kita tidak ingin kehilangan message/event yang sudah ditaruh di Partition mana saja di topic tersebut.

Bagaimana kalau dari sisi Partition ?

Apakah juga bisa diassign dengan banyak Consumer yang membacanya.?

Satu Partition misalnya dibaca oleh 2 Consumer atau 2 program/instance ??

Atau dalam dunia nyata, apakah mungkin sebuah antrian loket dilayani oleh 2 atau lebih orang kasir ?

Sayangnya tidak bisa, 1 Partition hanya bisa diassign/dibaca oleh 1 Consumer saja.

Istilahnya, cukup 1 program/instance/listener saja yang membaca data message/event di sebuah Partition.

Lebih mudah dari sisi pengelolaannya, koordinasi dan penandaan offset yang ada di Partition tersebut.

Di dunia nyata pun begitu, satu loket pembayaran cuma dilayani oleh satu orang kasir saja.

Oke, implikasinya jadinya apa ?

Implikasinya, kalau jumlah Consumer lebih banyak dari jumlah Partition, maka akan ada Consumer yang tidak akan kebagian Partition.

Akibatnya instance/program Consumer tersebut tidak melakukan apa2 termasuk tidak akan membaca message apapun dari topic, karena tidak dapat jatah Partition.

Sama halnya di dunia nyata, di antrian supermarket.

Kalau semua loket antrian sudah dilayani oleh masing-masing satu orang kasir, maka kalau ada kasir baru yang datang, maka dia tidak akan melakukan apa-apa dan tidak melayani pembeli manapun.

Consumer Group

Idealnya semua Consumer harus tergabung dalam sebuah Consumer Group.

Semua Consumer yang tergabung dalam sebuah Consumer Group dianggap sebuah kelompok yang bertugas bersama untuk memproses data yang banyak secara paralel.

Consumer Group merupakan konsep yang unik di Kafka.

Konsep ini membuat pengelompokan pemrosesan paralel untuk data/message yang masuk ke Kafka, sekaligus membuat pemrosesan data/message dapat dilakukan secara berbeda untuk kelompok yang berbeda.

Dengan Consumer Group ini, maka akan membuat sebuah data/message yang sama diconsume berulang kali oleh sekelompok proses/program yang berbeda untuk keperluan yang berbeda pula.

Apa maksudnya ?

Maksudnya cukup dengan data yang sama, di topic yang sama, kita bisa memproses datanya sesuai dengan keinginan tertentu kita, tentunya dengan proses yang berbeda.

Tidak usah membuat topic yang berbeda untuk data yang sama, cuma untuk kebutuhan tertentu.

Ok.. contohnya ?

Misalkan untuk proses pembayaran telah berhasil dilakukan di sebuah aplikasi e-commerce.

Sekali proses pembayaran berhasil, maka cukup masukkan data di topic pembayaran, lalu proses-proses yang berbeda akan membaca dari data tersebut, kemudian melanjutkan proses masing-masingnya.

Misalkan proses-proses yang memerlukan status pembayaran tersebut adalah :

  • proses delivery
  • proses pengurangan jumlah stok barang
  • proses analisa jenis pembayaran
  • proses pembuatan invoice.
  • proses notifikasi ke customer dan sales untuk penjualan barangnya.
  • dll.

Akan ada minimal 5 proses yang berbeda yang melakukan proses setelah pembayaran selesai.

Cukup buat 5 proses yang akan mendengarkan ke sebuah data di topic tadi, kemudian melanjutkan prosesnya masing-masing.

Tidak perlu melakukan duplikasi data di 5 topic yang berbeda, cukup 1 saja.

Kalau kita lihat biasanya dengan menggunakan messaging tradisional seperti ActiveMq atau RabbitMa., maka kita akan membuat 5 nama queue sendiri untuk masing2 proses tersebut, dan menaruh message yang sama di 5 topic berbeda agar diconsume terpisah.

Hal ini memboroskan data yang dikirim dan yang disimpan.

Padahal kita cuma butuh data pembayaran yang sama, kemudian kita lanjutkan untuk prosesnya masing-masing.

Tidak perlu menduplikasi data dan topic yang berbeda untuk hal tersebut.

Dengan konsep Consumer Group ini maka akan terakomodasi kebutuhan Event Store untuk Event Sourcing.

Dan juga pemrosesan data/message itu tetap bisa dilakukan tetap secara paralel per consumer group.

Konsistensi pembacaan data/message dilakukan dengan index dari offset dari consumer grup ini..

Kalau di dunia nyata, di supermarket, bisa dimisalkan ketika seorang pembeli dilayani di loket antrian, maka akan ada beberapa petugas di belakang loket kasir yang mengolah data tersebut, misalnya :

  • petugas kasir sendiri yang memproses pembayaran
  • petugas analisa pembelian barang.
  • petugas pencatatan barang dan stok.
  • program POS (Point Of Salse) kasir sendiri yang melakukan analisa dan pengolahan data dari data pembelian.
  • dll.

Data yang diterima sama, akan tetapi pengolahan dan pemrosesan serta tujuan pengolahannya berbeda.

Okeh. Kita akan lanjut part 5 mengenai producer.