{"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 mekanizmave t\u00eb shk\u00ebmbimit t\u00eb mesazheve p\u00ebrmes ActiveMQ dhe Kafka. KREU 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\u00abKuptimi i Broker\u00ebve t\u00eb Mesazheve\u00bb,<br \/>\nautor: Jakub Korab, botuesi: O'Reilly Media, Inc., data e publikuar: 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 mekanizmave t\u00eb shk\u00ebmbimit t\u00eb mesazheve p\u00ebrmes ActiveMQ dhe Kafka. KREU 1. Hyrje<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>KREU 3<\/h2>\n<p><\/p>\n<h2>Kafka<\/h2>\n<p>\nKafka u zhvillua n\u00eb LinkedIn p\u00ebr t\u00eb anashkaluar 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 \"pik\u00eb-pik\u00eb\", si\u00e7 p\u00ebrshkruhet n\u00eb k\u00ebt\u00eb lib\u00ebr n\u00eb seksionin \"Shkall\u00ebzimi vertikal dhe horizontal\" n\u00eb fq. 28. Skenar\u00ebt e p\u00ebrdorimit n\u00eb LinkedIn bazoheshin kryesisht n\u00eb thithjen unidireksionale t\u00eb volumit t\u00eb madh t\u00eb t\u00eb dh\u00ebnave, t\u00eb tilla si klikimet n\u00eb faqe dhe regjistrat e qasjes, duke lejuar nj\u00ebkoh\u00ebsisht q\u00eb k\u00ebto t\u00eb dh\u00ebna t\u00eb p\u00ebrdoren nga disa sisteme pa ndikuar n\u00eb performanc\u00ebn e prodhuesve ose konsumer\u00ebve t\u00eb tjer\u00eb. N\u00eb fakt, arsyeja p\u00ebr ekzistenc\u00ebn e Kafka \u00ebsht\u00eb t\u00eb krijohet nj\u00eb arkitektur\u00eb e till\u00eb e shk\u00ebmbimit t\u00eb mesazheve, e cila p\u00ebrshkruhet nga Universal Data Pipeline.<\/p>\n<p>Duke marr\u00eb parasysh k\u00ebt\u00eb q\u00ebllim p\u00ebrfundimtar, patjet\u00ebr q\u00eb u shfaq\u00ebn edhe k\u00ebrkesa t\u00eb tjera. Kafka duhet t\u00eb:<\/p>\n<ul>\n<li>I jet\u00ebshkurt\u00ebr jasht\u00ebzakonisht i shpejt\u00eb<\/li>\n<li>T\u00eb ofroj\u00eb nj\u00eb kapacitet t\u00eb madh gjat\u00eb p\u00ebrpunimit t\u00eb mesazheve<\/li>\n<li>T\u00eb mb\u00ebshtes\u00eb modelet \"Botues-Abonent\" dhe \"Pik\u00eb-Pik\u00eb\"<\/li>\n<li>Mos u vonit n\u00eb shtimin e konsumator\u00ebve. P\u00ebr shembull, performanca e rrjedhave dhe tematikave n\u00eb ActiveMQ p\u00ebrkeq\u00ebsohet me rritjen e numrit t\u00eb konsumator\u00ebve n\u00eb destinacion.<\/li>\n<li>T\u00eb jet\u00eb e shkall\u00ebzueshme horizontalisht; n\u00ebse nj\u00eb broker q\u00eb ruan mesazhet mund ta b\u00ebj\u00eb k\u00ebt\u00eb vet\u00ebm me shpejt\u00ebsin\u00eb maksimale t\u00eb diskut, ka kuptim t\u00eb dal\u00ebsh jasht\u00eb nj\u00eb instance brokeri p\u00ebr t\u00eb rritur performanc\u00ebn.<\/li>\n<li>T\u00eb kufizoni aksesin n\u00eb ruajtjen dhe rikthimin e mesazheve.<\/li>\n<\/ul>\n<p>\nP\u00ebr t\u00eb arritur gjith\u00e7ka k\u00ebt\u00eb, n\u00eb Kafka \u00ebsht\u00eb pranuar nj\u00eb arkitektur\u00eb q\u00eb ka ri-definuar rolet dhe detyrat e klient\u00ebve dhe broker\u00ebve t\u00eb mesazheve. Modeli JMS \u00ebsht\u00eb shum\u00eb orientuar ndaj brokerit, ku ai \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr shp\u00ebrndarjen e mesazheve, nd\u00ebrsa klient\u00ebt duhet t\u00eb merren vet\u00ebm me d\u00ebrgimin dhe marrjen e mesazheve. Kafka, nga ana tjet\u00ebr, \u00ebsht\u00eb orientuar ndaj klientit, ku klienti merr p\u00ebrsip\u00ebr shum\u00eb funksione t\u00eb brokerit tradicional, si\u00e7 \u00ebsht\u00eb shp\u00ebrndarja e ndershme e mesazheve p\u00ebrkat\u00ebse midis konsumator\u00ebve, duke fituar n\u00eb k\u00ebmbim nj\u00eb broker jasht\u00ebzakonisht t\u00eb shpejt\u00eb dhe t\u00eb shkall\u00ebzuar. P\u00ebr ata q\u00eb kan\u00eb punuar me sisteme tradicionale t\u00eb mesazheve, puna me Kafka k\u00ebrkon ndryshime themelore n\u00eb pik\u00ebpamje.<br \/>\nKy drejtim inxhinierik ka \u00e7uar n\u00eb krijimin e nj\u00eb infrastrukture p\u00ebr exchange mesazhesh e cila \u00ebsht\u00eb n\u00eb gjendje t\u00eb rris\u00eb shum\u00ebfish kapacitetin n\u00eb krahasim me nj\u00eb broker t\u00eb zakonsh\u00ebm. Si\u00e7 do t\u00eb shohim, kjo qasje \u00ebsht\u00eb e shoq\u00ebruar me kompromise q\u00eb n\u00ebnkuptojn\u00eb se Kafka nuk \u00ebsht\u00eb e p\u00ebrshtatshme p\u00ebr disa lloje ngarkesash dhe softueri t\u00eb instaluar.<\/p>\n<h3>Modeli i unifikuar i adresat<\/h3>\n<p>\nP\u00ebr t\u00eb p\u00ebrmbushur k\u00ebrkesat e p\u00ebrshkruara m\u00eb sip\u00ebr, Kafka ka kombinuar shk\u00ebmbimin e mesazheve t\u00eb tipit \"publikim-subskripsion\" dhe \"pik\u00eb-n\u00eb-pik\u00eb\" brenda nj\u00eb lloji adresuesi \u2014 <i>tem\u00ebn<\/i>. Kjo i ngat\u00ebrron njer\u00ebzit q\u00eb kan\u00eb punuar me sisteme shk\u00ebmbimi mesazhesh, ku fjala \"tem\u00eb\" i referohet mekanizmit t\u00eb transmetimit masiv, nga i cili (nga tema) leximi nuk \u00ebsht\u00eb i besuesh\u00ebm (\u00ebsht\u00eb jo i q\u00ebndruesh\u00ebm). T\u00eb temave t\u00eb Kafka duhet t\u2019u qaset si nj\u00eb lloj hibrid i adresuesit, n\u00eb p\u00ebrputhje me definicionin e dh\u00ebn\u00eb n\u00eb hyrjen e k\u00ebsaj libri.<\/p>\n<blockquote><p>N\u00eb pjes\u00ebn e mbetur t\u00eb k\u00ebtij kapitulli, n\u00ebse ne n\u00eb m\u00ebnyr\u00eb t\u00eb qart\u00eb nuk tregojm\u00eb ndryshe, termi \"tem\u00eb\" do t'i referohet tem\u00ebs s\u00eb Kafka.<\/p><\/blockquote>\n<p>\nP\u00ebr t\u00eb kuptuar plot\u00ebsisht se si veprojn\u00eb temat dhe \u00e7far\u00eb garancish ofrojn\u00eb, s\u00eb pari duhet t\u00eb shqyrtojm\u00eb se si ato jan\u00eb realizuar n\u00eb Kafka.<br \/>\n<i>\u00c7do tem\u00eb n\u00eb Kafka ka ditarin e saj.<\/i><br \/>\nProdhuesit q\u00eb d\u00ebrgojn\u00eb mesazhe n\u00eb Kafka shkruajn\u00eb n\u00eb k\u00ebt\u00eb jurnal, nd\u00ebrsa konsumator\u00ebt i lexojn\u00eb nga journal me ndihm\u00ebn e treguesve q\u00eb l\u00ebvizin vazhdimisht p\u00ebrpara. Her\u00eb pas here, Kafka heq pjes\u00ebt m\u00eb t\u00eb vjetra t\u00eb jurnalit, pavar\u00ebsisht n\u00ebse mesazhet n\u00eb k\u00ebto pjes\u00eb jan\u00eb lexuar apo jo. Nj\u00eb aspekt qendror i dizajnit t\u00eb Kafka \u00ebsht\u00eb se brokeri nuk e konsideron n\u00ebse mesazhet jan\u00eb lexuar apo jo \u2013 kjo \u00ebsht\u00eb p\u00ebrgjegj\u00ebsi e klientit.<\/p>\n<blockquote><p>Termat \"jurnal\" dhe \"tregues\" nuk shfaqen n\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/kafka.apache.org\/documentation.html\">dokumentacionin e Kafka<\/a><\/noindex>. K\u00ebto terma t\u00eb njohura p\u00ebrdoren k\u00ebtu p\u00ebr t\u00eb ndihmuar n\u00eb kuptimin.<\/p><\/blockquote>\n<p>\nKy model \u00ebsht\u00eb t\u00ebr\u00ebsisht ndryshe nga ActiveMQ, ku mesazhet nga t\u00eb gjitha radh\u00ebt ruhen n\u00eb nj\u00eb jurnal t\u00eb vet\u00ebm, dhe brokeri i sh\u00ebnon mesazhet si t\u00eb fshira pasi ato lexohen.<br \/>\nTani le t\u00eb thellohemi pak dhe t\u00eb shqyrtojm\u00eb jurnalin e tem\u00ebs m\u00eb n\u00eb detaje.<br \/>\nJurnali i Kafka-s p\u00ebrb\u00ebhet nga disa pjes\u00eb (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/tm\/w2\/yf\/tmw2yf3lanppqtrumxoidotplhi.png\">Figura 3-1<\/a><\/noindex>). Kafka garanton renditjen e rrept\u00eb t\u00eb renditur n\u00eb \u00e7do pjes\u00eb. Kjo do t\u00eb thot\u00eb se mesazhet e regjistruara n\u00eb nj\u00eb pjes\u00eb n\u00eb nj\u00eb rend t\u00eb caktuar do t\u00eb lexohen n\u00eb t\u00eb nj\u00ebjtin rend. \u00c7do pjes\u00eb \u00ebsht\u00eb realizuar si nj\u00eb skedar ciklik (rolling) logu q\u00eb p\u00ebrmban <i>n\u00ebngrup <\/i>(subset) t\u00eb gjitha mesazheve, t\u00eb d\u00ebrguara n\u00eb tem\u00eb nga prodhuesit e saj. Tema e krijuar ka p\u00ebr default nj\u00eb pjes\u00eb. Ideja e pjes\u00ebve \u00ebsht\u00eb nj\u00eb ide thelb\u00ebsore e Kafka p\u00ebr shkall\u00ebzimin horizontal.<\/p>\n<p><img decoding=\"async\" alt=\"Kuptimi i broker\u00ebve t\u00eb mesazheve. Studimi i mekanizmave t\u00eb shk\u00ebmbimit t\u00eb mesazheve p\u00ebrmes ActiveMQ dhe Kafka. KREU 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/39f41ebcb73ec247656c0dea438158a9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 3-1. Pjes\u00ebt e Kafka<\/i><\/p>\n<p>Kur nj\u00eb prodhues d\u00ebrgon nj\u00eb mesazh n\u00eb tem\u00ebn Kafka, ai vendos se n\u00eb cil\u00ebn pjes\u00eb do ta d\u00ebrgoj\u00eb mesazhin. Ne do ta shqyrtojm\u00eb k\u00ebt\u00eb m\u00eb n\u00eb detaje m\u00eb von\u00eb.<\/p>\n<h2>Leximi i mesazheve<\/h2>\n<p>\nKlienti, i cili d\u00ebshiron t\u00eb lexoj\u00eb mesazhet, menaxhon nj\u00eb tregues t\u00eb em\u00ebruar, t\u00eb quajtur <i>grupi i konsumator\u00ebve (consumer group)<\/i>, i cili tregon n\u00eb <i>shifr\u00ebn (offset)<\/i> e mesazhit n\u00eb pjes\u00eb. Shifra \u00ebsht\u00eb pozita me num\u00ebr n\u00eb rritje, e cila fillon nga 0 n\u00eb fillim t\u00eb pjes\u00ebs. Ky grup konsumator\u00ebsh, i referuar n\u00eb API p\u00ebrmes nj\u00eb identifikuesi t\u00eb p\u00ebrdoruesit group_id, p\u00ebrputhet me <i>nj\u00eb konsumator logjik ose sistem<\/i>.<\/p>\n<p>Shumica e sistemeve t\u00eb cilat p\u00ebrdorin nd\u00ebrlidhjen e mesazheve lexojn\u00eb t\u00eb dh\u00ebnat nga adresat p\u00ebrmes disa instancave dhe rrjedhave p\u00ebr p\u00ebrpunimin paralel t\u00eb mesazheve. K\u00ebshtu, zakonisht do t\u00eb ket\u00eb shum\u00eb instanca konsumator\u00ebsh q\u00eb ndajn\u00eb t\u00eb nj\u00ebjt\u00ebn grup konsumator\u00ebsh.<\/p>\n<p>Problemi i leximit mund t\u00eb paraqitet si vijon:<\/p>\n<ul>\n<li>Tema ka disa ndarje<\/li>\n<li>Mund t\u00eb p\u00ebrdoret nga shum\u00eb grupe konsumator\u00ebsh n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb<\/li>\n<li>Nj\u00eb grup konsumator\u00ebsh mund t\u00eb ket\u00eb disa instanca t\u00eb ve\u00e7anta<\/li>\n<\/ul>\n<p>\nKjo \u00ebsht\u00eb nj\u00eb problem jo trivial \u00abshum\u00eb n\u00eb shum\u00eb\u00bb. P\u00ebr ta kuptuar se si Kafka trajton marr\u00ebdh\u00ebniet midis grupeve t\u00eb konsumator\u00ebve, instancave t\u00eb konsumator\u00ebve dhe ndarjeve, le t\u00eb shqyrtojm\u00eb nj\u00eb seri skenesh leximi q\u00eb b\u00ebhen gjithnj\u00eb e m\u00eb t\u00eb komplikuara.<\/p>\n<h3>Konsumator\u00ebt dhe grupet e konsumator\u00ebve<\/h3>\n<p>\nLe t'i marim si pik\u00eb fillimi nj\u00eb tem\u00eb me nj\u00eb ndarje (<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 mekanizmave t\u00eb shk\u00ebmbimit t\u00eb mesazheve p\u00ebrmes ActiveMQ dhe Kafka. KREU 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/46c92e6bd38774dfef3be4bd198bf35d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 3-2. Konsumatori lexon nga ndarja<\/i><\/p>\n<p>Kur nj\u00eb instanc\u00eb e konsumatorit lidhet me k\u00ebt\u00eb tem\u00eb me grup_id e tij t\u00eb vet, i caktohet nj\u00eb pjes\u00eb p\u00ebr t\u00eb lexuar dhe nj\u00eb pozicion n\u00eb at\u00eb pjes\u00eb. Pozita e k\u00ebtij pozicioni konfigurohet n\u00eb klient si nj\u00eb tregues p\u00ebr pozitat m\u00eb t\u00eb fundit (mesazhi m\u00eb i ri) ose m\u00eb t\u00eb hershme (mesazhi m\u00eb i vjet\u00ebr). Konsumatori pyet (polls) p\u00ebr mesazhe nga tema, gj\u00eb q\u00eb \u00e7on n\u00eb leximin e tyre t\u00eb nj\u00ebpasnj\u00ebsh\u00ebm nga regjistri.<br \/>\nPozita e pozicionit komitohet rregullisht mbrapsht n\u00eb Kafka dhe ruhet si mesazhe n\u00eb tem\u00ebn e brendshme <i>_consumer_offsets<\/i>. Mesazhet e lexuara gjithsesi nuk fshihen, ndryshe nga nj\u00eb broker normal, dhe klienti mund t\u00eb rrotulluar (rewind) pozicionin p\u00ebr t\u00eb rishikuar mesazhet q\u00eb jan\u00eb par\u00eb m\u00eb par\u00eb.<\/p>\n<p>Kur nj\u00eb konsumator logjik i dyt\u00eb lidhet, duke p\u00ebrdorur nj\u00eb grup_id tjet\u00ebr, ai menaxhon nj\u00eb tregues t\u00eb dyt\u00eb, i cili nuk varet nga i pari (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/qe\/v1\/yk\/qev1yktga3s-g1gqlynylbe3n9w.png\">Figura 3-3<\/a><\/noindex>). N\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb, topic-i Kafka vepron si nj\u00eb radh\u00eb, ku ekziston nj\u00eb konsumator dhe, si nj\u00eb topic i zakonsh\u00ebm i publikuar-Subskriptues (pub-sub), n\u00eb t\u00eb cilin jan\u00eb t\u00eb regjistruar disa konsumator\u00eb, me p\u00ebrfitimin e shtuar 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 mekanizmave t\u00eb shk\u00ebmbimit t\u00eb mesazheve p\u00ebrmes ActiveMQ dhe Kafka. KREU 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/e9e8b9063ef7367005254d36abb47f4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 3-3. Dy konsumator\u00eb n\u00eb grupe t\u00eb ndryshme konsumator\u00ebsh lexojn\u00eb nga nj\u00eb particion<\/i><\/p>\n<h3>Konsumator\u00ebt n\u00eb grupin e konsumator\u00ebve<\/h3>\n<p>\nKur nj\u00eb shembull konsumatori lexon t\u00eb dh\u00ebnat nga particioni, ai kontrollon plot\u00ebsisht treguesin dhe p\u00ebrpunon mesazhet, si\u00e7 u p\u00ebrshkrua n\u00eb seksionin e m\u00ebparsh\u00ebm.<br \/>\nN\u00ebse disa shembuj konsumator\u00ebsh jan\u00eb lidhur me t\u00eb nj\u00ebjtin group_id n\u00eb nj\u00eb topic me nj\u00eb particion, at\u00ebher\u00eb shembulli q\u00eb u lidh s\u00eb fundmi do t\u2019i kaloj\u00eb kontrollin e treguesit dhe q\u00eb nga ai moment 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 mekanizmave t\u00eb shk\u00ebmbimit t\u00eb mesazheve p\u00ebrmes ActiveMQ dhe Kafka. KREU 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/ec6af819445dad4028f65449a735ae22.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 3-4. Dy konsumator\u00eb n\u00eb t\u00eb nj\u00ebjtin grup konsumator\u00ebsh lexojn\u00eb nga nj\u00eb particion<\/i><\/p>\n<p>Ky\u00e7i i till\u00eb i p\u00ebrpunimit, ku numri i ekzemplar\u00ebve t\u00eb konsumator\u00ebve tejkalon numrin e ndarjeve, mund t\u00eb konsiderohet si nj\u00eb lloj konsumatori monopol. Kjo mund t\u00eb jet\u00eb e dobishme n\u00ebse ju nevojitet nj\u00eb klasifikim \u00abaktiv-pasiv\u00bb (ose \u00abt\u00eb ngroht\u00eb-t\u00eb ftoht\u00eb\u00bb) t\u00eb ekzemplar\u00ebve tuaj t\u00eb konsumator\u00ebve, megjithat\u00eb, funksionimi paralel i disa konsumator\u00ebve (\u00abaktiv-aktiv\u00bb ose \u00abt\u00eb ngroht\u00eb-t\u00eb ngroht\u00eb\u00bb) \u00ebsht\u00eb shum\u00eb m\u00eb tipik sesa konsumator\u00ebt n\u00eb gjendje pritjeje.<\/p>\n<blockquote><p>Nj\u00eb sjellje e till\u00eb e shp\u00ebrndarjes s\u00eb mesazheve, e p\u00ebrshkruar m\u00eb sip\u00ebr, mund t\u00eb shkaktoj\u00eb habi n\u00eb krahasim 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 nj\u00eblloj midis dy konsumator\u00ebve.<\/p><\/blockquote>\n<p>\nM\u00eb s\u00eb shpeshti, kur ne krijojm\u00eb disa ekzemplar\u00eb konsumator\u00ebsh, ne e b\u00ebjm\u00eb k\u00ebt\u00eb ose p\u00ebr p\u00ebrpunimin paralel t\u00eb mesazheve, ose p\u00ebr t\u00eb rritur shpejt\u00ebsin\u00eb e leximit, ose p\u00ebr t\u00eb rritur q\u00ebndrueshm\u00ebrin\u00eb e procesit t\u00eb leximit. Duke qen\u00eb se vet\u00ebm nj\u00eb ekzemplar konsumatori mund t\u00eb lexoj\u00eb t\u00eb dh\u00ebnat nga nj\u00eb ndarje n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb, 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 t\u00eb p\u00ebrdorni nj\u00eb shembull konsumi q\u00eb lexon t\u00eb gjitha mesazhet dhe i d\u00ebrgon ato n\u00eb nj\u00eb grup threads. Edhe pse ky qasje rrit kapacitetin e p\u00ebrpunimit, ai rrit kompleksitetin e logjik\u00ebs s\u00eb konsumator\u00ebve dhe nuk b\u00ebn asgj\u00eb p\u00ebr t\u00eb rritur q\u00ebndrueshm\u00ebrin\u00eb e sistemit t\u00eb leximit. N\u00ebse nj\u00eb shembull konsumatori ndizet p\u00ebr shkak t\u00eb nj\u00eb defekti energjie ose ngjarje t\u00eb ngjashme, leximi ndalon.<\/p>\n<p>Nj\u00eb qasje kanonike p\u00ebr t\u00eb zgjidhur k\u00ebt\u00eb problem n\u00eb Kafka \u00ebsht\u00eb p\u00ebrdorimi i<i>m\u00eb<\/i>shum\u00eb ndarjeve.<\/p>\n<h3>Ndarjet<\/h3>\n<p>\nNdarjet jan\u00eb mekanizmi kryesor p\u00ebr paralelizimin e leximit dhe zgjerimin e tem\u00ebs p\u00ebrtej kapacitetit t\u00eb nj\u00eb shembulli brokeri. P\u00ebr ta kuptuar m\u00eb mir\u00eb k\u00ebt\u00eb, le t\u00eb shohim nj\u00eb situat\u00eb kur ekziston nj\u00eb tem\u00eb me dy ndarje dhe nj\u00eb konsumator i regjistruar p\u00ebr k\u00ebt\u00eb tem\u00eb (<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 mekanizmave t\u00eb shk\u00ebmbimit t\u00eb mesazheve p\u00ebrmes ActiveMQ dhe Kafka. KREU 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/cc766bf69af22698aacc3f1ac70b067f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 3-5. Nj\u00eb konsumator lexon nga disa ndarje<\/i><\/p>\n<p>N\u00eb k\u00ebt\u00eb skenar, konsumatori merr kontrollin mbi treguesit q\u00eb p\u00ebrkojn\u00eb me group_id e tij n\u00eb t\u00eb dy ndarjet dhe fillon t\u00eb lexoj\u00eb mesazhet nga t\u00eb dy ndarjet.<br \/>\nKur n\u00eb k\u00ebt\u00eb tem\u00eb shtohet nj\u00eb konsumator shtes\u00eb p\u00ebr t\u00eb nj\u00ebjtin group_id, Kafka ricakton (reallocate) nj\u00eb nga partit\u00eb nga konsumatori i par\u00eb n\u00eb konsumatorin e dyt\u00eb. Pas k\u00ebsaj, \u00e7do ekzemplar konsumatori do t\u00eb lexoj\u00eb nga nj\u00eb parti t\u00eb tem\u00ebs.<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 e mesazheve paralelisht n\u00eb 20 rrjedha, do t'ju nevojiten t\u00eb pakt\u00ebn 20 parti. N\u00ebse partit\u00eb jan\u00eb m\u00eb pak, do t\u00eb keni konsumator\u00eb q\u00eb nuk kan\u00eb me \u00e7far\u00eb t\u00eb punojn\u00eb, si\u00e7 u diskutua m\u00eb par\u00eb p\u00ebr konsumator\u00ebt monopol.<\/p>\n<p><img decoding=\"async\" alt=\"Kuptimi i broker\u00ebve t\u00eb mesazheve. Studimi i mekanizmave t\u00eb shk\u00ebmbimit t\u00eb mesazheve p\u00ebrmes ActiveMQ dhe Kafka. KREU 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/a3c4001e4a5b92d53b6f529b2633254a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 3-6. Dy konsumator\u00eb n\u00eb t\u00eb nj\u00ebjt\u00ebn grup konsumator\u00ebsh lexojn\u00eb nga partit\u00eb t\u00eb ndryshme<\/i><\/p>\n<p>Kjo skem\u00eb ndjesh\u00ebm ul kompleksitetin e pun\u00ebs s\u00eb brokerit Kafka n\u00eb krahasim me shp\u00ebrndarjen e mesazheve, e nevojshme p\u00ebr t\u00eb mb\u00ebshtetur radh\u00ebn JMS. K\u00ebtu, nuk ka nevoj\u00eb t\u00eb shqet\u00ebsoheni p\u00ebr momentet e m\u00ebposhtme:<\/p>\n<ul>\n<li>Cili konsumator duhet t\u00eb marr\u00eb mesazhin e ardhsh\u00ebm, n\u00eb baz\u00eb t\u00eb shp\u00ebrndarjes rrethore (round-robin), kapacitetit aktual t\u00eb tamponit t\u00eb parazgjedhur apo mesazheve t\u00eb m\u00ebparshme (si p\u00ebr grupet e mesazheve JMS).<\/li>\n<li>Cilat mesazhe jan\u00eb d\u00ebrguar cil\u00ebve konsumator\u00eb dhe a duhet t\u00eb p\u00ebrs\u00ebriten 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\u00eb transmetoj\u00eb mesazhet n\u00eb m\u00ebnyr\u00eb t\u00eb rregullt te konsumatori, kur ky i fundit i k\u00ebrkon ato.<\/p>\n<p>Megjithat\u00eb, k\u00ebrkesat p\u00ebr paralelizimin e leximit dhe d\u00ebrgimin p\u00ebrs\u00ebri t\u00eb mesazheve t\u00eb d\u00ebshtuara nuk zhduken asnj\u00ebher\u00eb \u2014 p\u00ebrgjegj\u00ebsia p\u00ebr to thjesht kalon nga brokeri te klienti. Kjo do t\u00eb thot\u00eb q\u00eb 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 vendosjen se n\u00eb cil\u00ebn parti t\u00eb d\u00ebrgohet mesazhi i takon producentit t\u00eb k\u00ebtij mesazhi. P\u00ebr t\u00eb kuptuar mekanizmin me an\u00eb t\u00eb cilit b\u00ebhet kjo, fillimisht duhet t\u00eb shqyrtojm\u00eb se \u00e7far\u00eb sakt\u00ebsisht po d\u00ebrgojm\u00eb.<\/p>\n<p>Nd\u00ebrsa n\u00eb JMS ne p\u00ebrdorim nj\u00eb struktur\u00eb mesazhi me metadata (tituj dhe prona) dhe nj\u00eb trup q\u00eb p\u00ebrmban ngarkes\u00ebn e dobishme (payload), n\u00eb Kafka mesazhi \u00ebsht\u00eb <i>nj\u00eb \u00e7ift \u00ab\u00e7el\u00ebs-vler\u00eb\u00bb<\/i>. Ngarkesa e dobishme e mesazhit d\u00ebrgohet si vler\u00eb (value). \u00c7el\u00ebsi, nga ana tjet\u00ebr, p\u00ebrdoret kryesisht p\u00ebr partitizim dhe duhet t\u00eb p\u00ebrmbaj\u00eb <i>nj\u00eb \u00e7el\u00ebs t\u00eb ve\u00e7ant\u00eb p\u00ebr logjik\u00ebn e biznesit<\/i>, p\u00ebr t\u00eb vendosur mesazhet e lidhura n\u00eb t\u00eb nj\u00ebjt\u00ebn parti.<\/p>\n<p>N\u00eb Kapitullin 2, ne diskutuam nj\u00eb skenar t\u00eb bastesh online, kur ngjarjet e lidhura duhet t\u00eb p\u00ebrpunohen nj\u00eb pas nj\u00eb nga nj\u00eb konsumator t\u00eb vet\u00ebm:<\/p>\n<ol>\n<li>Llogaria e p\u00ebrdoruesit \u00ebsht\u00eb konfiguruar.<\/li>\n<li>Parat\u00eb kreditohet n\u00eb llogari.<\/li>\n<li>B\u00ebhet nj\u00eb bast q\u00eb t\u00ebrheq para nga llogaria.<\/li>\n<\/ol>\n<p>\nN\u00ebse \u00e7do ngjarje \u00ebsht\u00eb nj\u00eb mesazh q\u00eb d\u00ebrgohet n\u00eb tem\u00eb, at\u00ebher\u00eb \u00e7el\u00ebsi natyror do t\u00eb jet\u00eb identifikuesi i llogaris\u00eb.<br \/>\nKur mesazhi d\u00ebrgohet duke p\u00ebrdorur Kafka Producer API, ai kalon n\u00ebp\u00ebr funksionin e ndarjes, i cili, duke marr\u00eb parasysh mesazhin dhe gjendjen aktuale t\u00eb klasterit Kafka, kthen identifikuesin e ndarjes, n\u00eb t\u00eb cil\u00ebn duhet t\u00eb d\u00ebrgohet mesazhi. Ky funksion \u00ebsht\u00eb realizuar 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 pjes\u00ebz\u00ebs p\u00ebrdor si parazgjedhje algoritmin e heshit t\u00eb \u00e7el\u00ebsit (general-purpose hashing algorithm over the key) ose metoden e rrethit (round-robin), n\u00ebse \u00e7el\u00ebsi nuk \u00ebsht\u00eb specifikuar. Ky vler\u00eb parazgjedhje funksionon mir\u00eb n\u00eb shumic\u00ebn e rasteve. Megjithat\u00eb, n\u00eb t\u00eb ardhmen mund t\u00eb d\u00ebshironi t\u00eb shkruani strategjin\u00eb tuaj p\u00ebr particionim.<\/p>\n<h3>Shkruani strategjin\u00eb tuaj p\u00ebr particionim<\/h3>\n<p>\nLe t\u00eb shqyrtojm\u00eb nj\u00eb shembull, kur d\u00ebshironi t\u00eb d\u00ebrgoni metad data s\u00eb bashku me ngarkes\u00ebn e mesazhit. Ngarkesa 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\u00ebrave. Udh\u00ebzimi \u00ebsht\u00eb ajo q\u00eb do t\u00eb doja ta garantonim se nuk do t\u00eb modifikohet gjat\u00eb transmetimit dhe duam t\u00eb sigurohemi se vet\u00ebm nj\u00eb sistem i besuesh\u00ebm m\u00eb i lart\u00eb mund ta inicioj\u00eb k\u00ebt\u00eb udh\u00ebzim. N\u00eb k\u00ebt\u00eb rast, sistemet d\u00ebrguese dhe pranuese bien dakord p\u00ebr t\u00eb p\u00ebrdorur n\u00ebnshkrimin p\u00ebr t\u00eb verifikuar autenticitetin e mesazhit.<br \/>\nN\u00eb JMS t\u00eb zakonsh\u00ebm, thjesht e p\u00ebrcaktojm\u00eb pron\u00ebn \"n\u00ebnshkrimi i mesazhit\" dhe e shtojm\u00eb at\u00eb n\u00eb mesazh. Megjithat\u00eb, Kafka nuk na ofron nj\u00eb mekaniz\u00ebm p\u00ebr t\u00eb transmetuar metadatat \u2014 vet\u00ebm \u00e7el\u00ebsin dhe vler\u00ebn.<\/p>\n<p>Duke vlera \u00ebsht\u00eb ngarkesa e transferit bankar (bank transfer payload), integriteti i s\u00eb cil\u00ebs ne duam ta ruajm\u00eb, ne nuk kemi alternativ\u00eb tjet\u00ebr p\u00ebrve\u00e7se t\u00eb p\u00ebrcaktojm\u00eb struktur\u00ebn e t\u00eb dh\u00ebnave p\u00ebr p\u00ebrdorim n\u00eb \u00e7el\u00ebs. Duke supozuar se na nevojitet nj\u00eb identifikues llogarie p\u00ebr ndarjen, pasi t\u00eb gjitha mesazhet q\u00eb lidhen me llogarin\u00eb duhet t\u00eb trajtohen n\u00eb rend, ne do t\u00eb krijojm\u00eb struktur\u00ebn JSON si m\u00eb posht\u00eb:<\/p>\n<pre><code class=\"json\">{\n  \"signature\": \"541661622185851c248b41bf0cea7ad0\",\n  \"accountId\": \"10007865234\"\n}<\/code><\/pre>\n<p>\nDuke pasur parasysh se vlera e n\u00ebnshkrimit do t\u00eb ndryshoj\u00eb n\u00eb var\u00ebsi t\u00eb ngarkes\u00ebs, strategjia e parazgjedhur e hashing-ut t\u00eb nd\u00ebrfaqes Partitioner nuk do t\u00eb grumbulloj\u00eb me besueshm\u00ebri mesazhet e lidhura. Prandaj, do t\u00eb na nevojitet t\u00eb shkruajm\u00eb strategjin\u00eb ton\u00eb, e cila do t\u00eb analizoj\u00eb k\u00ebt\u00eb \u00e7el\u00ebs dhe do t\u00eb ndaj\u00eb (partition) vler\u00ebn e accountId.<\/p>\n<blockquote><p>Kafka p\u00ebrfshin shumica kontrolle p\u00ebr zb discovery t\u00eb d\u00ebmtimit t\u00eb mesazheve n\u00eb depo dhe ka nj\u00eb grup t\u00eb plot\u00eb funksionesh sigurie. Edhe n\u00eb k\u00ebt\u00eb rast, ndonj\u00ebher\u00eb paraqiten k\u00ebrkesa specifike p\u00ebr industrin\u00eb, si ato t\u00eb p\u00ebrmendura m\u00eb lart.<\/p><\/blockquote>\n<p>\nStrategjia e ndarjes s\u00eb p\u00ebrdoruesit duhet t\u00eb garantosh\u00eb q\u00eb t\u00eb gjitha mesazhet e lidhura t\u00eb p\u00ebrfundojn\u00eb n\u00eb nj\u00eb partition t\u00eb vetme. Edhe pse 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 se sa fikse \u00ebsht\u00eb numri i partitioneve n\u00eb tem\u00eb.<\/p>\n<p>Numri i partitioneve n\u00eb tem\u00eb mund t\u00eb ndryshoj\u00eb me kalimin e koh\u00ebs, pasi ato mund t\u00eb shtohen n\u00ebse trafiku tejkalon pritshm\u00ebrin\u00eb fillestare. K\u00ebshtu, \u00e7el\u00ebsat e mesazheve mund t\u00eb lidhen me partitionin n\u00eb t\u00eb cilin jan\u00eb d\u00ebrguar fillimisht, duke n\u00ebnkuptuar nj\u00eb pjes\u00eb t\u00eb gjendjes q\u00eb duhet t\u00eb shp\u00ebrndahet nd\u00ebrmjet instancave t\u00eb prodhuesit.<\/p>\n<p>Nj\u00eb tjet\u00ebr faktor q\u00eb duhen marr\u00eb parasysh \u00ebsht\u00eb barazia e shp\u00ebrndarjes s\u00eb mesazheve midis partitioneve. Si rregull, \u00e7el\u00ebsat nuk shp\u00ebrndahen n\u00eb m\u00ebnyr\u00eb t\u00eb barabart\u00eb n\u00eb mesazhe, dhe funksionet e hash-it 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, si\u00e7 e vendosni ju mesazhet, ndar\u00ebsi mund t\u00eb ket\u00eb nevoj\u00eb t\u00eb p\u00ebrdoret p\u00ebrs\u00ebri.<\/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 lokacione t\u00eb ndryshme gjeografike. P\u00ebr k\u00ebt\u00eb q\u00ebllim, Kafka ofron nj\u00eb mjet komandash t\u00eb quajtur MirrorMaker, i cili p\u00ebrdoret p\u00ebr t\u00eb lexuar mesazhe nga nj\u00eb klaster dhe p\u00ebr t'i d\u00ebrguar ato n\u00eb nj\u00eb tjet\u00ebr.<\/p>\n<p>MirrorMaker duhet t\u00eb kuptoj\u00eb \u00e7el\u00ebsat e tem\u00ebs s\u00eb replikueshme, p\u00ebr t\u00eb mbajtur rendin relativ midis mesazheve gjat\u00eb replikimit mes klaster\u00ebve, pasi numri i ndarjeve p\u00ebr k\u00ebt\u00eb tem\u00eb mund t\u00eb mos p\u00ebrputhet n\u00eb dy klaster\u00eb.<\/p>\n<p>Strategjit\u00eb e personalizuara t\u00eb ndarjes takohen relativisht rrall\u00eb, pasi ndarjet e defoltit si hashing ose cikli i rrotullimit funksionojn\u00eb me sukses n\u00eb shumic\u00ebn e skenar\u00ebve. Megjithat\u00eb, n\u00ebse ju nevojiten garanci t\u00eb rrepta p\u00ebr renditje ose n\u00ebse duhet t\u00eb nxirrni metadata nga ngarkesat, at\u00ebher\u00eb ndarja \u00ebsht\u00eb di\u00e7ka q\u00eb duhet t\u00eb shqyrtoni m\u00eb n\u00eb detaje.<\/p>\n<p>Avantazhet e shkall\u00ebzueshm\u00ebris\u00eb dhe performanc\u00ebs s\u00eb Kafka-s jan\u00eb rezultat i transferimit t\u00eb disa detyrave tradicionale t\u00eb brokerit te klienti. N\u00eb k\u00ebt\u00eb rast, merret nj\u00eb vendim p\u00ebr shp\u00ebrndarjen e mesazheve q\u00eb potencialisht lidhen n\u00eb disa konsumatore q\u00eb punojn\u00eb paralelisht.<\/p>\n<blockquote><p>Brokes JMS gjithashtu duhet t\u00eb p\u00ebrballen me k\u00ebto k\u00ebrkesa. \u00cbsht\u00eb interesante se mekanizmi i d\u00ebrgimit t\u00eb mesazheve t\u00eb lidhura te i nj\u00ebjti konsumator, realizuar n\u00ebp\u00ebrmjet JMS Message Groups (nj\u00eb lloj strategjie balancimi ngjit\u00ebs), k\u00ebrkon gjithashtu q\u00eb d\u00ebrguesi t\u00eb etiketohet mesazhet si t\u00eb lidhura. N\u00eb rastin e JMS, brokeri \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr d\u00ebrgimin e k\u00ebsaj grupi mesazhesh t\u00eb lidhura te nj\u00eb konsumator nga shum\u00eb dhe p\u00ebr transferimin e t\u00eb drejtave t\u00eb pron\u00ebsis\u00eb mbi grupin n\u00ebse konsumatori rr\u00ebzohet.<\/p><\/blockquote>\n<p><\/p>\n<h2>Marr\u00ebveshjet mbi prodhuesin<\/h2>\n<p>\nParitizionimi nuk \u00ebsht\u00eb e vetmja gj\u00eb q\u00eb duhet t\u00eb merren 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 menzionuar menj\u00ebher\u00eb se t\u00eb dy metodat kthejn\u00eb nj\u00eb Future, \u00e7ka tregon se operacioni i d\u00ebrgimit nuk kryhet menj\u00ebher\u00eb. Si rezultat, mesazhi (ProducerRecord) shkruhet n\u00eb tamponin e d\u00ebrgimit p\u00ebr \u00e7do parti aktive dhe d\u00ebrgohet te brokeri n\u00eb nj\u00eb rrjedh\u00eb lokale n\u00eb bibliotek\u00ebn e klientit Kafka. Megjith\u00ebse kjo e b\u00ebn procesin jasht\u00ebzakonisht t\u00eb shpejt\u00eb, kjo do t\u00eb thot\u00eb se nj\u00eb aplikacion i shkruar keq mund t\u00eb humbas\u00eb mesazhe n\u00ebse procesi i tij ndalet.<\/p>\n<p>Si gjithmon\u00eb, ka nj\u00eb m\u00ebnyr\u00eb p\u00ebr ta b\u00ebr\u00eb operacionin e d\u00ebrgimit m\u00eb t\u00eb besuesh\u00ebm n\u00eb d\u00ebm t\u00eb performanc\u00ebs. Madh\u00ebsia e k\u00ebtij tamponi mund t\u00eb vendoset n\u00eb 0, dhe rrjedha e aplikacionit d\u00ebrgues do t\u00eb detyrohet t\u00eb pres\u00eb derisa d\u00ebrgimi i mesazhit te brokeri t\u00eb p\u00ebrfundoj\u00eb, n\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb:<\/p>\n<pre><code class=\"java\">RecordMetadata metadata = producer.send(record).get();<\/code><\/pre>\n<p><\/p>\n<h2>Nj\u00ebher\u00eb tjet\u00ebr p\u00ebr leximin e mesazheve<\/h2>\n<p>\nLeximi i mesazheve ka v\u00ebshtir\u00ebsi t\u00eb tjera, p\u00ebr t\u00eb cilat duhet t\u00eb mendojm\u00eb. Ndryshe nga API JMS, i cili mund t\u00eb niste nj\u00eb d\u00ebgjues mesazhesh (message listener) n\u00eb p\u00ebrgjigje t\u00eb mb\u00ebrritjes s\u00eb nj\u00eb mesazhi, interface <i>Consumer <\/i>Kafka vet\u00ebm kontrollon (polling). Le t\u00eb shohim m\u00eb n\u00eb detaje 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 kthyese e metod\u00ebs \u00ebsht\u00eb nj\u00eb struktur\u00eb kontainer q\u00eb p\u00ebrmban disa objekte <i>ConsumerRecord <\/i>nga potencialisht disa parti. <i>ConsumerRecord <\/i>\u00ebsht\u00eb vet\u00eb nj\u00eb objekt mbajt\u00ebs p\u00ebr nj\u00eb \u00e7ift \u00e7el\u00ebs-vler\u00eb me metadatat p\u00ebrkat\u00ebse, si\u00e7 jan\u00eb partia nga e cila \u00ebsht\u00eb marr\u00eb.<\/p>\n<p>Si\u00e7 u diskutua n\u00eb Kapitullin 2, duhet t\u00eb kujtojm\u00eb vazhdimisht se \u00e7far\u00eb ndodh me mesazhet pas p\u00ebrpunimit t\u00eb tyre me sukses ose d\u00ebshtim, p\u00ebr shembull, n\u00ebse klienti nuk mund ta p\u00ebrpunoj\u00eb mesazhin ose n\u00ebse ai nd\u00ebrprehet. N\u00eb JMS, kjo u p\u00ebrpunua p\u00ebrmes modalitetit t\u00eb konfirmimit (acknowledgement mode). Brokeri ose do t\u00eb fshij\u00eb mesazhin e p\u00ebrpunuar me sukses, ose do ta d\u00ebrgoj\u00eb p\u00ebrs\u00ebri at\u00eb q\u00eb nuk \u00ebsht\u00eb p\u00ebrpunuar ose q\u00eb ka d\u00ebshtuar (n\u00ebse jan\u00eb p\u00ebrdorur transaksionet). <br \/>\nKafka funksionon krejt ndryshe. Mesazhet nuk fshihen n\u00eb broker pas leximit dhe p\u00ebrgjegj\u00ebsia p\u00ebr ato q\u00eb ndodhin n\u00eb rast d\u00ebshtimi \u00ebsht\u00eb mbi kodin q\u00eb lexon vet\u00eb.<\/p>\n<p>Si\u00e7 e p\u00ebrmend\u00ebm, grupi i konsumator\u00ebve \u00ebsht\u00eb i lidhur me zhvendosjen n\u00eb regjist\u00ebr. Pozita n\u00eb regjist\u00ebr e lidhur me k\u00ebt\u00eb zhvendosje p\u00ebrputhet me mesazhin tjet\u00ebr q\u00eb do t\u00eb l\u00ebshohet si p\u00ebrgjigje n\u00eb <i>poll ()<\/i>. Momenti i koh\u00ebs, kur kjo zhvendosje rritet, ka r\u00ebnd\u00ebsi vendimtare n\u00eb lexim.<\/p>\n<p>Duke u kthyer te modeli i leximit, p\u00ebrpunimi i mesazhit p\u00ebrb\u00ebhet nga tre etapa:<\/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>\nKonsumeri Kafka vjen me nj\u00eb opsion konfigurimi <i>enable.auto.commit<\/i>. Ky \u00ebsht\u00eb nj\u00eb cil\u00ebsim i zakonsh\u00ebm n\u00eb m\u00ebnyr\u00eb default, si zakonisht \u00ebsht\u00eb me cil\u00ebsimet q\u00eb p\u00ebrmbajn\u00eb fjal\u00ebn 'auto'.<\/p>\n<p>Derisa Kafka 0.10, klienti q\u00eb p\u00ebrdorte k\u00ebt\u00eb paramet\u00ebr, d\u00ebrgonte zhvendosjen e mesazhit t\u00eb fundit t\u00eb lexuar n\u00eb thirrjen e ardhshme <i>poll ()<\/i> pas p\u00ebrpunimit. Kjo do t\u00eb thoshte se \u00e7do mesazh q\u00eb ishte nxjerr\u00eb (fetched) mund t\u00eb p\u00ebrpunohej p\u00ebrs\u00ebri, n\u00ebse clienti e kishte p\u00ebrpunuar at\u00eb, por kishte humbur papritur p\u00ebrpara thirrjes. <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 pasues q\u00eb merr k\u00ebt\u00eb mesazh nuk do t\u00eb dij\u00eb se ndodhi di\u00e7ka e keqe. Ky sjellje ishte pseudo-transaksionale. P\u00ebrparimi u komitua vet\u00ebm n\u00eb rastin e p\u00ebrpunimit t\u00eb suksessh\u00ebm t\u00eb mesazhit, por n\u00ebse klienti nd\u00ebrpriste pun\u00ebn, brokeri e d\u00ebrgonte s\u00ebrish t\u00eb nj\u00ebjtin mesazh te nj\u00eb klient tjet\u00ebr. Ky sjellje p\u00ebrputhej me garancin\u00eb e d\u00ebrgimit t\u00eb mesazheve \u00ab<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 q\u00eb komitimi t\u00eb fillonte periodikisht nga biblioteka e klientit, n\u00eb p\u00ebrputhje me konfigurimin <i>auto.commit.interval.ms<\/i>. Ky ky\u00e7je \u00ebsht\u00eb diku midis mod\u00ebs JMS AUTO_ACKNOWLEDGE dhe DUPS_OK_ACKNOWLEDGE. Kur p\u00ebrdoret auto-p\u00ebrfundimi, mesazhet mund t\u00eb konfirmohen pavar\u00ebsisht n\u00ebse ato jan\u00eb trajtuar realisht \u2014 kjo mund t\u00eb ndodh\u00eb n\u00eb rastin e nj\u00eb konsumer-i t\u00eb ngadalt\u00eb. N\u00ebse konsumer-i ndalej, mesazhet do t\u00eb p\u00ebrfundoheshin nga konsumer-i tjet\u00ebr, duke filluar nga pozita e p\u00ebrfunduar, e cila mund t\u00eb \u00e7oj\u00eb n\u00eb humbjen e nj\u00eb mesazhi. N\u00eb k\u00ebt\u00eb rast, Kafka nuk humb mesazhe, kodi i leximit thjesht nuk i trajton ato.<\/p>\n<p>Ky mod ka t\u00eb nj\u00ebjtat mund\u00ebsi si n\u00eb versionin 0.9: mesazhet mund t\u00eb trajtohen, por n\u00eb rast d\u00ebshtimi, offset-i mund t\u00eb mos jet\u00eb p\u00ebrfunduar, gj\u00eb q\u00eb potencialisht mund t\u00eb sjell\u00eb dyfishim t\u00eb dor\u00ebzimit. Sa m\u00eb shum\u00eb mesazhe t\u00eb nxirrni gjat\u00eb ekzekutimit <i>poll ()<\/i>, aq m\u00eb shum\u00eb \u00ebsht\u00eb problemi.<\/p>\n<p>Si\u00e7 u diskutua n\u00eb seksionin \"Leximi i mesazheve nga radh\u00ebt\" n\u00eb fq. 21, n\u00eb sistemin e shk\u00ebmbimit t\u00eb mesazheve nuk ka nj\u00eb koncept t\u00eb dor\u00ebzimit t\u00eb vet\u00ebm t\u00eb mesazhit, n\u00ebse merret parasysh modet e d\u00ebshtimit.<\/p>\n<p>N\u00eb Kafka ka dy m\u00ebnyra p\u00ebr t\u00eb konfirmuar (komit) 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 para komitimit. Ju gjithashtu mund t\u00eb mos e p\u00ebrpunoni fare mesazhin, n\u00ebse komitimi \u00ebsht\u00eb ndodhur n\u00eb sfond dhe kodi juaj \u00ebsht\u00eb p\u00ebrfunduar para se t\u00eb fillonte p\u00ebrpunimin (ndoshta n\u00eb Kafka 0.9 dhe versionet e m\u00ebparshme).<\/p>\n<p>T\u00eb menaxhosh procesin e komitimit t\u00eb offset-it manualisht mund t\u00eb b\u00ebhet n\u00eb API-n\u00eb e konsumatoreve t\u00eb Kafka, duke vendosur parametrin <i>enable.auto.commit<\/i> n\u00eb vler\u00ebn false dhe duke thirrur 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 t\u00eb p\u00ebrpunoni mesazhin \"t\u00eb pakt\u00ebn nj\u00eb her\u00eb\", duhet t\u00eb b\u00ebni komitimin 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 deri sa ato t\u00eb p\u00ebrpunohen, por ato nuk b\u00ebjn\u00eb asgj\u00eb p\u00ebr t\u00eb eliminuar potencialin p\u00ebr p\u00ebrpunim t\u00eb dyfisht\u00eb, nd\u00ebrkoh\u00eb q\u00eb krijojn\u00eb iluzionin e transaksionalitetit. N\u00eb Kafka nuk ka transaksione. Klienti nuk ka mund\u00ebsin\u00eb t\u00eb b\u00ebj k\u00ebt\u00eb:<\/p>\n<ul>\n<li>Rifit automatikisht nj\u00eb mesazh t\u00eb d\u00ebshtuar. Konsumator\u00ebt duhet t\u00eb trajtojn\u00eb vet\u00eb p\u00ebrjashtimet q\u00eb ndodhin p\u00ebr shkak t\u00eb ngarkesave problematike dhe nd\u00ebrprerjeve t\u00eb backend-it, pasi ata nuk mund t\u00eb mb\u00ebshteten n\u00eb rip\u00ebrs\u00ebritjen e mesazheve nga brokeri.<\/li>\n<li>D\u00ebrgoni mesazhe n\u00eb disa tema n\u00eb kuad\u00ebr t\u00eb nj\u00eb operacioni atomar. Si\u00e7 do t\u00eb shohim s\u00eb shpejti, kontrolli mbi tema dhe pjes\u00ebt e ndryshme mund t\u00eb jet\u00eb n\u00eb makina t\u00eb ndryshme n\u00eb klasterin Kafka, t\u00eb cilat nuk koordinojn\u00eb transaksionet gjat\u00eb d\u00ebrgimit. N\u00eb momentin q\u00eb po shkruaj k\u00ebt\u00eb artikull, \u00ebsht\u00eb b\u00ebr\u00eb nj\u00eb pun\u00eb e caktuar p\u00ebr t\u00eb b\u00ebr\u00eb k\u00ebt\u00eb t\u00eb mundur me an\u00eb t\u00eb KIP-98.<\/li>\n<li>Lidhni leximin e nj\u00eb mesazhi nga nj\u00eb tem\u00eb me d\u00ebrgimin e nj\u00eb mesazhi tjet\u00ebr n\u00eb nj\u00eb tem\u00eb tjet\u00ebr. Edhe nj\u00eb her\u00eb, arkitektura e Kafka-s varet nga shum\u00eb makina t\u00eb pavarura q\u00eb funksionojn\u00eb si nj\u00eb autobus dhe nuk b\u00ebhen p\u00ebrpjekje p\u00ebr ta fshehur k\u00ebt\u00eb. P\u00ebr shembull, nuk ka komponente API q\u00eb t\u00eb lejojn\u00eb lidhjen. <i>Konsumator <\/i>dhe <i>Prodhues <\/i>n\u00eb transaksion. N\u00eb JMS, kjo sigurohet nga objekti <i>Session<\/i>, nga i cili 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 q\u00eb \u00ebsht\u00eb m\u00eb af\u00ebr asaj q\u00eb ofrojn\u00eb sistemet tradicionale t\u00eb mesazheve?<\/p>\n<p>N\u00ebse ekziston mund\u00ebsia q\u00eb zhvendosja e konsumatorit t\u00eb rritet para se mesazhi t\u00eb p\u00ebrprocessed, p\u00ebr shembull, gjat\u00eb nj\u00eb d\u00ebshtimi t\u00eb konsumatorit, at\u00ebher\u00eb konsumatori nuk ka m\u00ebnyr\u00eb p\u00ebr t\u00eb ditur n\u00ebse grupi i tij i konsumator\u00ebve \u00ebsht\u00eb humbur mesazhe kur i caktohet nj\u00eb pjes\u00eb. Prandaj, nj\u00eb nga strategjit\u00eb \u00ebsht\u00eb t\u00eb rrokulliset (rewind) zhvendosja n\u00eb poziten para. API i konsumatorit Kafka 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>\nMetoda <i>seek ()<\/i> mund t\u00eb p\u00ebrdoret me metod\u00ebn <br \/>\n<i>offsetsForTimes (Map timestampsToSearch)<\/i> p\u00ebr t\u00eb rrokullisur n\u00eb nj\u00eb gjendje n\u00eb nj\u00eb moment t\u00eb caktuar n\u00eb t\u00eb kaluar\u00ebn.<\/p>\n<p>N\u00eb m\u00ebnyr\u00eb t\u00eb t\u00ebrthort\u00eb, p\u00ebrdorimi i k\u00ebtij qasje n\u00ebnkupton se \u00ebsht\u00eb shum\u00eb e mundshme q\u00eb disa mesazhe q\u00eb jan\u00eb p\u00ebrpunuar m\u00eb par\u00eb do t\u00eb lexohen dhe p\u00ebrpunohen p\u00ebrs\u00ebri. P\u00ebr t\u00eb shmangur k\u00ebt\u00eb, ne mund t\u00eb p\u00ebrdorim leximin idempotent, si\u00e7 p\u00ebrshkruhet n\u00eb Kapitullin 4, p\u00ebr t\u00eb ndjekur mesazhet q\u00eb jan\u00eb par\u00eb m\u00eb par\u00eb dhe p\u00ebr t\u00eb p\u00ebrjashtuar dyfishimet.<\/p>\n<p>Si nj\u00eb alternativ\u00eb, kodi i konsumatorit tuaj mund t\u00eb jet\u00eb i thjesht\u00eb, n\u00ebse humbja ose dyfishimi i mesazheve \u00ebsht\u00eb i pranuesh\u00ebm. Kur shqyrtojm\u00eb skenar\u00ebt e p\u00ebrdorimit, p\u00ebr t\u00eb cilat zakonisht p\u00ebrdoret Kafka, si p\u00ebrpunimi i ngjarjeve t\u00eb regjistrave, metrikeve, ndjekja e klikimeve etj., ne kuptojm\u00eb se humbja e mesazheve t\u00eb ve\u00e7anta nuk ka t\u00eb ngjar\u00eb t\u00eb ket\u00eb nj\u00eb ndikim t\u00eb r\u00ebnd\u00ebsish\u00ebm n\u00eb aplikacionet p\u00ebrreth. N\u00eb k\u00ebto raste, vlerat e parazgjedhura jan\u00eb plot\u00ebsisht t\u00eb pranueshme. Anasjelltas, n\u00ebse aplikacioni juaj ka nevoj\u00eb t\u00eb p\u00ebr\u00e7oj\u00eb pagesa, duhet t\u00eb kujdeseni me kujdes p\u00ebr secilin mesazh individual. E gjith\u00eb kjo nd\u00ebrlidhet me kontekstin.<\/p>\n<p>V\u00ebzhgimet personale tregojn\u00eb se me rritjen e intensitetit t\u00eb mesazheve, vlera e \u00e7do mesazhi t\u00eb ve\u00e7ant\u00eb zvog\u00eblohet. Mesazhet e shumta zakonisht b\u00ebhen t\u00eb vlefshme kur shqyrtohen n\u00eb form\u00eb t\u00eb agreguar.<\/p>\n<h2>Disponueshm\u00ebria e lart\u00eb (High Availability)<\/h2>\n<p>\nPragmatizmi i Kafka-s n\u00eb lidhje me disponueshm\u00ebrin\u00eb e lart\u00eb dallon n\u00eb m\u00ebnyr\u00eb thelb\u00ebsore nga ai i ActiveMQ. Kafka \u00ebsht\u00eb zhvilluar mbi klaster\u00eb q\u00eb shkall\u00ebzohen horizontalisht, ku t\u00eb gjitha instancat e brokerit pranojn\u00eb dhe shp\u00ebrndajn\u00eb mesazhe n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb.<\/p>\n<p>Klasteri i Kafka-s p\u00ebrb\u00ebhet nga disa instanca broker\u00ebsh q\u00eb punojn\u00eb n\u00eb server\u00eb t\u00eb ndrysh\u00ebm. Kafka \u00ebsht\u00eb krijuar p\u00ebr t\u00eb punuar n\u00eb pajisje autonome normale, ku \u00e7do nyje ka ruajtje t\u00eb saj t\u00eb dedikuar. P\u00ebrdorimi i ruajtjeve rrjet\u00ebsore (SAN) nuk rekomandohet, pasi nyjat e shumta t\u00eb computimit mund t\u00eb konkurrojn\u00eb p\u00ebr intervalet e koh\u00ebs s\u00eb ruajtjes dhe t\u00eb krijojn\u00eb konflikte.<i>\u00eb<\/i>t\u00eb<\/p>\n<p>Kafka \u00ebsht\u00eb <i>gjithmon\u00eb aktive<\/i> sistemi. Shum\u00eb p\u00ebrdorues t\u00eb m\u00ebdhenj t\u00eb Kafka kurr\u00eb nuk e ndalin klasterin e tyre, dhe softueri gjithmon\u00eb siguron p\u00ebrdit\u00ebsimin p\u00ebrmes rindizjes sekondare. Kjo arrihet duke garantuar p\u00ebrputhshm\u00ebrin\u00eb me versionin e m\u00ebparsh\u00ebm p\u00ebr mesazhet dhe nd\u00ebrveprimet nd\u00ebrmjet broker\u00ebve.<\/p>\n<p>Broker\u00ebt jan\u00eb t\u00eb lidhur me klasterin e server\u00ebve <noindex><a rel=\"nofollow\" href=\"http:\/\/zookeeper.apache.org\">ZooKeeper<\/a><\/noindex>, i cili vepron si regjistri i t\u00eb dh\u00ebnave t\u00eb konfigurimit dhe p\u00ebrdoret p\u00ebr t\u00eb koordinuar rolet e secilit broker. ZooKeeper vet\u00eb \u00ebsht\u00eb nj\u00eb sistem i shp\u00ebrndar\u00eb q\u00eb siguron disponueshm\u00ebri t\u00eb lart\u00eb p\u00ebrmes replikimit t\u00eb informacionit p\u00ebrmes vendosjes <i>kuorumit<\/i>.<\/p>\n<p>N\u00eb rastin bazik, nj\u00eb tem\u00eb krijohet n\u00eb klasterin Kafka me k\u00ebto pron\u00ebsi:<\/p>\n<ul>\n<li>Numri i particioneve. Si\u00e7 u diskutua m\u00eb par\u00eb, vlera e sakt\u00eb e p\u00ebrdorur k\u00ebtu varet nga niveli i d\u00ebshiruar i leximit paralel.<\/li>\n<li>Faktori i replikimit p\u00ebrcakton numrin e instancave t\u00eb broker\u00ebve n\u00eb klaster q\u00eb duhet t\u00eb p\u00ebrmbajn\u00eb regjistrat p\u00ebr k\u00ebt\u00eb particion.<\/li>\n<\/ul>\n<p>\nDuke p\u00ebrdor ZooKeepers p\u00ebr koordinim, Kafka p\u00ebrpiqet t\u00eb b\u00ebj\u00eb nj\u00eb shp\u00ebrndarje t\u00eb drejt\u00eb t\u00eb pjes\u00ebve t\u00eb reja midis broker\u00ebve n\u00eb kluster. Kjo realizohet nga nj\u00eb instanc\u00eb q\u00eb vepron si Kontrolluesi.<\/p>\n<p>n\u00eb koh\u00ebn e ekzekutimit <i>p\u00ebr \u00e7do pjes\u00eb t\u00eb tem\u00ebs<\/i> <i>Kontrolluesi <\/i>i cakton broker\u00ebve rolet <i>lider <\/i>(lider, master, i pari) dhe <i>ndjek\u00ebsve <\/i>(ndjek\u00ebs, skllev\u00ebr, t\u00eb n\u00ebnshtruar). Brokeri q\u00eb vepron si lider p\u00ebr k\u00ebt\u00eb pjes\u00eb \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr pranimin e t\u00eb gjitha mesazheve q\u00eb i d\u00ebrgojn\u00eb producent\u00ebt dhe shp\u00ebrndarjen e mesazheve te konsumator\u00ebt. Kur d\u00ebrgohen mesazhe n\u00eb pjes\u00ebn e tem\u00ebs, ato replicohen n\u00eb t\u00eb gjitha nyjat e brokerit q\u00eb veprojn\u00eb si ndjek\u00ebs p\u00ebr k\u00ebt\u00eb pjes\u00eb. \u00c7do nyje q\u00eb p\u00ebrmban regjistrat p\u00ebr pjes\u00ebn e tem\u00ebs quhet <i>replik\u00eb<\/i>. Brokeri mund t\u00eb veproj\u00eb si lider p\u00ebr disa pjes\u00eb dhe si ndjek\u00ebs p\u00ebr t\u00eb tjera.<\/p>\n<p>Ndjek\u00ebsi q\u00eb p\u00ebrmban t\u00eb gjitha mesazhet e ruajtura te lideri quhet <i>replik\u00eb e sinkronizuar<\/i> (replica e synchronizuar, in-sync replica). N\u00ebse brokeri q\u00eb vepron si lider p\u00ebr nj\u00eb partition ndalon s\u00eb funksionuari, cdo broker q\u00eb \u00ebsht\u00eb n\u00eb gjendje aktuale ose e synchronizuar p\u00ebr k\u00ebt\u00eb partition mund t\u00eb marr\u00eb rolin e liderit. Kjo \u00ebsht\u00eb nj\u00eb dizajn jasht\u00ebzakonisht i q\u00ebndruesh\u00ebm.<\/p>\n<p>Nj\u00eb pjes\u00eb e konfigurimit t\u00eb prodhuesit \u00ebsht\u00eb parametri <i>acks<\/i>, i cili p\u00ebrcakton se sa replika duhet t\u00eb konfirmojn\u00eb (acknowledge) marrjen e mesazhit para se fluksi i aplikacionit t\u00eb vazhdoj\u00eb d\u00ebrgimin: 0, 1 ose t\u00eb gjitha. N\u00ebse cakttohet vlera <i>all<\/i>, kur t\u00eb marr\u00eb mesazhin lideri do t\u00eb d\u00ebrgoj\u00eb nj\u00eb konfirmim (confirmation) p\u00ebrs\u00ebri tek prodhuesi, sapo t\u00eb marr\u00eb konfirmimin (acknowledgements) e regjistrimit nga disa replika (p\u00ebrfshir\u00eb veten), t\u00eb p\u00ebrcaktuara nga konfigurimi i tem\u00ebs <i>min.insync.replicas<\/i> (me parametrin e paracaktuar 1). N\u00ebse mesazhi nuk mund t\u00eb replicohet me sukses, at\u00ebher\u00eb prodhuesi do t\u00eb th\u00ebrras\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 tem\u00eb me nj\u00eb faktor replikimi 3 (1 lider, 2 ndjek\u00ebs p\u00ebr \u00e7do partition) dhe parametri <i>min.insync.replicas<\/i> vendoset n\u00eb vler\u00ebn 2. N\u00eb k\u00ebt\u00eb rast, klust\u00ebri do t\u00eb lejoj\u00eb q\u00eb nj\u00eb nga broker\u00ebt q\u00eb menaxhon ndarjen e tem\u00ebs t\u00eb shky\u00e7et pa ndikuar n\u00eb aplikacionet klient.<\/p>\n<p>Kjo na rikthen tek kompromisi i njohur midis performanc\u00ebs dhe besueshm\u00ebris\u00eb. Replikimi ndodh p\u00ebrmes koh\u00ebs shtes\u00eb t\u00eb pritjes p\u00ebr konfirmime (acknowledgments) nga ndjek\u00ebsit. Megjithat\u00eb, pasi q\u00eb kryhet paralelisht, replikimi, p\u00ebr t\u00eb pakt\u00ebn tri nyje, ka t\u00eb nj\u00ebjt\u00ebn performanc\u00eb si p\u00ebr dy (duke injoruar rritjen e p\u00ebrdorimit t\u00eb kapacitetit t\u00eb rrjetit).<\/p>\n<p>Duke p\u00ebrdorur k\u00ebt\u00eb skem\u00eb replikimi, Kafka siguron me mjeshtri shmangien e nevoj\u00ebs p\u00ebr t\u00eb siguruar regjistrimin fizik t\u00eb \u00e7do mesazhi n\u00eb disk p\u00ebrmes operacionit <i>sync ()<\/i>. \u00c7do mesazh i d\u00ebrguar nga prodhuesi do t\u00eb regjistrohet n\u00eb ditarin e particioneve, por, si\u00e7 u diskutua n\u00eb Kapitullin 2, regjistrimi n\u00eb skedarin fillimisht b\u00ebhet n\u00eb buferin e sistemit operativ. N\u00ebse ky mesazh \u00ebsht\u00eb replikuar n\u00eb nj\u00eb instanc\u00eb tjet\u00ebr t\u00eb Kafka dhe ndodhet n\u00eb memorjen e saj, humbja e liderit nuk do t\u00eb thot\u00eb q\u00eb vet\u00eb mesazhi \u00ebsht\u00eb humbur \u2014 ai mund t\u00eb merret nga nj\u00eb replik\u00eb e sinkronizuar.<br \/>\nHeqja e nevoj\u00ebs p\u00ebr t\u00eb kryer operacionin <i>sync ()<\/i> do t\u00eb thot\u00eb q\u00eb Kafka mund t\u00eb pranoj\u00eb mesazhe me ritmin me t\u00eb cilin mund t'i regjistroj\u00eb ato n\u00eb memorje. Dhe anasjelltas, sa m\u00eb gjat\u00eb t\u00eb shmanget shkarkimi (flushing) i memorjes n\u00eb disk, aq m\u00eb mir\u00eb. P\u00ebr k\u00ebt\u00eb arsye, nuk jan\u00eb t\u00eb rralla rastet kur broker\u00ebve t\u00eb Kafka u jepet 64 GB memorje ose m\u00eb shum\u00eb. Kjo p\u00ebrdorim i memorjes do t\u00eb thot\u00eb q\u00eb nj\u00eb instanc\u00eb e vetme e Kafka mund t\u00eb punoj\u00eb leht\u00ebsisht me shpejt\u00ebsi shum\u00eb mij\u00ebra her\u00eb m\u00eb t\u00eb shpejt\u00eb se nj\u00eb broker mesazhesh tradicional.<\/p>\n<p>Kafka gjithashtu mund t\u00eb konfigurohet p\u00ebr t\u00eb aplikuar operacionin <i>sync ()<\/i> n\u00eb paketat e mesazheve. Duke qen\u00eb se gjith\u00e7ka n\u00eb Kafka \u00ebsht\u00eb orientuar drejt pun\u00ebs me paketa, kjo n\u00eb t\u00eb v\u00ebrtet\u00eb 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 garantime shum\u00eb t\u00eb forta. Pjesa m\u00eb e madhe e performanc\u00ebs s\u00eb past\u00ebr t\u00eb Kafka \u00ebsht\u00eb e lidhur me mesazhet q\u00eb d\u00ebrgohen te brokeri n\u00eb form\u00eb paketash, dhe me faktin se k\u00ebto mesazhe lexohen nga brokeri n\u00eb blloqe t\u00eb nj\u00ebpasnj\u00ebshme me <noindex><a rel=\"nofollow\" href=\"http:\/\/www.linuxjournal.com\/article\/6345\">zero-copy<\/a><\/noindex> operacionet (operacione n\u00eb t\u00eb cilat nuk kryhet detyra e kopjimit t\u00eb t\u00eb dh\u00ebnave nga nj\u00eb zon\u00eb memorjeje n\u00eb nj\u00eb tjet\u00ebr). E fundit \u00ebsht\u00eb nj\u00eb fitim i madh p\u00ebr sa i p\u00ebrket performanc\u00ebs dhe burimeve dhe \u00ebsht\u00eb e mundur vet\u00ebm fal\u00eb p\u00ebrdorimit t\u00eb struktur\u00ebs s\u00eb dh\u00ebnash t\u00eb bazuar n\u00eb nj\u00eb regjist\u00ebr, q\u00eb p\u00ebrcakton skem\u00ebn e parti\u00e7ionit.<\/p>\n<p>N\u00eb klasterin Kafka, \u00ebsht\u00eb e mundur nj\u00eb performanc\u00eb shum\u00eb m\u00eb e lart\u00eb sesa duke p\u00ebrdorur nj\u00eb broker t\u00eb vet\u00ebm Kafka, pasi partit\u00eb e tem\u00ebs mund t\u00eb shkall\u00ebzohen horizontalisht n\u00eb shum\u00eb makina t\u00eb ve\u00e7anta.<\/p>\n<h2>P\u00ebrfundimet<\/h2>\n<p>\nN\u00eb k\u00ebt\u00eb kapitull ne shqyrtuam se si arkitektura e Kafka-rip\u00ebrcakton marr\u00ebdh\u00ebniet midis klient\u00ebve dhe broker\u00ebve p\u00ebr t\u00eb siguruar nj\u00eb sistem t\u00eb besuesh\u00ebm t\u00eb nd\u00ebrrimit t\u00eb mesazheve, me nj\u00eb kapacitet shum\u00eb her\u00eb m\u00eb t\u00eb madh se ai i nj\u00eb brokeri mesazhesh t\u00eb zakonsh\u00ebm. Diskutuam funksionalitetin q\u00eb ajo p\u00ebrdor p\u00ebr t\u00eb arritur k\u00ebt\u00eb q\u00ebllim dhe p\u00ebrshkruam m\u00eb shkurt arkitektur\u00ebn e aplikacioneve q\u00eb ofrojn\u00eb k\u00ebt\u00eb funksionalitet. N\u00eb kapitullin e ardhsh\u00ebm do shqyrtojm\u00eb problemet e zakonshme q\u00eb aplikacionet e bazuara n\u00eb nd\u00ebrrimin e mesazheve duhet t\u00eb trajtojn\u00eb dhe do diskutojm\u00eb strategjit\u00eb p\u00ebr zgjidhjen e tyre. Ne do ta mbyllim kapitullin duke p\u00ebrshkruar se si t\u00eb reflektojm\u00eb p\u00ebr teknologjit\u00eb e nd\u00ebrrimit t\u00eb mesazheve n\u00eb p\u00ebrgjith\u00ebsi, q\u00eb ju t\u00eb mund 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 nd\u00ebrrimit t\u00eb mesazheve p\u00ebrmes ActiveMQ dhe Kafka. Kapitulli 1<\/a><\/noindex><\/p>\n<p><b> P\u00ebrkthimi \u00ebsht\u00eb realizuar nga: <noindex><a rel=\"nofollow\" href=\"http:\/\/tele.gg\/middle_java\">tele.gg\/middle_java<\/a><\/noindex><\/b><\/p>\n<p><i>Vazhdohet...<\/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 lutemi.<\/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>                    E p\u00ebrdornim m\u00eb par\u00eb, tani jo<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Kemi planifikuar ta p\u00ebrdorim<\/p>\n<\/li>\n<\/ul>\n<p>    38 p\u00ebrdorues e votuan. 8 p\u00ebrdorues u p\u00ebrmbajt\u00ebn.<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 4.9.10 - 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 \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\" \/>\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) 4.9.10\" \/>\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 \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\" \/>\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 borker\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 nj\u00eb libri t\u00eb vog\u00ebl: \u00abKuptimi i Borker\u00ebve t\u00eb Mesazheve\u00bb, autor: Jakub Korab, botuesi: O'Reilly Media, Inc., data e botimit: Qershor 2017, ISBN: 9781492049296. Pjesa e m\u00ebparshme e p\u00ebrkthyer: Kuptimi i borker\u00ebve t\u00eb mesazheve. Studimi i mekanik\u00ebs s\u00eb shk\u00ebmbimit t\u00eb mesazheve p\u00ebrmes ActiveMQ dhe Kafka. Kapitulli 1. Hyrje KAPITULLI 3 Kafka Kafka u zhvillua n\u00eb LinkedIn p\u00ebr t\u00eb shmangur disa kufizime t\u00eb borker\u00ebve tradicional\u00eb t\u00eb mesazheve dhe","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 \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","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"},"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}]}}