KAFKA
Xususi ile “monolith to microservices”, “distributed systems” trendlerinden sonra daha da populyarlasan Kafka haqqinda gelin danisaq.
Ilk defe Linkedin daha sonrasinda ise diger neheng sirketler Netflix, Uber, Slack, Spotify ve.s terefinden de Kafka mutemadi istifade edilmeye baslanildi ve bu populyarligina elave bir populyarliq geldi)
Evvelce gelin Kafka-nin isleme mentiqine goz ataq. Umumi arxitekturasina ve komponentlerine baxaq.
Daha umumi anlayisimiz Cluster-dir. Bu termin artiq zaten coxumuza bellidir. Cluster icerisinde de brokerler vardir. Datalarimiz bu brokerlerde saxlanilir (daha deqiq partitionlarda) ve onlar hard disk uzerinde saxlanilir in memory deyil. Kafkanin bu brokerlerinin idare edilmesi, fault broker healt check edilmesi, leader partition switchler bu kimi isler ise Zookeper terefinden edilir deye siz Zookeper install edirsiniz kafka install ederken. Brokerlerin sayi hemise tek eded olmalidir duzgun replication getmesi ucun buna diqqet edin.
Gelin indi brokerimizin icerisine baxaq. Kafka datalari topiclerde saxlayir dedik. Yeni toplic-lerimiz brokerlerin icerisindedir. Bir nov database table-lerimize benzede bilersiniz topicleri. Topic-in de icerisinde partitionlarimiz vardir. Yeni datamiz, eventlerimiz eslinde partitionlarin icierisindedir. Bir topicde istediyiniz sayda partition ola biler. Partition sayini topicleri yaradarken ozumuz teyin edirik .Datalarimiz elave olunmas sira ile partitionlara dusur. Ve bu datalar ya muyyen muddetden( default 7 gun) ve ya mueyyen size kecmediyi muddetce tutulur bu parititonlarda. Her bir event offset ile bir yerde partitionda tutulur. Ve bu offset deyeri uniqie-dir. Bu partitionlar vasitesi ile sirali sekilde datalarimizi yaza ve store ede bilerik, event sourcing ede bilerik qisaca. Hemcinin data read ederken paritionlardan paralel oxumani temin ede bilerik daha da suret qazanmaq ucun.
Normalda topice publish olunan data partitionlara default olaraq raund ribbon paylanir random olaraq yeni. Amma biz record keyler vasitesile hansi fielde gore partitionlari ayri ayri aggregation olmasini temin ede bilerik. Eger record key olaraq sequence id-ni gonderirsiznizse demeli sizde sirali sekilde partionlara dusecek datalar ve event sorucing temin ede bilersiniz bu yolla. Bu arada partitionlarin da replication-ini ede bielrsiniz ve bu zaman mueyyen leader partition olur qalani replica partitinlar olur ve bu ayri ayri brokerlerde de tutula bilir.
Gelek acknowledgment meselesine. Burada bir nece cur yanasa bilerik. Kafkada bir nece delivery semanticler vardir ( at least once, at most once ve exactly once) ve bunlari ise ack deyerleri ve insync.replica deyerleri ile tenizmleye bilerik. Eger producer ack deyeri 0 veririkse bu o demekdirki mesaji gonder ve getdi getmedi cavab gozlemeden digerini gonder. Bu suretli amma riskli variantdir! Deyerini 1 versek bu defe ancaq leader partition yazana qeder saxlayacaq diger mesaji, sonrasinda iseb davam edecek . All deyerini versek bu defe mutleq sekilde butun partiitonlara dusmesini gozleyecek ve sonra diger mesaja kececek bu cox yavas usuldur!
Delivery semnaticleri de izahin verek ayriliqda nedir :
at most once — En coxu bir defe catdirila biler. Data itkisi goze alinandir bu case-de. Offsete commit qebul edilen kimi bas verir proses sonunda yox. Ve Retry mexanizmi qurmuruq.
at least once — Burda bir event bir nece defe catdirila biler. Duplication ehtimnali var amma data itkisi qebul edilmir. Daha cox istifade edilir ancaq emin olmalisiniz ki sizin sistem idompotentdir yeni tekrar event emal olsa sistemde size bu problem yaratmirsa uygundur.
exactly once — Event ancaq max bir defe catdirila biler ve data da itkisi de ola bilmez. Komplekslilik baximindan en komplekisidir.
Kafkaya dusen data immutable-dir kenardan deyisdirile bilmez! Bunu ancaq kafka ozu ede biler.
Gelek consumerlerimize, bu daha cox rabbit ve kafka bir biri ile qarisdiran ve ferqlerini ile bagli beyninde qarsiqiligi, suallari olanlar ucun de daha onemli hissedir. Kafkada da consumer publish olunan mesaji goturur eyni qaydada. Offset olaraq zookeperden harda qaldigi bilir ve ordan ve ya ilk defe ise dusubse basdan baslayaraq oxuyur partionlardaki datani.
Burada rabbitden de esas ferqli olaraq offset commit, offset reset anlayislari var. Rabbitde biz eventi consume edirdik ve artiq o queue-den itirdi, multiple consmer consume etse bele lock olurdu data digeri ucun ve process zamani event isleyerken xeta alsaq bele tutaqki bazaya yazanda rabbitde elave DL ve PL queue-ler yaradib mecbur fail olduqda ora yigirdiq eventlerimizi. Amma kafkada bir nece yanasma var ve biz bir nece defe commit etmesek eventi alib process ede bilirik.
Hemcinin en gozel xususiyyeti menim fikrimce consumer group-lar olmasidir ki bu bize one message to multiple consumer imkani verir. Ve kafkada consumer groupaki consumer ve onlarin oxusudqlari topic saylarimizi kafka ozu bolusdurur, Meselem 2 topic 2 consumer varsa heresi birin. 2 consumer 4 topic arsa heresi 2-sini. Bunu ozu bolur kafka elave setting ehtiyac yoxdur. Artiq elave consumer varsa o ise bosda qalir.
Kafka race condition meselelerine gore bir partition-a birden cox consumer baglamamiza izin vermir.
Consumerlerimiz ucun bir nece configler vardir bunlar kafka oz documentationinda qeyd edilib. Bunlardan bezilerine baxaq :
session.timeout.ms : CG daixlindeki comsumerin broklerle elaqenin kesilmesinin maximal vaxtidir.Bu muddet kecildikde reblalans bas verir aktiv CG-e
enable.auto.commit : Consumerin offseti auto commit edilib edilmemesi ucun istifde edilir. Default true-dur amma false verilse commit edilme intervali control edilmelidir ve duplicate consumingden qacilmalidir. True secildiyi halda her 5 saniyeden bir (default commit interval) pool()-dan gelen last offset id-ni commit edir. commit.interval.ms ile bu intervali deyise bilersiniz ancaq qisa qoysaz network traffic yukleneceyini nezere alin!
auto.offser.reset : Bele bir ssenari dusunek. 1 topicim var ve icerisinde 2 partition ve ilk partitionda 100 message. 2 dene de consumer groupumuz var ve heresinde 2 consumer var. Ve her ikisinin consumeri 1-ci topici consume edir. Bu zaman duplication bas vermesin deye CG1 ve CG2 consumerlerler offsetlerle islemeldiir. Buna gore kafkada offset reset anlayisi vardir. Burada optionlar earliest, latest, datetime, shift by ve none ola biler ve default latest-dir. Earliest secdikde en evvel basdaki offsetden read edecek, latestde en sondan oxuyur. None zamani ise previous offset tapmasa CG ucun xeta verir.
partition.assignment.strategy: Kafkada consumerlere konkret spesifik uneven/even falan spesifik partitionlardan oxunmani temin ede bilerik. Default ise round Robbin-dir yeni partitionlara muraciet paylanir, ancaq spesifik paritionlardan oxunma isteseydik bunun ucun range deyeri veririk.
Producerler ucun de mueyyen maraqli configler var :
batch.size : eventler gonderilmezden evvel max batch seklinde ne qeder byte yigila biler onu gösteririz
linger.ms : Bu producerin eventi kafkaya atmaq ucun gozleme muddetidir. Default eyeri 0-dir. Bele bir example deyek avtobus daynacagi dusunun burda 0 deyeri versek avtobus adam goren kimi dayanacaga gelib onu aparacaq eve ( topic), amma 5 versem meselem 5 deqiqeden bir gelecek ve hetta batch.size = 10 versem her defe max 10 nefer alacaq avtobusa ))
compression.type: Kafkada high throughput elde etmek ucun compression configle de oynaya bilersiniz, hansiki size datani gondermezden evvel compress edib kafka servere atmaga imkan verir. Ve consumer teref ucun her hansi elace decompress-e ehtiyac olmur:
Kafka ozellikleri tekce bunla bitmir Connect Api ve streaming ucun api da verir.
Kafka connect ile meselem siz hanisa bazada table-a qosulub deye bilersizki bu datalar kafkaya replika olunsun dussun o eventler ora.
Kafka streaming ile ise kafkadaki eventler uzerinde aggregationlar apara, join ede bilersiz bir nece topicde olan datani ve.s. Ve sonda harasa sink ede bilersiniz neticeni.
Bunlar haqqinda erragli novbeti meqalelerde yazaram …
Kafka re
