{"id":52525,"date":"2019-11-10T00:00:00","date_gmt":"2019-11-09T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah"},"modified":"2020-02-18T14:00:16","modified_gmt":"2020-02-18T11:00:16","slug":"rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","title":{"rendered":"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/d8e584d210a6a016a962ad6f956a2078.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQ\u00ebndrueshm\u00ebria dhe disponueshm\u00ebria e lart\u00eb jan\u00eb tema t\u00eb m\u00ebdha, k\u00ebshtu q\u00eb do t'i kushtojm\u00eb RabbitMQ dhe Kafka artikuj t\u00eb ve\u00e7ant\u00eb. Ky artikull \u00ebsht\u00eb p\u00ebr RabbitMQ, nd\u00ebrsa artikulli tjet\u00ebr \u00ebsht\u00eb p\u00ebr Kafka, n\u00eb krahasim me RabbitMQ. Artikulli \u00ebsht\u00eb i gjat\u00eb, prandaj b\u00ebni nj\u00eb komoditet.<\/p>\n<p>Le t\u00eb shqyrtojm\u00eb strategjit\u00eb e q\u00ebndrueshm\u00ebris\u00eb, koherenc\u00ebs dhe disponueshm\u00ebris\u00eb s\u00eb lart\u00eb (HA), si dhe kompromiset q\u00eb duhet t\u00eb b\u00ebhen n\u00eb \u00e7do strategji. RabbitMQ mund t\u00eb funksionoj\u00eb n\u00eb nj\u00eb klaster nyjesh - dhe at\u00ebher\u00eb klasifikohet si nj\u00eb sistem t\u00eb shp\u00ebrndar\u00eb. Kur flasim p\u00ebr sistemet e shp\u00ebrndara, shpesh flasim p\u00ebr koherenc\u00ebn dhe disponueshm\u00ebrin\u00eb. <\/p>\n<p>K\u00ebto koncepte p\u00ebrshkruajn\u00eb se si sillet nj\u00eb sistem n\u00eb rast t\u00eb nj\u00eb d\u00ebshtimi. D\u00ebshtimi i lidhjes rrjet, d\u00ebshtimi i serverit, d\u00ebshtimi i hard diskut, mungesa e p\u00ebrkohshme e serverit p\u00ebr shkak t\u00eb grumbullimit t\u00eb t\u00eb dh\u00ebnave, humbja e paketeve ose ngadal\u00ebsimi i lidhjes rrjet. T\u00eb gjitha k\u00ebto mund t\u00eb \u00e7ojn\u00eb n\u00eb humbje t\u00eb t\u00eb dh\u00ebnave ose konflikte. Duket se \u00ebsht\u00eb praktikisht e pamundur t\u00eb ngrish nj\u00eb sistem, n\u00eb m\u00ebnyr\u00eb t\u00eb nj\u00ebkohshme dhe plot\u00ebsisht t\u00eb koherent (pa humbje t\u00eb t\u00eb dh\u00ebnave, pa kund\u00ebrshtim t\u00eb t\u00eb dh\u00ebnave), dhe t\u00eb jet\u00eb i disponuesh\u00ebm (do t\u00eb pranoj\u00eb operacione leximi dhe shkrimi) p\u00ebr t\u00eb gjitha rastet e d\u00ebshtimit.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nNe do t\u00eb shohim se koherenca dhe disponueshm\u00ebria jan\u00eb n\u00eb skajet e ndryshme t\u00eb spektrit, dhe duhet t\u00eb zgjidhni se n\u00eb cilin drejtim t\u00eb optimizoni. Lajmi i mir\u00eb \u00ebsht\u00eb se me RabbitMQ ky zgjedhje \u00ebsht\u00eb e mundur. Keni ato \"leverat nerd\" p\u00ebr t\u00eb l\u00ebvizur balanc\u00ebn drejt m\u00eb shum\u00eb koherenc\u00ebs ose m\u00eb shum\u00eb disponueshm\u00ebris\u00eb.<\/p>\n<p>Do t'i kushtohet v\u00ebmendje t\u00eb ve\u00e7ant\u00eb se cilat konfigurime \u00e7ojn\u00eb n\u00eb humbje t\u00eb t\u00eb dh\u00ebnave p\u00ebr shkak t\u00eb konfirmimeve. Ekziston nj\u00eb zinxhir p\u00ebrgjegj\u00ebsie midis botuesve, broker\u00ebve dhe konsumator\u00ebve. Pasi mesazhi i \u00ebsht\u00eb dor\u00ebzuar brokerit, kjo \u00ebsht\u00eb puna e tij - t\u00eb mos humbas\u00eb mesazhin. Kur brokeri konfirmon pranim nga botuesi t\u00eb mesazhit, ne nuk presim q\u00eb ai t\u00eb humbet. Por do t\u00eb shohim se kjo mund t\u00eb ndodh\u00eb n\u00eb var\u00ebsi t\u00eb konfigurimit t\u00eb brokerit dhe botuesit tuaj.<\/p>\n<h1>Primitiv\u00ebt e q\u00ebndrueshm\u00ebris\u00eb s\u00eb nj\u00eb nyje<\/h1>\n<p><\/p>\n<h3>Radh\u00eb t\u00eb q\u00ebndrueshme \/ Rrjet\u00ebzimi<\/h3>\n<p>\nN\u00eb RabbitMQ ka dy lloje t\u00eb radh\u00ebve: t\u00eb q\u00ebndrueshme (durable) dhe t\u00eb paq\u00ebndrueshme (non-durable). T\u00eb gjitha radh\u00ebt ruhen n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave Mnesia. Radh\u00ebt e q\u00ebndruara shpall\u00ebn p\u00ebrs\u00ebri kur niset nodi dhe, k\u00ebshtu, mbijetojn\u00eb rinisjen, d\u00ebshtimin e sistemit ose d\u00ebshtimin e serverit (derisa t\u00eb dh\u00ebnat ruajn\u00eb). Kjo do t\u00eb thot\u00eb se sa her\u00eb q\u00eb ju shpallni routing (exchange) dhe radh\u00ebn si t\u00eb q\u00ebndruara, infrastruktura e radh\u00ebve\/routing do t\u00eb rikthehet n\u00eb operim.<\/p>\n<p>Radh\u00ebt e paq\u00ebndrueshme dhe routing fshihen kur rip\u00ebrdoret nodi.<\/p>\n<h3>Mesazhet e q\u00ebndrueshme<\/h3>\n<p>\nFakti q\u00eb nj\u00eb radh\u00eb \u00ebsht\u00eb e q\u00ebndrueshme nuk do t\u00eb thot\u00eb se t\u00eb gjitha mesazhet e saj do t\u00eb mbijetojn\u00eb rinisjen e nodit. Do t\u00eb rikuperohen vet\u00ebm mesazhet q\u00eb jan\u00eb vendosur nga publikuesi si <i>t\u00eb q\u00ebndrueshme<\/i> (persistent). Mesazhet e q\u00ebndrueshme n\u00eb t\u00eb v\u00ebrtet\u00eb krijojn\u00eb nj\u00eb ngarkes\u00eb shtes\u00eb p\u00ebr brokerin, por n\u00ebse humbja e mesazhit \u00ebsht\u00eb e papranueshme, at\u00ebher\u00eb nuk ka tjet\u00ebr zgjedhje.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/8b8e2de4ef82bf8497960657aac0ddb0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 1. Matrica e q\u00ebndrueshm\u00ebris\u00eb<\/i><\/p>\n<h1>Klastrimi me pasqyrime radh\u00ebsh<\/h1>\n<p>\nP\u00ebr t\u00eb mbijetuar humbjen e brokerit, na nevojitet tep\u00ebrsi. Mund t\u00eb kombinojm\u00eb disa nodo RabbitMQ n\u00eb nj\u00eb klaster dhe pastaj t\u00eb shtojm\u00eb tep\u00ebrsi t\u00eb m\u00ebtejshme p\u00ebrmes replikimit t\u00eb radh\u00ebve mes disa nodave. K\u00ebshtu, n\u00ebse nj\u00eb nod bie, ne nuk humbasim t\u00eb dh\u00ebna dhe mbetemi t\u00eb aksesuesh\u00ebm. <\/p>\n<p>Pasqyrimi i radh\u00ebs:<\/p>\n<ul>\n<li>nj\u00eb radh\u00eb kryesore (master), e cila merr t\u00eb gjitha komandat p\u00ebr shkrim dhe lexim\n<\/li>\n<li>nj\u00eb ose m\u00eb shum\u00eb pasqyra, t\u00eb cilat merrni t\u00eb gjitha mesazhet dhe metadatet nga radha kryesore. K\u00ebto pasqyra nuk ekzistojn\u00eb p\u00ebr shkak t\u00eb shkall\u00ebzimit, por ekskluzivisht p\u00ebr tep\u00ebrsi.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/35f3d4bdc4f5e10da0e40eb91c5d8280.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 2. Pasqyrimi i radh\u00ebs<\/i><\/p>\n<p>Pasqyrimi vendoset nga politika p\u00ebrkat\u00ebse. N\u00eb t\u00eb mund t\u00eb zgjidhet faktor i replikimit dhe madje nodet ku duhet t\u00eb vendoset radh\u00eb. Shembuj:<\/p>\n<ul>\n<li><code>ha-mode: all<\/code>\n<\/li>\n<li><code>ha-mode: exactly, ha-params: 2<\/code> (nj\u00eb master dhe nj\u00eb pasqyr\u00eb)\n<\/li>\n<li><code>ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2<\/code><\/li>\n<\/ul>\n<p><\/p>\n<h1>Konfirmimi p\u00ebr publikuesin<\/h1>\n<p>\nP\u00ebr t\u00eb arritur nj\u00eb regjistrim t\u00eb zakonsh\u00ebm, jan\u00eb t\u00eb nevojshme konfirmimet p\u00ebr botuesin (Publisher Confirms). Pa to, ka mund\u00ebsi p\u00ebr humbje t\u00eb mesazheve. Konfirmimi i d\u00ebrgohet botuesit pasi mesazhi t\u00eb regjistrohet n\u00eb disk. RabbitMQ regjistron mesazhet n\u00eb disk jo n\u00eb momentin e pranimit, por n\u00eb baza periodike, rreth disa qindra milisekondash. Kur radh\u00ebt jan\u00eb pasqyruar, konfirmimi d\u00ebrgohet vet\u00ebm pasi t\u00eb gjitha pasqyrat gjithashtu t\u00eb ken\u00eb regjistruar kopjen e tyre t\u00eb mesazhit n\u00eb disk. Kjo do t\u00eb thot\u00eb se p\u00ebrdorimi i konfirmimeve shton vones\u00eb, por n\u00ebse siguria e t\u00eb dh\u00ebnave \u00ebsht\u00eb e r\u00ebnd\u00ebsishme, ato jan\u00eb t\u00eb nevojshme.<\/p>\n<h1>Radh\u00eb rezistente ndaj d\u00ebshtimit<\/h1>\n<p>\nKur brokeri ndalon ose d\u00ebshtojn\u00eb, t\u00eb gjitha radh\u00ebt kryesore (master) n\u00eb k\u00ebt\u00eb nyj\u00eb ndalen bashk\u00eb me t\u00eb. Pastaj, klusteri zgjedh pasqyr\u00ebn m\u00eb t\u00eb vjet\u00ebr t\u00eb \u00e7do masteri dhe e promovon at\u00eb si nj\u00eb master t\u00eb ri.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/8d8227c00643f35e0dc752b6617e18fb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 3. Disa radh\u00eb t\u00eb pasqyruara dhe politikat e tyre<\/i><\/p>\n<p>Brokeri 3 d\u00ebshton. Vini re se pasqyra e Radh\u00ebs C n\u00eb Brokerin 2 ngjitet n\u00eb master. Gjithashtu, v\u00ebrejtni se p\u00ebr Radh\u00ebn C \u00ebsht\u00eb krijuar nj\u00eb pasqyr\u00eb e re n\u00eb Brokerin 1. RabbitMQ gjithmon\u00eb p\u00ebrpiqet t\u00eb mbaj\u00eb raportin e replikimit q\u00eb \u00ebsht\u00eb treguar n\u00eb politikat tuaja.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/d08b3ada22e79686d448714f7bab009a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 4. Brokeri 3 d\u00ebshton, duke shkaktuar d\u00ebshtimin e radh\u00ebs C<\/i> <\/p>\n<p>D\u00ebshmoni se Brokeri 1 d\u00ebshton! Na ka mbetur vet\u00ebm nj\u00eb broker. Pasqyra e Radh\u00ebs B ngjitet n\u00eb master.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/dcc1d542c40c441194fd07e51046c619.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 5<\/i><\/p>\n<p>E kthejm\u00eb Brokerin 1. Pavar\u00ebsisht se sa t\u00eb suksesshme ishin t\u00eb dh\u00ebnat q\u00eb mbijetuan humbjen dhe rikthimin e brokerit, t\u00eb gjitha mesazhet e pasqyruara t\u00eb radh\u00ebs jan\u00eb hedhur gjat\u00eb rindizjes. \u00cbsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb theksohet, pasi do t\u00eb ket\u00eb pasoja. Shpejt do t\u00eb shqyrtojm\u00eb k\u00ebto pasoja. Pra, Brokeri 1 tani \u00ebsht\u00eb p\u00ebrs\u00ebri nj\u00eb an\u00ebtar i klasterit, dhe klasteri p\u00ebrpiqet t\u00eb respektoj\u00eb politikat dhe k\u00ebshtu krijon pasqyra n\u00eb Brokerin 1.<\/p>\n<p>N\u00eb k\u00ebt\u00eb rast, humbja e Brokerit 1 ishte e plot\u00eb, ashtu si dhe e dh\u00ebnave, k\u00ebshtu q\u00eb Radh\u00eb B e pa pasqyr\u00eb u humb t\u00ebr\u00ebsisht.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/7ac7ab65ea6dff9c5a49372c04c83a37.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 6. Brokeri 1 kthehet n\u00eb pun\u00eb<\/i><\/p>\n<p>Broker 3 \u00ebsht\u00eb rikthyer n\u00eb funksion, k\u00ebshtu q\u00eb radh\u00ebt A dhe B po rikthejn\u00eb pasqyrat e krijuara mbi t\u00eb, p\u00ebr t'u p\u00ebrmbushur politikave t\u00eb tyre HA. Por tani, t\u00eb gjitha radh\u00ebt kryesore jan\u00eb n\u00eb nj\u00eb nod! Kjo nuk \u00ebsht\u00eb ideale, do t\u00eb ishte m\u00eb mir\u00eb nj\u00eb shp\u00ebrndarje e barabart\u00eb mes nod\u00ebve. Fatkeq\u00ebsisht, k\u00ebtu nuk ka shum\u00eb mund\u00ebsi p\u00ebr riparimin e balancimit t\u00eb master\u00ebve. Do t\u00eb kthehemi n\u00eb k\u00ebt\u00eb problem m\u00eb von\u00eb, pasi fillimisht duhet t\u00eb shqyrtojm\u00eb sinkronizimin e radh\u00ebs. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/a54e53bb01e2f830a54f88acaa668984.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 7. Broker 3 rikthehet n\u00eb funksion. T\u00eb gjitha radh\u00ebt kryesore jan\u00eb n\u00eb nj\u00eb nod!<\/i><\/p>\n<p>Si\u00e7 \u00ebsht\u00eb, tani duhet t\u00eb keni nj\u00eb pamje se si pasqyrat sigurojn\u00eb tep\u00ebrsi dhe q\u00ebndres\u00eb ndaj d\u00ebshtimit. Kjo garanton disponueshm\u00ebrin\u00eb n\u00eb rast d\u00ebshtimi t\u00eb nj\u00eb nodi dhe mbron nga humbja e t\u00eb dh\u00ebnave. Por ne nuk kemi p\u00ebrfunduar ende, sepse n\u00eb t\u00eb v\u00ebrtet\u00eb gjith\u00e7ka \u00ebsht\u00eb shum\u00eb m\u00eb e komplikuar.<\/p>\n<h1>Sinkronizimi<\/h1>\n<p>\nKur krijoni nj\u00eb pasqyr\u00eb t\u00eb re, t\u00eb gjitha mesazhet e reja gjithmon\u00eb do t\u00eb replikohen n\u00eb k\u00ebt\u00eb pasqyr\u00eb dhe \u00e7do tjet\u00ebr. Sa i p\u00ebrket t\u00eb dh\u00ebnave ekzistuese n\u00eb radh\u00ebn kryesore, ne mund t'i replikojm\u00eb ato n\u00eb pasqyr\u00ebn e re, e cila b\u00ebhet nj\u00eb kopje e plot\u00eb e masterit. Ne gjithashtu mund t\u00eb mos replikojm\u00eb mesazhet ekzistuese dhe t'i lejojm\u00eb radh\u00ebn kryesore dhe pasqyr\u00ebn e re t\u00eb bashkohen n\u00eb nj\u00eb moment, kur mesazhet e reja hyjn\u00eb n\u00eb bisht, nd\u00ebrsa mesazhet ekzistuese dalin nga krye.<\/p>\n<p>Kjo sinkronizim b\u00ebhet automatikisht ose manualisht dhe menaxhohet me politika t\u00eb radh\u00ebve. Le t\u00eb shqyrtojm\u00eb nj\u00eb shembull.<\/p>\n<p>Kemi dy radh\u00eb t\u00eb pasqyruara. Radh\u00eb A sinkronizohet automatikisht, nd\u00ebrsa Radh\u00eb B manualisht. T\u00eb dy radh\u00ebt kan\u00eb dhjet\u00eb mesazhe.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/304f2a475fdd0cb6d3069140c667a0a7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 8. Dy radh\u00eb me m\u00ebnyra t\u00eb ndryshme sinkronizimi<\/i><\/p>\n<p>Tani po humbasim Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/49114966f440c407488bb467ff6dbf93.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 9. Broker 3 ka r\u00ebn\u00eb<\/i><\/p>\n<p>Broker 3 rikthehet n\u00eb funksion. Klasteri krijon nj\u00eb pasqyr\u00eb p\u00ebr \u00e7do radh\u00eb n\u00eb nj\u00eb nod t\u00eb ri dhe automatikisht sinkronizon Radh\u00ebn e Re A me masterin. Megjithat\u00eb, pasqyra e re e Radh\u00ebs B mbetet bosh. K\u00ebshtu, kemi tep\u00ebrsi t\u00eb plot\u00eb t\u00eb Radh\u00ebs A dhe vet\u00ebm nj\u00eb pasqyr\u00eb p\u00ebr mesazhet ekzistuese t\u00eb Radh\u00ebs B.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/adffc1f5eff8806edbd83772f338d67f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 10. Pasqyra e re e Radh\u00ebs A merr t\u00eb gjitha mesazhet ekzistuese, nd\u00ebrsa pasqyra e re e Radh\u00ebs B nuk merr asnj\u00eb<\/i><\/p>\n<p>T\u00eb dy radh\u00ebt pranojn\u00eb edhe nga dhjet\u00eb mesazhe. M\u00eb pas, Brokeri 2 bie, nd\u00ebrsa Rradha A kthehet n\u00eb pasqyr\u00ebn m\u00eb t\u00eb vjet\u00ebr q\u00eb ndodhet te Brokeri 1. N\u00eb rastin e d\u00ebshtimit nuk ka humbje t\u00eb t\u00eb dh\u00ebnave. N\u00eb Rradh\u00ebn B ka nj\u00ebzet mesazhe n\u00eb mjeshtrin\u00eb dhe vet\u00ebm dhjet\u00eb n\u00eb pasqyr\u00eb, pasi kjo radh\u00eb asnj\u00ebher\u00eb nuk ka riplikuar dhjet\u00eb mesazhet fillestare.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/c6cfef4bced5627bf243c2f020a42646.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 11. Rradha A kthehet te Brokeri 1 pa humbje mesazhesh<\/i><\/p>\n<p>N\u00eb t\u00eb dy radh\u00ebt pranojn\u00eb tani edhe nga dhjet\u00eb mesazhe. Tani bie Brokeri 1. Rradha A kalon pa probleme te pasqyra pa humbje mesazhesh. Sidoqoft\u00eb, Rradha B p\u00ebrballet me probleme. N\u00eb k\u00ebt\u00eb pik\u00eb ne mund t\u00eb optimizojm\u00eb ose disponueshm\u00ebrin\u00eb, ose konsistenc\u00ebn. <\/p>\n<p>N\u00ebse duam t\u00eb optimizojm\u00eb disponueshm\u00ebrin\u00eb, at\u00ebher\u00eb politika <b><i>ha-promote-on-failure<\/i><\/b> duhet t\u00eb vendoset n\u00eb <b><i>always<\/i><\/b>. Ky \u00ebsht\u00eb vlera e parazgjedhur, prandaj mund ta l\u00ebm\u00eb politik\u00ebn t\u00eb pap\u00ebrcaktuar fare. N\u00eb k\u00ebt\u00eb rast, n\u00eb thelb, ne lejojm\u00eb d\u00ebshtime n\u00eb pasqyrat q\u00eb nuk jan\u00eb n\u00eb sinkronizim. Kjo do t\u00eb \u00e7oj\u00eb n\u00eb humbje mesazhesh, por rradha mbetet e disponueshme p\u00ebr lexim dhe shkrim.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/cd704cf4397184c212e1576b986abbaa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 12. Rradha A kthehet te Brokeri 3 pa humbje mesazhesh. Rradha B kthehet te Brokeri 3 me humbje t\u00eb dhjet\u00eb mesazheve<\/i><\/p>\n<p>Ne gjithashtu mund t\u00eb vendosim <code>ha-promote-on-failure<\/code> n\u00eb vler\u00ebn <code>when-synced<\/code>. N\u00eb k\u00ebt\u00eb rast, n\u00eb vend q\u00eb t\u00eb kthehet te pasqyra, rradha do t\u00eb pres\u00eb derisa Brokeri 1 me t\u00eb dh\u00ebnat e tij t\u00eb kthehet n\u00eb operim. Pas rikthimit t\u00eb tij, rradha kryesore kthehet p\u00ebrs\u00ebri te Brokeri 1 pa humbje t\u00eb t\u00eb dh\u00ebnave. Disponueshm\u00ebria sakrifikohet p\u00ebr sigurin\u00eb e t\u00eb dh\u00ebnave. Por kjo \u00ebsht\u00eb nj\u00eb m\u00ebnyr\u00eb me rrezik, e cila mund t\u00eb \u00e7oj\u00eb madje n\u00eb humbjen e plot\u00eb t\u00eb t\u00eb dh\u00ebnave, \u00e7ka do ta shqyrtojm\u00eb s\u00eb shpejti.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/03fed936fe75220e22f68432ca81b654.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 13. Rradha B mbetet e paqasshme pas humbjes s\u00eb Brokerit 1<\/i><\/p>\n<p>Mund t\u00eb b\u00ebni nj\u00eb pyetje: \"A \u00ebsht\u00eb ndoshta m\u00eb mir\u00eb t\u00eb mos p\u00ebrdorni kurr\u00eb sinkronizimin automatik?\". P\u00ebrshtypja \u00ebsht\u00eb se sinkronizimi \u00ebsht\u00eb nj\u00eb operacion bllokues. Gjat\u00eb sinkronizimit, rradha kryesore nuk mund t\u00eb kryej\u00eb asnj\u00eb operacion lexim ose shkrim!<\/p>\n<p>Le t\u00eb shqyrtojm\u00eb nj\u00eb shembull. Tani kemi radh\u00eb shum\u00eb t\u00eb m\u00ebdha. Si mund t\u00eb arrijn\u00eb t\u00eb rriten n\u00eb k\u00ebt\u00eb madh\u00ebsi? P\u00ebr disa arsye:<\/p>\n<ul>\n<li>Rradhat nuk p\u00ebrdoren aktivisht\n<\/li>\n<li>K\u00ebto jan\u00eb rradha me shpejt\u00ebsi t\u00eb lart\u00eb, dhe tani konsumator\u00ebt po punojn\u00eb ngadal\u00eb \n<\/li>\n<li>K\u00ebto jan\u00eb rradha me shpejt\u00ebsi t\u00eb lart\u00eb, ndodhi nj\u00eb d\u00ebshtim dhe konsumator\u00ebt po arrijn\u00eb<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/dd4b0fd70cbbc0b7defc06536157770d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 14. Dy dy big queues with different synchronization modes<\/i><\/p>\n<p>Now Broker 3 is crashing.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/8c31cfdf485ab4c9dfe13e86a151df4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 15. Broker 3 crashes, leaving one master and one mirror in each queue<\/i><\/p>\n<p>Broker 3 returns to operation, and new mirrors are created. The main Queue A starts replicating existing messages to the new mirror, and during this time the Queue is unavailable. Data replication takes two hours, resulting in two hours of downtime for this Queue!<\/p>\n<p>However, Queue B remains available throughout the period. It sacrificed some redundancy for availability.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/28e641300a1c3f4d70e29a16db51521e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 16. The queue remains unavailable during synchronization<\/i><\/p>\n<p>After two hours, Queue A also becomes available and can again start accepting read and write operations.<\/p>\n<h3>Azhurnimet<\/h3>\n<p>\nSuch blocking behavior during synchronization complicates updates to clusters with very large queues. At some point, the node with the master needs to be restarted, which means either switching to a mirror or taking the queue offline during the server update. If we choose to switch, we will lose messages if the mirrors are not synchronized. By default, during broker shutdown, switching to an unsynchronized mirror does not occur. This means that as soon as the broker returns, we lose no messages; the only damage done is the queue's downtime. The rules for behavior during broker shutdown are set by policy. <code>ha-promote-on-shutdown<\/code>. You can set one of two values:<\/p>\n<ul>\n<li><code>always<\/code>= enable switching to unsynchronized mirrors\n<\/li>\n<li><code>when-synced<\/code>= switch only to a synchronized mirror; otherwise, the queue becomes unavailable for reading and writing. The queue returns to operation as soon as the broker returns.<\/li>\n<\/ul>\n<p>\nEither way, with large queues, one has to choose between data loss and unavailability.<\/p>\n<h3>When availability increases data security<\/h3>\n<p>\nBefore making a decision, one must consider another complication. While automatic synchronization is better for redundancy, how does it affect data security? Of course, with better redundancy, RabbitMQ is less likely to lose existing messages, but what about new messages from publishers?<\/p>\n<p>One must consider the following:<\/p>\n<ul>\n<li>A mund t\u00eb kthej\u00eb nj\u00eb publisher gabim, dhe sh\u00ebrbimi m\u00eb i lart\u00eb ose p\u00ebrdoruesi t\u00eb provoj\u00eb p\u00ebrs\u00ebri 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 publisher-i \u00ebsht\u00eb n\u00eb gjendje vet\u00ebm t\u00eb heq\u00eb mesazhin, at\u00ebher\u00eb p\u00ebrmir\u00ebsimi i disponueshm\u00ebris\u00eb gjithashtu rrit sigurin\u00eb e t\u00eb dh\u00ebnave.<\/p>\n<p>Prandaj, duhet t\u00eb k\u00ebrkohet nj\u00eb ekuilib\u00ebr dhe zgjidhja varet nga situata e ve\u00e7ant\u00eb.<\/p>\n<h1>Problemet me ha-promote-on-failure=when-synced<\/h1>\n<p>\nIdeja <i><b>ha-promote-on-failure<\/b><\/i>= <i><b>when-synced<\/b><\/i> ka t\u00eb b\u00ebj\u00eb me faktin se ne parandalojm\u00eb kalimin n\u00eb nj\u00eb pasqyr\u00eb t\u00eb pa sinkronizuar dhe k\u00ebshtu shmangim humbjen e t\u00eb dh\u00ebnave. Rrjeti mbetet i paqassh\u00ebm p\u00ebr lexim ose shkrim. N\u00eb vend t\u00eb k\u00ebsaj, ne p\u00ebrpiqemi t\u00eb rikthejm\u00eb brokerin e r\u00ebn\u00eb me t\u00eb dh\u00ebna t\u00eb paprekura q\u00eb t\u00eb vazhdoj\u00eb si master pa humbur t\u00eb dh\u00ebnat. <\/p>\n<p>Por (dhe ky \u00ebsht\u00eb nj\u00eb \u00e7\u00ebshtje e madhe) n\u00ebse brokeri humbi t\u00eb dh\u00ebnat e tij, at\u00ebher\u00eb kemi nj\u00eb problem t\u00eb madh: rrjeti \u00ebsht\u00eb humbur! T\u00eb gjitha t\u00eb dh\u00ebnat jan\u00eb zhdukur! Edhe n\u00ebse keni pasqyra q\u00eb zakonisht e ndjekin rrjetin kryesor, k\u00ebto pasqyra gjithashtu jan\u00eb hequr.<\/p>\n<p>P\u00ebr t\u00eb riem\u00ebruar nj\u00eb nyj\u00eb me t\u00eb nj\u00ebjtin em\u00ebr, ne i themi klashtit t\u00eb harroj\u00eb nyj\u00ebn e humbur (me komand\u00ebn <i>rabbitmqctl forget_cluster_node<\/i>) dhe t\u00eb nisin nj\u00eb broker t\u00eb ri me t\u00eb nj\u00ebjtin em\u00ebr host. Derisa klasteri t\u00eb mbaj\u00eb mend nyj\u00ebn e humbur, ai mban edhe rrjetin e vjet\u00ebr dhe pasqyrat e pa sinkronizuar. Kur klasterit i thuhet t\u00eb harroj\u00eb nyj\u00ebn e humbur, ky rrjet gjithashtu harrohet. Tani duhet ta shpallim p\u00ebrs\u00ebri. Ne kemi humbur t\u00eb gjitha t\u00eb dh\u00ebnat, megjith\u00ebse kishim pasqyra me nj\u00eb grup t\u00eb pjessh\u00ebm t\u00eb t\u00eb dh\u00ebnave. Do t\u00eb ishte m\u00eb mir\u00eb t\u00eb kalonim n\u00eb nj\u00eb pasqyr\u00eb t\u00eb pa sinkronizuar!<\/p>\n<p>Prandaj, sinkronizimi manual (dhe mosrealizimi i sinkronizimit) s\u00eb bashku me <code>ha-promote-on-failure=when-synced<\/code>, n\u00eb mendimin tim, \u00ebsht\u00eb mjaft i rreziksh\u00ebm. Dokumentet thon\u00eb se ky opsion ekziston p\u00ebr sigurin\u00eb e t\u00eb dh\u00ebnave, por \u00ebsht\u00eb nj\u00eb thik\u00eb me dy tehe.<\/p>\n<h1>Ribalan\u00e7imi i master\u00ebve<\/h1>\n<p>\nSi\u00e7 u premtua, kthehemi te problemi i grumbullimit t\u00eb t\u00eb gjith\u00eb master\u00ebve n\u00eb nj\u00eb ose m\u00eb shum\u00eb nyje. Kjo mund t\u00eb ndodh\u00eb edhe si rezultat i nj\u00eb p\u00ebrdit\u00ebsimi 'rr\u00ebshqit\u00ebs' (rolling) t\u00eb klasterit. N\u00eb nj\u00eb klaster me tre nyje, t\u00eb gjitha rrjetet kryesore do t\u00eb grumbullohen n\u00eb nj\u00eb ose dy nyje.<\/p>\n<p>Ribalan\u00e7imi i master\u00ebve mund t\u00eb jet\u00eb problematik p\u00ebr dy arsye:<\/p>\n<ul>\n<li>Nuk ka mjete t\u00eb mira p\u00ebr t\u00eb realizuar ribalan\u00e7imin<\/li>\n<li>Sinkronizimi i rrjeteve<\/li>\n<\/ul>\n<p>\nP\u00ebr ribalan\u00e7imin ekziston nj\u00eb plug-in t\u00eb tret\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Ayanda-D\/rabbitmq-queue-master-balancer\">plugin<\/a><\/noindex>, i cili nuk mb\u00ebshtetet zyrtarisht. N\u00eb lidhje me plugins e jashtme n\u00eb udh\u00ebzimin e RabbitMQ <noindex><a rel=\"nofollow\" href=\"https:\/\/www.rabbitmq.com\/upgrade.html\">thuhet<\/a><\/noindex>: \u00abPlugin'i ofron disa mjete shtes\u00eb p\u00ebr konfigurimin dhe raportimin, por nuk mb\u00ebshtetet dhe nuk \u00ebsht\u00eb kontrolluar nga ekipi i RabbitMQ. P\u00ebrdorni me rrezikun tuaj\u00bb.<\/p>\n<p>Ekziston edhe nj\u00eb mashtrim tjet\u00ebr p\u00ebr t\u00eb zhvendosur rreshtin kryesor p\u00ebrmes politikave HA. N\u00eb udh\u00ebzimin p\u00ebrmendet <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/rabbitmq\/support-tools\/blob\/master\/scripts\/rebalance-queue-masters\">skript<\/a><\/noindex> p\u00ebr k\u00ebt\u00eb. Funksionon k\u00ebshtu:<\/p>\n<ul>\n<li>Fshin t\u00eb gjitha pasqyrat duke p\u00ebrdorur nj\u00eb politik\u00eb p\u00ebrkoh\u00ebsisht me prioritet m\u00eb t\u00eb lart\u00eb se politika ekzistuese HA.\n<\/li>\n<li>Ndryshon politik\u00ebn p\u00ebrkoh\u00ebsisht HA p\u00ebr t\u00eb p\u00ebrdorur modalitetin 'nodi' me tregimin e nodit ku duhet t\u00eb zhvendoset rreshti kryesor.\n<\/li>\n<li>Sinkronizon rreshtin p\u00ebr migrim t\u00eb detyruar.\n<\/li>\n<li>Pas p\u00ebrfundimit t\u00eb migrimit, fshin politik\u00ebn p\u00ebrkoh\u00ebsisht. Politika origjinale HA hyjn\u00eb n\u00eb veprim dhe krijohen numri i nevojsh\u00ebm i pasqyrave.<\/li>\n<\/ul>\n<p>\nDisavantazhi \u00ebsht\u00eb se ky qasje mund t\u00eb mos funskionoj\u00eb n\u00ebse keni rreshta t\u00eb m\u00ebdhenj ose k\u00ebrkesa strikte p\u00ebr tep\u00ebrsi.<\/p>\n<p>Tani le t\u00eb shohim se si funksionojn\u00eb klaster\u00ebt RabbitMQ me ndarjet e rrjetit.<\/p>\n<h1>Nd\u00ebrprerja e lidhjes<\/h1>\n<p>\nNodet e sistemit t\u00eb shp\u00ebrndar\u00eb lidhen me lidhje rrjetesh, dhe lidhjet rrjetike mund dhe do t\u00eb shk\u00ebputen. Shpesh shk\u00ebputjesh varet nga infrastruktura lokale apo besueshm\u00ebria e sistemit t\u00eb zgjedhur t\u00eb re. N\u00eb \u00e7do rast, sistemet e shp\u00ebrndara duhet t\u00eb jen\u00eb t\u00eb afta p\u00ebr t'u p\u00ebrballur me to. P\u00ebrs\u00ebri kemi zgjedhjen midis disponueshm\u00ebris\u00eb dhe koherenc\u00ebs, dhe p\u00ebrs\u00ebri lajm i mir\u00eb \u00ebsht\u00eb se RabbitMQ ofron t\u00eb dyja opsionet (thjesht jo nj\u00ebkoh\u00ebsisht).<\/p>\n<p>Me RabbitMQ kemi dy opsione kryesore:<\/p>\n<ul>\n<li>T\u00eb lejojm\u00eb ndarjen logjike (split-brain). Kjo siguron disponueshm\u00ebri, por mund t\u00eb provokoj\u00eb humbjen e t\u00eb dh\u00ebnave.\n<\/li>\n<li>T\u00eb ndalojm\u00eb ndarjen logjike. Mund t\u00eb \u00e7oj\u00eb n\u00eb humbje t\u00eb p\u00ebrkohshme t\u00eb disponueshm\u00ebris\u00eb n\u00eb var\u00ebsi t\u00eb m\u00ebnyr\u00ebs s\u00eb lidhjes s\u00eb klient\u00ebve me klasterin. Po ashtu mund t\u00eb shkaktoj\u00eb plot\u00ebsisht pamund\u00ebsi n\u00eb klasterin me dy node.<\/li>\n<\/ul>\n<p>\nPor \u00e7far\u00eb \u00ebsht\u00eb ndarja logjike? Kjo \u00ebsht\u00eb kur klasteri ndahet n\u00eb dy pjes\u00eb p\u00ebr shkak t\u00eb humbjes s\u00eb lidhjeve rrjetike. N\u00eb secil\u00ebn an\u00eb, pasqyrat ngrihen n\u00eb master, k\u00ebshtu q\u00eb n\u00eb fund \u00e7do rresht ka disa mastera.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/d880a935df450fb994edfed0715e026e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 17. Kryeqendra dhe dy pasqyra, secila n\u00eb nyj\u00eb t\u00eb ndryshme. Pastaj ndodh nj\u00eb d\u00ebshtim rrjeti, dhe nj\u00eb pasqyr\u00eb ndahet. Nyja e ndar\u00eb sheh se dy t\u00eb tjera kan\u00eb r\u00ebn\u00eb, dhe avancojn\u00eb pasqyrat e tyre deri te masteri. Tani kemi dy kryeqendra, dhe t\u00eb dyja lejojn\u00eb t\u00eb shkruhet dhe t\u00eb lexohen.<\/i> <\/p>\n<p>N\u00ebse botuesit d\u00ebrgojn\u00eb t\u00eb dh\u00ebna n\u00eb t\u00eb dy masterat, do t\u00eb kemi dy kopje q\u00eb ndahen t\u00eb radh\u00ebs.<\/p>\n<p>Modet e ndryshme t\u00eb RabbitMQ ofrojn\u00eb ose disponueshm\u00ebri, ose konsistenc\u00eb.<\/p>\n<h3>Modi Ignore (n\u00eb parazgjedhje)<\/h3>\n<p>\nKy mod ofron disponueshm\u00ebri. Pas humbjes s\u00eb lidhjes ndodh nj\u00eb ndarje logjike. Pas rikthimit t\u00eb lidhjes, administratori duhet t\u00eb vendos\u00eb se cil\u00ebs ndarje t'i jap\u00eb p\u00ebrpar\u00ebsi. Anija e humbur do t\u00eb riniset, dhe t\u00eb dh\u00ebnat e grumbulluara nga kjo anije humben.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/4d82c13b5ef21837ba819f5c246a1e41.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 18. Tre botues jan\u00eb t\u00eb lidhur me tre broker\u00eb. Brenda, klasteri drejton t\u00eb gjitha k\u00ebrkesat n\u00eb kryeqendr\u00ebn n\u00eb Brokerin 2.<\/i><\/p>\n<p>Tani ne e humbim Brokerin 3. Ai sheh se broker\u00ebt e tjer\u00eb kan\u00eb r\u00ebn\u00eb, dhe avancon pasqyr\u00ebn e tij deri te masteri. K\u00ebshtu ndodh ndarja logjike.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/c7e01d51b24023bacdd93cfad95c9eab.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 19. Ndarja logjike (split-brain). Shkrimet shkojn\u00eb n\u00eb dy kryeqendra, dhe dy kopjet ndahen.<\/i><\/p>\n<p>Lidhja rikthehet, por ndarja logjike mbetet. Administratori duhet t\u00eb zgjedh\u00eb me dor\u00eb an\u00ebn e humbur. N\u00eb rastin e m\u00ebposht\u00ebm, administratori rinis Brokerin 3. T\u00eb gjitha mesazhet q\u00eb ai nuk arriti t'i d\u00ebrgoj\u00eb humbin.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/51c3ee15024d3c83ba625e3ff9cdeb90.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 20. Administratori \u00e7on n\u00eb ndales\u00ebn e Brokerit 3.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/0bac8e33de25c0c5381d336d26464858.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 21. Administratori fillon Brokerin 3 dhe ai bashkohet me klasterin, duke humbur t\u00eb gjitha mesazhet q\u00eb ishin aty.<\/i><\/p>\n<p>Gjat\u00eb humbjes s\u00eb lidhjes dhe pas rikthimit t\u00eb saj, klasteri dhe kjo kryeqend\u00ebr ishin t\u00eb disponueshme p\u00ebr shkrim dhe lexim.<\/p>\n<h3>Modi Autoheal<\/h3>\n<p>\nFunksionon ashtu si moda Ignore, p\u00ebrve\u00e7 se klasteri automatikisht zgjedh an\u00ebn e humbur pas ndarjes dhe rikthimit t\u00eb lidhjes. Anija e humbur kthehet n\u00eb klaster bosh, dhe kryeqendra humb t\u00eb gjitha mesazhet q\u00eb ishin d\u00ebrguar vet\u00ebm n\u00eb at\u00eb an\u00eb.<\/p>\n<h3>Modi Pause Minority<\/h3>\n<p>\nN\u00ebse nuk duam t\u00eb lejojm\u00eb nj\u00eb ndarje logjike, opsioni yn\u00eb i vet\u00ebm \u00ebsht\u00eb t\u00eb heqim dor\u00eb nga leximi dhe shkrimi n\u00eb an\u00ebn m\u00eb t\u00eb vog\u00ebl pas ndarjes s\u00eb klasterit. Kur brokeri sheh q\u00eb ndodhet n\u00eb an\u00ebn m\u00eb t\u00eb vog\u00ebl, ai ndalon pun\u00ebn, pra mbyll t\u00eb gjitha lidhjet e ekzistuara dhe refuzon \u00e7do t\u00eb re. Nj\u00eb her\u00eb n\u00eb sekond\u00eb, ai kontrollon rikuperimin e lidhshm\u00ebris\u00eb. Sa her\u00eb q\u00eb lidhshm\u00ebria rikuperohet, ai rifillon pun\u00ebn dhe bashkohet me klasterin.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/7a51cf509b2c94e2ae100c7dedd9d21a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 22. Tre publikues jan\u00eb t\u00eb lidhur me tre broker\u00eb. Brenda, klasteri drejton t\u00eb gjitha k\u00ebrkesat n\u00eb radh\u00ebn kryesore n\u00eb Brokerin 2.<\/i><\/p>\n<p>Pastaj Broker\u00ebt 1 dhe 2 ndahen nga Brokeri 3. N\u00eb vend q\u00eb t\u00eb rris\u00eb pasqin\u00eb e tij n\u00eb master, Brokeri 3 ndalon pun\u00ebn dhe b\u00ebhet i pap\u00ebrshtatsh\u00ebm.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/c12ec38a47e1f8ccceebfa1854f54f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 23. Brokeri 3 ndalon pun\u00ebn, \u00e7aktivizon t\u00eb gjith\u00eb klient\u00ebt dhe refuzon k\u00ebrkesat p\u00ebr lidhje.<\/i><\/p>\n<p>Sa her\u00eb q\u00eb lidhshm\u00ebria rikuperohet, ai kthehet n\u00eb klaster.<\/p>\n<p>Le t\u00eb shikojm\u00eb nj\u00eb shembull tjet\u00ebr, ku rada kryesore ndodhet n\u00eb Brokerin 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/4cc6a28270f00a280ecb5af5252f4e07.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 24. Rada kryesore n\u00eb Brokerin 3.<\/i><\/p>\n<p>Pastaj ndodh e nj\u00ebjta humbje lidhshm\u00ebrie. Brokeri 3 ndalon, pasi ndodhet n\u00eb an\u00ebn m\u00eb t\u00eb vog\u00ebl. N\u00eb an\u00ebn tjet\u00ebr, nyjat shohin q\u00eb Brokeri 3 \u00ebsht\u00eb ndar\u00eb, k\u00ebshtu q\u00eb nj\u00eb pasqyr\u00eb m\u00eb e vjet\u00ebr nga Broker\u00ebt 1 dhe 2 rritet n\u00eb master.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/d0d032385533bb53c5a95927afcd3119.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 25. Kalimi te Brokeri 2 n\u00eb pap\u00ebrshtatshm\u00ebrin\u00eb e Brokerit 3.<\/i><\/p>\n<p>Kur lidhshm\u00ebria rikuperohet, Brokeri 3 do t'i bashkohet klasterit.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kund\u00ebr Kafka: q\u00ebndrueshm\u00ebri dhe disponueshm\u00ebri e lart\u00eb n\u00eb klastere\" src=\"\/wp-content\/uploads\/2019\/11\/53f8186a040ae07724ef59cf79b72a0c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 26. Klasteri u kthye n\u00eb pun\u00ebn normale.<\/i><\/p>\n<p>K\u00ebtu \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb kuptojm\u00eb se ne arrijm\u00eb konsistenc\u00eb, por gjithashtu mund t\u00eb arrijm\u00eb disponueshm\u00ebri, <i><b>n\u00ebse<\/b><\/i> me sukses t\u00eb transferojm\u00eb klient\u00ebt n\u00eb pjes\u00ebn m\u00eb t\u00eb madhe t\u00eb ndarjes. P\u00ebr shumic\u00ebn e situatave, personalisht do t\u00eb zgjidhja modin Pause Minority, por kjo v\u00ebrtet varet nga rasti i ve\u00e7ant\u00eb.<\/p>\n<p>P\u00ebr t\u00eb siguruar disponueshm\u00ebrin\u00eb, \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb sigurohemi q\u00eb klient\u00ebt lidhen me sukses me nyj\u00ebn. Le t\u00eb shqyrtojm\u00eb opsionet tona.<\/p>\n<h1>Sigurimi i lidhshm\u00ebris\u00eb s\u00eb klient\u00ebve<\/h1>\n<p>\nNe kemi disa mund\u00ebsi se si t\u00eb drejtojm\u00eb klient\u00ebt n\u00eb pjes\u00ebn kryesore t\u00eb klasterit ose n\u00eb nyjat q\u00eb punojn\u00eb (pas d\u00ebshtimit t\u00eb nj\u00eb nyjeje). S\u00eb pari, le t\u00eb kujtojm\u00eb se radh\u00ebt specifike vendosen n\u00eb nj\u00eb nyje t\u00eb caktuar, por rrug\u00ebtimi dhe politikat riprodhohen n\u00eb t\u00eb gjitha nyjat. Klient\u00ebt mund t\u00eb lidhen me \u00e7do nyje, dhe rrug\u00ebtimi i brendsh\u00ebm do t'i drejtoj\u00eb ata aty ku duhet. Por kur nj\u00eb nyje \u00ebsht\u00eb pezull, ajo refuzon lidhjet, k\u00ebshtu q\u00eb klient\u00ebt duhet t\u00eb lidhen me nj\u00eb nyje tjet\u00ebr. N\u00ebse nj\u00eb nyje ndalon, ajo n\u00eb t\u00eb v\u00ebrtet\u00eb nuk mund t\u00eb b\u00ebj\u00eb shum\u00eb.<\/p>\n<p>Mund\u00ebsit\u00eb tona:<\/p>\n<ul>\n<li>Qasja n\u00eb klaster \u00ebsht\u00eb e mundur p\u00ebrmes balancuesit t\u00eb ngarkes\u00ebs, i cili thjesht kalon n\u00ebp\u00ebr nyjat, nd\u00ebrsa klient\u00ebt kryejn\u00eb p\u00ebrpjekje t\u00eb p\u00ebrs\u00ebritura p\u00ebr lidhje deri n\u00eb p\u00ebrfundim t\u00eb suksessh\u00ebm. N\u00ebse nj\u00eb nyje nuk punon ose \u00ebsht\u00eb pezull, p\u00ebrpjekjet p\u00ebr lidhje me k\u00ebt\u00eb nyje do t\u00eb d\u00ebshtojn\u00eb, por p\u00ebrpjekjet e m\u00ebpasshme do t\u00eb shkojn\u00eb n\u00eb servera t\u00eb tjer\u00eb (n\u00eb m\u00ebnyr\u00eb ciklike). Kjo \u00ebsht\u00eb e p\u00ebrshtatshme p\u00ebr nj\u00eb humbje t\u00eb shkurt\u00ebr t\u00eb lidhjes ose p\u00ebr nj\u00eb server q\u00eb ka r\u00ebn\u00eb dhe do t\u00eb rrije shpejt.\n<\/li>\n<li>Qasja n\u00eb klaster p\u00ebrmes balancuesit t\u00eb ngarkes\u00ebs dhe heqja e nyjave t\u00eb pezulluara\/d\u00ebmtuara nga lista, sa her\u00eb q\u00eb identifikohen. N\u00ebse b\u00ebhet shpejt, dhe n\u00ebse klient\u00ebt jan\u00eb n\u00eb gjendje t\u00eb kryejn\u00eb p\u00ebrpjekjet e lidhjes, at\u00ebher\u00eb ne do t\u00eb arrijm\u00eb nj\u00eb disponueshm\u00ebri t\u00eb vazhdueshme.\n<\/li>\n<li>T\u00eb jepni \u00e7do klienti nj\u00eb list\u00eb t\u00eb t\u00eb gjitha nyjave, dhe klienti, kur lidhet, zgjedh rast\u00ebsisht nj\u00eb prej tyre. N\u00ebse gjat\u00eb p\u00ebrpjekjes p\u00ebr lidhje merr nj\u00eb gabim, ai kalon n\u00eb nyj\u00ebn e ardhshme n\u00eb list\u00eb, derisa t\u00eb krijoj\u00eb lidhjen.\n<\/li>\n<li>T\u00eb largoni trafik nga nyja e r\u00ebn\u00eb\/pezulluar p\u00ebrmes DNS. Kjo b\u00ebhet me nj\u00eb TTL t\u00eb vog\u00ebl.<\/li>\n<\/ul>\n<p><\/p>\n<h1>P\u00ebrfundimet<\/h1>\n<p>\nKlasterizimi i RabbitMQ ka p\u00ebrfitimet dhe disavantazhet e veta. Dezavantazhet m\u00eb serioze jan\u00eb:<\/p>\n<ul>\n<li>kur nyjat bashkohen n\u00eb klaster, ato heqin dor\u00eb nga t\u00eb dh\u00ebnat e tyre;\n<\/li>\n<li>sinkronizimi bllokues \u00e7on n\u00eb paaft\u00ebsin\u00eb e radh\u00ebs.<\/li>\n<\/ul>\n<p>\nT\u00eb gjitha vendimet e v\u00ebshtira rrjedhin nga k\u00ebto dy karakteristika t\u00eb arkitektur\u00ebs. N\u00ebse RabbitMQ do t\u00eb kishte mund\u00ebsin\u00eb t\u00eb ruante t\u00eb dh\u00ebnat gjat\u00eb ri-nd\u00ebrlidhjes s\u00eb klasterit, at\u00ebher\u00eb sinkronizimi do t\u00eb ndodhte m\u00eb shpejt. N\u00ebse do t\u00eb ishte n\u00eb gjendje t\u00eb b\u00ebnte sinkronizim pa bllokim, do t\u00eb mb\u00ebshteste m\u00eb mir\u00eb radh\u00ebt e m\u00ebdha. Zgjidhja e k\u00ebtyre dy problemeve do t\u00eb p\u00ebrmir\u00ebsonte ndjesh\u00ebm karakteristikat e RabbitMQ si nj\u00eb teknologji e besueshme dhe me akses t\u00eb lart\u00eb p\u00ebr shk\u00ebmbimin e mesazheve. Un\u00eb nuk do t\u00eb rekomandoja RabbitMQ me klasterizim n\u00eb situatat e m\u00ebposhtme:<\/p>\n<ul>\n<li>Rrjet i pasigurt.\n<\/li>\n<li>Ruajtje e pasigurt.\n<\/li>\n<li>Radh\u00eb shum\u00eb t\u00eb m\u00ebdha.<\/li>\n<\/ul>\n<p>\nSa i p\u00ebrket konfigurimeve p\u00ebr akses t\u00eb lart\u00eb, shqyrtoni k\u00ebto:<\/p>\n<ul>\n<li><code>ha-promote-on-failure=always<\/code>\n<\/li>\n<li><code>ha-sync-mode=manual<\/code>\n<\/li>\n<li><code>cluster_partition_handling=ignore<\/code> (ose <code>autoheal<\/code>)\n<\/li>\n<li>mesazhe t\u00eb q\u00ebndrueshme\n<\/li>\n<li>sigurohuni q\u00eb klient\u00ebt t\u00eb lidhen me nodin aktiv kur ndonj\u00eb nod del nga funksioni<\/li>\n<\/ul>\n<p>\nP\u00ebr koherenc\u00ebn (sigurin\u00eb e t\u00eb dh\u00ebnave) shqyrtoni k\u00ebto konfigurime:<\/p>\n<ul>\n<li>Publisher Confirms dhe Manual Acknowledgements nga ana e konsumatorit\n<\/li>\n<li><code>ha-promote-on-failure=when-synced<\/code>, n\u00ebse botuesit mund t\u00eb p\u00ebrpiqen p\u00ebrs\u00ebri m\u00eb von\u00eb dhe n\u00ebse keni nj\u00eb ruajtje shum\u00eb t\u00eb besueshme! P\u00ebrndryshe vendosni <code>=always<\/code>.\n<\/li>\n<li><code>ha-sync-mode=automatic<\/code> (por p\u00ebr radh\u00eb t\u00eb m\u00ebdha joaktive mund t\u00eb k\u00ebrkohet nj\u00eb mod manual; p\u00ebr m\u00eb tep\u00ebr, mendoni n\u00ebse mos aksesimi do t\u00eb \u00e7onte n\u00eb humbje mesazhesh)\n<\/li>\n<li>modi Pause Minority\n<\/li>\n<li>mesazhe t\u00eb q\u00ebndrueshme<\/li>\n<\/ul>\n<p>\nNuk i kemi shqyrtuar t\u00eb gjitha \u00e7\u00ebshtjet e besueshm\u00ebris\u00eb dhe aksesit t\u00eb lart\u00eb; p\u00ebr shembull, si t\u00eb kryeni procedura administrative n\u00eb siguri (si p\u00ebrdit\u00ebsimet e vazhdueshme). Duhet t\u00eb flasim gjithashtu p\u00ebr federat\u00ebn dhe plugin-in Shovel.<\/p>\n<p>N\u00ebse kam humbur ndonj\u00eb gj\u00eb, ju lutem m\u00eb njoftoni.<\/p>\n<p>Shihni gjithashtu artikullin tim <noindex><a rel=\"nofollow\" href=\"https:\/\/jack-vanlightly.com\/blog\/2018\/9\/10\/how-to-lose-messages-on-a-rabbitmq-cluster\">nj\u00eb postim<\/a><\/noindex>, ku realizoj nj\u00eb p\u00ebrshkall\u00ebzim n\u00eb klasterin RabbitMQ duke p\u00ebrdorur Docker dhe Blockade p\u00ebr t\u00eb testuar disa skenar\u00eb t\u00eb humbjes s\u00eb mesazheve q\u00eb jan\u00eb p\u00ebrshkruar n\u00eb k\u00ebt\u00eb artikull.<\/p>\n<p>Artikujt e m\u00ebparsh\u00ebm t\u00eb seris\u00eb: <br \/>\nNr. 1 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/416629\/\">habr.com\/ru\/company\/itsumma\/blog\/416629<\/a><\/noindex> <br \/>\nNr. 2 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/418389\/\">habr.com\/ru\/company\/itsumma\/blog\/418389<\/a><\/noindex> <br \/>\nNr. 3 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/437446\/\">habr.com\/ru\/company\/itsumma\/blog\/437446<\/a><\/noindex><br \/>\n<br \/>Burimi: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/471858\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041e\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 \u2014 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0442\u0435\u043c\u044b, \u0442\u0430\u043a \u0447\u0442\u043e \u043f\u043e\u0441\u0432\u044f\u0442\u0438\u043c RabbitMQ \u0438 Kafka \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0435 \u0441\u0442\u0430\u0442\u044c\u0438. \u0414\u0430\u043d\u043d\u0430\u044f \u0441\u0442\u0430\u0442\u044c\u044f \u043e RabbitMQ, \u0430 \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u2014 \u043e Kafka, \u0432 \u0441\u0440\u0430\u0432\u043d\u0435\u043d\u0438\u0438 \u0441 RabbitMQ. \u0421\u0442\u0430\u0442\u044c\u044f \u0434\u043b\u0438\u043d\u043d\u0430\u044f, \u0442\u0430\u043a \u0447\u0442\u043e \u0443\u0441\u0442\u0440\u0430\u0438\u0432\u0430\u0439\u0442\u0435\u0441\u044c \u043f\u043e\u0443\u0434\u043e\u0431\u043d\u0435\u0435. \u0420\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0441\u0442\u0440\u0430\u0442\u0435\u0433\u0438\u0438 \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438, \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u0438 \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u0438 (HA), \u0430 \u0442\u0430\u043a\u0436\u0435 \u043a\u043e\u043c\u043f\u0440\u043e\u043c\u0438\u0441\u0441\u044b, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0438\u0434\u0442\u0438 \u0432 \u043a\u0430\u0436\u0434\u043e\u0439 \u0441\u0442\u0440\u0430\u0442\u0435\u0433\u0438\u0438. RabbitMQ \u043c\u043e\u0436\u0435\u0442 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c [&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-52525","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=\".\" \/>\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-v-klasterah\" \/>\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 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\".\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah\" \/>\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-09T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:00:16+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: besueshm\u00ebria dhe akses i lart\u00eb n\u00eb klastere | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","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 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 | ProHoster","og:description":".","og:url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","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-09T21:00:00+00:00","article:modified_time":"2020-02-18T11:00:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52525","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:54:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:41:25","updated":"2026-01-24 03:54:19","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\/52525","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=52525"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/52525\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=52525"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=52525"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=52525"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}