{"id":38172,"date":"2019-10-31T22:22:05","date_gmt":"2019-10-31T19:22:05","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka\/"},"modified":"2019-10-31T22:22:05","modified_gmt":"2019-10-31T19:22:05","slug":"ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka","title":{"rendered":"Kuptimi i broker\u00ebve t\u00eb mesazheve. Studimi i mekanik\u00ebs s\u00eb shk\u00ebmbimit t\u00eb mesazheve me ActiveMQ dhe Kafka. Kapitulli 3. Kafka","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Vazhdimi i p\u00ebrkthimit t\u00eb nj\u00eb libri t\u00eb vog\u00ebl:<br \/>\n\u00abUnderstanding Message Brokers\u00bb,<br \/>\nautori: Jakub Korab, botuesi: O'Reilly Media, Inc., data e botimit: Qershor 2017, ISBN: 9781492049296.<\/p>\n<p>Pjesa e m\u00ebparshme e p\u00ebrkthyer: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466385\/\">Kuptimi i broker\u00ebve t\u00eb mesazheve. Studimi i mekanik\u00ebs s\u00eb shk\u00ebmbimit t\u00eb mesazheve me ActiveMQ dhe Kafka. Kapitulli 1. Hyrje<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>KAPITULLI 3<\/h2>\n<p><\/p>\n<h2>Kafka<\/h2>\n<p>\nKafka u zhvillua n\u00eb LinkedIn p\u00ebr t\u00eb kap\u00ebrcyer disa kufizime t\u00eb broker\u00ebve tradicional\u00eb t\u00eb mesazheve dhe p\u00ebr t\u00eb shmangur nevoj\u00ebn p\u00ebr t\u00eb konfiguruar disa broker\u00eb mesazhesh p\u00ebr nd\u00ebrveprime t\u00eb ndryshme \u00abpik\u00eb m\u00eb pik\u00eb\u00bb, si\u00e7 p\u00ebrshkruhet n\u00eb k\u00ebt\u00eb lib\u00ebr te seksioni \u00abShkall\u00ebzimi vertikal dhe horizontal\u00bb n\u00eb faqen 28. Rastet e p\u00ebrdorimit n\u00eb LinkedIn bazoheshin kryesisht n\u00eb p\u00ebrthithjen nj\u00ebkah\u00ebshe t\u00eb v\u00ebllimeve shum\u00eb t\u00eb m\u00ebdha t\u00eb t\u00eb dh\u00ebnave, si klikimet n\u00eb faqe dhe regjistrat e aksesit, duke u mund\u00ebsuar nj\u00ebkoh\u00ebsisht disa sistemeve t\u2019i p\u00ebrdorin k\u00ebto t\u00eb dh\u00ebna pa ndikuar n\u00eb performanc\u00ebn e prodhuesve ose t\u00eb konsumator\u00ebve t\u00eb tjer\u00eb. N\u00eb fakt, arsyeja pse ekziston Kafka \u00ebsht\u00eb krijimi i asaj arkitekture t\u00eb shk\u00ebmbimit t\u00eb mesazheve q\u00eb p\u00ebrshkruhet nga Universal Data Pipeline.<\/p>\n<p>Duke pasur parasysh k\u00ebt\u00eb q\u00ebllim p\u00ebrfundimtar, natyrsh\u00ebm lind\u00ebn edhe k\u00ebrkesa t\u00eb tjera. Kafka duhet:<\/p>\n<ul>\n<li>T\u00eb jet\u00eb jasht\u00ebzakonisht e shpejt\u00eb<\/li>\n<li>T\u00eb ofroj\u00eb throughput t\u00eb lart\u00eb gjat\u00eb pun\u00ebs me mesazhe<\/li>\n<li>T\u00eb mb\u00ebshtes\u00eb modelet \u00abPublisher-Subscriber\u00bb dhe \u00abPoint-to-Point\u00bb<\/li>\n<li>T\u00eb mos ngadal\u00ebsohet me shtimin e konsumator\u00ebve. P\u00ebr shembull, performanca si e radh\u00ebs ashtu edhe e topic n\u00eb ActiveMQ bie me rritjen e numrit t\u00eb konsumator\u00ebve te destinacioni<\/li>\n<li>T\u00eb jet\u00eb e shkall\u00ebzueshme horizontalisht; n\u00ebse nj\u00eb broker i vet\u00ebm q\u00eb ruan (persists) mesazhet mund ta b\u00ebj\u00eb k\u00ebt\u00eb vet\u00ebm me shpejt\u00ebsin\u00eb maksimale t\u00eb diskut, at\u00ebher\u00eb p\u00ebr t\u00eb rritur performanc\u00ebn ka kuptim t\u00eb kalohet p\u00ebrtej nj\u00eb instance t\u00eb vetme brokeri<\/li>\n<li>T\u00eb ndaj\u00eb aksesin ndaj ruajtjes dhe ririkthimit t\u00eb mesazheve<\/li>\n<\/ul>\n<p>\nP\u00ebr t\u00eb arritur t\u00eb gjitha k\u00ebto, Kafka p\u00ebrdor nj\u00eb arkitektur\u00eb q\u00eb ka rip\u00ebrcaktuar rolet dhe p\u00ebrgjegj\u00ebsit\u00eb e klient\u00ebve dhe broker\u00ebve t\u00eb mesazheve. Modeli JMS \u00ebsht\u00eb shum\u00eb i p\u00ebrqendruar te brokeri, ku ai \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr shp\u00ebrndarjen e mesazheve, nd\u00ebrsa klient\u00ebt duhet t\u00eb kujdesen vet\u00ebm p\u00ebr d\u00ebrgimin dhe marrjen e tyre. Kafka, nga ana tjet\u00ebr, \u00ebsht\u00eb e p\u00ebrqendruar te klienti, ku klienti merr p\u00ebrsip\u00ebr shum\u00eb funksione t\u00eb brokerit tradicional, si\u00e7 \u00ebsht\u00eb shp\u00ebrndarja e drejt\u00eb e mesazheve p\u00ebrkat\u00ebse te konsumator\u00ebt, duke marr\u00eb n\u00eb k\u00ebmbim nj\u00eb broker jasht\u00ebzakonisht t\u00eb shpejt\u00eb dhe t\u00eb shkall\u00ebzuesh\u00ebm. P\u00ebr ata q\u00eb kan\u00eb punuar me sisteme tradicionale t\u00eb mesazheve, puna me Kafka k\u00ebrkon nj\u00eb ndryshim thelb\u00ebsor n\u00eb m\u00ebnyr\u00ebn e t\u00eb menduarit.<br \/>\nKjo qasje inxhinierike \u00e7oi n\u00eb krijimin e nj\u00eb infrastrukture mesazhesh q\u00eb \u00ebsht\u00eb n\u00eb gjendje t\u00eb rris\u00eb throughput-in me shum\u00eb rende madh\u00ebsie krahasuar me nj\u00eb broker t\u00eb zakonsh\u00ebm. Si\u00e7 do t\u00eb shohim, kjo qasje sjell edhe kompromise, q\u00eb do t\u00eb thot\u00eb se Kafka nuk \u00ebsht\u00eb e p\u00ebrshtatshme p\u00ebr disa lloje ngarkesash dhe software-i t\u00eb instaluar.<\/p>\n<h3>Modeli i unifikuar i adresimit<\/h3>\n<p>\nP\u00ebr t\u00eb p\u00ebrmbushur k\u00ebrkesat e p\u00ebrshkruara m\u00eb sip\u00ebr, Kafka bashkoi modelet e mesazheve \u00abpublish-subscribe\u00bb dhe \u00abpoint-to-point\u00bb brenda nj\u00eb lloji t\u00eb vet\u00ebm adresimi \u2014 <i>topic<\/i>. Kjo mund t\u00eb ngat\u00ebrroj\u00eb ata q\u00eb kan\u00eb punuar me sisteme mesazhesh ku fjala \u00abtopic\u00bb i referohet nj\u00eb mekanizmi broadcast, nga i cili leximi nuk \u00ebsht\u00eb i q\u00ebndruesh\u00ebm (is nondurable). Topic-et n\u00eb Kafka duhen par\u00eb si nj\u00eb lloj hibrid adresimi, sipas p\u00ebrkufizimit t\u00eb dh\u00ebn\u00eb n\u00eb hyrje t\u00eb k\u00ebtij libri.<\/p>\n<blockquote><p>N\u00eb pjes\u00ebn e mbetur t\u00eb k\u00ebtij kapitulli, n\u00ebse nuk e specifikojm\u00eb qart\u00eb ndryshe, termi \u00abtopic\u00bb do t\u2019i referohet topic-ut t\u00eb Kafka.<\/p><\/blockquote>\n<p>\nP\u00ebr t\u00eb kuptuar plot\u00ebsisht si sillen topic-et dhe \u00e7far\u00eb garancish ofrojn\u00eb ato, fillimisht duhet t\u00eb shqyrtojm\u00eb se si zbatohen ato n\u00eb Kafka.<br \/>\n<i>\u00c7do topic n\u00eb Kafka ka log-un e vet.<\/i><br \/>\nProdhuesit q\u00eb d\u00ebrgojn\u00eb mesazhe n\u00eb Kafka shkruajn\u00eb n\u00eb k\u00ebt\u00eb log, nd\u00ebrsa konsumator\u00ebt lexojn\u00eb nga logu duke p\u00ebrdorur tregues q\u00eb l\u00ebvizin vazhdimisht p\u00ebrpara. Her\u00eb pas here, Kafka fshin pjes\u00ebt m\u00eb t\u00eb vjetra t\u00eb logut, pavar\u00ebsisht n\u00ebse mesazhet n\u00eb ato pjes\u00eb jan\u00eb lexuar apo jo. Nj\u00eb pjes\u00eb qendrore e arkitektur\u00ebs s\u00eb Kafka \u00ebsht\u00eb se brokeri nuk merret me faktin n\u00ebse mesazhet jan\u00eb lexuar apo jo \u2014 kjo \u00ebsht\u00eb p\u00ebrgjegj\u00ebsi e klientit.<\/p>\n<blockquote><p>Termat \u00ablog\u00bb dhe \u00abtregues\u00bb nuk p\u00ebrdoren n\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/kafka.apache.org\/documentation.html\">dokumentacionin e Kafka<\/a><\/noindex>. K\u00ebta terma t\u00eb njohur p\u00ebrdoren k\u00ebtu p\u00ebr ta b\u00ebr\u00eb kuptimin m\u00eb t\u00eb qart\u00eb.<\/p><\/blockquote>\n<p>\nKy model \u00ebsht\u00eb krejt\u00ebsisht i ndrysh\u00ebm nga ActiveMQ, ku mesazhet nga t\u00eb gjitha radh\u00ebt ruhen n\u00eb nj\u00eb log t\u00eb vet\u00ebm dhe brokeri i sh\u00ebnon mesazhet si t\u00eb fshira pasi t\u00eb jen\u00eb lexuar.<br \/>\nTani le t\u00eb hyjm\u00eb pak m\u00eb thell\u00eb dhe ta shqyrtojm\u00eb m\u00eb n\u00eb detaje logun e topic.<br \/>\nLogu i Kafka p\u00ebrb\u00ebhet nga disa particione (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/tm\/w2\/yf\/tmw2yf3lanppqtrumxoidotplhi.png\">Figure 3-1<\/a><\/noindex>). Kafka garanton renditje strikte brenda \u00e7do particioni. Kjo do t\u00eb thot\u00eb se mesazhet e shkruara n\u00eb nj\u00eb particion n\u00eb nj\u00eb rend t\u00eb caktuar do t\u00eb lexohen n\u00eb t\u00eb nj\u00ebjtin rend. \u00c7do particion zbatohet si nj\u00eb skedar logu ciklik (rolling), i cili p\u00ebrmban <i>nj\u00eb n\u00ebngrup <\/i>(subset) t\u00eb t\u00eb gjitha mesazheve t\u00eb d\u00ebrguara n\u00eb topic nga prodhuesit e tij. Topic i krijuar p\u00ebrmban si parazgjedhje nj\u00eb particion. Ideja e particioneve \u00ebsht\u00eb thelb\u00ebsore n\u00eb Kafka p\u00ebr shkall\u00ebzim horizontal.<\/p>\n<p><img decoding=\"async\" alt=\"Kuptimi i broker\u00ebve t\u00eb mesazheve. Studimi i mekanik\u00ebs s\u00eb shk\u00ebmbimit t\u00eb mesazheve me ActiveMQ dhe Kafka. Kapitulli 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/39f41ebcb73ec247656c0dea438158a9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figure 3-1. Particionet e Kafka<\/i><\/p>\n<p>Kur prodhuesi d\u00ebrgon nj\u00eb mesazh n\u00eb nj\u00eb topic t\u00eb Kafka, ai vendos se n\u00eb cilin particion do ta d\u00ebrgoj\u00eb mesazhin. K\u00ebt\u00eb do ta shqyrtojm\u00eb m\u00eb n\u00eb detaje m\u00eb von\u00eb.<\/p>\n<h2>Leximi i mesazheve<\/h2>\n<p>\nKlienti q\u00eb d\u00ebshiron t\u00eb lexoj\u00eb mesazhe menaxhon nj\u00eb tregues t\u00eb em\u00ebrtuar, i quajtur <i>grup konsumator\u00ebsh (consumer group)<\/i>, i cili tregon te <i>zhvendosja (offset)<\/i> e mesazhit n\u00eb particion. Zhvendosja \u00ebsht\u00eb nj\u00eb pozicion me num\u00ebr n\u00eb rritje, q\u00eb fillon nga 0 n\u00eb fillim t\u00eb particionit. Ky grup konsumator\u00ebsh, t\u00eb cilit i referohet API p\u00ebrmes identifikuesit group_id t\u00eb p\u00ebrcaktuar nga p\u00ebrdoruesi, korrespondon me <i>nj\u00eb konsumator ose sistem logjik t\u00eb vet\u00ebm<\/i>.<\/p>\n<p>Shumica e sistemeve q\u00eb p\u00ebrdorin shk\u00ebmbimin e mesazheve i lexojn\u00eb t\u00eb dh\u00ebnat nga marr\u00ebsi p\u00ebrmes disa instancave dhe rrjedhave p\u00ebr p\u00ebrpunim paralel t\u00eb mesazheve. Prandaj, zakonisht ka shum\u00eb instanca consumer q\u00eb ndajn\u00eb t\u00eb nj\u00ebjtin grup consumer\u00ebsh.<\/p>\n<p>Problemi i leximit mund t\u00eb paraqitet si m\u00eb posht\u00eb:<\/p>\n<ul>\n<li>Topic ka disa particione<\/li>\n<li>Nj\u00eb topic mund t\u00eb p\u00ebrdoret nj\u00ebkoh\u00ebsisht nga shum\u00eb grupe consumer\u00ebsh<\/li>\n<li>Nj\u00eb grup consumer\u00ebsh mund t\u00eb ket\u00eb disa instanca t\u00eb ve\u00e7anta<\/li>\n<\/ul>\n<p>\nKjo \u00ebsht\u00eb nj\u00eb problematik\u00eb jo e thjesht\u00eb \u00abshum\u00eb me shum\u00eb\u00bb. P\u00ebr t\u00eb kuptuar se si Kafka i trajton marr\u00ebdh\u00ebniet midis grupeve t\u00eb consumer\u00ebve, instancave t\u00eb consumer\u00ebve dhe particioneve, le t\u00eb shqyrtojm\u00eb nj\u00eb s\u00ebr\u00eb skenar\u00ebsh leximi q\u00eb b\u00ebhen gradualisht m\u00eb kompleks\u00eb.<\/p>\n<h3>Consumer\u00ebt dhe grupet e consumer\u00ebve<\/h3>\n<p>\nLe t\u00eb marrim si pik\u00ebnisje nj\u00eb topic me nj\u00eb particion (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/6z\/tz\/dh\/6ztzdhqmjweck-z15htxb2xbe28.png\">Figura 3-2<\/a><\/noindex>).<\/p>\n<p><img decoding=\"async\" alt=\"Kuptimi i broker\u00ebve t\u00eb mesazheve. Studimi i mekanik\u00ebs s\u00eb shk\u00ebmbimit t\u00eb mesazheve me ActiveMQ dhe Kafka. Kapitulli 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/46c92e6bd38774dfef3be4bd198bf35d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 3-2. Consumer lexon nga particioni<\/i><\/p>\n<p>Kur nj\u00eb instanc\u00eb consumer lidhet me k\u00ebt\u00eb topic me group_id-n\u00eb e vet, asaj i caktohet nj\u00eb particion p\u00ebr lexim dhe nj\u00eb offset n\u00eb at\u00eb particion. Pozicioni i k\u00ebtij offset-i konfigurohet te klienti si tregues i pozicionit m\u00eb t\u00eb fundit (mesazhi m\u00eb i ri) ose i pozicionit m\u00eb t\u00eb hersh\u00ebm (mesazhi m\u00eb i vjet\u00ebr). Consumer k\u00ebrkon (polls) mesazhe nga topic, gj\u00eb q\u00eb \u00e7on n\u00eb leximin e tyre n\u00eb m\u00ebnyr\u00eb sekuenciale nga log-u.<br \/>\nPozicioni i offset-it komitohet rregullisht p\u00ebrs\u00ebri n\u00eb Kafka dhe ruhet si mesazhe n\u00eb topic-un e brendsh\u00ebm <i>_consumer_offsets<\/i>. Mesazhet e lexuara gjithsesi nuk fshihen, ndryshe nga nj\u00eb broker i zakonsh\u00ebm, dhe klienti mund ta kthej\u00eb mbrapa (rewind) offset-in p\u00ebr t\u00eb rip\u00ebrpunuar mesazhet e shqyrtuara m\u00eb par\u00eb.<\/p>\n<p>Kur lidhet nj\u00eb consumer i dyt\u00eb logjik, duke p\u00ebrdorur nj\u00eb group_id tjet\u00ebr, ai menaxhon nj\u00eb tregues t\u00eb dyt\u00eb q\u00eb \u00ebsht\u00eb i pavarur nga i pari (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/qe\/v1\/yk\/qev1yktga3s-g1gqlynylbe3n9w.png\">Figura 3-3<\/a><\/noindex>). K\u00ebshtu, topic-u Kafka vepron si nj\u00eb radh\u00eb ku ekziston nj\u00eb consumer dhe, nj\u00ebkoh\u00ebsisht, si nj\u00eb topic i zakonsh\u00ebm publisher-subscriber (pub-sub), n\u00eb t\u00eb cilin jan\u00eb abonuar disa consumer\u00eb, me avantazhin shtes\u00eb q\u00eb t\u00eb gjitha mesazhet ruhen dhe mund t\u00eb p\u00ebrpunohen disa her\u00eb.<\/p>\n<p><img decoding=\"async\" alt=\"Kuptimi i broker\u00ebve t\u00eb mesazheve. Studimi i mekanik\u00ebs s\u00eb shk\u00ebmbimit t\u00eb mesazheve me ActiveMQ dhe Kafka. Kapitulli 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/e9e8b9063ef7367005254d36abb47f4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 3-3. Dy consumer\u00eb n\u00eb grupe t\u00eb ndryshme consumer\u00ebsh lexojn\u00eb nga i nj\u00ebjti particion<\/i><\/p>\n<h3>Consumer\u00ebt n\u00eb nj\u00eb grup consumer\u00ebsh<\/h3>\n<p>\nKur nj\u00eb instanc\u00eb e consumer-it lexon t\u00eb dh\u00ebna nga nj\u00eb particion, ajo e kontrollon plot\u00ebsisht pointer-in dhe p\u00ebrpunon mesazhet, si\u00e7 p\u00ebrshkruhet n\u00eb seksionin e m\u00ebparsh\u00ebm.<br \/>\nN\u00ebse disa instanca consumer-\u00ebsh jan\u00eb lidhur me t\u00eb nj\u00ebjtin group_id n\u00eb nj\u00eb topic me nj\u00eb particion, kontrolli mbi pointer-in do t\u2019i kaloj\u00eb instanc\u00ebs q\u00eb \u00ebsht\u00eb lidhur e fundit dhe q\u00eb nga ai moment ajo do t\u00eb marr\u00eb t\u00eb gjitha mesazhet (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/0j\/ao\/f2\/0jaof2mdwg3cqvmwemhtxkrltuq.png\">Figura 3-4<\/a><\/noindex>).<\/p>\n<p><img decoding=\"async\" alt=\"Kuptimi i broker\u00ebve t\u00eb mesazheve. Studimi i mekanik\u00ebs s\u00eb shk\u00ebmbimit t\u00eb mesazheve me ActiveMQ dhe Kafka. Kapitulli 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/ec6af819445dad4028f65449a735ae22.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 3-4. Dy consumer n\u00eb t\u00eb nj\u00ebjtin grup consumer-\u00ebsh lexojn\u00eb nga nj\u00eb particion<\/i><\/p>\n<p>Ky regjim p\u00ebrpunimi, ku numri i instancave t\u00eb consumer-it tejkalon numrin e particioneve, mund t\u00eb konsiderohet si nj\u00eb variant i konsumatorit monopol. Kjo mund t\u00eb jet\u00eb e dobishme n\u00ebse ju nevojitet klasterizim \u00abactive-passive\u00bb (ose \u00abhot-warm\u00bb) i instancave tuaja consumer, megjith\u00ebse funksionimi paralel i disa consumer-\u00ebve (\u00abactive-active\u00bb ose \u00abhot-hot\u00bb) \u00ebsht\u00eb shum\u00eb m\u00eb tipik sesa consumer-\u00ebt n\u00eb gjendje pritjeje.<\/p>\n<blockquote><p>Kjo sjellje e shp\u00ebrndarjes s\u00eb mesazheve, e p\u00ebrshkruar m\u00eb sip\u00ebr, mund t\u00eb duket e pazakont\u00eb krahasuar me m\u00ebnyr\u00ebn se si sillet nj\u00eb radh\u00eb e zakonshme JMS. N\u00eb k\u00ebt\u00eb model, mesazhet e d\u00ebrguara n\u00eb radh\u00eb do t\u00eb shp\u00ebrndahen n\u00eb m\u00ebnyr\u00eb t\u00eb barabart\u00eb midis dy consumer-\u00ebve.<\/p><\/blockquote>\n<p>\nM\u00eb s\u00eb shpeshti, kur krijojm\u00eb disa instanca consumer-\u00ebsh, e b\u00ebjm\u00eb k\u00ebt\u00eb ose p\u00ebr p\u00ebrpunim paralel t\u00eb mesazheve, ose p\u00ebr t\u00eb rritur shpejt\u00ebsin\u00eb e leximit, ose p\u00ebr t\u00eb p\u00ebrmir\u00ebsuar q\u00ebndrueshm\u00ebrin\u00eb e procesit t\u00eb leximit. Meqen\u00ebse t\u00eb dh\u00ebnat nga nj\u00eb particion mund t\u00eb lexohen nj\u00ebkoh\u00ebsisht vet\u00ebm nga nj\u00eb instanc\u00eb consumer-i, si arrihet kjo n\u00eb Kafka?<\/p>\n<p>Nj\u00eb nga m\u00ebnyrat p\u00ebr ta b\u00ebr\u00eb k\u00ebt\u00eb \u00ebsht\u00eb p\u00ebrdorimi i nj\u00eb instance consumer-i p\u00ebr t\u00eb lexuar t\u00eb gjitha mesazhet dhe p\u00ebr t\u2019ia kaluar ato nj\u00eb pool-i threads. Edhe pse kjo qasje rrit kapacitetin e p\u00ebrpunimit, ajo e shton kompleksitetin e logjik\u00ebs s\u00eb consumer-it dhe nuk b\u00ebn asgj\u00eb p\u00ebr t\u00eb p\u00ebrmir\u00ebsuar q\u00ebndrueshm\u00ebrin\u00eb e sistemit t\u00eb leximit. N\u00ebse nj\u00eb instanc\u00eb consumer-i ndalet p\u00ebr shkak t\u00eb nd\u00ebrprerjes s\u00eb energjis\u00eb ose nj\u00eb ngjarjeje t\u00eb ngjashme, leximi nd\u00ebrpritet.<\/p>\n<p>M\u00ebnyra kanonike p\u00ebr ta zgjidhur k\u00ebt\u00eb problem n\u00eb Kafka \u00ebsht\u00eb p\u00ebrdorimi i nj\u00eb numri m\u00eb t\u00eb<i>Q<\/i>madh particionesh.<\/p>\n<h3>Particionimi<\/h3>\n<p>\nParticionet jan\u00eb mekanizmi kryesor p\u00ebr paralelizimin e leximit dhe p\u00ebr shkall\u00ebzimin e topic p\u00ebrtej kapacitetit t\u00eb nj\u00eb instance t\u00eb vetme brokeri. P\u00ebr ta kuptuar m\u00eb mir\u00eb k\u00ebt\u00eb, le t\u00eb shqyrtojm\u00eb situat\u00ebn kur ekziston nj\u00eb topic me dy particione dhe n\u00eb k\u00ebt\u00eb topic \u00ebsht\u00eb abonuar nj\u00eb consumer (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/en\/9g\/ct\/en9gct0o017cqp8buawguwlscty.png\">Figura 3-5<\/a><\/noindex>).<\/p>\n<p><img decoding=\"async\" alt=\"Kuptimi i broker\u00ebve t\u00eb mesazheve. Studimi i mekanik\u00ebs s\u00eb shk\u00ebmbimit t\u00eb mesazheve me ActiveMQ dhe Kafka. Kapitulli 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/cc766bf69af22698aacc3f1ac70b067f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 3-5. Nj\u00eb consumer lexon nga disa particione<\/i><\/p>\n<p>N\u00eb k\u00ebt\u00eb skenar, consumer-it i jepet kontrolli mbi offset-et q\u00eb korrespondojn\u00eb me group_id e tij n\u00eb t\u00eb dy particionet dhe nis leximi i mesazheve nga t\u00eb dy particionet.<br \/>\nKur k\u00ebtij topic i shtohet nj\u00eb consumer tjet\u00ebr p\u00ebr t\u00eb nj\u00ebjtin group_id, Kafka ricakton (reallocate) nj\u00ebrin nga particionet nga consumer-i i par\u00eb te i dyti. Pas k\u00ebsaj, secila instanc\u00eb consumer-i do t\u00eb lexoj\u00eb nga nj\u00eb particion i topic (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/8b\/a0\/um\/8ba0umn2yzr9yy3vztonhdfiub0.png\">Figura 3-6<\/a><\/noindex>).<\/p>\n<p>P\u00ebr t\u00eb siguruar p\u00ebrpunimin paralel t\u00eb mesazheve n\u00eb 20 rrjedha, do t\u2019ju duhen t\u00eb pakt\u00ebn 20 particione. N\u00ebse particionet jan\u00eb m\u00eb pak, do t\u00eb mbeten consumer-a pa pun\u00eb, si\u00e7 u p\u00ebrshkrua m\u00eb her\u00ebt n\u00eb diskutimin p\u00ebr consumer-at monopol.<\/p>\n<p><img decoding=\"async\" alt=\"Kuptimi i broker\u00ebve t\u00eb mesazheve. Studimi i mekanik\u00ebs s\u00eb shk\u00ebmbimit t\u00eb mesazheve me ActiveMQ dhe Kafka. Kapitulli 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/a3c4001e4a5b92d53b6f529b2633254a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 3-6. Dy consumer-a n\u00eb t\u00eb nj\u00ebjtin grup consumer-ash lexojn\u00eb nga particione t\u00eb ndryshme<\/i><\/p>\n<p>Kjo skem\u00eb e ul ndjesh\u00ebm kompleksitetin e pun\u00ebs s\u00eb brokerit Kafka krahasuar me shp\u00ebrndarjen e mesazheve q\u00eb k\u00ebrkohet p\u00ebr t\u00eb mb\u00ebshtetur nj\u00eb radh\u00eb JMS. K\u00ebtu nuk ka nevoj\u00eb t\u00eb shqet\u00ebsoheni p\u00ebr pikat e m\u00ebposhtme:<\/p>\n<ul>\n<li>Cili consumer duhet ta marr\u00eb mesazhin e radh\u00ebs, bazuar n\u00eb shp\u00ebrndarjen ciklike (round-robin), kapacitetin aktual t\u00eb buffer-\u00ebve t\u00eb prefetch-it ose mesazhet e m\u00ebparshme (si te grupet e mesazheve JMS).<\/li>\n<li>Cilat mesazhe u jan\u00eb d\u00ebrguar cil\u00ebve consumer-ave dhe n\u00ebse ato duhet t\u00eb rid\u00ebrgohen n\u00eb rast d\u00ebshtimi.<\/li>\n<\/ul>\n<p>\nGjith\u00e7ka q\u00eb duhet t\u00eb b\u00ebj\u00eb brokeri Kafka \u00ebsht\u00eb t\u2019i dor\u00ebzoj\u00eb mesazhet consumer-it n\u00eb m\u00ebnyr\u00eb sekuenciale, kur ky i fundit i k\u00ebrkon ato.<\/p>\n<p>Megjithat\u00eb, k\u00ebrkesat p\u00ebr paralelizimin e leximit dhe rid\u00ebrgimin e mesazheve t\u00eb d\u00ebshtuara nuk zhduken askund \u2014 p\u00ebrgjegj\u00ebsia p\u00ebr to thjesht kalon nga brokeri te klienti. Kjo do t\u00eb thot\u00eb se ato duhet t\u00eb merren parasysh n\u00eb kodin tuaj.<\/p>\n<h2>D\u00ebrgimi i mesazheve<\/h2>\n<p>\nP\u00ebrgjegj\u00ebsia p\u00ebr t\u00eb vendosur se n\u00eb cilin particion t\u00eb d\u00ebrgohet mesazhi i takon producer-it t\u00eb atij mesazhi. P\u00ebr t\u00eb kuptuar mekanizmin me t\u00eb cilin b\u00ebhet kjo, fillimisht duhet t\u00eb shqyrtojm\u00eb se \u00e7far\u00eb po d\u00ebrgojm\u00eb n\u00eb t\u00eb v\u00ebrtet\u00eb.<\/p>\n<p>Nd\u00ebrsa n\u00eb JMS p\u00ebrdorim nj\u00eb struktur\u00eb mesazhi me metadata (header-a dhe veti) dhe nj\u00eb trup q\u00eb p\u00ebrmban ngarkes\u00ebn e dobishme (payload), n\u00eb Kafka mesazhi \u00ebsht\u00eb nj\u00eb <i>\u00e7ift \u00ab\u00e7el\u00ebs-vler\u00eb\u00bb<\/i>. Ngarkesa e dobishme e mesazhit d\u00ebrgohet si vlera (value). \u00c7el\u00ebsi, nga ana tjet\u00ebr, p\u00ebrdoret kryesisht p\u00ebr particionim dhe duhet t\u00eb p\u00ebrmbaj\u00eb nj\u00eb <i>\u00e7el\u00ebs specifik p\u00ebr logjik\u00ebn e biznesit<\/i>, n\u00eb m\u00ebnyr\u00eb q\u00eb mesazhet e lidhura t\u00eb vendosen n\u00eb t\u00eb nj\u00ebjtin particion.<\/p>\n<p>N\u00eb Kapitullin 2 diskutuam skenarin e basteve online, ku ngjarjet e lidhura duhet t\u00eb p\u00ebrpunohen sipas radh\u00ebs nga nj\u00eb consumer i vet\u00ebm:<\/p>\n<ol>\n<li>Llogaria e p\u00ebrdoruesit konfigurohet.<\/li>\n<li>Parat\u00eb kreditohen n\u00eb llogari.<\/li>\n<li>Vendoset nj\u00eb bast, i cili i t\u00ebrheq parat\u00eb nga llogaria.<\/li>\n<\/ol>\n<p>\nN\u00ebse \u00e7do ngjarje p\u00ebrfaq\u00ebson nj\u00eb mesazh t\u00eb d\u00ebrguar n\u00eb nj\u00eb topic, at\u00ebher\u00eb n\u00eb k\u00ebt\u00eb rast \u00e7el\u00ebsi natyror do t\u00eb ishte identifikuesi i llogaris\u00eb.<br \/>\nKur nj\u00eb mesazh d\u00ebrgohet duke p\u00ebrdorur Kafka Producer API, ai i kalon funksionit t\u00eb particionimit, i cili, duke marr\u00eb parasysh mesazhin dhe gjendjen aktuale t\u00eb klasterit Kafka, kthen identifikuesin e particionit ku duhet t\u00eb d\u00ebrgohet mesazhi. Ky funksion zbatohet n\u00eb Java p\u00ebrmes nd\u00ebrfaqes Partitioner.<\/p>\n<p>Kjo nd\u00ebrfaqe duket si m\u00eb posht\u00eb:<\/p>\n<pre><code class=\"java\">interface Partitioner {\n    int partition(String topic,\n        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);\n}<\/code><\/pre>\n<p>\nImplementimi i Partitioner p\u00ebr p\u00ebrcaktimin e particionit p\u00ebrdor si parazgjedhje algoritmin e hash-it mbi \u00e7el\u00ebsin (general-purpose hashing algorithm over the key) ose round-robin, n\u00ebse \u00e7el\u00ebsi nuk \u00ebsht\u00eb specifikuar. Kjo vler\u00eb e parazgjedhur funksionon mir\u00eb n\u00eb shumic\u00ebn e rasteve. Megjithat\u00eb, n\u00eb t\u00eb ardhmen mund t\u00eb d\u00ebshironi t\u00eb shkruani nj\u00eb implementim tuajin.<\/p>\n<h3>Shkrimi i strategjis\u00eb suaj t\u00eb particionimit<\/h3>\n<p>\nLe t\u00eb shqyrtojm\u00eb nj\u00eb shembull kur d\u00ebshironi t\u00eb d\u00ebrgoni metadata s\u00eb bashku me ngarkes\u00ebn e dobishme t\u00eb mesazhit. Ngarkesa e dobishme n\u00eb shembullin ton\u00eb \u00ebsht\u00eb nj\u00eb udh\u00ebzim p\u00ebr t\u00eb b\u00ebr\u00eb nj\u00eb depozit\u00eb n\u00eb llogarin\u00eb e loj\u00ebs. Udh\u00ebzimi \u00ebsht\u00eb ajo q\u00eb duam t\u00eb garantojm\u00eb se nuk modifikohet gjat\u00eb transmetimit dhe duam t\u00eb jemi t\u00eb sigurt se vet\u00ebm nj\u00eb sistem i besuar n\u00eb rrjedh\u00ebn sip\u00ebr mund ta inicioj\u00eb k\u00ebt\u00eb udh\u00ebzim. N\u00eb k\u00ebt\u00eb rast, sistemi d\u00ebrgues dhe ai marr\u00ebs bien dakord p\u00ebr p\u00ebrdorimin e nj\u00eb n\u00ebnshkrimi p\u00ebr t\u00eb verifikuar autenticitetin e mesazhit.<br \/>\nN\u00eb JMS t\u00eb zakonsh\u00ebm, thjesht p\u00ebrcaktojm\u00eb nj\u00eb veti \u00abn\u00ebnshkrimi i mesazhit\u00bb dhe ia shtojm\u00eb mesazhit. Megjithat\u00eb, Kafka nuk na ofron nj\u00eb mekaniz\u00ebm p\u00ebr t\u00eb transmetuar metadata \u2014 vet\u00ebm \u00e7el\u00ebsin dhe vler\u00ebn.<\/p>\n<p>Meqen\u00ebse vlera \u00ebsht\u00eb payload-i i transferimit bankar, integritetin e s\u00eb cil\u00ebs duam ta ruajm\u00eb, nuk na mbetet zgjidhje tjet\u00ebr ve\u00e7se t\u00eb p\u00ebrcaktojm\u00eb nj\u00eb struktur\u00eb t\u00eb dh\u00ebnash p\u00ebr p\u00ebrdorim te \u00e7el\u00ebsi. Duke supozuar se na duhet identifikuesi i llogaris\u00eb p\u00ebr particionim, pasi t\u00eb gjitha mesazhet q\u00eb lidhen me llogarin\u00eb duhet t\u00eb p\u00ebrpunohen sipas radh\u00ebs, do t\u00eb p\u00ebrdorim struktur\u00ebn e m\u00ebposhtme JSON:<\/p>\n<pre><code class=\"json\">{\n  \"signature\": \"541661622185851c248b41bf0cea7ad0\",\n  \"accountId\": \"10007865234\"\n}<\/code><\/pre>\n<p>\nMeqen\u00ebse vlera e n\u00ebnshkrimit do t\u00eb ndryshoj\u00eb n\u00eb var\u00ebsi t\u00eb payload-it, strategjia e parazgjedhur e hash-it e nd\u00ebrfaqes Partitioner nuk do t\u2019i grupoj\u00eb n\u00eb m\u00ebnyr\u00eb t\u00eb besueshme mesazhet e lidhura. Prandaj, do t\u00eb na duhet t\u00eb shkruajm\u00eb strategjin\u00eb ton\u00eb, e cila do ta analizoj\u00eb k\u00ebt\u00eb \u00e7el\u00ebs dhe do t\u00eb b\u00ebj\u00eb partition sipas vler\u00ebs accountId.<\/p>\n<blockquote><p>Kafka p\u00ebrfshin checksum-e p\u00ebr zbulimin e d\u00ebmtimit t\u00eb mesazheve n\u00eb ruajtje dhe ofron nj\u00eb gam\u00eb t\u00eb plot\u00eb funksionesh sigurie. Edhe k\u00ebshtu, ndonj\u00ebher\u00eb shfaqen k\u00ebrkesa specifike p\u00ebr industri t\u00eb caktuara, si ajo e p\u00ebrmendur m\u00eb sip\u00ebr.<\/p><\/blockquote>\n<p>\nNj\u00eb strategji e personalizuar e particionimit duhet t\u00eb garantoj\u00eb q\u00eb t\u00eb gjitha mesazhet e lidhura t\u00eb p\u00ebrfundojn\u00eb n\u00eb t\u00eb nj\u00ebjt\u00ebn particion. Edhe pse kjo duket e thjesht\u00eb, k\u00ebrkesa mund t\u00eb nd\u00ebrlikohet p\u00ebr shkak t\u00eb r\u00ebnd\u00ebsis\u00eb s\u00eb renditjes s\u00eb mesazheve t\u00eb lidhura dhe nga fakti sa i pandryshuesh\u00ebm \u00ebsht\u00eb numri i particioneve n\u00eb topic.<\/p>\n<p>Numri i particioneve n\u00eb topic mund t\u00eb ndryshoj\u00eb me kalimin e koh\u00ebs, pasi ato mund t\u00eb shtohen n\u00ebse trafiku tejkalon pritshm\u00ebrit\u00eb fillestare. Si rrjedhoj\u00eb, \u00e7el\u00ebsat e mesazheve mund t\u00eb lidhen me particionin ku jan\u00eb d\u00ebrguar fillimisht, duke n\u00ebnkuptuar nj\u00eb pjes\u00eb gjendjeje q\u00eb duhet t\u00eb shp\u00ebrndahet midis instancave t\u00eb producer-it.<\/p>\n<p>Nj\u00eb faktor tjet\u00ebr q\u00eb duhet marr\u00eb parasysh \u00ebsht\u00eb nj\u00ebtrajtshm\u00ebria e shp\u00ebrndarjes s\u00eb mesazheve midis particioneve. N\u00eb p\u00ebrgjith\u00ebsi, \u00e7el\u00ebsat nuk shp\u00ebrndahen n\u00eb m\u00ebnyr\u00eb t\u00eb barabart\u00eb n\u00ebp\u00ebr mesazhe dhe funksionet hash nuk garantojn\u00eb shp\u00ebrndarje t\u00eb drejt\u00eb t\u00eb mesazheve p\u00ebr nj\u00eb grup t\u00eb vog\u00ebl \u00e7el\u00ebsash.<br \/>\n\u00cbsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb theksohet se, pavar\u00ebsisht si vendosni t\u2019i ndani mesazhet, vet\u00eb ndar\u00ebsi mund t\u00eb duhet t\u00eb p\u00ebrdoret s\u00ebrish.<\/p>\n<p>Le t\u00eb shqyrtojm\u00eb k\u00ebrkes\u00ebn p\u00ebr replikimin e t\u00eb dh\u00ebnave midis klaster\u00ebve Kafka n\u00eb vendndodhje t\u00eb ndryshme gjeografike. P\u00ebr k\u00ebt\u00eb q\u00ebllim, Kafka ofron nj\u00eb mjet t\u00eb linj\u00ebs s\u00eb komand\u00ebs t\u00eb quajtur MirrorMaker, i cili p\u00ebrdoret p\u00ebr t\u00eb lexuar mesazhe nga nj\u00eb klaster dhe p\u00ebr t\u2019i d\u00ebrguar ato n\u00eb nj\u00eb tjet\u00ebr.<\/p>\n<p>MirrorMaker duhet t\u00eb kuptoj\u00eb \u00e7el\u00ebsat e topic-ut q\u00eb replikohet, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb ruaj\u00eb rendin relativ midis mesazheve gjat\u00eb replikimit nd\u00ebrmjet klaster\u00ebve, pasi numri i particioneve p\u00ebr k\u00ebt\u00eb topic mund t\u00eb mos p\u00ebrputhet n\u00eb t\u00eb dy klaster\u00ebt.<\/p>\n<p>Strategjit\u00eb e personalizuara t\u00eb particionimit hasen relativisht rrall\u00eb, sepse hash-i i parazgjedhur ose round-robin funksionojn\u00eb mir\u00eb n\u00eb shumic\u00ebn e skenar\u00ebve. Megjithat\u00eb, n\u00ebse ju duhen garanci strikte p\u00ebr renditjen ose duhet t\u00eb nxirrni metadata nga payload-et, at\u00ebher\u00eb particionimi \u00ebsht\u00eb di\u00e7ka q\u00eb duhet ta shqyrtoni m\u00eb nga af\u00ebr.<\/p>\n<p>P\u00ebrpar\u00ebsit\u00eb e shkall\u00ebzueshm\u00ebris\u00eb dhe performanc\u00ebs s\u00eb Kafka vijn\u00eb nga kalimi i disa p\u00ebrgjegj\u00ebsive t\u00eb broker-it tradicional te klienti. N\u00eb k\u00ebt\u00eb rast, merret vendimi se si t\u00eb shp\u00ebrndahen mesazhet potencialisht t\u00eb lidhura te disa consumer-a q\u00eb punojn\u00eb paralelisht.<\/p>\n<blockquote><p>Edhe broker-\u00ebt JMS duhet t\u00eb p\u00ebrballojn\u00eb k\u00ebrkesa t\u00eb tilla. Interesante \u00ebsht\u00eb se mekanizmi i d\u00ebrgimit t\u00eb mesazheve t\u00eb lidhura te i nj\u00ebjti consumer, i realizuar p\u00ebrmes JMS Message Groups (nj\u00eb variant i strategjis\u00eb sticky load balancing (SLB)), gjithashtu k\u00ebrkon q\u00eb d\u00ebrguesi t\u2019i sh\u00ebnoj\u00eb mesazhet si t\u00eb lidhura. N\u00eb rastin e JMS, broker-i \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr d\u00ebrgimin e k\u00ebtij grupi mesazhesh t\u00eb lidhura te nj\u00eb consumer nga shum\u00eb t\u00eb till\u00eb dhe p\u00ebr transferimin e pron\u00ebsis\u00eb s\u00eb grupit n\u00ebse consumer-i bie.<\/p><\/blockquote>\n<p><\/p>\n<h2>Marr\u00ebveshje nga ana e producer-it<\/h2>\n<p>\nParticionimi nuk \u00ebsht\u00eb e vetmja gj\u00eb q\u00eb duhet marr\u00eb parasysh gjat\u00eb d\u00ebrgimit t\u00eb mesazheve. Le t\u00eb shqyrtojm\u00eb metodat send() t\u00eb klas\u00ebs Producer n\u00eb Java API:<\/p>\n<pre><code class=\"java\">Future  send(ProducerRecord  record);\nFuture  send(ProducerRecord  record, Callback callback);<\/code><\/pre>\n<p>\nDuhet theksuar menj\u00ebher\u00eb se t\u00eb dyja metodat kthejn\u00eb Future, \u00e7ka tregon se operacioni i d\u00ebrgimit nuk kryhet menj\u00ebher\u00eb. N\u00eb praktik\u00eb, mesazhi (ProducerRecord) shkruhet n\u00eb buffer-in e d\u00ebrgimit p\u00ebr \u00e7do particion aktiv dhe i transmetohet broker-it nga nj\u00eb thread n\u00eb sfond n\u00eb bibliotek\u00ebn e klientit Kafka. Edhe pse kjo e b\u00ebn pun\u00ebn jasht\u00ebzakonisht t\u00eb shpejt\u00eb, do t\u00eb thot\u00eb gjithashtu se nj\u00eb aplikacion i shkruar pa p\u00ebrvoj\u00eb mund t\u2019i humbas\u00eb mesazhet n\u00ebse procesi i tij ndalet.<\/p>\n<p>Si gjithmon\u00eb, ekziston nj\u00eb m\u00ebnyr\u00eb p\u00ebr ta b\u00ebr\u00eb operacionin e d\u00ebrgimit m\u00eb t\u00eb besuesh\u00ebm n\u00eb kurriz t\u00eb performanc\u00ebs. Madh\u00ebsia e k\u00ebtij buffer-i mund t\u00eb vendoset n\u00eb 0, dhe thread-i i aplikacionit q\u00eb d\u00ebrgon do t\u00eb detyrohet t\u00eb pres\u00eb derisa transmetimi i mesazhit te broker-i t\u00eb p\u00ebrfundoj\u00eb, si m\u00eb posht\u00eb:<\/p>\n<pre><code class=\"java\">RecordMetadata metadata = producer.send(record).get();<\/code><\/pre>\n<p><\/p>\n<h2>Edhe nj\u00eb her\u00eb p\u00ebr leximin e mesazheve<\/h2>\n<p>\nLeximi i mesazheve sjell v\u00ebshtir\u00ebsi shtes\u00eb, p\u00ebr t\u00eb cilat duhet t\u00eb ndalemi pak. Ndryshe nga API i JMS, i cili mund t\u00eb nis\u00eb nj\u00eb message listener si p\u00ebrgjigje ndaj mb\u00ebrritjes s\u00eb nj\u00eb mesazhi, nd\u00ebrfaqja <i>Consumer <\/i>n\u00eb Kafka p\u00ebrdor vet\u00ebm polling. Le ta shqyrtojm\u00eb m\u00eb nga af\u00ebr metod\u00ebn <i>poll ()<\/i>, e cila p\u00ebrdoret p\u00ebr k\u00ebt\u00eb q\u00ebllim:<\/p>\n<pre><code class=\"java\">ConsumerRecords  poll(long timeout);<\/code><\/pre>\n<p>\nVlera e kthyer nga metoda \u00ebsht\u00eb nj\u00eb struktur\u00eb-kontejner q\u00eb p\u00ebrmban disa objekte <i>ConsumerRecord <\/i>nga potencialisht disa particione. <i>ConsumerRecord <\/i>n\u00eb vetvete \u00ebsht\u00eb nj\u00eb objekt mbajt\u00ebs p\u00ebr nj\u00eb \u00e7ift ky\u00e7-vler\u00eb me metadata p\u00ebrkat\u00ebse, si p.sh. particioni nga i cili \u00ebsht\u00eb marr\u00eb.<\/p>\n<p>Si\u00e7 u diskutua n\u00eb Kapitullin 2, duhet t\u00eb mbajm\u00eb vazhdimisht parasysh se \u00e7far\u00eb ndodh me mesazhet pas p\u00ebrpunimit t\u00eb tyre me sukses ose pa sukses, p\u00ebr shembull n\u00ebse klienti nuk mund ta p\u00ebrpunoj\u00eb mesazhin ose n\u00ebse nd\u00ebrpret pun\u00ebn. N\u00eb JMS kjo trajtohej p\u00ebrmes acknowledgement mode. Broker-i ose do ta fshij\u00eb mesazhin e p\u00ebrpunuar me sukses, ose do ta rid\u00ebrgoj\u00eb mesazhin e pap\u00ebrpunuar ose t\u00eb d\u00ebshtuar (me kusht q\u00eb t\u00eb jen\u00eb p\u00ebrdorur transaksione). <br \/>\nKafka funksionon krejt ndryshe. Mesazhet nuk fshihen n\u00eb broker pas leximit, dhe p\u00ebrgjegj\u00ebsia p\u00ebr at\u00eb q\u00eb ndodh n\u00eb rast d\u00ebshtimi i takon vet\u00eb kodit q\u00eb i lexon.<\/p>\n<p>Si\u00e7 e kemi th\u00ebn\u00eb tashm\u00eb, grupi i consumer-\u00ebve \u00ebsht\u00eb i lidhur me offset-in n\u00eb log. Pozicioni n\u00eb log i lidhur me k\u00ebt\u00eb offset korrespondon me mesazhin e radh\u00ebs q\u00eb do t\u00eb kthehet si p\u00ebrgjigje ndaj <i>poll ()<\/i>Koha kur kjo zhvendosje rritet \u00ebsht\u00eb vendimtare gjat\u00eb leximit.<\/p>\n<p>Duke iu rikthyer modelit t\u00eb leximit t\u00eb shqyrtuar m\u00eb par\u00eb, p\u00ebrpunimi i mesazhit p\u00ebrb\u00ebhet nga tre faza:<\/p>\n<ol>\n<li>Nxirrni mesazhin p\u00ebr lexim.<\/li>\n<li>P\u00ebrpunoni mesazhin.<\/li>\n<li>Konfirmoni mesazhin.<\/li>\n<\/ol>\n<p>\nKonsumatori Kafka ofrohet me opsionin e konfigurimit <i>enable.auto.commit<\/i>. Ky \u00ebsht\u00eb nj\u00eb konfigurim i parazgjedhur q\u00eb p\u00ebrdoret shpesh, si\u00e7 ndodh zakonisht me cil\u00ebsimet q\u00eb p\u00ebrmbajn\u00eb fjal\u00ebn \u00abauto\u00bb.<\/p>\n<p>Deri n\u00eb Kafka 0.10, klienti q\u00eb p\u00ebrdorte k\u00ebt\u00eb paramet\u00ebr d\u00ebrgonte offset-in e mesazhit t\u00eb fundit t\u00eb lexuar n\u00eb thirrjen e radh\u00ebs t\u00eb <i>poll ()<\/i> pas p\u00ebrpunimit. Kjo do t\u00eb thoshte se \u00e7do mesazh q\u00eb ishte nxjerr\u00eb tashm\u00eb (fetched) mund t\u00eb rip\u00ebrpunohej n\u00ebse klienti e kishte p\u00ebrpunuar tashm\u00eb, por ishte nd\u00ebrprer\u00eb papritur p\u00ebrpara thirrjes s\u00eb <i>poll ()<\/i>. N\u00ebse brokeri nuk ruan asnj\u00eb gjendje n\u00eb lidhje me numrin e her\u00ebve q\u00eb nj\u00eb mesazh \u00ebsht\u00eb lexuar, konsumatori i ardhsh\u00ebm q\u00eb nxjerr k\u00ebt\u00eb mesazh nuk do t\u00eb dij\u00eb se ndodhi ndonj\u00eb gj\u00eb e keqe. Ky sjellje ishte pseudo-transaksionale. Offset-i u angazhua vet\u00ebm n\u00eb rastin e p\u00ebrpunimit t\u00eb suksessh\u00ebm t\u00eb mesazhit, por n\u00ebse klienti nd\u00ebrpriste pun\u00ebn, brokeri i d\u00ebrgonte p\u00ebrs\u00ebri t\u00eb nj\u00ebjtin mesazh nj\u00eb klienti tjet\u00ebr. Ky sjellje p\u00ebrputhej me garancin\u00eb e d\u00ebrgimit t\u00eb mesazheve<i>t\u00eb pakt\u00ebn nj\u00eb her\u00eb<\/i>&#171;.<\/p>\n<p>N\u00eb Kafka 0.10, kodi i klientit u ndryshua n\u00eb m\u00ebnyr\u00eb t\u00eb till\u00eb q\u00eb commit t\u00eb nisej periodikisht nga biblioteka e klientit, n\u00eb p\u00ebrputhje me cil\u00ebsimin <i>auto.commit.interval.ms<\/i>. Kjo sjellje ndodhet diku mes m\u00ebnyrave JMS AUTO_ACKNOWLEDGE dhe DUPS_OK_ACKNOWLEDGE. Kur p\u00ebrdoret auto-commit, mesazhet mund t\u00eb konfirmohen pavar\u00ebsisht n\u00ebse jan\u00eb p\u00ebrpunuar realisht apo jo \u2014 kjo mund t\u00eb ndodh\u00eb n\u00eb rastin e nj\u00eb konsumatori t\u00eb ngadalt\u00eb. N\u00ebse konsumatori nd\u00ebrpritej, mesazhet nxirreshin nga konsumatori pasues duke filluar nga pozicioni i komituar, gj\u00eb q\u00eb mund t\u00eb \u00e7onte n\u00eb kap\u00ebrcimin e nj\u00eb mesazhi. N\u00eb k\u00ebt\u00eb rast, Kafka nuk i humbte mesazhet; kodi q\u00eb lexonte thjesht nuk i p\u00ebrpunonte ato.<\/p>\n<p>Ky regjim ka t\u00eb nj\u00ebjtat pasoja si n\u00eb versionin 0.9: mesazhet mund t\u00eb p\u00ebrpunohen, por n\u00eb rast d\u00ebshtimi, offset-i mund t\u00eb mos komitohet, gj\u00eb q\u00eb mund t\u00eb \u00e7oj\u00eb potencialisht n\u00eb dublim t\u00eb dor\u00ebzimit. Sa m\u00eb shum\u00eb mesazhe t\u00eb nxirrni gjat\u00eb ekzekutimit t\u00eb <i>poll ()<\/i>, aq m\u00eb i madh b\u00ebhet ky problem.<\/p>\n<p>Si\u00e7 u diskutua n\u00eb seksionin \u00abLeximi i mesazheve nga radha\u00bb n\u00eb faqen 21, n\u00eb nj\u00eb sistem mesazhesh nuk ekziston koncepti i dor\u00ebzimit t\u00eb mesazhit vet\u00ebm nj\u00eb her\u00eb, n\u00ebse merren parasysh skenar\u00ebt e d\u00ebshtimit.<\/p>\n<p>N\u00eb Kafka ka dy m\u00ebnyra p\u00ebr t\u00eb konfirmuar (commit) offset-in: automatikisht dhe manualisht. N\u00eb t\u00eb dyja rastet, mesazhet mund t\u00eb p\u00ebrpunohen disa her\u00eb n\u00ebse mesazhi \u00ebsht\u00eb p\u00ebrpunuar, por ka ndodhur nj\u00eb d\u00ebshtim p\u00ebrpara commit-it. Gjithashtu, mund t\u00eb ndodh\u00eb q\u00eb mesazhi t\u00eb mos p\u00ebrpunohet fare, n\u00ebse commit-i \u00ebsht\u00eb kryer n\u00eb sfond dhe kodi juaj \u00ebsht\u00eb nd\u00ebrprer\u00eb para se t\u00eb fillonte p\u00ebrpunimin (e mundur n\u00eb Kafka 0.9 dhe versionet m\u00eb t\u00eb hershme).<\/p>\n<p>Procesi i commit-it t\u00eb offset-it mund t\u00eb menaxhohet manualisht n\u00eb API-n\u00eb e consumer-it Kafka duke vendosur parametrin <i>enable.auto.commit<\/i> n\u00eb vler\u00ebn false dhe duke thirrur n\u00eb m\u00ebnyr\u00eb t\u00eb qart\u00eb nj\u00eb nga metodat e m\u00ebposhtme:<\/p>\n<pre><code class=\"java\">void commitSync();\nvoid commitAsync();<\/code><\/pre>\n<p>\nN\u00ebse synoni ta p\u00ebrpunoni mesazhin \u00abt\u00eb pakt\u00ebn nj\u00eb her\u00eb\u00bb, duhet ta b\u00ebni commit-in e offset-it manualisht me <i>commitSync ()<\/i>, duke e ekzekutuar k\u00ebt\u00eb komand\u00eb menj\u00ebher\u00eb pas p\u00ebrpunimit t\u00eb mesazheve.<\/p>\n<p>K\u00ebto metoda nuk lejojn\u00eb konfirmimin (acknowledged) t\u00eb mesazheve p\u00ebrpara se t\u00eb p\u00ebrpunohen, por nuk b\u00ebjn\u00eb asgj\u00eb p\u00ebr t\u00eb eliminuar mund\u00ebsin\u00eb e p\u00ebrpunimit t\u00eb dyfisht\u00eb, nd\u00ebrkoh\u00eb q\u00eb krijojn\u00eb p\u00ebrshtypjen e transaksionalitetit. Kafka nuk ka transaksione. Klienti nuk ka mund\u00ebsi t\u00eb b\u00ebj\u00eb sa vijon:<\/p>\n<ul>\n<li>T\u00eb kthej\u00eb automatikisht pas (roll back) nj\u00eb mesazh q\u00eb ka d\u00ebshtuar. Consumer-\u00ebt duhet t\u2019i trajtojn\u00eb vet\u00eb p\u00ebrjashtimet q\u00eb lindin nga payload-et problematike dhe nd\u00ebrprerjet e backend-it, pasi nuk mund t\u00eb mb\u00ebshteten te ridor\u00ebzimi i mesazheve nga broker-i.<\/li>\n<li>T\u00eb d\u00ebrgoj\u00eb mesazhe n\u00eb disa topic-e brenda nj\u00eb operacioni t\u00eb vet\u00ebm atomik. Si\u00e7 do ta shohim s\u00eb shpejti, kontrolli mbi topic-et dhe partition-et e ndryshme mund t\u00eb jet\u00eb n\u00eb makina t\u00eb ndryshme n\u00eb cluster-in Kafka, t\u00eb cilat nuk koordinojn\u00eb transaksionet gjat\u00eb d\u00ebrgimit. N\u00eb koh\u00ebn e shkrimit t\u00eb k\u00ebtij artikulli, ishte b\u00ebr\u00eb nj\u00eb pun\u00eb e caktuar p\u00ebr ta b\u00ebr\u00eb k\u00ebt\u00eb t\u00eb mundur me ndihm\u00ebn e KIP-98.<\/li>\n<li>T\u00eb lidh\u00eb leximin e nj\u00eb mesazhi nga nj\u00eb topic me d\u00ebrgimin e nj\u00eb mesazhi tjet\u00ebr n\u00eb nj\u00eb topic tjet\u00ebr. Edhe k\u00ebtu, arkitektura e Kafka-s mb\u00ebshtetet n\u00eb shum\u00eb makina t\u00eb pavarura q\u00eb punojn\u00eb si nj\u00eb bus i vet\u00ebm dhe nuk b\u00ebhet asnj\u00eb p\u00ebrpjekje p\u00ebr ta fshehur k\u00ebt\u00eb. P\u00ebr shembull, nuk ekzistojn\u00eb komponent\u00eb API q\u00eb do t\u00eb b\u00ebnin t\u00eb mundur lidhjen e <i>Consumer <\/i>dhe <i>Producer <\/i>n\u00eb transaksion. N\u00eb JMS kjo sigurohet nga objekti <i>Session<\/i>, prej t\u00eb cilit krijohen <i>MessageProducers <\/i>dhe <i>MessageConsumers<\/i>.<\/li>\n<\/ul>\n<p>\nN\u00ebse nuk mund t\u00eb mb\u00ebshtetemi te transaksionet, si mund t\u00eb sigurojm\u00eb semantik\u00eb m\u00eb t\u00eb af\u00ebrt me at\u00eb q\u00eb ofrojn\u00eb sistemet tradicionale t\u00eb mesazheve?<\/p>\n<p>N\u00ebse ekziston mund\u00ebsia q\u00eb offset-i i consumer-it t\u00eb rritet p\u00ebrpara se mesazhi t\u00eb jet\u00eb p\u00ebrpunuar, p\u00ebr shembull gjat\u00eb nj\u00eb d\u00ebshtimi t\u00eb consumer-it, at\u00ebher\u00eb consumer-i nuk ka asnj\u00eb m\u00ebnyr\u00eb t\u00eb dij\u00eb n\u00ebse grupi i tij i consumer-\u00ebve ka humbur mesazhe kur i caktohet nj\u00eb partition. Prandaj, nj\u00eb nga strategjit\u00eb \u00ebsht\u00eb kthimi prapa (rewind) i offset-it n\u00eb nj\u00eb pozicion t\u00eb m\u00ebparsh\u00ebm. API-ja e consumer-it t\u00eb Kafka-s ofron metodat e m\u00ebposhtme p\u00ebr k\u00ebt\u00eb:<\/p>\n<pre><code class=\"java\">void seek(TopicPartition partition, long offset);\nvoid seekToBeginning(Collection  partitions);<\/code><\/pre>\n<p>\nSanitizer.replaceElementWithChildren() <i>seek ()<\/i> mund t\u00eb p\u00ebrdoret me metod\u00ebn <br \/>\n<i>offsetsForTimes (Map timestampsToSearch)<\/i> p\u00ebr t'u kthyer n\u00eb gjendjen e nj\u00eb momenti t\u00eb caktuar n\u00eb t\u00eb kaluar\u00ebn.<\/p>\n<p>N\u00eb m\u00ebnyr\u00eb t\u00eb n\u00ebnkuptuar, p\u00ebrdorimi i k\u00ebsaj qasjeje do t\u00eb thot\u00eb se ka shum\u00eb gjasa q\u00eb disa mesazhe q\u00eb jan\u00eb p\u00ebrpunuar m\u00eb par\u00eb t\u00eb lexohen dhe t\u00eb p\u00ebrpunohen s\u00ebrish. P\u00ebr ta shmangur k\u00ebt\u00eb, mund t\u00eb p\u00ebrdorim lexim idempotent, si\u00e7 p\u00ebrshkruhet n\u00eb Kapitullin 4, p\u00ebr t\u00eb gjurmuar mesazhet e shqyrtuara m\u00eb par\u00eb dhe p\u00ebr t\u00eb p\u00ebrjashtuar dublikatat.<\/p>\n<p>Si alternativ\u00eb, kodi i consumer-it tuaj mund t\u00eb jet\u00eb i thjesht\u00eb n\u00ebse humbja ose dublikimi i mesazheve \u00ebsht\u00eb i pranuesh\u00ebm. Kur shqyrtojm\u00eb rastet e p\u00ebrdorimit p\u00ebr t\u00eb cilat Kafka p\u00ebrdoret zakonisht, si p\u00ebrpunimi i ngjarjeve t\u00eb log-eve, metrikave, gjurmimi i klikimeve etj., kuptojm\u00eb se humbja e mesazheve t\u00eb ve\u00e7anta ka pak gjasa t\u00eb ket\u00eb ndikim dometh\u00ebn\u00ebs te aplikacionet p\u00ebrreth. N\u00eb raste t\u00eb tilla, vlerat e parazgjedhura jan\u00eb plot\u00ebsisht t\u00eb pranueshme. Nga ana tjet\u00ebr, n\u00ebse aplikacioni juaj duhet t\u00eb transmetoj\u00eb pagesa, duhet t\u00eb kujdeseni me v\u00ebmendje p\u00ebr \u00e7do mesazh t\u00eb vet\u00ebm. Gjith\u00e7ka varet nga konteksti.<\/p>\n<p>V\u00ebzhgimet personale tregojn\u00eb se, me rritjen e intensitetit t\u00eb mesazheve, vlera e secilit mesazh individual bie. Mesazhet n\u00eb v\u00ebllim t\u00eb madh, si rregull, b\u00ebhen t\u00eb vlefshme kur shqyrtohen n\u00eb form\u00eb t\u00eb agreguar.<\/p>\n<h2>Disponueshm\u00ebri e lart\u00eb (High Availability)<\/h2>\n<p>\nQasja e Kafka-s ndaj disponueshm\u00ebris\u00eb s\u00eb lart\u00eb ndryshon ndjesh\u00ebm nga ajo e ActiveMQ. Kafka \u00ebsht\u00eb projektuar mbi klaster\u00eb horizontalisht t\u00eb shkall\u00ebzuesh\u00ebm, ku t\u00eb gjitha instancat e brokerit pranojn\u00eb dhe shp\u00ebrndajn\u00eb mesazhe nj\u00ebkoh\u00ebsisht.<\/p>\n<p>Klasteri Kafka p\u00ebrb\u00ebhet nga disa instanca brokeri q\u00eb funksionojn\u00eb n\u00eb server\u00eb t\u00eb ndrysh\u00ebm. Kafka \u00ebsht\u00eb projektuar p\u00ebr t\u00eb punuar n\u00eb pajisje standarde t\u00eb pavarura, ku \u00e7do nyje ka hap\u00ebsir\u00ebn e vet t\u00eb dedikuar t\u00eb ruajtjes. P\u00ebrdorimi i ruajtjes n\u00eb rrjet (SAN) nuk rekomandohet, pasi disa nyje llogarit\u00ebse mund t\u00eb konkurrojn\u00eb p\u00ebr intervalet kohore t\u00eb ruajtjes<i>D<\/i>he t\u00eb krijojn\u00eb konflikte.<\/p>\n<p>Kafka \u00ebsht\u00eb nj\u00eb <i>gjithmon\u00eb aktive<\/i> sistem. Shum\u00eb p\u00ebrdorues t\u00eb m\u00ebdhenj t\u00eb Kafka-s nuk i fikin kurr\u00eb klaster\u00ebt e tyre dhe softueri p\u00ebrdit\u00ebsohet gjithmon\u00eb p\u00ebrmes rinisjes sekuenciale. Kjo arrihet duke garantuar p\u00ebrputhshm\u00ebri me versionet e m\u00ebparshme p\u00ebr mesazhet dhe nd\u00ebrveprimet midis broker\u00ebve.<\/p>\n<p>Broker\u00ebt lidhen me klasterin e server\u00ebve <noindex><a rel=\"nofollow\" href=\"http:\/\/zookeeper.apache.org\">ZooKeeper<\/a><\/noindex>, i cili vepron si regjist\u00ebr i t\u00eb dh\u00ebnave t\u00eb konfigurimit dhe p\u00ebrdoret p\u00ebr t\u00eb koordinuar rolet e \u00e7do brokeri. Vet\u00eb ZooKeeper \u00ebsht\u00eb nj\u00eb sistem i shp\u00ebrndar\u00eb q\u00eb siguron disponueshm\u00ebri t\u00eb lart\u00eb p\u00ebrmes replikimit t\u00eb informacionit duke vendosur nj\u00eb <i>kuorum<\/i>.<\/p>\n<p>N\u00eb rastin baz\u00eb, nj\u00eb topic krijohet n\u00eb klasterin Kafka me vetit\u00eb e m\u00ebposhtme:<\/p>\n<ul>\n<li>Numri i particioneve. Si\u00e7 u diskutua m\u00eb her\u00ebt, vlera e sakt\u00eb e p\u00ebrdorur k\u00ebtu varet nga niveli i d\u00ebshiruar i leximit paralel.<\/li>\n<li>Koeficienti (faktori) i replikimit p\u00ebrcakton sa instanca brokeri n\u00eb klaster duhet t\u00eb p\u00ebrmbajn\u00eb regjistrat p\u00ebr k\u00ebt\u00eb particion.<\/li>\n<\/ul>\n<p>\nDuke p\u00ebrdorur ZooKeeper p\u00ebr koordinim, Kafka p\u00ebrpiqet t\u2019i shp\u00ebrndaj\u00eb n\u00eb m\u00ebnyr\u00eb t\u00eb drejt\u00eb particionet e reja midis broker\u00ebve n\u00eb klaster. Kjo b\u00ebhet nga nj\u00eb instanc\u00eb q\u00eb kryen rolin e Kontrolluesit.<\/p>\n<p>Gjat\u00eb ekzekutimit, <i>p\u00ebr \u00e7do particion t\u00eb topic-ut<\/i> <i>Kontrolluesi <\/i>i cakton brokerit rolet e <i>liderit <\/i>(leader, master, drejtues) dhe <i>ndjek\u00ebsve <\/i>(followers, slaves, vart\u00ebs). Brokeri q\u00eb vepron si lider p\u00ebr k\u00ebt\u00eb particion \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr marrjen e t\u00eb gjitha mesazheve q\u00eb i d\u00ebrgohen nga prodhuesit dhe p\u00ebr shp\u00ebrndarjen e mesazheve te konsumator\u00ebt. Kur mesazhet d\u00ebrgohen n\u00eb particionin e topic-ut, ato replikohen n\u00eb t\u00eb gjitha nyjet e brokerit q\u00eb veprojn\u00eb si vart\u00ebse p\u00ebr k\u00ebt\u00eb particion. \u00c7do nyje q\u00eb p\u00ebrmban log-et p\u00ebr particionin quhet <i>replik\u00eb<\/i>. Nj\u00eb broker mund t\u00eb veproj\u00eb si lider p\u00ebr disa particione dhe si vart\u00ebs p\u00ebr t\u00eb tjerat.<\/p>\n<p>Nj\u00eb vart\u00ebs q\u00eb p\u00ebrmban t\u00eb gjitha mesazhet e ruajtura te lideri quhet <i>replik\u00eb e sinkronizuar<\/i> (replik\u00eb n\u00eb gjendje sinkronizimi, in-sync replica). N\u00ebse brokeri q\u00eb vepron si lider p\u00ebr particionin shk\u00ebputet, \u00e7do broker q\u00eb \u00ebsht\u00eb n\u00eb gjendje t\u00eb p\u00ebrdit\u00ebsuar ose t\u00eb sinkronizuar p\u00ebr k\u00ebt\u00eb particion mund t\u00eb marr\u00eb rolin e liderit. Ky \u00ebsht\u00eb nj\u00eb dizajn jasht\u00ebzakonisht i q\u00ebndruesh\u00ebm.<\/p>\n<p>Pjes\u00eb e konfigurimit t\u00eb prodhuesit \u00ebsht\u00eb parametri <i>acks<\/i>, i cili p\u00ebrcakton sa replika duhet t\u00eb konfirmojn\u00eb (acknowledge) marrjen e mesazhit p\u00ebrpara se rrjedha e aplikacionit t\u00eb vazhdoj\u00eb d\u00ebrgimin: 0, 1 ose t\u00eb gjitha. N\u00ebse \u00ebsht\u00eb caktuar vlera <i>t\u00eb gjitha<\/i>, at\u00ebher\u00eb pas marrjes s\u00eb mesazhit, lideri do t\u2019i d\u00ebrgoj\u00eb konfirmimin (confirmation) prodhuesit sapo t\u00eb marr\u00eb konfirmimin (acknowledgements) e shkrimit nga disa replika (duke p\u00ebrfshir\u00eb veten), t\u00eb p\u00ebrcaktuara nga cil\u00ebsimi i topic-ut <i>min.insync.replicas<\/i> (si parazgjedhje 1). N\u00ebse mesazhi nuk mund t\u00eb replikohet me sukses, at\u00ebher\u00eb prodhuesi do t\u00eb shkaktoj\u00eb nj\u00eb p\u00ebrjashtim p\u00ebr aplikacionin (<i>NotEnoughReplicas<\/i> ose <i>NotEnoughReplicasAfterAppend<\/i>).<\/p>\n<p>N\u00eb nj\u00eb konfigurim tipik krijohet nj\u00eb topic me faktor replikimi 3 (1 lider, 2 vart\u00ebs p\u00ebr \u00e7do particion) dhe parametri <i>min.insync.replicas<\/i> caktohet n\u00eb vler\u00ebn 2. N\u00eb k\u00ebt\u00eb rast, klasteri do t\u00eb lejoj\u00eb q\u00eb nj\u00eb nga broker\u00ebt q\u00eb menaxhojn\u00eb particionin e topic-ut t\u00eb mund t\u00eb shk\u00ebputet pa ndikuar te aplikacionet kliente.<\/p>\n<p>Kjo na kthen te kompromisi tashm\u00eb i njohur mes performanc\u00ebs dhe besueshm\u00ebris\u00eb. Replikimi kryhet me koston e koh\u00ebs shtes\u00eb t\u00eb pritjes p\u00ebr konfirmimet (acknowledgments) nga ndjek\u00ebsit. Megjithat\u00eb, meqen\u00ebse b\u00ebhet paralelisht, replikimi, t\u00eb pakt\u00ebn n\u00eb tre nyje, ka t\u00eb nj\u00ebjt\u00ebn performanc\u00eb si edhe n\u00eb dy (duke injoruar rritjen e p\u00ebrdorimit t\u00eb bandwidth-it t\u00eb rrjetit).<\/p>\n<p>Duke p\u00ebrdorur k\u00ebt\u00eb skem\u00eb replikimi, Kafka shmang me zgjuarsi nevoj\u00ebn p\u00ebr t\u00eb garantuar shkrimin fizik t\u00eb \u00e7do mesazhi n\u00eb disk p\u00ebrmes operacionit <i>sync ()<\/i>. \u00c7do mesazh i d\u00ebrguar nga prodhuesi do t\u00eb shkruhet n\u00eb log-un e particionit, por, si\u00e7 u diskutua n\u00eb Kapitullin 2, shkrimi n\u00eb skedar fillimisht kryhet n\u00eb buffer-in e sistemit operativ. N\u00ebse ky mesazh replikohet n\u00eb nj\u00eb instanc\u00eb tjet\u00ebr Kafka dhe ndodhet n\u00eb memorien e saj, humbja e liderit nuk do t\u00eb thot\u00eb se vet\u00eb mesazhi \u00ebsht\u00eb humbur \u2014 at\u00eb mund ta marr\u00eb p\u00ebrsip\u00ebr replika e sinkronizuar.<br \/>\nHeqja dor\u00eb nga nevoja p\u00ebr t\u00eb kryer operacionin <i>sync ()<\/i> do t\u00eb thot\u00eb se Kafka mund t\u00eb pranoj\u00eb mesazhe me shpejt\u00ebsin\u00eb me t\u00eb cil\u00ebn mund t\u2019i shkruaj\u00eb ato n\u00eb memorie. Anasjelltas, sa m\u00eb gjat\u00eb t\u00eb mund t\u00eb shmanget flushing i memories n\u00eb disk, aq m\u00eb mir\u00eb. P\u00ebr k\u00ebt\u00eb arsye, nuk jan\u00eb t\u00eb rralla rastet kur broker\u00ebve Kafka u caktohen 64 GB memorie ose m\u00eb shum\u00eb. Ky p\u00ebrdorim i memories do t\u00eb thot\u00eb se nj\u00eb instanc\u00eb Kafka mund t\u00eb funksionoj\u00eb leht\u00ebsisht me shpejt\u00ebsi shum\u00eb mij\u00ebra her\u00eb m\u00eb t\u00eb lart\u00eb se nj\u00eb broker tradicional mesazhesh.<\/p>\n<p>Kafka mund t\u00eb konfigurohet gjithashtu p\u00ebr t\u00eb zbatuar operacionin <i>sync ()<\/i> mbi paketat e mesazheve. Meqen\u00ebse gjith\u00e7ka n\u00eb Kafka \u00ebsht\u00eb e orientuar drejt pun\u00ebs me paketa, kjo n\u00eb fakt funksionon mjaft mir\u00eb p\u00ebr shum\u00eb skenar\u00eb p\u00ebrdorimi dhe \u00ebsht\u00eb nj\u00eb mjet i dobish\u00ebm p\u00ebr p\u00ebrdoruesit q\u00eb k\u00ebrkojn\u00eb garanci shum\u00eb t\u00eb forta. Pjesa m\u00eb e madhe e performanc\u00ebs s\u00eb lart\u00eb t\u00eb Kafka-s lidhet me mesazhet q\u00eb i d\u00ebrgohen brokerit n\u00eb form\u00eb paketash dhe me faktin q\u00eb k\u00ebto mesazhe lexohen nga brokeri n\u00eb blloqe sekuenciale duke p\u00ebrdorur <noindex><a rel=\"nofollow\" href=\"http:\/\/www.linuxjournal.com\/article\/6345\">zero-copy<\/a><\/noindex> operacioneve (me operacione gjat\u00eb t\u00eb cilave nuk kryhet detyra e kopjimit t\u00eb t\u00eb dh\u00ebnave nga nj\u00eb zon\u00eb e memories n\u00eb tjetr\u00ebn). Kjo e fundit \u00ebsht\u00eb nj\u00eb p\u00ebrfitim i madh p\u00ebr sa i p\u00ebrket performanc\u00ebs dhe burimeve dhe b\u00ebhet e mundur vet\u00ebm fal\u00eb p\u00ebrdorimit t\u00eb struktur\u00ebs s\u00eb t\u00eb dh\u00ebnave s\u00eb jurnalit n\u00eb baz\u00eb, e cila p\u00ebrcakton skem\u00ebn e particionimit.<\/p>\n<p>N\u00eb nj\u00eb klaster Kafka, mund t\u00eb arrihet performanc\u00eb shum\u00eb m\u00eb e lart\u00eb sesa me p\u00ebrdorimin e nj\u00eb brokeri t\u00eb vet\u00ebm Kafka, sepse particionet e topic-ut mund t\u00eb shkall\u00ebzohen horizontalisht n\u00eb shum\u00eb makina t\u00eb ve\u00e7anta.<\/p>\n<h2>P\u00ebrfundime<\/h2>\n<p>\nN\u00eb k\u00ebt\u00eb kapitull pam\u00eb se si arkitektura e Kafka-s rishikon marr\u00ebdh\u00ebnien midis klient\u00ebve dhe broker\u00ebve p\u00ebr t\u00eb siguruar nj\u00eb pipeline jasht\u00ebzakonisht t\u00eb q\u00ebndruesh\u00ebm t\u00eb shk\u00ebmbimit t\u00eb mesazheve, me throughput shum\u00eb her\u00eb m\u00eb t\u00eb lart\u00eb se ai i nj\u00eb brokeri t\u00eb zakonsh\u00ebm t\u00eb mesazheve. Diskutuam funksionalitetin q\u00eb p\u00ebrdor p\u00ebr ta arritur k\u00ebt\u00eb q\u00ebllim dhe shqyrtuam shkurt arkitektur\u00ebn e aplikacioneve q\u00eb e mund\u00ebsojn\u00eb k\u00ebt\u00eb funksionalitet. N\u00eb kapitullin tjet\u00ebr do t\u00eb shohim problemet e p\u00ebrgjithshme q\u00eb duhet t\u00eb zgjidhin aplikacionet e bazuara n\u00eb shk\u00ebmbimin e mesazheve dhe do t\u00eb diskutojm\u00eb strategjit\u00eb p\u00ebr t\u2019i adresuar ato. Kapitullin do ta p\u00ebrmbyllim duke p\u00ebrshkruar se si t\u00eb arsyetohet p\u00ebr teknologjit\u00eb e mesazheve n\u00eb t\u00ebr\u00ebsi, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb vler\u00ebsoni p\u00ebrshtatshm\u00ebrin\u00eb e tyre p\u00ebr skenar\u00ebt tuaj t\u00eb p\u00ebrdorimit.<\/p>\n<p>Pjesa e m\u00ebparshme e p\u00ebrkthyer: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466385\/\">Kuptimi i broker\u00ebve t\u00eb mesazheve. Studimi i mekanik\u00ebs s\u00eb shk\u00ebmbimit t\u00eb mesazheve p\u00ebrmes ActiveMQ dhe Kafka. Kapitulli 1<\/a><\/noindex><\/p>\n<p><b> P\u00ebrkthimi u krye: <noindex><a rel=\"nofollow\" href=\"http:\/\/tele.gg\/middle_java\">tele.gg\/middle_java<\/a><\/noindex><\/b><\/p>\n<p><i>Vazhdon&#8230;<\/i><\/p>\n<p class=\"for_users_only_msg\">Vet\u00ebm p\u00ebrdoruesit e regjistruar mund t\u00eb marrin pjes\u00eb n\u00eb anket\u00eb. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Hyni<\/a><\/noindex>, ju lutem.<\/p>\n<h2 class=\"default-block__polling-title\">A p\u00ebrdoret Kafka n\u00eb organizat\u00ebn tuaj?<\/h2>\n<ul class=\"content-list content-list_polling\">\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Po.<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Jo<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    P\u00ebrdorej m\u00eb par\u00eb, tani jo<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Planifikojm\u00eb ta p\u00ebrdorim<\/p>\n<\/li>\n<\/ul>\n<p>    Kan\u00eb votuar 38 p\u00ebrdorues. Kan\u00eb abstenuar 8 p\u00ebrdorues.<br \/>\n<br \/>Burimi: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466585\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: \u00abUnderstanding Message Brokers\u00bb, \u0430\u0432\u0442\u043e\u0440: Jakub Korab, \u0438\u0437\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u043e: O&#8217;Reilly Media, Inc., \u0434\u0430\u0442\u0430 \u0438\u0437\u0434\u0430\u043d\u0438\u044f: June 2017, ISBN: 9781492049296. \u041f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0430\u044f \u043f\u0435\u0440\u0435\u0432\u0435\u0434\u0435\u043d\u043d\u0430\u044f \u0447\u0430\u0441\u0442\u044c: \u041f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0438 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e\u043c ActiveMQ \u0438 Kafka. \u0413\u043b\u0430\u0432\u0430 1. \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0413\u041b\u0410\u0412\u0410 3 Kafka Kafka \u0431\u044b\u043b\u0430 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u0430 \u0432 LinkedIn \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043e\u0431\u043e\u0439\u0442\u0438 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u044f \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439 \u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38172","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: \u00abUnderstanding Message Brokers\u00bb, \u0430\u0432\u0442\u043e\u0440: Jakub Korab, \u0438\u0437\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u043e: O&#039;Reilly Media, Inc., \u0434\u0430\u0442\u0430 \u0438\u0437\u0434\u0430\u043d\u0438\u044f: June 2017, ISBN: 9781492049296. \u041f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0430\u044f \u043f\u0435\u0440\u0435\u0432\u0435\u0434\u0435\u043d\u043d\u0430\u044f.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"sq_AL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0438 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e\u043c ActiveMQ \u0438 Kafka. \u0413\u043b\u0430\u0432\u0430 3. Kafka | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: \u00abUnderstanding Message Brokers\u00bb, \u0430\u0432\u0442\u043e\u0440: Jakub Korab, \u0438\u0437\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u043e: O&#039;Reilly Media, Inc., \u0434\u0430\u0442\u0430 \u0438\u0437\u0434\u0430\u043d\u0438\u044f: June 2017, ISBN: 9781492049296. \u041f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0430\u044f \u043f\u0435\u0440\u0435\u0432\u0435\u0434\u0435\u043d\u043d\u0430\u044f.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:22:05+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:22:05+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Kuptimi i broker\u00ebve t\u00eb mesazheve. Studimi i mekanik\u00ebs s\u00eb shk\u00ebmbimit t\u00eb mesazheve p\u00ebrmes ActiveMQ dhe Kafka. Kapitulli 3. Kafka | ProHoster","description":"Vazhdimi i p\u00ebrkthimit t\u00eb librit t\u00eb shkurt\u00ebr: \u00abUnderstanding Message Brokers\u00bb, autor: Jakub Korab, botuesi: O'Reilly Media, Inc., data e botimit: qershor 2017, ISBN: 9781492049296. Pjesa e m\u00ebparshme e p\u00ebrkthyer.","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0438 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e\u043c ActiveMQ \u0438 Kafka. \u0413\u043b\u0430\u0432\u0430 3. Kafka | ProHoster","og:description":"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: \u00abUnderstanding Message Brokers\u00bb, \u0430\u0432\u0442\u043e\u0440: Jakub Korab, \u0438\u0437\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u043e: O'Reilly Media, Inc., \u0434\u0430\u0442\u0430 \u0438\u0437\u0434\u0430\u043d\u0438\u044f: June 2017, ISBN: 9781492049296. \u041f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0430\u044f \u043f\u0435\u0440\u0435\u0432\u0435\u0434\u0435\u043d\u043d\u0430\u044f.","og:url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:22:05+00:00","article:modified_time":"2019-10-31T19:22:05+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38172","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 20:46:00","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:34:26","updated":"2026-01-23 20:46:00","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/38172","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=38172"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/38172\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=38172"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=38172"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=38172"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}