{"id":52541,"date":"2019-11-11T00:00:00","date_gmt":"2019-11-10T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost"},"modified":"2020-02-18T14:00:17","modified_gmt":"2020-02-18T11:00:17","slug":"rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","title":{"rendered":"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/6557ce69c2b3070622feca8b3c228b09.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/471858\/\">artikullin e kaluar<\/a><\/noindex> Kemi shqyrtuar klasterizimin e RabbitMQ p\u00ebr t\u00eb siguruar toleranc\u00eb ndaj d\u00ebshtimeve dhe disponueshm\u00ebri t\u00eb lart\u00eb. Tani do t\u00eb hyjm\u00eb m\u00eb thell\u00eb n\u00eb Apache Kafka.<\/p>\n<p>K\u00ebtu nj\u00ebsia e replikimit \u00ebsht\u00eb particioni (partition). \u00c7do topic ka nj\u00eb ose m\u00eb shum\u00eb particione. N\u00eb \u00e7do partition ka nj\u00eb lider, me ose pa followers. Gjat\u00eb krijimit t\u00eb topic p\u00ebrcaktohen numri i particioneve dhe faktori i replikimit. Vlera tipike \u00ebsht\u00eb 3, q\u00eb do t\u00eb thot\u00eb tre replika: nj\u00eb lider dhe dy followers.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/36deb6d506223c2ee2ec147d5c215789.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 1. Kat\u00ebr particione jan\u00eb shp\u00ebrndar\u00eb midis tre broker\u00ebve<\/i><\/p>\n<p>T\u00eb gjitha k\u00ebrkesat p\u00ebr lexim dhe shkrim i d\u00ebrgohen liderit. Followers i d\u00ebrgojn\u00eb periodikisht liderit k\u00ebrkesa p\u00ebr t\u00eb marr\u00eb mesazhet m\u00eb t\u00eb fundit. Konsumator\u00ebt nuk i drejtohen kurr\u00eb followers; k\u00ebta t\u00eb fundit ekzistojn\u00eb vet\u00ebm p\u00ebr tepric\u00eb dhe toleranc\u00eb ndaj d\u00ebshtimeve.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/715c51d75cb45863cfad4b37e81b9a9a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>D\u00ebshtimi i partition<\/h1>\n<p>\nKur nj\u00eb broker bie, shpesh dalin jasht\u00eb funksioni lider\u00ebt e disa particioneve. N\u00eb secilin prej tyre, lider b\u00ebhet nj\u00eb follower nga nj\u00eb nyje tjet\u00ebr. N\u00eb praktik\u00eb, kjo nuk ndodh gjithmon\u00eb k\u00ebshtu, sepse ndikon edhe faktori i sinkronizimit: a ka followers t\u00eb sinkronizuar dhe, n\u00ebse jo, a lejohet kalimi te nj\u00eb replik\u00eb e pasinkronizuar. Por p\u00ebr momentin t\u00eb mos e komplikojm\u00eb.<\/p>\n<p>Brokeri 3 del nga rrjeti dhe p\u00ebr partition 2 zgjidhet nj\u00eb lider i ri n\u00eb brokerin 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/b8cfce64cf6b848b0659de023f9d9b63.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 2. Brokeri 3 bie dhe follower-i i tij n\u00eb brokerin 2 zgjidhet lideri i ri i partition 2<\/i><\/p>\n<p>M\u00eb pas bie edhe brokeri 1 dhe partition 1 humbet gjithashtu liderin e vet, roli i t\u00eb cilit kalon te brokeri 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/9f5409c723da7ff059b93f9b23e7d5f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 3. Ka mbetur vet\u00ebm nj\u00eb broker. T\u00eb gjith\u00eb lider\u00ebt ndodhen n\u00eb nj\u00eb broker me tepric\u00eb zero<\/i><\/p>\n<p>Kur brokeri 1 rikthehet n\u00eb rrjet, ai shton kat\u00ebr followers, duke siguruar nj\u00ebfar\u00eb teprice p\u00ebr \u00e7do partition. Por t\u00eb gjith\u00eb lider\u00ebt mbeten ende n\u00eb brokerin 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/f9c8e42f51258b7fd7f6f35dc7b8cc3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 4. Lider\u00ebt mbeten n\u00eb brokerin 2<\/i><\/p>\n<p>Kur ngrihet brokeri 3, kthehemi te tre replika p\u00ebr partition. Por t\u00eb gjith\u00eb lider\u00ebt mbeten ende n\u00eb brokerin 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/9c8c02be4161f8468b5dbc1e3f6ecb3a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 5. Vendosje e pabalancuar e lider\u00ebve pas rikthimit t\u00eb broker\u00ebve 1 dhe 3<\/i><\/p>\n<p>Kafka ka nj\u00eb mjet p\u00ebr ribalancim t\u00eb lider\u00ebve m\u00eb cil\u00ebsor se RabbitMQ. Atje duhej p\u00ebrdorur nj\u00eb plugin ose script i pal\u00ebs s\u00eb tret\u00eb, i cili ndryshonte politikat p\u00ebr t\u00eb migruar nyjen kryesore duke ulur tepric\u00ebn gjat\u00eb migrimit. P\u00ebr m\u00eb tep\u00ebr, p\u00ebr radh\u00eb t\u00eb m\u00ebdha duhej pranuar edhe mosdisponueshm\u00ebria gjat\u00eb sinkronizimit.<\/p>\n<p>Kafka ka konceptin e \u00abreplikave t\u00eb preferuara\u00bb p\u00ebr rolin e liderit. Kur krijohen particionet e nj\u00eb topic-u, Kafka p\u00ebrpiqet t\u2019i shp\u00ebrndaj\u00eb lider\u00ebt n\u00eb m\u00ebnyr\u00eb t\u00eb barabart\u00eb n\u00ebp\u00ebr nyje dhe i sh\u00ebnon k\u00ebta lider\u00eb fillestar\u00eb si t\u00eb preferuar. Me kalimin e koh\u00ebs, p\u00ebr shkak t\u00eb rinisjeve t\u00eb server\u00ebve, d\u00ebshtimeve dhe problemeve t\u00eb lidhjes, lider\u00ebt mund t\u00eb p\u00ebrfundojn\u00eb n\u00eb nyje t\u00eb tjera, si n\u00eb rastin ekstrem t\u00eb p\u00ebrshkruar m\u00eb sip\u00ebr.<\/p>\n<p>P\u00ebr ta korrigjuar k\u00ebt\u00eb, Kafka ofron dy mund\u00ebsi:<\/p>\n<ul>\n<li>Opcioni <i>auto.leader.rebalance.enable=true<\/i> i lejon nyjes kontrolluese t\u00eb ricaktoj\u00eb automatikisht lider\u00ebt te replikat e preferuara dhe k\u00ebshtu t\u00eb rikthej\u00eb shp\u00ebrndarjen e barabart\u00eb.\n<\/li>\n<li>Administratori mund t\u00eb ekzekutoj\u00eb skriptin <i>kafka-preferred-replica-election.sh<\/i> p\u00ebr ricaktim manual.<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/831930b06809637018fecb6d7d5a558d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 6. Replikat pas ribalancimit<\/i><\/p>\n<p>Ky ishte nj\u00eb version i thjeshtuar i nj\u00eb d\u00ebshtimi, por realiteti \u00ebsht\u00eb m\u00eb kompleks, megjith\u00ebse k\u00ebtu nuk ka asgj\u00eb tep\u00ebr t\u00eb v\u00ebshtir\u00eb. Gjith\u00e7ka reduktohet te replikat e sinkronizuara (In-Sync Replicas, ISR).<\/p>\n<h1>Replikat e sinkronizuara (ISR)<\/h1>\n<p>\nISR \u00ebsht\u00eb grupi i replikave t\u00eb nj\u00eb particioni q\u00eb konsiderohet \u00abi sinkronizuar\u00bb (in-sync). K\u00ebtu ka nj\u00eb lider, nd\u00ebrsa followers mund t\u00eb mungojn\u00eb. Nj\u00eb follower konsiderohet i sinkronizuar n\u00ebse ka b\u00ebr\u00eb kopje t\u00eb sakta t\u00eb t\u00eb gjitha mesazheve t\u00eb liderit para skadimit t\u00eb intervalit <i>replica.lag.time.max.ms<\/i>.<\/p>\n<p>Nj\u00eb follower hiqet nga grupi ISR n\u00ebse:<\/p>\n<ul>\n<li>nuk ka b\u00ebr\u00eb nj\u00eb k\u00ebrkes\u00eb fetch brenda intervalit <i>replica.lag.time.max.ms<\/i> (konsiderohet i vdekur)\n<\/li>\n<li>nuk ka arritur t\u00eb p\u00ebrdit\u00ebsohet brenda intervalit <i>replica.lag.time.max.ms<\/i> (konsiderohet i ngadalt\u00eb)<\/li>\n<\/ul>\n<p>\nFollowers b\u00ebjn\u00eb k\u00ebrkesa fetch n\u00eb intervalin <i>replica.fetch.wait.max.ms<\/i>, i cili si parazgjedhje \u00ebsht\u00eb 500 ms.<\/p>\n<p>P\u00ebr t\u00eb shpjeguar qart\u00eb q\u00ebllimin e ISR, duhet t\u00eb shohim konfirmimet nga producer dhe disa skenar\u00eb d\u00ebshtimi. Producers mund t\u00eb zgjedhin kur broker d\u00ebrgon konfirmimin:<\/p>\n<ul>\n<li>acks=0, konfirmimi nuk d\u00ebrgohet\n<\/li>\n<li>acks=1, konfirmimi d\u00ebrgohet pasi lideri e ka shkruar mesazhin n\u00eb log-un e tij lokal\n<\/li>\n<li>acks=all, konfirmimi d\u00ebrgohet pasi t\u00eb gjitha replikat n\u00eb ISR e kan\u00eb shkruar mesazhin n\u00eb log-et lokale<\/li>\n<\/ul>\n<p>\nN\u00eb terminologjin\u00eb e Kafka-s, n\u00ebse ISR ruan nj\u00eb mesazh, ndodh \"komitimi\" i tij. Acks=all \u00ebsht\u00eb opsioni m\u00eb i sigurt, por ka edhe nj\u00eb vones\u00eb shtes\u00eb. Le t\u00eb shqyrtojm\u00eb dy shembuj d\u00ebshtimi dhe si opsione t\u00eb ndryshme 'acks' nd\u00ebrveprojn\u00eb me konceptin e ISR.<\/p>\n<h3>Acks=1 dhe ISR<\/h3>\n<p>\nN\u00eb k\u00ebt\u00eb shembull do t\u00eb shohim se, n\u00ebse lideri nuk pret ruajtjen e \u00e7do mesazhi nga t\u00eb gjith\u00eb followers, n\u00eb rast t\u00eb d\u00ebshtimit t\u00eb liderit mund t\u00eb ndodh\u00eb humbje e t\u00eb dh\u00ebnave. Kalimi te nj\u00eb follower i pasinkronizuar mund t\u00eb lejohet ose t\u00eb ndalohet nga konfigurimi <i>unclean.leader.election.enable<\/i>.<\/p>\n<p>N\u00eb k\u00ebt\u00eb shembull, te producer \u00ebsht\u00eb vendosur vlera acks=1. Particioni \u00ebsht\u00eb shp\u00ebrndar\u00eb n\u00eb t\u00eb tre broker\u00ebt. Brokeri 3 ka mbetur prapa; ai u sinkronizua me liderin tet\u00eb sekonda m\u00eb par\u00eb dhe tani ka vones\u00eb prej 7456 mesazhesh. Brokeri 1 ka mbetur prapa vet\u00ebm me nj\u00eb sekond\u00eb. Producer-i yn\u00eb d\u00ebrgon mesazhin dhe merr shpejt ack mbrapsht, pa overhead nga followers t\u00eb ngadalt\u00eb ose t\u00eb d\u00ebshtuar, t\u00eb cil\u00ebt lideri nuk i pret.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/f194e6309b732b772574392eff482a8b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 7. ISR me tre replika<\/i><\/p>\n<p>Brokeri 2 del jasht\u00eb funksionit dhe producer merr nj\u00eb gabim lidhjeje. Pas kalimit t\u00eb lidershipit te brokeri 1, humbasim 123 mesazhe. Follower n\u00eb brokerin 1 ishte pjes\u00eb e ISR, por nuk ishte sinkronizuar plot\u00ebsisht me liderin kur ai ra.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/367f219daebafefe585059f67fdedf6f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 8. Gjat\u00eb d\u00ebshtimit humben mesazhe<\/i><\/p>\n<p>N\u00eb konfigurimin <i>bootstrap.servers<\/i> te producer jan\u00eb listuar disa broker\u00eb, dhe ai mund t\u00eb pyes\u00eb nj\u00eb broker tjet\u00ebr se kush \u00ebsht\u00eb b\u00ebr\u00eb lideri i ri i particionit. M\u00eb pas ai krijon lidhje me brokerin 1 dhe vazhdon t\u00eb d\u00ebrgoj\u00eb mesazhe.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/ba45c51f4ce1f63f10b2fa0e1487b223.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 9. D\u00ebrgimi i mesazheve rifillon pas nj\u00eb nd\u00ebrprerjeje t\u00eb shkurt\u00ebr<\/i><\/p>\n<p>Brokeri 3 mbetet edhe m\u00eb shum\u00eb prapa. Ai b\u00ebn k\u00ebrkesa fetch, por nuk mund t\u00eb sinkronizohet. Kjo mund t\u00eb lidhet me nj\u00eb lidhje t\u00eb ngadalt\u00eb rrjeti midis broker\u00ebve, nj\u00eb problem me storage etj. Ai hiqet nga ISR. Tani ISR p\u00ebrb\u00ebhet nga nj\u00eb replik\u00eb t\u00eb vetme \u2014 lideri! Producer vazhdon t\u00eb d\u00ebrgoj\u00eb mesazhe dhe t\u00eb marr\u00eb konfirmime.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/592c74632e3a8d80c2b4fc15bde5d401.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 10. Follower n\u00eb brokerin 3 hiqet nga ISR<\/i><\/p>\n<p>Brokeri 1 bie dhe roli i liderit kalon te brokeri 3 me humbjen e 15286 mesazheve! Producer merr nj\u00eb mesazh p\u00ebr gabim lidhjeje. Kalimi te nj\u00eb lider jasht\u00eb ISR ishte i mundur vet\u00ebm p\u00ebr shkak t\u00eb konfigurimit <i>unclean.leader.election.enable=true<\/i>. N\u00ebse do t\u00eb ishte vendosur n\u00eb <i>false<\/i>, at\u00ebher\u00eb kalimi nuk do t\u00eb ndodhte dhe t\u00eb gjitha k\u00ebrkesat p\u00ebr lexim dhe shkrim do t\u00eb refuzoheshin. N\u00eb k\u00ebt\u00eb rast presim rikthimin e brokerit 1 me t\u00eb dh\u00ebnat e tij t\u00eb paprekura n\u00eb replik\u00eb, e cila do t\u00eb marr\u00eb s\u00ebrish rolin e liderit.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/30f01ca715ccc194890ae061a3ef7396.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 11. Brokeri 1 bie. Gjat\u00eb d\u00ebshtimit humbet nj\u00eb sasi e madhe mesazhesh<\/i><\/p>\n<p>Prodhuesi krijon lidhje me brokerin e fundit dhe sheh q\u00eb ai tani \u00ebsht\u00eb lideri i particionit. Ai fillon t\u2019i d\u00ebrgoj\u00eb mesazhe brokerit 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/986532d9b22b6514b6039c8460b1beb4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 12. Pas nj\u00eb nd\u00ebrprerjeje t\u00eb shkurt\u00ebr, mesazhet d\u00ebrgohen s\u00ebrish n\u00eb particionin 0<\/i><\/p>\n<p>Pam\u00eb q\u00eb, p\u00ebrve\u00e7 nd\u00ebrprerjeve t\u00eb shkurtra p\u00ebr krijimin e lidhjeve t\u00eb reja dhe gjetjen e liderit t\u00eb ri, prodhuesi vazhdimisht d\u00ebrgonte mesazhe. Nj\u00eb konfigurim i till\u00eb siguron disponueshm\u00ebri n\u00eb kurriz t\u00eb konsistenc\u00ebs (siguris\u00eb s\u00eb t\u00eb dh\u00ebnave). Kafka humbi mij\u00ebra mesazhe, por vazhdoi t\u00eb pranonte regjistrime t\u00eb reja.<\/p>\n<h3>Acks=all dhe ISR<\/h3>\n<p>\nLe ta p\u00ebrs\u00ebrisim k\u00ebt\u00eb skenar edhe nj\u00eb her\u00eb, por me <i>acks=all<\/i>. Vonesa e brokerit 3 \u00ebsht\u00eb mesatarisht kat\u00ebr sekonda. Prodhuesi d\u00ebrgon nj\u00eb mesazh me <i>acks=all<\/i>, dhe tani nuk merr nj\u00eb p\u00ebrgjigje t\u00eb shpejt\u00eb. Lideri pret derisa mesazhi t\u00eb ruhet nga t\u00eb gjitha replikat n\u00eb ISR.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/95b1abdc92e699f7bc41ebab249a2e08.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 13. ISR me tre replika. Nj\u00ebra punon ngadal\u00eb, gj\u00eb q\u00eb sjell vones\u00eb n\u00eb shkrim<\/i><\/p>\n<p>Pas kat\u00ebr sekondash vones\u00eb shtes\u00eb, brokeri 2 d\u00ebrgon ack. Tani t\u00eb gjitha replikat jan\u00eb plot\u00ebsisht t\u00eb p\u00ebrdit\u00ebsuara.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/64356dc8d2641a3e22947126dd047f39.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 14. T\u00eb gjitha replikat i ruajn\u00eb mesazhet dhe d\u00ebrgohet ack<\/i><\/p>\n<p>Brokeri 3 tani mbetet edhe m\u00eb shum\u00eb pas dhe hiqet nga ISR. Vonesa ulet ndjesh\u00ebm, sepse n\u00eb ISR nuk kan\u00eb mbetur replika t\u00eb ngadalta. Brokeri 2 tani pret vet\u00ebm brokerin 1, dhe ai ka nj\u00eb lag mesatar prej 500 ms.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/5d3bd67dc53cb868fa40b358ed483a1d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 15. Replika n\u00eb brokerin 3 hiqet nga ISR<\/i><\/p>\n<p>M\u00eb pas bie brokeri 2 dhe lidershipi kalon te brokeri 1 pa humbje mesazhesh.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/e3f0417aa7714ea5eae8a8e8d61662bd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 16. Brokeri 2 bie<\/i><\/p>\n<p>Prodhuesi gjen liderin e ri dhe fillon t\u2019i d\u00ebrgoj\u00eb atij mesazhe. Vonesa ulet edhe m\u00eb shum\u00eb, sepse tani ISR p\u00ebrb\u00ebhet nga nj\u00eb replik\u00eb e vetme! Prandaj opsioni <i>acks=all<\/i> nuk shton tepric\u00eb.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/fec9aae9977757d5f61c2909ceae0536.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 17. Replika n\u00eb brokerin 1 merr lidershipin pa humbje mesazhesh<\/i><\/p>\n<p>M\u00eb pas bie brokeri 1 dhe lidershipi kalon te brokeri 3 me humbjen e 14238 mesazheve!<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/730b3951fb75ab3a782fc6d064615212.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 18. Brokeri 1 ndalet, nd\u00ebrsa kalimi i lidershipit me cil\u00ebsimin unclean \u00e7on n\u00eb humbje t\u00eb m\u00ebdha t\u00eb t\u00eb dh\u00ebnave<\/i><\/p>\n<p>Mund t\u00eb mos e vendosnim opsionin <i>unclean.leader.election.enable<\/i> n\u00eb vler\u00ebn <i>true<\/i>. Si parazgjedhje, ai \u00ebsht\u00eb <i>false<\/i>. Cil\u00ebsimi <i>acks=all<\/i> me <i>unclean.leader.election.enable=true<\/i> siguron disponueshm\u00ebri me nj\u00eb nivel shtes\u00eb t\u00eb siguris\u00eb s\u00eb t\u00eb dh\u00ebnave. Por, si\u00e7 e shihni, prap\u00eb mund t\u00eb humbasim mesazhe.<\/p>\n<p>Po sikur t\u00eb duam t\u00eb rrisim sigurin\u00eb e t\u00eb dh\u00ebnave? Mund t\u00eb vendosim <i>unclean.leader.election.enable = false<\/i>, por kjo nuk do t\u00eb na mbroj\u00eb domosdoshm\u00ebrisht nga humbja e t\u00eb dh\u00ebnave. N\u00ebse lideri rr\u00ebzohet r\u00ebnd\u00eb dhe humbet edhe t\u00eb dh\u00ebnat me vete, at\u00ebher\u00eb mesazhet gjithsesi humbasin, nd\u00ebrsa disponueshm\u00ebria humbet derisa administratori t\u00eb rikthej\u00eb situat\u00ebn.<\/p>\n<p>\u00cbsht\u00eb m\u00eb mir\u00eb t\u00eb garantohet teprica e t\u00eb gjitha mesazheve, p\u00ebrndryshe t\u00eb refuzohet shkrimi. At\u00ebher\u00eb, t\u00eb pakt\u00ebn nga k\u00ebndv\u00ebshtrimi i broker-it, humbja e t\u00eb dh\u00ebnave b\u00ebhet e mundur vet\u00ebm n\u00eb rast t\u00eb dy ose m\u00eb shum\u00eb d\u00ebshtimeve t\u00eb nj\u00ebkohshme.<\/p>\n<h3>Acks=all, min.insync.replicas dhe ISR<\/h3>\n<p>\nMe konfigurimin e topic-ut <i>min.insync.replicas<\/i> ne e rrisim nivelin e siguris\u00eb s\u00eb t\u00eb dh\u00ebnave. Le ta kalojm\u00eb edhe nj\u00eb her\u00eb pjes\u00ebn e fundit t\u00eb skenarit t\u00eb m\u00ebparsh\u00ebm, por k\u00ebt\u00eb her\u00eb me <i>min.insync.replicas=2<\/i>.<\/p>\n<p>Pra, te broker 2 ndodhet replika lider, nd\u00ebrsa follower-i n\u00eb broker 3 \u00ebsht\u00eb hequr nga ISR.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/5831463293f1837d3232756894e97162.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 19. ISR me dy replika<\/i><\/p>\n<p>Broker 2 rr\u00ebzohet dhe lidershipi kalon te broker 1 pa humbje mesazhesh. Por tani ISR p\u00ebrb\u00ebhet vet\u00ebm nga nj\u00eb replik\u00eb. Kjo nuk p\u00ebrputhet me numrin minimal t\u00eb k\u00ebrkuar p\u00ebr t\u00eb pranuar shkrime, ndaj broker-i i p\u00ebrgjigjet p\u00ebrpjekjes s\u00eb shkrimit me gabimin <i>NotEnoughReplicas<\/i>.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/6b2ee477f4c33ec84f3068b792814e5d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 20. Numri i ISR \u00ebsht\u00eb nj\u00eb m\u00eb i ul\u00ebt se ai i p\u00ebrcaktuar n\u00eb min.insync.replicas<\/i><\/p>\n<p>Ky konfigurim sakrifikon disponueshm\u00ebrin\u00eb n\u00eb favor t\u00eb konsistenc\u00ebs. Para se t\u00eb konfirmojm\u00eb mesazhin, ne garantojm\u00eb q\u00eb ai t\u00eb shkruhet t\u00eb pakt\u00ebn n\u00eb dy replika. Kjo i jep producer-it shum\u00eb m\u00eb tep\u00ebr siguri. K\u00ebtu humbja e mesazheve \u00ebsht\u00eb e mundur vet\u00ebm n\u00eb rast t\u00eb d\u00ebshtimit t\u00eb nj\u00ebkohsh\u00ebm t\u00eb dy replikave brenda nj\u00eb intervali t\u00eb shkurt\u00ebr, p\u00ebrpara se mesazhi t\u00eb replikohet te nj\u00eb follower shtes\u00eb, gj\u00eb q\u00eb ka pak gjasa t\u00eb ndodh\u00eb. Por n\u00ebse jeni superparanojak, mund ta vendosni faktorin e replikimit n\u00eb 5, nd\u00ebrsa <i>min.insync.replicas<\/i> n\u00eb 3. N\u00eb k\u00ebt\u00eb rast, duhen t\u00eb rr\u00ebzohen menj\u00ebher\u00eb tre broker-a nj\u00ebkoh\u00ebsisht q\u00eb t\u00eb humbet nj\u00eb shkrim! Natyrisht, p\u00ebr nj\u00eb besueshm\u00ebri t\u00eb till\u00eb do t\u00eb paguani me vones\u00eb shtes\u00eb.<\/p>\n<h1>Kur disponueshm\u00ebria \u00ebsht\u00eb e nevojshme p\u00ebr sigurin\u00eb e t\u00eb dh\u00ebnave<\/h1>\n<p>\nAshtu si n\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/471858\/\">rastin e RabbitMQ<\/a><\/noindex>, ndonj\u00ebher\u00eb disponueshm\u00ebria \u00ebsht\u00eb e nevojshme p\u00ebr sigurin\u00eb e t\u00eb dh\u00ebnave. Duhet t\u00eb mendoni p\u00ebr sa vijon:<\/p>\n<ul>\n<li>A mundet publisher-i thjesht t\u00eb kthej\u00eb nj\u00eb gabim, nd\u00ebrsa sh\u00ebrbimi n\u00eb shtres\u00ebn sip\u00ebr ose p\u00ebrdoruesi t\u00eb provoj\u00eb s\u00ebrish m\u00eb von\u00eb?\n<\/li>\n<li>A mundet publisher-i ta ruaj\u00eb mesazhin lokalisht ose n\u00eb nj\u00eb baz\u00eb t\u00eb dh\u00ebnash, q\u00eb t\u00eb provoj\u00eb s\u00ebrish m\u00eb von\u00eb?<\/li>\n<\/ul>\n<p>\nN\u00ebse p\u00ebrgjigjja \u00ebsht\u00eb negative, at\u00ebher\u00eb optimizimi i disponueshm\u00ebris\u00eb rrit sigurin\u00eb e t\u00eb dh\u00ebnave. Do t\u00eb humbni m\u00eb pak t\u00eb dh\u00ebna n\u00ebse zgjidhni disponueshm\u00ebrin\u00eb n\u00eb vend t\u00eb refuzimit t\u00eb shkrimit. Pra, gjith\u00e7ka varet nga gjetja e ekuilibrit, dhe vendimi varet nga situata konkrete.<\/p>\n<h1>Kuptimi i ISR<\/h1>\n<p>\nMekanizmi ISR ju lejon t\u00eb zgjidhni ekuilibrin optimal midis siguris\u00eb s\u00eb t\u00eb dh\u00ebnave dhe vones\u00ebs. P\u00ebr shembull, t\u00eb siguroni disponueshm\u00ebri n\u00eb rast d\u00ebshtimi t\u00eb shumic\u00ebs s\u00eb replikave, duke minimizuar ndikimin e replikave t\u00eb vdekura ose t\u00eb ngadalta n\u00eb aspektin e vones\u00ebs.<\/p>\n<p>Vler\u00ebn e zgjedhim vet\u00eb <i>replica.lag.time.max.ms<\/i> sipas nevojave tona. N\u00eb thelb, ky paramet\u00ebr tregon se \u00e7far\u00eb vonese jemi t\u00eb gatsh\u00ebm t\u00eb pranojm\u00eb gjat\u00eb <i>acks=all<\/i>. Vlera e paracaktuar \u00ebsht\u00eb dhjet\u00eb sekonda. N\u00ebse kjo \u00ebsht\u00eb shum\u00eb p\u00ebr ju, mund ta ulni. At\u00ebher\u00eb do t\u00eb rritet shpesht\u00ebsia e ndryshimeve n\u00eb ISR, sepse followers do t\u00eb hiqen dhe do t\u00eb shtohen m\u00eb shpesh.<\/p>\n<p>N\u00eb RabbitMQ ekziston thjesht nj\u00eb grup pasqyrash q\u00eb duhen replikuar. Pasqyrat e ngadalta sjellin vones\u00eb shtes\u00eb, nd\u00ebrsa p\u00ebrgjigjja nga pasqyrat e vdekura mund t\u00eb pritet derisa t\u00eb skadoj\u00eb koha e jet\u00ebs s\u00eb paketave q\u00eb kontrollojn\u00eb disponueshm\u00ebrin\u00eb e \u00e7do nyjeje (net tick). ISR \u00ebsht\u00eb nj\u00eb m\u00ebnyr\u00eb interesante p\u00ebr t\u2019i shmangur k\u00ebto probleme pa rritur vones\u00ebn. Megjithat\u00eb, rrezikojm\u00eb t\u00eb humbasim tepric\u00ebn, sepse ISR mund t\u00eb tkurret deri vet\u00ebm te lideri. P\u00ebr t\u00eb shmangur k\u00ebt\u00eb rrezik, p\u00ebrdorni cil\u00ebsimin <i>min.insync.replicas<\/i>.<\/p>\n<h1>Garancia e lidhjes s\u00eb klient\u00ebve<\/h1>\n<p>\nN\u00eb cil\u00ebsimet e <i>bootstrap.servers<\/i> prodhuesit dhe konsumatorit mund t\u00eb specifikohen disa broker\u00eb p\u00ebr lidhjen e klient\u00ebve. Ideja \u00ebsht\u00eb q\u00eb, n\u00ebse nj\u00eb nyje del jasht\u00eb funksionit, t\u00eb mbeten disa opsione rezerv\u00eb me t\u00eb cilat klienti mund t\u00eb hap\u00eb lidhjen. K\u00ebto nuk jan\u00eb domosdoshm\u00ebrisht lider\u00eb t\u00eb partizioneve, por thjesht nj\u00eb pik\u00ebnisje p\u00ebr ngarkimin fillestar. Klienti mund t\u2019i pyes\u00eb se n\u00eb cil\u00ebn nyje ndodhet lideri i partizionit p\u00ebr lexim\/shkrim.<\/p>\n<p>N\u00eb RabbitMQ klient\u00ebt mund t\u00eb lidhen me \u00e7do nyje, nd\u00ebrsa rutimi i brendsh\u00ebm e d\u00ebrgon k\u00ebrkes\u00ebn aty ku duhet. Kjo do t\u00eb thot\u00eb se p\u00ebrpara RabbitMQ mund t\u00eb vendosni nj\u00eb balancues ngarkese. Kafka k\u00ebrkon q\u00eb klient\u00ebt t\u00eb lidhen me nyjen ku ndodhet lideri i partizionit p\u00ebrkat\u00ebs. N\u00eb k\u00ebt\u00eb rast, nuk mund t\u00eb vendoset nj\u00eb balancues ngarkese. Lista <i>bootstrap.servers<\/i> \u00ebsht\u00eb me r\u00ebnd\u00ebsi kritike q\u00eb klient\u00ebt t\u00eb mund t\u2019u drejtohen nyjeve t\u00eb duhura dhe t\u2019i gjejn\u00eb ato pas nj\u00eb d\u00ebshtimi.<\/p>\n<h1>Arkitektura e konsensusit n\u00eb Kafka<\/h1>\n<p>\nDeri tani nuk kemi shqyrtuar se si klasteri e kupton q\u00eb nj\u00eb broker ka r\u00ebn\u00eb dhe si zgjidhet nj\u00eb lider i ri. P\u00ebr t\u00eb kuptuar se si Kafka punon me ndarjet e rrjetit, fillimisht duhet t\u00eb kuptoni arkitektur\u00ebn e konsensusit.<\/p>\n<p>\u00c7do klaster Kafka vendoset s\u00eb bashku me nj\u00eb klaster Zookeeper \u2014 nj\u00eb sh\u00ebrbim i konsensusit t\u00eb shp\u00ebrndar\u00eb q\u00eb i lejon sistemit t\u00eb arrij\u00eb konsensus p\u00ebr nj\u00eb gjendje t\u00eb caktuar, duke i dh\u00ebn\u00eb p\u00ebrpar\u00ebsi konsistenc\u00ebs ndaj disponueshm\u00ebris\u00eb. P\u00ebr t\u00eb miratuar operacionet e leximit dhe shkrimit k\u00ebrkohet p\u00eblqimi i shumic\u00ebs s\u00eb nyjeve Zookeeper.<\/p>\n<p>Zookeeper ruan gjendjen e klasterit:<\/p>\n<ul>\n<li>List\u00ebn e topic-eve, ndarjeve, konfigurimin, replikat aktuale t\u00eb liderit, replikat e preferuara.\n<\/li>\n<li>An\u00ebtar\u00ebt e klasterit. \u00c7do broker d\u00ebrgon ping te klasteri Zookeeper. N\u00ebse ai nuk merr ping brenda nj\u00eb periudhe t\u00eb caktuar kohe, Zookeeper e sh\u00ebnon brokerin si t\u00eb padisponuesh\u00ebm.\n<\/li>\n<li>Zgjedhjen e nyjeve kryesore dhe rezerv\u00eb p\u00ebr kontrolluesin.<\/li>\n<\/ul>\n<p>\nNyja e kontrolluesit \u00ebsht\u00eb nj\u00eb nga broker\u00ebt Kafka q\u00eb p\u00ebrgjigjet p\u00ebr zgjedhjen e lider\u00ebve t\u00eb replikave. Zookeeper i d\u00ebrgon kontrolluesit njoftime p\u00ebr an\u00ebtar\u00ebsin\u00eb n\u00eb klaster dhe ndryshimet e topic-eve, dhe kontrolluesi duhet t\u00eb veproj\u00eb n\u00eb p\u00ebrputhje me k\u00ebto ndryshime.<\/p>\n<p>P\u00ebr shembull, le t\u00eb marrim nj\u00eb topic t\u00eb ri me dhjet\u00eb ndarje dhe koeficient replikimi 3. Kontrolluesi duhet t\u00eb zgjedh\u00eb liderin e secil\u00ebs ndarje, duke u p\u00ebrpjekur t\u2019i shp\u00ebrndaj\u00eb lider\u00ebt n\u00eb m\u00ebnyr\u00eb optimale mes broker\u00ebve. <\/p>\n<p>P\u00ebr \u00e7do ndarje, kontrolluesi:<\/p>\n<ul>\n<li>p\u00ebrdit\u00ebson informacionin n\u00eb Zookeeper p\u00ebr ISR dhe liderin;\n<\/li>\n<li>d\u00ebrgon komand\u00ebn LeaderAndISRCommand te \u00e7do broker q\u00eb mban nj\u00eb replik\u00eb t\u00eb k\u00ebsaj ndarjeje, duke i informuar broker\u00ebt p\u00ebr ISR dhe liderin.<\/li>\n<\/ul>\n<p>\nKur bie brokeri me liderin, Zookeeper i d\u00ebrgon njoftim kontrolluesit dhe ai zgjedh nj\u00eb lider t\u00eb ri. Edhe n\u00eb k\u00ebt\u00eb rast, kontrolluesi fillimisht p\u00ebrdit\u00ebson Zookeeper dhe m\u00eb pas i d\u00ebrgon komand\u00eb secilit broker, duke i njoftuar p\u00ebr ndryshimin e lidershipit.<\/p>\n<p>\u00c7do lider mban p\u00ebrgjegj\u00ebsi p\u00ebr nj\u00eb grup ISR. Konfigurimi <i>replica.lag.time.max.ms<\/i> p\u00ebrcakton se kush do t\u00eb p\u00ebrfshihet aty. Kur ISR ndryshon, lideri i transmeton Zookeeper informacionin e ri.<\/p>\n<p>Zookeeper \u00ebsht\u00eb gjithmon\u00eb i informuar p\u00ebr \u00e7do ndryshim, n\u00eb m\u00ebnyr\u00eb q\u00eb n\u00eb rast d\u00ebshtimi drejtimi t\u00eb kaloj\u00eb pa probleme te lideri i ri.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/3adb1d204b28e3ed85bef3530fa2b738.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 21. Konsensusi i Kafka<\/i><\/p>\n<h1>Protokolli i replikimit<\/h1>\n<p>\nKuptimi i detajeve t\u00eb replikimit ndihmon p\u00ebr t\u00eb kuptuar m\u00eb mir\u00eb skenar\u00ebt e mundsh\u00ebm t\u00eb humbjes s\u00eb t\u00eb dh\u00ebnave.<\/p>\n<h3>K\u00ebrkesat e t\u00ebrheqjes, Log End Offset (LEO) dhe Highwater Mark (HW)<\/h3>\n<p>\nPam\u00eb se followers u d\u00ebrgojn\u00eb periodikisht k\u00ebrkesa fetch liderit. Intervali i parazgjedhur \u00ebsht\u00eb 500 ms. Kjo ndryshon nga RabbitMQ, ku replikimi nuk niset nga pasqyra e radh\u00ebs, por nga master-i. Master-i i shtyn ndryshimet te pasqyrat.<\/p>\n<p>Lideri dhe t\u00eb gjith\u00eb followers ruajn\u00eb Log End Offset (LEO) dhe shenj\u00ebn Highwater (HW). Shenja LEO ruan offset-in e mesazhit t\u00eb fundit n\u00eb replik\u00ebn lokale, nd\u00ebrsa HW ruan offset-in e commit-it t\u00eb fundit. Mbani mend se, q\u00eb nj\u00eb mesazh t\u00eb marr\u00eb statusin \u00abcommit\u00bb, ai duhet t\u00eb ruhet n\u00eb t\u00eb gjitha replikat ISR. Kjo do t\u00eb thot\u00eb se LEO zakonisht \u00ebsht\u00eb pak p\u00ebrpara HW.<\/p>\n<p>Kur lideri merr nj\u00eb mesazh, ai e ruan lokalisht. Followers d\u00ebrgojn\u00eb nj\u00eb k\u00ebrkes\u00eb fetch duke kaluar LEO-n e tyre. M\u00eb pas, lideri d\u00ebrgon nj\u00eb paket\u00eb mesazhesh duke filluar nga ky LEO, si edhe vler\u00ebn aktuale t\u00eb HW. Kur lideri merr informacion se t\u00eb gjitha replikat e kan\u00eb ruajtur mesazhin me offset-in e caktuar, ai l\u00ebviz shenj\u00ebn HW. Vet\u00ebm lideri mund ta l\u00ebviz\u00eb HW, dhe k\u00ebshtu t\u00eb gjith\u00eb followers m\u00ebsojn\u00eb vler\u00ebn aktuale n\u00eb p\u00ebrgjigjet ndaj k\u00ebrkesave t\u00eb tyre. Kjo do t\u00eb thot\u00eb se followers mund t\u00eb mbeten prapa liderit si p\u00ebr mesazhet, ashtu edhe p\u00ebr njohjen e vler\u00ebs HW. Konsumator\u00ebt marrin mesazhe vet\u00ebm deri te HW aktual.<\/p>\n<p>Vini re se \u00abpersisted\u00bb do t\u00eb thot\u00eb i shkruar n\u00eb memorie, jo n\u00eb disk. P\u00ebr arsye performance, Kafka kryen sinkronizimin n\u00eb disk me nj\u00eb interval t\u00eb caktuar. Edhe RabbitMQ ka nj\u00eb interval t\u00eb till\u00eb, por ai do t\u2019i d\u00ebrgoj\u00eb konfirmim publisher-it vet\u00ebm pasi master-i dhe t\u00eb gjitha pasqyrat ta ken\u00eb shkruar mesazhin n\u00eb disk. Zhvilluesit e Kafka, p\u00ebr arsye performance, kan\u00eb vendosur t\u00eb d\u00ebrgojn\u00eb ack sapo mesazhi t\u00eb shkruhet n\u00eb memorie. Kafka mb\u00ebshtetet te fakti q\u00eb teprica e kopjeve kompenson rrezikun e ruajtjes afatshkurt\u00ebr t\u00eb mesazheve t\u00eb konfirmuara vet\u00ebm n\u00eb memorie.<\/p>\n<h1>D\u00ebshtimi i liderit<\/h1>\n<p>\nKur lideri bie, Zookeeper njofton controller-in dhe ai zgjedh nj\u00eb replik\u00eb t\u00eb re lidere. Lideri i ri vendos nj\u00eb shenj\u00eb t\u00eb re HW n\u00eb p\u00ebrputhje me LEO-n e vet. M\u00eb pas, followers marrin informacionin p\u00ebr liderin e ri. N\u00eb var\u00ebsi t\u00eb versionit t\u00eb Kafka, follower do t\u00eb zgjedh\u00eb nj\u00eb nga dy skenar\u00ebt:<\/p>\n<ol>\n<li>Do ta shkurtoj\u00eb log-un lokal deri te HW i njohur dhe do t\u2019i d\u00ebrgoj\u00eb liderit t\u00eb ri nj\u00eb k\u00ebrkes\u00eb p\u00ebr mesazhet pas k\u00ebsaj shenje.\n<\/li>\n<li>Do t\u2019i d\u00ebrgoj\u00eb liderit nj\u00eb k\u00ebrkes\u00eb p\u00ebr t\u00eb marr\u00eb HW n\u00eb momentin kur ai u zgjodh lider dhe m\u00eb pas do ta shkurtoj\u00eb log-un deri n\u00eb at\u00eb offset. M\u00eb pas do t\u00eb nis\u00eb t\u00eb b\u00ebj\u00eb k\u00ebrkesa periodike fetch duke filluar nga ai offset.<\/li>\n<\/ol>\n<p>\nFollower-it mund t\u2019i duhet ta shkurtoj\u00eb log-un p\u00ebr arsyet e m\u00ebposhtme:<\/p>\n<ul>\n<li>Kur ndodh nj\u00eb d\u00ebshtim i liderit, follower-i i par\u00eb nga grupi ISR i regjistruar n\u00eb Zookeeper fiton zgjedhjet dhe b\u00ebhet lider. T\u00eb gjith\u00eb follower-\u00ebt n\u00eb ISR, megjith\u00ebse konsiderohen \u00abt\u00eb sinkronizuar\u00bb, mund t\u00eb mos ken\u00eb marr\u00eb nga lideri i m\u00ebparsh\u00ebm kopjet e t\u00eb gjitha mesazheve. \u00cbsht\u00eb plot\u00ebsisht e mundur q\u00eb follower-i i zgjedhur t\u00eb mos ket\u00eb kopjen m\u00eb t\u00eb p\u00ebrdit\u00ebsuar. Kafka garanton q\u00eb midis replikave t\u00eb mos ket\u00eb divergjenc\u00eb. Prandaj, p\u00ebr t\u00eb shmangur divergjenc\u00ebn, \u00e7do follower duhet ta shkurtoj\u00eb log-un e vet deri te vlera HW e liderit t\u00eb ri n\u00eb momentin e zgjedhjes s\u00eb tij. Kjo \u00ebsht\u00eb nj\u00eb arsye tjet\u00ebr pse konfigurimi <i>acks=all<\/i> \u00ebsht\u00eb kaq i r\u00ebnd\u00ebsish\u00ebm p\u00ebr konsistenc\u00ebn.\n<\/li>\n<li>Mesazhet shkruhen periodikisht n\u00eb disk. N\u00ebse t\u00eb gjitha nyjet e klasterit d\u00ebshtojn\u00eb nj\u00ebkoh\u00ebsisht, n\u00eb disqe do t\u00eb mbeten replika me offset-e t\u00eb ndryshme. \u00cbsht\u00eb plot\u00ebsisht e mundur q\u00eb, kur broker-at t\u00eb rikthehen s\u00ebrish n\u00eb rrjet, lideri i ri q\u00eb do t\u00eb zgjidhet t\u00eb jet\u00eb prapa follower-\u00ebve t\u00eb tij, sepse ai \u00ebsht\u00eb ruajtur n\u00eb disk m\u00eb her\u00ebt se t\u00eb tjer\u00ebt.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Ribashkimi me klasterin<\/h3>\n<p>\nGjat\u00eb ribashkimit me klasterin, replikat veprojn\u00eb nj\u00ebsoj si n\u00eb rastin e d\u00ebshtimit t\u00eb liderit: kontrollojn\u00eb replik\u00ebn e liderit dhe e shkurtojn\u00eb log-un e tyre deri te HW i tij (n\u00eb momentin e zgjedhjes). P\u00ebr krahasim, RabbitMQ i trajton nyjet e ribashkuara nj\u00ebsoj si nyje krejt\u00ebsisht t\u00eb reja. N\u00eb t\u00eb dyja rastet, broker-i hedh posht\u00eb \u00e7do gjendje ekzistuese. N\u00ebse p\u00ebrdoret sinkronizimi automatik, at\u00ebher\u00eb master duhet t\u00eb replikoj\u00eb t\u00eb gjith\u00eb p\u00ebrmbajtjen aktuale n\u00eb pasqyr\u00ebn e re me qasjen \u00able t\u00eb pres\u00eb gjith\u00eb bota\u00bb. Gjat\u00eb k\u00ebtij operacioni, master nuk pranon asnj\u00eb operacion leximi apo shkrimi. Nj\u00eb qasje e till\u00eb krijon probleme n\u00eb radh\u00eb t\u00eb m\u00ebdha.<\/p>\n<p>Kafka \u00ebsht\u00eb nj\u00eb log i shp\u00ebrndar\u00eb dhe, n\u00eb p\u00ebrgjith\u00ebsi, ruan m\u00eb shum\u00eb mesazhe sesa radha RabbitMQ, ku t\u00eb dh\u00ebnat hiqen nga radha pasi lexohen. Radh\u00ebt aktive duhet t\u00eb mbeten relativisht t\u00eb vogla. Por Kafka \u00ebsht\u00eb nj\u00eb log me politik\u00ebn e vet t\u00eb ruajtjes, e cila mund t\u00eb p\u00ebrcaktoj\u00eb nj\u00eb afat prej dit\u00ebsh ose jav\u00ebsh. Qasja me bllokimin e radh\u00ebs dhe sinkronizimin e plot\u00eb \u00ebsht\u00eb krejt\u00ebsisht e papranueshme p\u00ebr nj\u00eb log t\u00eb shp\u00ebrndar\u00eb. N\u00eb vend t\u00eb k\u00ebsaj, follower-at e Kafka thjesht e shkurtojn\u00eb log-un e tyre deri te HW e leader-it (n\u00eb momentin e zgjedhjes s\u00eb tij) n\u00ebse kopja e tyre \u00ebsht\u00eb m\u00eb p\u00ebrpara se leader-i. N\u00eb rastin m\u00eb t\u00eb mundsh\u00ebm, kur follower-i mbetet pas, ai thjesht nis t\u00eb b\u00ebj\u00eb k\u00ebrkesa fetch duke filluar nga LEO i tij aktual.<\/p>\n<p>Follower-at e rinj ose t\u00eb rilidhur nisin jasht\u00eb ISR dhe nuk marrin pjes\u00eb n\u00eb commit-e. Ata thjesht punojn\u00eb paralelisht me grupin, duke marr\u00eb mesazhe sa m\u00eb shpejt q\u00eb munden, derisa t\u00eb arrijn\u00eb leader-in dhe t\u00eb hyjn\u00eb n\u00eb ISR. K\u00ebtu nuk ka bllokim dhe nuk ka nevoj\u00eb t\u00eb hidhen posht\u00eb t\u00eb gjitha t\u00eb dh\u00ebnat e tyre.<\/p>\n<h1>Nd\u00ebrprerja e lidhjes<\/h1>\n<p>\nKafka ka m\u00eb shum\u00eb komponent\u00eb se RabbitMQ, prandaj k\u00ebtu ka nj\u00eb grup sjelljesh m\u00eb kompleks kur n\u00eb cluster prishet lidhja. Por Kafka \u00ebsht\u00eb projektuar q\u00eb n\u00eb fillim p\u00ebr cluster-a, ndaj zgjidhjet jan\u00eb menduar shum\u00eb mir\u00eb.<\/p>\n<p>M\u00eb posht\u00eb jan\u00eb disa skenar\u00eb t\u00eb nd\u00ebrprerjes s\u00eb lidhjes:<\/p>\n<ul>\n<li>Skenari 1. Follower-i nuk e sheh leader-in, por ende e sheh Zookeeper.\n<\/li>\n<li>Skenari 2. Leader-i nuk sheh asnj\u00eb follower, por ende e sheh Zookeeper.\n<\/li>\n<li>Skenari 3. Follower-i e sheh leader-in, por nuk e sheh Zookeeper.\n<\/li>\n<li>Skenari 4. Leader-i i sheh follower-at, por nuk e sheh Zookeeper.\n<\/li>\n<li>Skenari 5. Follower-i \u00ebsht\u00eb plot\u00ebsisht i ndar\u00eb si nga nyjet e tjera Kafka, ashtu edhe nga Zookeeper.\n<\/li>\n<li>Skenari 6. Leader-i \u00ebsht\u00eb plot\u00ebsisht i ndar\u00eb si nga nyjet e tjera Kafka, ashtu edhe nga Zookeeper.\n<\/li>\n<li>Skenari 7. Nyja e controller-it Kafka nuk e sheh nj\u00eb nyje tjet\u00ebr Kafka.\n<\/li>\n<li>Skenari 8. Controller-i Kafka nuk e sheh Zookeeper.<\/li>\n<\/ul>\n<p>\nP\u00ebr secilin skenar \u00ebsht\u00eb parashikuar sjellja p\u00ebrkat\u00ebse.<\/p>\n<h3>Skenari 1. Follower-i nuk e sheh leader-in, por ende e sheh Zookeeper<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/5f51ae679933b2b5a69e21831465d121.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 22. Skenari 1. ISR me tre replika<\/i><\/p>\n<p>Nd\u00ebrprerja e lidhjes e ndan broker-in 3 nga broker-at 1 dhe 2, por jo nga Zookeeper. Broker-i 3 nuk mund t\u00eb d\u00ebrgoj\u00eb m\u00eb k\u00ebrkesa fetch. Pas skadimit t\u00eb koh\u00ebs <i>replica.lag.time.max.ms<\/i> ai hiqet nga ISR dhe nuk merr pjes\u00eb n\u00eb commit-et e mesazheve. Sapo lidhja t\u00eb rikthehet, ai do t\u00eb rifilloj\u00eb k\u00ebrkesat fetch dhe do t\u2019i bashkohet ISR-s\u00eb kur t\u00eb arrij\u00eb liderin. Zookeeper do t\u00eb vazhdoj\u00eb t\u00eb marr\u00eb ping-e dhe do t\u00eb konsideroj\u00eb se brokeri \u00ebsht\u00eb aktiv dhe funksionon normalisht.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/976b7ff080ee6a6d76a165f614f40e95.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 23. Skenari 1. Brokeri hiqet nga ISR n\u00ebse nuk merret asnj\u00eb k\u00ebrkes\u00eb fetch prej tij brenda intervalit replica.lag.time.max.ms<\/i><\/p>\n<p>Nuk ka asnj\u00eb ndarje logjike (split-brain) ose pezullim t\u00eb nyj\u00ebs, si n\u00eb RabbitMQ. N\u00eb vend t\u00eb k\u00ebsaj, zvog\u00eblohet redundanca. <\/p>\n<h3>Skenari 2. Lideri nuk sheh asnj\u00eb follower, por ende sheh Zookeeper<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/ff6aaa053d73e8b7c97111979bcf97aa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 24. Skenari 2. Lideri dhe dy follower<\/i><\/p>\n<p>Nj\u00eb nd\u00ebrprerje e lidhjes s\u00eb rrjetit e ndan liderin nga follower-at, por brokeri ende sheh Zookeeper. Ashtu si n\u00eb skenarin e par\u00eb, ISR tkurret, por k\u00ebt\u00eb her\u00eb vet\u00ebm deri te lideri, sepse t\u00eb gjith\u00eb follower-at ndalojn\u00eb s\u00eb d\u00ebrguari k\u00ebrkesa fetch. S\u00ebrish, nuk ka asnj\u00eb ndarje logjike. N\u00eb vend t\u00eb k\u00ebsaj, ndodh humbje e redundanc\u00ebs p\u00ebr mesazhet e reja derisa lidhja t\u00eb rikthehet. Zookeeper vazhdon t\u00eb marr\u00eb ping-e dhe konsideron se brokeri \u00ebsht\u00eb aktiv dhe funksionon normalisht.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/3c69e8327da241407f76719fc022c37a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 25. Skenari 2. ISR u tkurr vet\u00ebm deri te lideri<\/i><\/p>\n<h3>Skenari 3. Follower-i sheh liderin, por nuk sheh Zookeeper<\/h3>\n<p>\nFollower-i ndahet nga Zookeeper, por jo nga brokeri lider. Si rezultat, follower-i vazhdon t\u00eb b\u00ebj\u00eb k\u00ebrkesa fetch dhe t\u00eb mbetet an\u00ebtar i ISR-s\u00eb. Zookeeper nuk merr m\u00eb ping-e dhe regjistron r\u00ebnien e brokerit, por meq\u00eb ky \u00ebsht\u00eb vet\u00ebm nj\u00eb follower, pas rikthimit nuk ka pasoja.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/1183bcfe45a3225ae3ef1a0651f61350.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 26. Skenari 3. Follower-i vazhdon t\u2019i d\u00ebrgoj\u00eb liderit k\u00ebrkesa fetch<\/i><\/p>\n<h3>Skenari 4. Lideri sheh follower-at, por nuk sheh Zookeeper<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/b3bf27fcb0eb806b27ad00f098e50a26.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 27. Skenari 4. Lideri dhe dy follower<\/i><\/p>\n<p>Lideri \u00ebsht\u00eb i ndar\u00eb nga Zookeeper, por jo nga broker\u00ebt follower. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/82d9f2e5868566678befc414d1885bfd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 28. Skenari 4. Lideri \u00ebsht\u00eb i izoluar nga Zookeeper<\/i><\/p>\n<p>Pas nj\u00eb kohe, Zookeeper do t\u00eb regjistroj\u00eb r\u00ebnien e brokerit dhe do ta njoftoj\u00eb kontrolluesin p\u00ebr k\u00ebt\u00eb. Ky i fundit do t\u00eb zgjedh\u00eb nj\u00eb lider t\u00eb ri nga follower-at. Megjithat\u00eb, lideri fillestar do t\u00eb vazhdoj\u00eb t\u00eb mendoj\u00eb se \u00ebsht\u00eb lider dhe do t\u00eb vazhdoj\u00eb t\u00eb pranoj\u00eb shkrime me <i>acks=1<\/i>. Follower-at nuk do t\u2019i d\u00ebrgojn\u00eb m\u00eb k\u00ebrkesa fetch, ndaj ai do t\u2019i konsideroj\u00eb t\u00eb vdekur dhe do t\u00eb p\u00ebrpiqet ta tkurroj\u00eb ISR vet\u00ebm te vetja. Por meq\u00eb nuk ka lidhje me Zookeeper, nuk do t\u00eb mund ta b\u00ebj\u00eb k\u00ebt\u00eb dhe n\u00eb at\u00eb moment do t\u00eb refuzoj\u00eb t\u00eb pranoj\u00eb shkrime t\u00eb m\u00ebtejshme. <\/p>\n<p>Mesazhet <i>acks=all<\/i> nuk do t\u00eb marrin konfirmim, sepse fillimisht ISR p\u00ebrfshin t\u00eb gjitha replikat, nd\u00ebrsa mesazhet nuk arrijn\u00eb deri te ato. Kur lideri fillestar t\u00eb p\u00ebrpiqet t\u2019i heq\u00eb ato nga ISR, ai nuk do t\u00eb mund ta b\u00ebj\u00eb k\u00ebt\u00eb dhe do t\u00eb ndaloj\u00eb s\u00eb pranuari \u00e7do mesazh.<\/p>\n<p>Klient\u00ebt e v\u00ebrejn\u00eb shpejt ndryshimin e liderit dhe nisin t\u00eb d\u00ebrgojn\u00eb regjistrime n\u00eb serverin e ri. Sapo rrjeti t\u00eb rikthehet, lideri fillestar sheh se nuk \u00ebsht\u00eb m\u00eb lider dhe e shkurton log-un e tij deri te vlera HW q\u00eb kishte lideri i ri n\u00eb momentin e nd\u00ebrprerjes, p\u00ebr t\u00eb shmangur mosp\u00ebrputhjet n\u00eb log. M\u00eb pas ai do t\u00eb nis\u00eb t\u00eb d\u00ebrgoj\u00eb k\u00ebrkesa fetch te lideri i ri. Humbasin t\u00eb gjitha regjistrimet e liderit fillestar q\u00eb nuk jan\u00eb replikuar te lideri i ri. Kjo do t\u00eb thot\u00eb se do t\u00eb humben mesazhet q\u00eb nuk u konfirmuan nga lideri fillestar gjat\u00eb atyre pak sekondave kur funksionuan dy lider\u00eb.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/d88d6f33c13dccb814c0f206ec72512b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 29. Skenari 4. Lideri n\u00eb brokerin 1 b\u00ebhet follower pas rikthimit t\u00eb rrjetit<\/i><\/p>\n<h3>Skenari 5. Follower \u00ebsht\u00eb plot\u00ebsisht i ndar\u00eb si nga nyjat e tjera Kafka, ashtu edhe nga Zookeeper<\/h3>\n<p>\nFollower \u00ebsht\u00eb plot\u00ebsisht i izoluar si nga nyjat e tjera Kafka, ashtu edhe nga Zookeeper. Ai thjesht hiqet nga ISR derisa rrjeti t\u00eb rikthehet, dhe m\u00eb pas arrin pjes\u00ebn tjet\u00ebr.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/b092607f777014fd945f18734dd7f4e7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 30. Skenari 5. Follower-i i izoluar hiqet nga ISR<\/i><\/p>\n<h3>Skenari 6. Lideri \u00ebsht\u00eb plot\u00ebsisht i ndar\u00eb si nga nyjat e tjera Kafka, ashtu edhe nga Zookeeper<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/bb808d534dbf65748eb0b481f86b4926.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 31. Skenari 6. Lideri dhe dy followers<\/i><\/p>\n<p>Lideri \u00ebsht\u00eb plot\u00ebsisht i izoluar nga followers-at e tij, kontrolluesi dhe Zookeeper. P\u00ebr nj\u00eb periudh\u00eb t\u00eb shkurt\u00ebr ai do t\u00eb vazhdoj\u00eb t\u00eb pranoj\u00eb regjistrime nga <i>acks=1<\/i>.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/6fda78bcd26ef6b916579d447e9fb1f0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 32. Skenari 6. Izolimi i liderit nga nyjat e tjera Kafka dhe Zookeeper<\/i><\/p>\n<p>Pa marr\u00eb k\u00ebrkesa pas skadimit t\u00eb <i>replica.lag.time.max.ms<\/i>, ai do t\u00eb p\u00ebrpiqet ta reduktoj\u00eb ISR vet\u00ebm te vetja, por nuk do t\u00eb mund ta b\u00ebj\u00eb k\u00ebt\u00eb, sepse nuk ka lidhje me Zookeeper, ndaj do t\u00eb ndaloj\u00eb s\u00eb pranuari regjistrime. <\/p>\n<p>Nd\u00ebrkoh\u00eb, Zookeeper do ta sh\u00ebnoj\u00eb brokerin e izoluar si t\u00eb vdekur, nd\u00ebrsa kontrolluesi do t\u00eb zgjedh\u00eb nj\u00eb lider t\u00eb ri.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/73d611a411fc64d835af2c714e9eba0a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 33. Skenari 6. Dy lider\u00eb<\/i><\/p>\n<p>Lideri fillestar mund t\u00eb pranoj\u00eb regjistrime p\u00ebr disa sekonda, por m\u00eb pas ndalon s\u00eb pranuari \u00e7do mesazh. Klient\u00ebt p\u00ebrdit\u00ebsohen \u00e7do 60 sekonda me metadata-t m\u00eb t\u00eb fundit. Ata do t\u00eb njoftohen p\u00ebr ndryshimin e liderit dhe do t\u00eb fillojn\u00eb t\u00eb d\u00ebrgojn\u00eb regjistrime te lideri i ri.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/ae99380c8a84fac15f440b699b9c552b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 34. Skenari 6. Producer-at kalojn\u00eb te lideri i ri<\/i><\/p>\n<p>T\u00eb gjitha regjistrimet e konfirmuara, t\u00eb b\u00ebra nga lideri fillestar q\u00eb nga momenti i humbjes s\u00eb lidhjes, do t\u00eb humbasin. Sapo rrjeti t\u00eb rikthehet, lideri fillestar do t\u00eb zbuloj\u00eb p\u00ebrmes Zookeeper se nuk \u00ebsht\u00eb m\u00eb lider. M\u00eb pas do ta shkurtoj\u00eb log-un e vet deri te HW e liderit t\u00eb ri n\u00eb momentin e zgjedhjes dhe do t\u00eb nis\u00eb t\u00eb d\u00ebrgoj\u00eb k\u00ebrkesa si follower.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebri e lart\u00eb\" src=\"\/wp-content\/uploads\/2019\/11\/10f0983a829b03ca9bbc62e12cbf8a5d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 35. Skenari 6. Lideri fillestar b\u00ebhet follower pas rikthimit t\u00eb lidhjes s\u00eb rrjetit<\/i><\/p>\n<p>N\u00eb k\u00ebt\u00eb situat\u00eb, p\u00ebr nj\u00eb periudh\u00eb t\u00eb shkurt\u00ebr mund t\u00eb v\u00ebrehet nj\u00eb ndarje logjike, por vet\u00ebm n\u00ebse <i>acks=1<\/i> dhe <i>min.insync.replicas<\/i> \u00ebsht\u00eb gjithashtu 1. Ndarja logjike p\u00ebrfundon automatikisht ose pas rikthimit t\u00eb rrjetit, kur lideri fillestar e kupton se nuk \u00ebsht\u00eb m\u00eb lider, ose kur t\u00eb gjith\u00eb klient\u00ebt e kuptojn\u00eb se lideri ka ndryshuar dhe fillojn\u00eb t\u00eb shkruajn\u00eb te lideri i ri \u2014 var\u00ebsisht se cila ndodh m\u00eb par\u00eb. N\u00eb \u00e7do rast, do t\u00eb ket\u00eb humbje t\u00eb disa mesazheve, por vet\u00ebm nga <i>acks=1<\/i>.<\/p>\n<p>Ekziston edhe nj\u00eb variant tjet\u00ebr i k\u00ebtij skenari, kur menj\u00ebher\u00eb para ndarjes s\u00eb rrjetit followers kishin mbetur prapa dhe lideri e kishte ngjeshur ISR vet\u00ebm te vetja. M\u00eb pas ai izolohet p\u00ebr shkak t\u00eb humbjes s\u00eb lidhjes. Zgjidhet nj\u00eb lider i ri, por lideri fillestar vazhdon t\u00eb pranoj\u00eb regjistrime, edhe <i>acks=all<\/i>, sepse n\u00eb ISR nuk ka ask\u00ebnd tjet\u00ebr p\u00ebrve\u00e7 tij. K\u00ebto regjistrime do t\u00eb humbasin pas rikthimit t\u00eb rrjetit. E vetmja m\u00ebnyr\u00eb p\u00ebr ta shmangur k\u00ebt\u00eb variant \u00ebsht\u00eb \u2014 <i>min.insync.replicas = 2<\/i>.<\/p>\n<h3>Skenari 7. Nyja e kontrolluesit Kafka nuk e sheh nj\u00eb nyje tjet\u00ebr Kafka<\/h3>\n<p>\nN\u00eb p\u00ebrgjith\u00ebsi, pas humbjes s\u00eb lidhjes me nj\u00eb nyje Kafka, kontrolluesi nuk do t\u00eb mund t\u2019i transmetoj\u00eb asnj\u00eb informacion p\u00ebr ndryshimin e liderit. N\u00eb rastin m\u00eb t\u00eb keq, kjo do t\u00eb \u00e7oj\u00eb n\u00eb nj\u00eb ndarje logjike afatshkurt\u00ebr, si n\u00eb skenarin 6. M\u00eb shpesh, broker-i thjesht nuk do t\u00eb b\u00ebhet kandidat p\u00ebr lidership n\u00eb rast d\u00ebshtimi t\u00eb k\u00ebtij t\u00eb fundit.<\/p>\n<h3>Skenari 8. Kontrolluesi Kafka nuk e sheh Zookeeper<\/h3>\n<p>\nNga kontrolluesi i shk\u00ebputur, Zookeeper nuk do t\u00eb marr\u00eb ping dhe do t\u00eb zgjedh\u00eb si kontrollues nj\u00eb nyje t\u00eb re Kafka. Kontrolluesi fillestar mund t\u00eb vazhdoj\u00eb ta konsideroj\u00eb veten t\u00eb till\u00eb, por ai nuk merr njoftime nga Zookeeper, prandaj nuk do t\u00eb ket\u00eb asnj\u00eb detyr\u00eb p\u00ebr t\u00eb ekzekutuar. Sapo rrjeti t\u00eb rikthehet, ai do ta kuptoj\u00eb se nuk \u00ebsht\u00eb m\u00eb kontrollues, por \u00ebsht\u00eb b\u00ebr\u00eb nj\u00eb nyje e zakonshme Kafka.<\/p>\n<h3>P\u00ebrfundime nga skenar\u00ebt<\/h3>\n<p>\nShohim se humbja e lidhjes s\u00eb follower-\u00ebve nuk \u00e7on n\u00eb humbje mesazhesh, por vet\u00ebm ul p\u00ebrkoh\u00ebsisht tepric\u00ebn derisa rrjeti t\u00eb rikthehet. Kjo, sigurisht, mund t\u00eb \u00e7oj\u00eb n\u00eb humbje t\u00eb t\u00eb dh\u00ebnave n\u00ebse humbasin nj\u00eb ose m\u00eb shum\u00eb nyje.<\/p>\n<p>N\u00ebse p\u00ebr shkak t\u00eb humbjes s\u00eb lidhjes lideri ndahet nga Zookeeper, kjo mund t\u00eb \u00e7oj\u00eb n\u00eb humbje mesazhesh me <i>acks=1<\/i>. Mungesa e lidhjes me Zookeeper shkakton nj\u00eb ndarje logjike afatshkurt\u00ebr me dy lider\u00eb. Kjo problematik\u00eb zgjidhet nga parametri <i>acks=all<\/i>.<\/p>\n<p>Parametri <i>min.insync.replicas<\/i> n\u00eb dy ose m\u00eb shum\u00eb replika jep garanci shtes\u00eb q\u00eb skenar\u00eb t\u00eb till\u00eb afatshkurt\u00ebr nuk do t\u00eb \u00e7ojn\u00eb n\u00eb humbje mesazhesh, si n\u00eb skenarin 6.<\/p>\n<h1>P\u00ebrmbledhje mbi humbjen e mesazheve<\/h1>\n<p>\nLe t\u00eb rendisim t\u00eb gjitha m\u00ebnyrat se si mund t\u00eb humben t\u00eb dh\u00ebnat n\u00eb Kafka:<\/p>\n<ul>\n<li>\u00c7do d\u00ebshtim i liderit, n\u00ebse mesazhet konfirmoheshin me <i>acks=1<\/i>\n<\/li>\n<li>\u00c7do kalim i papast\u00ebr (unclean) i lidershipit, pra te nj\u00eb follower jasht\u00eb ISR, edhe me <i>acks=all<\/i>\n<\/li>\n<li>Izolimi i liderit nga Zookeeper, n\u00ebse mesazhet konfirmoheshin me <i>acks=1<\/i>\n<\/li>\n<li>Izolimi i plot\u00eb i liderit, i cili tashm\u00eb e ka ngushtuar grupin ISR vet\u00ebm te vetja. Do t\u00eb humben t\u00eb gjitha mesazhet, edhe <i>acks=all<\/i>. Kjo \u00ebsht\u00eb e v\u00ebrtet\u00eb vet\u00ebm n\u00ebse <i>min.insync.replicas=1<\/i>.\n<\/li>\n<li>D\u00ebshtime t\u00eb nj\u00ebkohshme t\u00eb t\u00eb gjitha nyjeve t\u00eb ndarjes. Meq\u00eb mesazhet konfirmohen nga memoria, disa prej tyre mund t\u00eb mos jen\u00eb shkruar ende n\u00eb disk. Pas rinisjes s\u00eb server\u00ebve, disa mesazhe mund t\u00eb mungojn\u00eb.<\/li>\n<\/ul>\n<p>\nKalimet e papastra t\u00eb lidershipit mund t\u00eb shmangen ose duke i ndaluar ato, ose duke siguruar tepric\u00eb prej t\u00eb pakt\u00ebn dy replikash. Konfigurimi m\u00eb i q\u00ebndruesh\u00ebm \u00ebsht\u00eb kombinimi i <i>acks=all<\/i> dhe <i>min.insync.replicas<\/i> m\u00eb shum\u00eb se 1.<\/p>\n<h1>Krahasim i drejtp\u00ebrdrejt\u00eb i besueshm\u00ebris\u00eb s\u00eb RabbitMQ dhe Kafka<\/h1>\n<p>\nP\u00ebr t\u00eb garantuar besueshm\u00ebri dhe disponueshm\u00ebri t\u00eb lart\u00eb, t\u00eb dyja platformat zbatojn\u00eb nj\u00eb sistem replikimi primar dhe sekondar. Megjithat\u00eb, RabbitMQ ka nj\u00eb pik\u00eb t\u00eb dob\u00ebt kritike. Kur nyjet ribashkohen pas nj\u00eb d\u00ebshtimi, ato i hedhin posht\u00eb t\u00eb dh\u00ebnat e tyre dhe sinkronizimi bllokohet. Ky goditje e dyfisht\u00eb v\u00eb n\u00eb pik\u00ebpyetje q\u00ebndrueshm\u00ebrin\u00eb e radh\u00ebve t\u00eb m\u00ebdha n\u00eb RabbitMQ. Do t\u2019ju duhet t\u00eb pranoni ose uljen e tepric\u00ebs, ose bllokime t\u00eb gjata. Ulja e tepric\u00ebs rrit rrezikun e humbjes masive t\u00eb t\u00eb dh\u00ebnave. Por n\u00ebse radh\u00ebt jan\u00eb t\u00eb vogla, p\u00ebr t\u00eb ruajtur tepric\u00ebn me periudha t\u00eb shkurtra mosdisponueshm\u00ebrie (disa sekonda), kjo mund t\u00eb p\u00ebrballohet me riprovime t\u00eb lidhjes.<\/p>\n<p>N\u00eb Kafka nuk ka nj\u00eb problem t\u00eb till\u00eb. Ajo hedh posht\u00eb t\u00eb dh\u00ebnat vet\u00ebm nga pika ku lideri dhe follower-i fillojn\u00eb t\u00eb ndryshojn\u00eb. T\u00eb gjitha t\u00eb dh\u00ebnat e p\u00ebrbashk\u00ebta ruhen. P\u00ebr m\u00eb tep\u00ebr, replikimi nuk e bllokon sistemin. Lideri vazhdon t\u00eb pranoj\u00eb shkrime nd\u00ebrsa follower-i i ri e arrin, k\u00ebshtu q\u00eb p\u00ebr DevOps bashkimi ose ribashkimi i cluster-it b\u00ebhet nj\u00eb detyr\u00eb triviale. Sigurisht, mbeten ende \u00e7\u00ebshtje t\u00eb tilla si gjer\u00ebsia e brezit t\u00eb rrjetit gjat\u00eb replikimit. N\u00ebse shtohen nj\u00ebkoh\u00ebsisht disa follower-a, mund t\u00eb p\u00ebrballeni me kufirin e bandwidth-it.<\/p>\n<p>RabbitMQ e tejkalon Kafka n\u00eb besueshm\u00ebri kur ndodh d\u00ebshtim i nj\u00ebkohsh\u00ebm i disa server\u00ebve n\u00eb cluster. Si\u00e7 e tham\u00eb tashm\u00eb, RabbitMQ i d\u00ebrgon publisher-it konfirmim vet\u00ebm pasi mesazhi t\u00eb shkruhet n\u00eb disk te master-i dhe te t\u00eb gjitha pasqyrat. Por kjo shton vones\u00eb shtes\u00eb p\u00ebr dy arsye:<\/p>\n<ul>\n<li>fsync \u00e7do disa qindra milisekonda\n<\/li>\n<li>D\u00ebshtimi i pasqyr\u00ebs mund t\u00eb zbulohet vet\u00ebm pasi t\u00eb kaloj\u00eb koha e jet\u00ebs s\u00eb paketave q\u00eb kontrollojn\u00eb disponueshm\u00ebrin\u00eb e \u00e7do nyje (net tick). N\u00ebse pasqyra ngadal\u00ebsohet ose bie, kjo shton vones\u00eb.<\/li>\n<\/ul>\n<p>\nKafka mb\u00ebshtetet te ideja se, n\u00ebse nj\u00eb mesazh ruhet n\u00eb disa nyje, mesazhet mund t\u00eb konfirmohen sapo t\u00eb ken\u00eb arritur n\u00eb memorie. P\u00ebr k\u00ebt\u00eb arsye ekziston rreziku i humbjes s\u00eb mesazheve t\u00eb \u00e7do lloji (madje edhe <i>acks=all<\/i>, <i>min.insync.\u0440\u0435\u043f\u043b\u0438\u043a\u0438=2<\/i>) n\u00eb rast d\u00ebshtimi t\u00eb nj\u00ebkohsh\u00ebm.<\/p>\n<p>N\u00eb p\u00ebrgjith\u00ebsi, Kafka tregon performanc\u00eb m\u00eb t\u00eb lart\u00eb dhe q\u00eb n\u00eb fillim \u00ebsht\u00eb projektuar p\u00ebr cluster-a. Numri i follower-\u00ebve mund t\u00eb rritet deri n\u00eb 11, n\u00ebse kjo k\u00ebrkohet p\u00ebr besueshm\u00ebri. Nj\u00eb faktor replikimi 5 dhe numri minimal i replikave n\u00eb gjendje t\u00eb sinkronizuar <i>min.insync.replicas=3<\/i> do ta b\u00ebjn\u00eb humbjen e nj\u00eb mesazhi nj\u00eb ngjarje shum\u00eb t\u00eb rrall\u00eb. N\u00ebse infrastruktura juaj mund t\u00eb siguroj\u00eb nj\u00eb faktor t\u00eb till\u00eb replikimi dhe k\u00ebt\u00eb nivel redundance, mund t\u00eb zgjidhni k\u00ebt\u00eb variant.<\/p>\n<p>Cluster-izimi i RabbitMQ \u00ebsht\u00eb i mir\u00eb p\u00ebr radh\u00eb t\u00eb vogla. Por edhe radh\u00ebt e vogla mund t\u00eb rriten shpejt kur trafiku \u00ebsht\u00eb i lart\u00eb. Sapo radh\u00ebt b\u00ebhen t\u00eb m\u00ebdha, do t\u2019ju duhet t\u00eb b\u00ebni nj\u00eb zgjedhje t\u00eb v\u00ebshtir\u00eb midis disponueshm\u00ebris\u00eb dhe besueshm\u00ebris\u00eb. Cluster-izimi i RabbitMQ \u00ebsht\u00eb m\u00eb i p\u00ebrshtatsh\u00ebm p\u00ebr situata jo shum\u00eb tipike, ku avantazhet e fleksibilitetit t\u00eb RabbitMQ i tejkalojn\u00eb \u00e7do mang\u00ebsi t\u00eb cluster-izimit t\u00eb tij.<\/p>\n<p>Nj\u00eb nga m\u00ebnyrat p\u00ebr t\u00eb zbutur dob\u00ebsin\u00eb e RabbitMQ ndaj radh\u00ebve shum\u00eb t\u00eb m\u00ebdha \u00ebsht\u00eb ndarja e tyre n\u00eb shum\u00eb m\u00eb t\u00eb vogla. N\u00ebse nuk k\u00ebrkohet renditja e plot\u00eb e gjith\u00eb radh\u00ebs, por vet\u00ebm e mesazheve p\u00ebrkat\u00ebse (p\u00ebr shembull, mesazhet e nj\u00eb klienti t\u00eb caktuar), ose n\u00ebse renditja nuk \u00ebsht\u00eb fare e nevojshme, at\u00ebher\u00eb kjo qasje \u00ebsht\u00eb e pranueshme: shikoni projektin tim <noindex><a rel=\"nofollow\" href=\"https:\/\/jack-vanlightly.com\/blog\/2018\/7\/22\/creating-consumer-groups-in-rabbitmq-with-rebalanser-part-1\">Rebalanser<\/a><\/noindex> p\u00ebr ndarjen e radh\u00ebs (projekti \u00ebsht\u00eb ende n\u00eb faz\u00eb t\u00eb hershme). <\/p>\n<p>S\u00eb fundi, mos harroni p\u00ebr nj\u00eb s\u00ebr\u00eb gabimesh n\u00eb mekanizmat e klasterizimit dhe replikimit si te RabbitMQ, ashtu edhe te Kafka. Me kalimin e koh\u00ebs, sistemet jan\u00eb b\u00ebr\u00eb m\u00eb t\u00eb pjekura dhe m\u00eb t\u00eb q\u00ebndrueshme, por asnj\u00eb mesazh nuk do t\u00eb jet\u00eb kurr\u00eb 100% i mbrojtur nga humbja! P\u00ebr m\u00eb tep\u00ebr, n\u00eb qendrat e t\u00eb dh\u00ebnave ndodhin edhe avari n\u00eb shkall\u00eb t\u00eb gjer\u00eb!<\/p>\n<p>N\u00ebse kam l\u00ebn\u00eb di\u00e7ka pa p\u00ebrmendur, kam b\u00ebr\u00eb ndonj\u00eb gabim ose nuk pajtoheni me cilindo nga pohimet, mos hezitoni t\u00eb lini nj\u00eb koment ose t\u00eb m\u00eb kontaktoni.<\/p>\n<p>Shpesh m\u00eb pyesin: \u00ab\u00c7far\u00eb t\u00eb zgjedh, Kafka apo RabbitMQ?\u00bb, \u00abCila platform\u00eb \u00ebsht\u00eb m\u00eb e mir\u00eb?\u00bb. E v\u00ebrteta \u00ebsht\u00eb se kjo varet v\u00ebrtet nga situata juaj, p\u00ebrvoja aktuale e k\u00ebshtu me radh\u00eb. Nuk guxoj t\u00eb jap nj\u00eb mendim t\u00eb prer\u00eb, sepse do t\u00eb ishte nj\u00eb thjeshtim i tepruar t\u00eb rekomandoja nj\u00eb platform\u00eb t\u00eb vetme p\u00ebr t\u00eb gjitha rastet e p\u00ebrdorimit dhe kufizimet e mundshme. E kam shkruar k\u00ebt\u00eb seri artikujsh q\u00eb t\u00eb mund t\u00eb formoni mendimin tuaj.<\/p>\n<p>Dua t\u00eb them se t\u00eb dy sistemet jan\u00eb lider\u00eb n\u00eb k\u00ebt\u00eb fush\u00eb. Ndoshta jam pak i nj\u00ebansh\u00ebm, sepse nga p\u00ebrvoja n\u00eb projektet e mia prirem t\u00eb vler\u00ebsoj m\u00eb shum\u00eb gj\u00ebra si renditja e garantuar e mesazheve dhe besueshm\u00ebria. <\/p>\n<p>Shoh teknologji t\u00eb tjera q\u00eb nuk e kan\u00eb k\u00ebt\u00eb besueshm\u00ebri dhe k\u00ebt\u00eb renditje t\u00eb garantuar, pastaj shoh RabbitMQ dhe Kafka \u2014 dhe kuptoj vler\u00ebn e jasht\u00ebzakonshme t\u00eb t\u00eb dy k\u00ebtyre sistemeve.<br \/>\n<br \/>Burimi: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/474984\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u043f\u0440\u043e\u0448\u043b\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0435\u043b\u0438 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0438\u0437\u0430\u0446\u0438\u044e RabbitMQ \u0434\u043b\u044f \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u0438 \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u0438. \u0422\u0435\u043f\u0435\u0440\u044c \u0433\u043b\u0443\u0431\u043e\u043a\u043e \u043f\u043e\u043a\u043e\u043f\u0430\u0435\u043c\u0441\u044f \u0432 Apache Kafka. \u0417\u0434\u0435\u0441\u044c \u0435\u0434\u0438\u043d\u0438\u0446\u0435\u0439 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0440\u0430\u0437\u0434\u0435\u043b (partition). \u0423 \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u0442\u043e\u043f\u0438\u043a\u0430 \u043e\u0434\u0438\u043d \u0438\u043b\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0440\u0430\u0437\u0434\u0435\u043b\u043e\u0432. \u0412 \u043a\u0430\u0436\u0434\u043e\u043c \u0440\u0430\u0437\u0434\u0435\u043b\u0435 \u0435\u0441\u0442\u044c \u043b\u0438\u0434\u0435\u0440 \u0441 \u0444\u043e\u043b\u043b\u043e\u0432\u0435\u0440\u0430\u043c\u0438 \u0438\u043b\u0438 \u0431\u0435\u0437 \u043d\u0438\u0445. \u041f\u0440\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0438 \u0442\u043e\u043f\u0438\u043a\u0430 \u0443\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u0440\u0430\u0437\u0434\u0435\u043b\u043e\u0432 \u0438 \u043a\u043e\u044d\u0444\u0444\u0438\u0446\u0438\u0435\u043d\u0442 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438. \u041e\u0431\u044b\u0447\u043d\u043e\u0435 \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0435 3, \u044d\u0442\u043e [&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-52541","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\" \/>\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\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\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\udd47RabbitMQ \u043f\u0440\u043e\u0442\u0438\u0432 Kafka: \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c \u0438 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost\" \/>\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-11-10T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:00:17+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\udd47RabbitMQ kund\u00ebr Kafka: toleranca ndaj d\u00ebshtimeve dhe disponueshm\u00ebria e lart\u00eb | ProHoster","description":"N\u00eb","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","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\udd47RabbitMQ \u043f\u0440\u043e\u0442\u0438\u0432 Kafka: \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c \u0438 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c | ProHoster","og:description":"\u0412","og:url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","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-11-10T21:00:00+00:00","article:modified_time":"2020-02-18T11:00:17+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52541","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-24 03:57:21","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:41:24","updated":"2026-01-24 03:57:22","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\/52541","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=52541"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/52541\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=52541"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=52541"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=52541"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}