{"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 \/>\nRreth q\u00ebndrueshm\u00ebris\u00eb dhe disponueshm\u00ebris\u00eb s\u00eb lart\u00eb - k\u00ebto jan\u00eb tema t\u00eb m\u00ebdha, prandaj do t'i kushtojm\u00eb artikuj t\u00eb ve\u00e7ant\u00eb RabbitMQ dhe Kafka. Ky artikull \u00ebsht\u00eb p\u00ebr RabbitMQ, nd\u00ebrsa artikulli tjet\u00ebr do t\u00eb jet\u00eb p\u00ebr Kafka, n\u00eb krahasim me RabbitMQ. Artikulli \u00ebsht\u00eb i gjat\u00eb, k\u00ebshtu q\u00eb b\u00ebhuni gati.<\/p>\n<p>Le t'i shqyrtojm\u00eb strategjit\u00eb e q\u00ebndrueshm\u00ebris\u00eb, koherenc\u00ebs dhe disponueshm\u00ebris\u00eb (HA), si dhe kompromiset q\u00eb duhet t\u00eb b\u00ebhen p\u00ebr \u00e7do strategji. RabbitMQ mund t\u00eb funksionoj\u00eb n\u00eb nj\u00eb klaster t\u00eb node-ve - dhe at\u00ebher\u00eb klasifikohet si nj\u00eb sistem t\u00eb shp\u00ebrndar\u00eb. Kur flasim p\u00ebr sistemet e shp\u00ebrndara, shpesh diskutojm\u00eb p\u00ebr koherenc\u00ebn dhe disponueshm\u00ebrin\u00eb. <\/p>\n<p>K\u00ebto koncepte p\u00ebrshkruajn\u00eb se si sistemi sillet n\u00eb rast t\u00eb d\u00ebshtimit. D\u00ebshtimi i lidhjes rrjetore, d\u00ebshtimi i serverit, d\u00ebshtimi i hard disku, mungesa e p\u00ebrkohshme e serverit p\u00ebr shkak t\u00eb pastrimit t\u00eb mbetjeve, humbja e paketave ose ngadal\u00ebsimi i lidhjes rrjetore. T\u00eb gjitha k\u00ebto mund t\u00eb \u00e7ojn\u00eb n\u00eb humbje t\u00eb t\u00eb dh\u00ebnave ose konflikte. T\u00eb duket e pamundur t\u00eb kesh nj\u00eb sistem q\u00eb \u00ebsht\u00eb nj\u00ebkoh\u00ebsisht dhe t\u00ebr\u00ebsisht i koherent (pa humbje t\u00eb t\u00eb dh\u00ebnave, pa mosmarr\u00ebveshje t\u00eb t\u00eb dh\u00ebnave) dhe t\u00eb disponuesh\u00ebm (do t\u00eb pranojn\u00eb operacione t\u00eb leximit dhe shkrimit) 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 ju duhet t\u00eb zgjidhni n\u00eb cilin drejtim t\u00eb optimizoni. Lajmi i mir\u00eb \u00ebsht\u00eb se me RabbitMQ ky zgjedhje \u00ebsht\u00eb e mundur. Keni disa \"lev\u00eb\" q\u00eb t\u00eb zhvendosni ekuilibrin drejt m\u00eb shum\u00eb koherenc\u00ebs ose m\u00eb shum\u00eb disponueshm\u00ebris\u00eb.<\/p>\n<p>M\u00eb shum\u00eb v\u00ebmendje do t'i kushtojm\u00eb cilave konfigurime \u00e7ojn\u00eb n\u00eb humbje t\u00eb t\u00eb dh\u00ebnave p\u00ebr shkak t\u00eb konfirmimeve t\u00eb regjistrimeve. Ka nj\u00eb zinxhir p\u00ebrgjegj\u00ebsie mes publisher-\u00ebve, broker-\u00ebve dhe konsumator\u00ebve. Pasi mesazhi \u00ebsht\u00eb dor\u00ebzuar broker-it, \u00ebsht\u00eb detyra e tij - t\u00eb mos humb\u00eb mesazhin. Kur broker-i konfirmon p\u00ebr publisher-in marrjen e mesazhit, ne nuk presim q\u00eb ai t\u00eb humbet. Por do t\u00eb shohim se kjo n\u00eb t\u00eb v\u00ebrtet\u00eb mund t\u00eb ndodh\u00eb n\u00eb var\u00ebsi t\u00eb konfigurimit t\u00eb broker-it dhe publisher-it tuaj.<\/p>\n<h1>Primitive t\u00eb q\u00ebndrueshm\u00ebris\u00eb s\u00eb nj\u00eb nodi<\/h1>\n<p><\/p>\n<h3>Radh\u00ebt e q\u00ebndrueshme\/rutimi<\/h3>\n<p>\nN\u00eb RabbitMQ ka dy lloje radh\u00ebsh: t\u00eb q\u00ebndrueshme (durable) dhe jo t\u00eb q\u00ebndrueshme (non-durable). T\u00eb gjitha radh\u00ebt ruhen n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave Mnesia. Radh\u00ebt e q\u00ebndrueshme shpallen p\u00ebrs\u00ebri gjat\u00eb nisjes s\u00eb nodit dhe k\u00ebshtu p\u00ebrjetojn\u00eb rindezjen, d\u00ebshtimin e sistemit ose d\u00ebshtimin e serverit (p\u00ebrsa koh\u00eb q\u00eb t\u00eb dh\u00ebnat ruhen). Kjo do t\u00eb thot\u00eb se p\u00ebr sa koh\u00eb q\u00eb shpallni rutin\u00ebn (exchange) dhe radh\u00ebn si t\u00eb q\u00ebndrueshme, infrastruktura e radh\u00ebve\/rutim do t\u00eb kthehet n\u00eb funksion.<\/p>\n<p>Radh\u00ebt dhe rutimi jo t\u00eb q\u00ebndrueshme fshihen gjat\u00eb rindezjes s\u00eb nodit.<\/p>\n<h3>Mesazhe t\u00eb q\u00ebndrueshme<\/h3>\n<p>\nFakti q\u00eb radha \u00ebsht\u00eb e q\u00ebndrueshme, nuk do t\u00eb thot\u00eb q\u00eb t\u00eb gjitha mesazhet e saj do t\u00eb p\u00ebrjetojn\u00eb rindezjen e nodit. Do t\u00eb rikthehen vet\u00ebm mesazhet q\u00eb publisher-i ka vendosur 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 mbi broker-in, por n\u00ebse humbja e mesazhit \u00ebsht\u00eb e papranueshme, nuk ka zgjidhje tjet\u00ebr.<\/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 pasqyrimin e radh\u00ebs<\/h1>\n<p>\nP\u00ebr t\u00eb p\u00ebrjetuar humbjen e broker-it, na nevojitet mbinxehje. Mund t\u00eb bashkojm\u00eb disa node t\u00eb RabbitMQ n\u00eb nj\u00eb klaster dhe pastaj t\u00eb shtojm\u00eb mbinxehje shtes\u00eb p\u00ebrmes replikimit t\u00eb radh\u00ebve mes disa node-ve. K\u00ebshtu, n\u00ebse nj\u00eb nod\u00eb bie, ne nuk humbim t\u00eb dh\u00ebna dhe mbetemi t\u00eb disponuesh\u00ebm. <\/p>\n<p>Pasqyrimi i radh\u00ebs:<\/p>\n<ul>\n<li>nj\u00eb radhe kryesore (master), e cila merr t\u00eb gjitha urdhrat p\u00ebr shkrim dhe lexim\n<\/li>\n<li>nj\u00eb ose disa pasqyra, t\u00eb cilat marrin t\u00eb gjitha mesazhet dhe metadata nga radha kryesore. K\u00ebto pasqyra ekzistojn\u00eb jo p\u00ebr shkall\u00ebzim, por ekskluzivisht p\u00ebr mbinxehje.<\/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 zgjidhni faktor\u00ebt e replikimit dhe madje edhe node-t mbi t\u00eb cilat duhet t\u00eb vendoset radha. 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 publisher-in<\/h1>\n<p>\nP\u00ebr t\u00eb arritur nj\u00eb shkruarje t\u00eb besueshme, jan\u00eb t\u00eb nevojshme konfirmimet p\u00ebr publisher-in (Publisher Confirms). Pa to ka mund\u00ebsi p\u00ebr humbje mesazhesh. Konfirmimi d\u00ebrgohet publisher-it pas regjistrimit t\u00eb mesazhit n\u00eb disk. RabbitMQ regjistron mesazhet n\u00eb disk jo me marrjen e tyre, por n\u00eb nj\u00eb baz\u00eb periodike, rreth disa qindra milisekondave. Kur radha pasqyrohet, konfirmimi d\u00ebrgohet vet\u00ebm pasi t\u00eb gjitha pasqyrat gjithashtu kan\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>Radha e q\u00ebndrueshme<\/h1>\n<p>\nKur brokeri p\u00ebrfundon pun\u00ebn ose bie, t\u00eb gjitha radh\u00ebt kryesore (masterat) n\u00eb k\u00ebt\u00eb nyje bien gjithashtu me t\u00eb. Pastaj, klust\u00ebri zgjodhi pasqyr\u00ebn m\u00eb t\u00eb vjet\u00ebr t\u00eb \u00e7do masteri dhe e avancoi si 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 bie. Vini re se pasqyra e Radh\u00ebs C mbi Brokerin 2 avancuar n\u00eb master. Gjithashtu, vini re se nj\u00eb pasqyr\u00eb e re p\u00ebr Radh\u00ebn C \u00ebsht\u00eb krijuar mbi Brokerin 1. RabbitMQ gjithmon\u00eb p\u00ebrpiqet t\u00eb mbaj\u00eb raportin e replikimit t\u00eb specifikuar 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 bie, duke shkaktuar d\u00ebshtimin e Radh\u00ebs C<\/i> <\/p>\n<p>Bie Brokeri 1! Na ka mbetur vet\u00ebm nj\u00eb broker. Pasqyra e Radh\u00ebs B avancuar 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>Kemi kthyer Brokerin 1. Pavar\u00ebsisht se sa mir\u00eb e p\u00ebrballuan t\u00eb dh\u00ebnat humbjen dhe rikuperimin e brokerit, t\u00eb gjitha mesazhet e radh\u00ebs t\u00eb pasqyruara hidhen posht\u00eb gjat\u00eb rifillimit. Kjo \u00ebsht\u00eb e r\u00ebnd\u00ebsishme p\u00ebr t'u theksuar, pasi do t\u00eb ket\u00eb pasoja. K\u00ebto pasoja do t'i shqyrtojm\u00eb s\u00eb shpejti. Pra, Brokeri 1 tani \u00ebsht\u00eb p\u00ebrs\u00ebri an\u00ebtar i klustrit, dhe klust\u00ebr p\u00ebrpiqet t\u00eb respektoj\u00eb politikat dhe prandaj krijon pasqyra mbi Brokerin 1.<\/p>\n<p>N\u00eb k\u00ebt\u00eb rast, humbja e Brokerit 1 ishte totale, ashtu si dhe t\u00eb dh\u00ebnat, prandaj Radh\u00eb B e pa pasqyr\u00eb humbi plot\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 rikthehet n\u00eb pun\u00eb<\/i><\/p>\n<p>Brokeri 3 kthehet n\u00eb pun\u00eb, k\u00ebshtu q\u00eb radh\u00ebt A dhe B kthejn\u00eb pasqyrat e krijuara mbi t\u00eb, p\u00ebr t\u00eb p\u00ebrmbushur politikat e tyre HA. Por tani t\u00eb gjitha radh\u00ebt kryesore jan\u00eb n\u00eb nj\u00eb nyje! Kjo nuk \u00ebsht\u00eb ideale, \u00ebsht\u00eb m\u00eb mir\u00eb nj\u00eb shp\u00ebrndarje e barabart\u00eb midis nyjeve. Fatkeq\u00ebsisht, k\u00ebtu nuk ka opsione t\u00eb ve\u00e7anta p\u00ebr riparimin e masterave. Do t\u00eb kthehemi n\u00eb k\u00ebt\u00eb problem m\u00eb von\u00eb, pasi m\u00eb par\u00eb 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. Brokeri 3 kthehet n\u00eb pun\u00eb. T\u00eb gjitha radh\u00ebt kryesore n\u00eb nj\u00eb nyje!<\/i><\/p>\n<p>K\u00ebshtu q\u00eb tani duhet t\u00eb keni nj\u00eb ide se si pasqyrat ofrojn\u00eb redundanc\u00eb dhe q\u00ebndres\u00eb ndaj d\u00ebshtimit. Kjo garanton disponueshm\u00ebrin\u00eb n\u00eb rast t\u00eb d\u00ebshtimit t\u00eb nj\u00eb nyje dhe mbron nga humbja e t\u00eb dh\u00ebnave. Por ende nuk kemi mbaruar, 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 krijohet nj\u00eb pasqyr\u00eb e re, t\u00eb gjitha mesazhet e reja gjithmon\u00eb do t\u00eb replikohen n\u00eb k\u00ebt\u00eb pasqyr\u00eb dhe n\u00eb \u00e7do pasqyr\u00eb tjet\u00ebr. Sa i p\u00ebrket t\u00eb dh\u00ebnave ekzistuese n\u00eb radh\u00ebn kryesore, ne mund t'i riplikojm\u00eb n\u00eb nj\u00eb pasqyr\u00eb t\u00eb re, e cila b\u00ebhet nj\u00eb kopje e plot\u00eb e masterit. Ne gjithashtu mund t\u00eb mos riplikojm\u00eb mesazhet ekzistuese dhe t\u00eb lejojm\u00eb radh\u00ebn kryesore dhe pasqyr\u00ebn e re t\u00eb sinkronizohen me kalimin e koh\u00ebs, kur mesazhet e reja hyjn\u00eb n\u00eb bisht, nd\u00ebrsa mesazhet ekzistuese dalin nga koka e radh\u00ebs kryesore.<\/p>\n<p>Kjo sinkronizim b\u00ebhet automatikisht ose manualisht dhe menaxhohet me an\u00eb t\u00eb politikave 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 \u00ebsht\u00eb manuale. 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 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\/49114966f440c407488bb467ff6dbf93.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 9. Brokeri 3 ka r\u00ebn\u00eb<\/i><\/p>\n<p>Brokeri 3 kthehet n\u00eb pun\u00eb. Klust\u00ebri krijon nj\u00eb pasqyr\u00eb p\u00ebr \u00e7do radh\u00eb n\u00eb nyj\u00ebn e re dhe automatikisht sinkronizon Radh\u00ebn A t\u00eb re me masterin. Megjithat\u00eb, pasqyra e Radh\u00ebs B t\u00eb re mbetet bosh. K\u00ebshtu q\u00eb kemi plot\u00ebsisht redundanc\u00eb p\u00ebr Radh\u00ebn 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 jo<\/i><\/p>\n<p>T\u00eb dy radh\u00ebt marrin nga dhjet\u00eb mesazhe. Pastaj Brokeri 2 bie, dhe Radh\u00eb A kthehet n\u00eb pasqyr\u00ebn m\u00eb t\u00eb vjet\u00ebr, e cila ndodhet n\u00eb Brokerin 1. Gjat\u00eb d\u00ebshtimit nuk ka humbje t\u00eb dh\u00ebnash. N\u00eb Radh\u00eb B jan\u00eb nj\u00ebzet mesazhe n\u00eb master dhe vet\u00ebm dhjet\u00eb n\u00eb pasqyr\u00eb, pasi kjo radh\u00eb nuk ka riplikuar kurr\u00eb 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. Radh\u00eb A kthehet n\u00eb Brokerin 1 pa humbje mesazhesh<\/i><\/p>\n<p>T\u00eb dy radh\u00ebt marrin p\u00ebrs\u00ebri nga dhjet\u00eb mesazhe. Tani bie Brokeri 1. Radh\u00eb A kalon n\u00eb pasqyr\u00eb pa probleme pa humbje mesazhesh. Megjithat\u00eb, Radh\u00eb B ka probleme. N\u00eb k\u00ebt\u00eb pik\u00eb, 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, politikat <b><i>ha-promote-on-failure<\/i><\/b> duhet t\u00eb vendoset n\u00eb <b><i>always<\/i><\/b>. Ky \u00ebsht\u00eb vlera e paracaktuar, prandaj mund ta lini politiken pa e specifikuar fare. N\u00eb k\u00ebt\u00eb rast, n\u00eb themel, ne lejojm\u00eb d\u00ebshtimet n\u00eb pasqyrat e pa sinkronizuara. Kjo do t\u00eb \u00e7oj\u00eb n\u00eb humbje t\u00eb mesazheve, por radh\u00ebt mbeten t\u00eb disponueshme p\u00ebr t\u00eb lexuar dhe shkruar.<\/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. Radh\u00eb A kthehet n\u00eb Brokerin 3 pa humbje mesazhesh. Radh\u00eb B kthehet n\u00eb Brokerin 3 me humbjen e dhjet\u00eb mesazheve.<\/i><\/p>\n<p>Ne gjithashtu mund t\u00eb vendosim <code>ha-promote-on-failure<\/code> n\u00eb vler\u00eb <code>when-synced<\/code>. N\u00eb k\u00ebt\u00eb rast, n\u00eb vend t\u00eb rikthimit n\u00eb pasqyr\u00eb, radh\u00ebt do t\u00eb presin derisa Broker 1 t\u00eb rikthehet n\u00eb funksionim me t\u00eb dh\u00ebnat e tij. Pas rikthimit t\u00eb tij, radh\u00ebt kryesore kthehen p\u00ebrs\u00ebri te Broker 1 pa humbje t\u00eb t\u00eb dh\u00ebnave. Disponueshm\u00ebria sakrifikohet p\u00ebr sigurin\u00eb e t\u00eb dh\u00ebnave. Por ky \u00ebsht\u00eb nj\u00eb mod i rreziksh\u00ebm, q\u00eb mund t\u00eb \u00e7oj\u00eb madje n\u00eb humbje t\u00eb plot\u00eb t\u00eb t\u00eb dh\u00ebnave, nj\u00eb \u00e7\u00ebshtje q\u00eb 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. Radh\u00ebt B mbeten t\u00eb pap\u00ebrftueshme pas humbjes s\u00eb Broker 1<\/i><\/p>\n<p>Mund t\u00eb b\u00ebni pyetjen: \u00abMbase \u00ebsht\u00eb m\u00eb mir\u00eb t\u00eb mos p\u00ebrdorim kurr\u00eb sinkronizimin automatik?\u00bb P\u00ebrgjigja \u00ebsht\u00eb se sinkronizimi \u00ebsht\u00eb nj\u00eb operacion bllokues. Gjat\u00eb sinkronizimit, radh\u00ebt kryesore nuk mund t\u00eb kryejn\u00eb asnj\u00eb operacion leximi ose shkrimi!<\/p>\n<p>Le t\u00eb shqyrtojm\u00eb nj\u00eb shembull. Aktualisht kemi radh\u00eb shum\u00eb t\u00eb m\u00ebdha. Si mund t\u00eb rriten ato n\u00eb k\u00ebt\u00eb mas\u00eb? P\u00ebr disa arsye:<\/p>\n<ul>\n<li>Radh\u00ebt nuk p\u00ebrdoren aktivisht\n<\/li>\n<li>K\u00ebto jan\u00eb radh\u00eb me shpejt\u00ebsi t\u00eb lart\u00eb, dhe tani konsumator\u00ebt punojn\u00eb ngadal\u00eb \n<\/li>\n<li>K\u00ebto jan\u00eb radh\u00eb me shpejt\u00ebsi t\u00eb lart\u00eb, ka ndodhur nj\u00eb defekt, dhe konsumator\u00ebt po p\u00ebrpiqen t\u00eb 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 radh\u00eb t\u00eb m\u00ebdha me moda t\u00eb ndryshme sinkronizimi<\/i><\/p>\n<p>Tani bie 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\/8c31cfdf485ab4c9dfe13e86a151df4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 15. Broker 3 bie, duke l\u00ebn\u00eb nga nj\u00eb master dhe nj\u00eb pasqyr\u00eb n\u00eb \u00e7do radh\u00eb<\/i><\/p>\n<p>Brokeri 3 rikthehet n\u00eb funksionim, dhe krijohen pasqyra t\u00eb reja. Radh\u00ebt Kryesore A fillon t\u00eb replikoj\u00eb mesazhet ekzistuese n\u00eb pasqyr\u00ebn e re, dhe gjat\u00eb k\u00ebsaj kohe Radh\u00ebt jan\u00eb t\u00eb pap\u00ebrftueshme. P\u00ebr replikimin e t\u00eb dh\u00ebnave nevojiten dy or\u00eb, \u00e7ka rezulton n\u00eb dy or\u00eb pezullimi p\u00ebr k\u00ebt\u00eb Radh\u00eb!<\/p>\n<p>Megjithat\u00eb, Radh\u00ebt B mbetet e p\u00ebrftueshme gjat\u00eb gjith\u00eb periudh\u00ebs. Ajo sakrifikon disa redundanca p\u00ebr t\u00eb siguruar disponueshm\u00ebrin\u00eb.<\/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. Radh\u00ebt mbeten t\u00eb pap\u00ebrftueshme gjat\u00eb sinkronizimit<\/i><\/p>\n<p>Pas dy or\u00ebsh, Radh\u00ebt A gjithashtu b\u00ebhen t\u00eb p\u00ebrftueshme dhe mund t\u00eb fillojn\u00eb p\u00ebrs\u00ebri t\u00eb pranojn\u00eb operacione leximi dhe shkrimi.<\/p>\n<h3>P\u00ebrdit\u00ebsime<\/h3>\n<p>\nKy q\u00ebndrim bllokues gjat\u00eb sinkronizimit e b\u00ebn t\u00eb v\u00ebshtir\u00eb p\u00ebrdit\u00ebsimin e klaster\u00ebve me radh\u00eb shum\u00eb t\u00eb m\u00ebdha. N\u00eb nj\u00eb pik\u00eb, nj\u00eb nyje me masterin duhet t\u00eb ri-startohet, q\u00eb do t\u00eb thot\u00eb ose kalim n\u00eb pasqyr\u00eb, ose \u00e7aktivizim e radh\u00ebs gjat\u00eb p\u00ebrdit\u00ebsimit t\u00eb serverit. N\u00ebse zgjidhim kalimin, do t\u00eb humbasim mesazhe, n\u00ebse pasqyrat nuk jan\u00eb sinkronizuar. Me default, gjat\u00eb \u00e7aktivizimit t\u00eb brokerit, kalimi n\u00eb pasqyr\u00eb t\u00eb nesinkronizuar nuk realizohet. Kjo do t\u00eb thot\u00eb se sa her\u00eb q\u00eb brokeri rikthehet, ne nuk humbasim asnj\u00eb mesazh, d\u00ebmimi i vet\u00ebm \u00ebsht\u00eb pezullimi i radh\u00ebs. Rregullat e sjelljes gjat\u00eb \u00e7aktivizimit t\u00eb brokerit p\u00ebrcaktohen nga politika <code>ha-promote-on-shutdown<\/code>. Mund t\u00eb vendosni nj\u00eb nga dy vlerat:<\/p>\n<ul>\n<li><code>always<\/code>= p\u00ebrfshi kalimin n\u00eb pasqyra t\u00eb nesinkronizuara\n<\/li>\n<li><code>when-synced<\/code>= kalimi vet\u00ebm n\u00eb pasqyr\u00ebn e sinkronizuar, ndryshe radh\u00ebt b\u00ebhen t\u00eb pap\u00ebrftueshme p\u00ebr lexim dhe shkrim. Radh\u00ebt kthehen n\u00eb funksion sapo brokeri t\u00eb rikthehet<\/li>\n<\/ul>\n<p>\nMe \u00e7do rast, me radh\u00eb t\u00eb m\u00ebdha duhet t\u00eb zgjidhni midis humbjes s\u00eb t\u00eb dh\u00ebnave dhe pap\u00ebrftueshm\u00ebris\u00eb.<\/p>\n<h3>Kur disponueshm\u00ebria rrit sigurin\u00eb e t\u00eb dh\u00ebnave<\/h3>\n<p>\nPara se t\u00eb merrni nj\u00eb vendim, duhet t\u00eb merrni parasysh nj\u00eb nd\u00ebrlikim tjet\u00ebr. Megjith\u00ebse sinkronizimi automatik \u00ebsht\u00eb m\u00eb i mir\u00eb p\u00ebr redundanc\u00ebn, si ndikon ai n\u00eb sigurin\u00eb e t\u00eb dh\u00ebnave? Sigurisht, fal\u00eb redundanc\u00ebs m\u00eb t\u00eb mir\u00eb, RabbitMQ ka m\u00eb pak shanse t\u00eb humbas\u00eb mesazhet ekzistuese, por \u00e7far\u00eb ndodh me mesazhet e reja nga botuesit?<\/p>\n<p>K\u00ebtu duhet marr\u00eb parasysh:<\/p>\n<ul>\n<li>A mund t\u00eb kthye botuesi vet\u00ebm nj\u00eb gabim, dhe sh\u00ebrbimi i lart\u00eb ose p\u00ebrdoruesi ta provoni m\u00eb von\u00eb?\n<\/li>\n<li>A mund t\u00eb ruaj\u00eb botuesi mesazhin lokalisht ose n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave p\u00ebr ta provuar m\u00eb von\u00eb?<\/li>\n<\/ul>\n<p>\nN\u00ebse botuesi \u00ebsht\u00eb n\u00eb gjendje vet\u00ebm t\u00eb hedh\u00eb mesazhin, at\u00ebher\u00eb n\u00eb t\u00eb v\u00ebrtet\u00eb, p\u00ebrmir\u00ebsimi i disponueshm\u00ebris\u00eb gjithashtu rrit sigurin\u00eb e t\u00eb dh\u00ebnave.<\/p>\n<p>Prandaj, \u00ebsht\u00eb e nevojshme t\u00eb k\u00ebrkoni nj\u00eb ekuilib\u00ebr, dhe zgjidhja varet nga situata specifike.<\/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> q\u00ebndron n\u00eb faktin se ne parandalojm\u00eb kalimin n\u00eb pasqyra t\u00eb nesinkronizuara dhe k\u00ebshtu shmangim humbjen e t\u00eb dh\u00ebnave. Radh\u00ebt mbeten t\u00eb pap\u00ebrftueshme p\u00ebr lexim ose shkrim. P\u00ebrkundrazi, ne p\u00ebrpiqemi t\u00eb rikthejm\u00eb brokerin e r\u00ebn\u00eb me t\u00eb dh\u00ebna t\u00eb paprekura, p\u00ebr ta rikthyer si master pa humbje t\u00eb t\u00eb dh\u00ebnave. <\/p>\n<p>Por (dhe ky \u00ebsht\u00eb nj\u00eb por i madh) n\u00ebse brokeri humbi t\u00eb dh\u00ebnat e tij, at\u00ebher\u00eb kemi nj\u00eb problem t\u00eb madh: radh\u00ebt jan\u00eb humbur! T\u00eb gjitha t\u00eb dh\u00ebnat jan\u00eb zhdukur! Edhe n\u00ebse keni pasqyra, t\u00eb cilat kryesisht po arrijn\u00eb radh\u00ebt kryesore, k\u00ebto pasqyra gjithashtu p\u00ebrjashtohen.<\/p>\n<p>P\u00ebr t\u00eb shtuar p\u00ebrs\u00ebri nj\u00eb nyje me emrin e nj\u00ebjt\u00eb, ne i themi klasterit t\u00eb harroj\u00eb nyj\u00ebn e humbur (me komand\u00ebn <i>rabbitmqctl forget_cluster_node<\/i>) dhe t\u00eb lan\u00e7oni nj\u00eb broker t\u00eb ri me t\u00eb nj\u00ebjtin em\u00ebr p\u00ebrdoruesi. Deri sa klasteri t\u00eb kujtoj\u00eb nodin e humbur, ai mban mend radh\u00ebn e vjet\u00ebr dhe pasqyrat e nesinhronizuara. Kur klasterit i thuhet t\u00eb harroj\u00eb nodin e humbur, kjo radh\u00eb gjithashtu harrohet. Tani duhet ta shpallim p\u00ebrs\u00ebri. Kemi humbur t\u00eb dh\u00ebnat, ndon\u00ebse kemi pasur 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 nesinhronizuar!<\/p>\n<p>Prandaj, sinkronizimi manual (dhe mos kryerja e sinkronizimit) n\u00eb kombinim 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 maj\u00eb.<\/p>\n<h1>Ribalanconi i masterave<\/h1>\n<p>\nSi\u00e7 u premtua, po kthehemi n\u00eb problemin e grumbullimit t\u00eb t\u00eb gjith\u00eb masterave n\u00eb nj\u00eb ose disa nodet. Kjo mund t\u00eb ndodh\u00eb edhe p\u00ebr shkak t\u00eb nj\u00eb p\u00ebrdit\u00ebsimi \"rr\u00ebshqit\u00ebs\" (rolling) t\u00eb klasterit. N\u00eb nj\u00eb klaster me tre nodet, t\u00eb gjitha radh\u00ebt kryesore do t\u00eb grumbullohen n\u00eb nj\u00eb ose dy nodet.<\/p>\n<p>Ribalanconi i masterave 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 kryer ribalancimin<\/li>\n<li>Sinkronizimi i radh\u00ebve<\/li>\n<\/ul>\n<p>\nP\u00ebr ribalancon ka nj\u00eb pal\u00eb t\u00eb tret\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Ayanda-D\/rabbitmq-queue-master-balancer\">plugins<\/a><\/noindex>, e cila nuk mb\u00ebshtetet zyrtarisht. N\u00eb lidhje me plugin\u00ebt e tret\u00eb, n\u00eb manualin e RabbitMQ <noindex><a rel=\"nofollow\" href=\"https:\/\/www.rabbitmq.com\/upgrade.html\">thuhet<\/a><\/noindex>: \"Plugini ofron disa mjete t\u00eb tjera t\u00eb konfigurimit dhe raportimit, por nuk mb\u00ebshtetet dhe nuk \u00ebsht\u00eb verifikuar nga ekipi i RabbitMQ. P\u00ebrdorni me rrezik t\u00ebndin.\"<\/p>\n<p>Ka edhe nj\u00eb truk tjet\u00ebr p\u00ebr t\u00eb l\u00ebvizur radh\u00ebn kryesore p\u00ebrmes politikave HA. N\u00eb manual p\u00ebrmendet <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/rabbitmq\/support-tools\/blob\/master\/scripts\/rebalance-queue-masters\">sk\u0440\u0438\u043f\u0442<\/a><\/noindex> p\u00ebr k\u00ebt\u00eb. Funksionon si m\u00eb posht\u00eb:<\/p>\n<ul>\n<li>Largon t\u00eb gjitha pasqyrat duke p\u00ebrdorur nj\u00eb politik\u00eb t\u00eb p\u00ebrkohshme me prioritet m\u00eb t\u00eb lart\u00eb se sa politika ekzistuese HA.\n<\/li>\n<li>Ndryshon politik\u00ebn e p\u00ebrkohshme HA p\u00ebr t\u00eb p\u00ebrdorur modin \"nodet\" duke specifikuar nodin n\u00eb t\u00eb cilin duhet t\u00eb l\u00ebvizet radh\u00ebn kryesore.\n<\/li>\n<li>Sinkronizon radh\u00ebn p\u00ebr migrimin e detyruar.\n<\/li>\n<li>Pas p\u00ebrfundimit t\u00eb migrimit, heq politik\u00ebn e p\u00ebrkohshme. Politika origjinale HA hyn n\u00eb fuqi dhe krijohen pasqyra e nevojshme.<\/li>\n<\/ul>\n<p>\nDisavantazhi \u00ebsht\u00eb se ky qasje mund t\u00eb mos funksionoj\u00eb n\u00ebse keni radh\u00eb t\u00eb m\u00ebdha ose k\u00ebrkesa strikte p\u00ebr tepric\u00eb.<\/p>\n<p>Tani le t\u00eb shohim si klaster\u00ebt RabbitMQ punojn\u00eb me ndarje t\u00eb rrjetit.<\/p>\n<h1>Shkeputja e lidhshm\u00ebris\u00eb<\/h1>\n<p>\nNodet e nj\u00eb sistemi t\u00eb shp\u00ebrndara jan\u00eb t\u00eb lidhura me lidhje rrjeti, dhe lidhjet rrjetit mund dhe do t\u00eb fik\u00ebn. Frekuenca e shk\u00ebputjeve varet nga infrastruktura lokale ose besueshm\u00ebria e nj\u00ebsis\u00eb t\u00eb zgjedhura t\u00eb cloud. N\u00eb \u00e7do rast, sistemet e shp\u00ebrndara duhet t\u00eb jen\u00eb n\u00eb gjendje t\u00eb p\u00ebrballojn\u00eb ato. S\u00ebrish na del zgjedhja midis disponueshm\u00ebris\u00eb dhe p\u00ebrputhshm\u00ebris\u00eb, dhe s\u00ebrish, lajm i mir\u00eb \u00ebsht\u00eb se RabbitMQ ofron t\u00eb dy opsionet (thjesht jo nj\u00ebher\u00ebsh).<\/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 shkaktoj\u00eb humbje t\u00eb t\u00eb dh\u00ebnave.\n<\/li>\n<li>T\u00eb ndalojm\u00eb ndarjen logjike. Kjo mund t\u00eb \u00e7oj\u00eb n\u00eb humbjen e p\u00ebrkohshme t\u00eb disponueshm\u00ebris\u00eb n\u00eb var\u00ebsi t\u00eb m\u00ebnyr\u00ebs se si lidhen klient\u00ebt me klasterin. Gjithashtu, mund t\u00eb \u00e7oj\u00eb n\u00eb munges\u00eb t\u00eb plot\u00eb t\u00eb aksesit n\u00eb klaster me dy nodet.<\/li>\n<\/ul>\n<p>\nPor \u00e7far\u00eb \u00ebsht\u00eb ndarja logjike? Kjo ndodh kur klasteri ndahet n\u00eb dy p\u00ebr shkak t\u00eb humbjes s\u00eb lidhjeve rrjet. N\u00eb secil\u00ebn an\u00eb, pasqyrat ngrihen n\u00eb master, k\u00ebshtu q\u00eb p\u00ebrfundimisht \u00e7do radh\u00eb 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. Radh\u00eb kryesore dhe dy pasqyra, secila n\u00eb nodet e ndryshme. Pastaj ndodh nj\u00eb defekt rrjeti dhe nj\u00eb pasqyr\u00eb shk\u00ebputet. Nodi i ndar\u00eb sheh se dy t\u00eb tjer\u00ebt jan\u00eb shk\u00ebputur, dhe avancojn\u00eb pasqyrat e tij n\u00eb master. Tani kemi dy radh\u00eb kryesore, dhe t\u00eb dy lejojn\u00eb shkrim dhe lexim.<\/i> <\/p>\n<p>N\u00ebse publikuesit d\u00ebrgojn\u00eb t\u00eb dh\u00ebna n\u00eb t\u00eb dy masterat, do t\u00eb kemi dy kopje t\u00eb ndara t\u00eb radh\u00ebs.<\/p>\n<p>Modet e ndryshme t\u00eb RabbitMQ ofrojn\u00eb ose disponueshm\u00ebri, ose p\u00ebrputhshm\u00ebri.<\/p>\n<h3>Re\u017eimi Ignore (si parazgjedhje)<\/h3>\n<p>\nKy re\u017eim siguron disponueshm\u00ebri. Pas humbjes s\u00eb lidhshm\u00ebris\u00eb ndodh ndarja logjike. Pas rivendosjes s\u00eb lidhshm\u00ebris\u00eb, administratori duhet t\u00eb vendos\u00eb se cil\u00ebs ndarje t\u2019i jap\u00eb p\u00ebrpar\u00ebsi. Ana e humbur do t\u00eb rindez dhe t\u00eb gjitha t\u00eb dh\u00ebnat e mbledhura nga kjo an\u00eb humbasin.<\/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 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 Broker 2.<\/i><\/p>\n<p>Tani humbasim Broker 3. Ai sheh se broker\u00ebt e tjer\u00eb jan\u00eb shk\u00ebputur dhe avancon pasqyr\u00ebn e tij n\u00eb master. 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 radh\u00eb kryesore dhe dy kopje shkojn\u00eb n\u00eb ndarje.<\/i><\/p>\n<p>Konfirmimi rikthehet, por ndarja logjike mbetet. Administratori duhet t\u00eb zgjedh\u00eb manualisht an\u00ebn e humbur. N\u00eb rastin e m\u00ebposht\u00ebm, administratori rindez Broker 3. T\u00eb gjitha mesazhet q\u00eb ai nuk arriti t'i d\u00ebrgoj\u00eb humbasin.<\/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 Broker 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 aktivizon Broker 3, dhe ai i bashkohet klasterit, duke humbur t\u00eb gjitha mesazhet q\u00eb kishin mbetur atje.<\/i><\/p>\n<p>Gjat\u00eb humbjes s\u00eb konfirmimit dhe pas rikthimit t\u00eb tij, klasteri dhe kjo radh\u00eb ishin t\u00eb disponueshme p\u00ebr lexim dhe shkrim.<\/p>\n<h3>Reimi Autoheal<\/h3>\n<p>\nFunksionon n\u00eb m\u00ebnyr\u00eb t\u00eb ngjashme me reimin Ignore, me p\u00ebrjashtim t\u00eb faktit se klasteri automatikisht zgjidh an\u00ebn e humbur pas ndarjes dhe rikthimit t\u00eb konfirmimit. An\u00ebn e humbur e rikthen n\u00eb klaster bosh, dhe radh\u00eb humbet t\u00eb gjitha mesazhet q\u00eb ishin d\u00ebrguar vet\u00ebm n\u00eb at\u00eb an\u00eb.<\/p>\n<h3>Reimi 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 ndalim leximin dhe shkrimin n\u00eb an\u00ebn e vog\u00ebl pas ndarjes s\u00eb klasterit. Kur brokeri sheh se ndodhet n\u00eb an\u00ebn e vog\u00ebl, ai ndalon pun\u00ebn, duke mbyllur t\u00eb gjitha lidhjet ekzistuese dhe duke refuzuar \u00e7do t\u00eb re. Nj\u00eb her\u00eb n\u00eb sekond\u00eb kontrollon rikthimin e konfirmimit. Sa m\u00eb shpejt q\u00eb konfirmimi rikthehet, ai rinis pun\u00ebn dhe 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\/7a51cf509b2c94e2ae100c7dedd9d21a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 22. Tre publikues jan\u00eb lidhur me tre broker\u00eb. Brenda klasterit, t\u00eb gjitha k\u00ebrkesat drejtohen n\u00eb radh\u00ebn kryesore n\u00eb Broker 2.<\/i><\/p>\n<p>Pastaj Brokerat 1 dhe 2 ndahet nga Brokeri 3. N\u00eb vend q\u00eb t\u00eb rritet n\u00eb nj\u00eb master, Brokeri 3 ndalon pun\u00ebn dhe b\u00ebhet i padisponuesh\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, \u00e7on jasht\u00eb t\u00eb gjith\u00eb klient\u00ebt dhe refuzon k\u00ebrkesat p\u00ebr lidhje.<\/i><\/p>\n<p>Sa m\u00eb shpejt q\u00eb konfirmimi rikthehet, ai rikthehet n\u00eb klaster.<\/p>\n<p>Le t\u00eb shohim nj\u00eb shembull tjet\u00ebr, ku radh\u00eb kryesore \u00ebsht\u00eb n\u00eb 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\/4cc6a28270f00a280ecb5af5252f4e07.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 24. Radh\u00eb kryesore n\u00eb Broker 3.<\/i><\/p>\n<p>Pastaj ndodh e nj\u00ebjta humbje konfirmimi. Brokeri 3 ndalon, pasi ndodhet n\u00eb an\u00ebn e vog\u00ebl. N\u00eb an\u00ebn tjet\u00ebr, nyjet shohin se Brokeri 3 \u00ebsht\u00eb ndar\u00eb, k\u00ebshtu q\u00eb nj\u00eb kopi e m\u00ebparshme nga Brokerat 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 n\u00eb Broker 2 n\u00eb paq\u00ebndrueshm\u00ebrin\u00eb e Brokerit 3.<\/i><\/p>\n<p>Kur konfirmimi rikthehet, 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 \u00ebsht\u00eb rikthyer n\u00eb pun\u00eb normale.<\/i><\/p>\n<p>K\u00ebtu \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb kuptohet se ajo q\u00eb arrijm\u00eb \u00ebsht\u00eb koherenc\u00eb, por gjithashtu mund t\u00eb arrijm\u00eb disponueshm\u00ebri. <i><b>n\u00ebse<\/b><\/i> nd\u00ebrsa klient\u00ebt kalojn\u00eb me sukses n\u00eb pjes\u00ebn m\u00eb t\u00eb madhe t\u00eb ndarjes. N\u00eb shumic\u00ebn e situatave, un\u00eb personalisht do t\u00eb zgjidhja reimin Pause Minority, por kjo varet realisht nga rasti konkret.<\/p>\n<p>P\u00ebr t\u00eb siguruar disponueshm\u00ebrin\u00eb \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb sigurohet q\u00eb klient\u00ebt lidhen me nyj\u00ebn. Le t\u00eb shqyrtojm\u00eb opsionet tona.<\/p>\n<h1>Sigurimi i konfirmimit p\u00ebr klient\u00ebt<\/h1>\n<p>\nKemi disa opsione si pas humbjes s\u00eb konfirmimit t\u00eb drejtojm\u00eb klient\u00ebt n\u00eb pjes\u00ebn kryesore t\u00eb klasterit ose n\u00eb nyjet q\u00eb funksionojn\u00eb (pas d\u00ebshtimit t\u00eb nj\u00eb nyje). S\u00eb pari, le t\u00eb kujtojm\u00eb se nj\u00eb radh\u00eb specifike vendoset n\u00eb nj\u00eb nyje t\u00eb caktuar, por rrjedha dhe politikat kopjosen n\u00eb t\u00eb gjitha nyjet. Klient\u00ebt mund t\u00eb lidhen me \u00e7do nyje, dhe rrjedhja e brendshme do t'i drejtoj\u00eb ata ku duhet. Por kur nyja ndalon, ajo refuzon lidhjet, k\u00ebshtu q\u00eb klient\u00ebt duhet t\u00eb lidhen me nj\u00eb nyje tjet\u00ebr. N\u00ebse nyja \u00ebsht\u00eb ndar\u00eb, ajo n\u00eb t\u00eb v\u00ebrtet\u00eb nuk mund t\u00eb b\u00ebj\u00eb shum\u00eb.<\/p>\n<p>Opsionet tona:<\/p>\n<ul>\n<li>Qasja n\u00eb klaster b\u00ebhet p\u00ebrmes nj\u00eb balancuesi ngarkese, i cili thjesht kalon direkt mbi nyjet, dhe klient\u00ebt p\u00ebrpiqen t\u00eb lidhen deri n\u00eb nj\u00eb p\u00ebrfundim t\u00eb suksessh\u00ebm. N\u00ebse nyja nuk funksionon ose \u00ebsht\u00eb ndalur, p\u00ebrpjekjet p\u00ebr t'u lidhur me at\u00eb nyje do t\u00eb d\u00ebshtojn\u00eb, por p\u00ebrpjekjet e m\u00ebvonshme do t\u00eb shkojn\u00eb n\u00eb server\u00eb t\u00eb tjer\u00eb (n\u00eb m\u00ebnyr\u00eb rrethore). Kjo \u00ebsht\u00eb e p\u00ebrshtatshme p\u00ebr humbje t\u00eb p\u00ebrkohshme t\u00eb konfirmimit ose p\u00ebr nj\u00eb server q\u00eb ka r\u00ebn\u00eb dhe do t\u00eb ngrihet shpejt.\n<\/li>\n<li>Qasja n\u00eb klaster n\u00ebp\u00ebrmjet nj\u00eb balancuesi ngarkese dhe heqja e nyjeve t\u00eb ndaluara\/rajtura nga lista, sa m\u00eb shpejt q\u00eb ato t\u00eb zbulohen. N\u00ebse k\u00ebt\u00eb e b\u00ebjm\u00eb shpejt, dhe n\u00ebse klient\u00ebt jan\u00eb n\u00eb gjendje t\u00eb provojn\u00eb lidhen, at\u00ebher\u00eb do t\u00eb kemi disponueshm\u00ebri t\u00eb vazhdueshme.\n<\/li>\n<li>Dhuroni \u00e7do klient nj\u00eb list\u00eb t\u00eb gjitha nyjeve dhe ai\/i zgjidh nj\u00eb nga ato rast\u00ebsisht gjat\u00eb lidhjes. N\u00ebse gjat\u00eb p\u00ebrpjekjes p\u00ebr t'u lidhur merr nj\u00eb gabim, at\u00ebher\u00eb kalon n\u00eb nyj\u00ebn tjet\u00ebr n\u00eb list\u00eb, derisa t\u00eb lidhet.\n<\/li>\n<li>Hiqni trafikun nga nyja e r\u00ebn\u00eb\/n\u00eb pauz\u00eb p\u00ebrmes DNS. Kjo b\u00ebhet p\u00ebrmes nj\u00eb TTL t\u00eb vog\u00ebl.<\/li>\n<\/ul>\n<p><\/p>\n<h1>P\u00ebrfundimet<\/h1>\n<p>\nKlasterizimi i RabbitMQ ka avantazhet dhe disavantazhet e veta. Disavantazhet m\u00eb t\u00eb r\u00ebnd\u00ebsishme jan\u00eb:<\/p>\n<ul>\n<li>kur lidhja n\u00eb klaster, nyjat heqin t\u00eb dh\u00ebnat e tyre;\n<\/li>\n<li>sinkronizimi i bllokimit \u00e7on n\u00eb papasht\u00ebm\u00ebrin\u00eb e radh\u00ebs.<\/li>\n<\/ul>\n<p>\nT\u00eb gjitha vendimet e v\u00ebshtira rrjedhin nga k\u00ebto dy tipare t\u00eb arkitektur\u00ebs. Po t\u00eb mund t\u00eb ruante t\u00eb dh\u00ebnat gjat\u00eb rinisjes s\u00eb klasterit, sinkronizimi do t\u00eb ndodhte m\u00eb shpejt. Po t\u00eb ishte n\u00eb gjendje t\u00eb kryente nj\u00eb sinkronizim jo-bllokues, 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 p\u00ebr shk\u00ebmbim mesazhe q\u00eb garanton q\u00ebndrueshm\u00ebri dhe jet\u00ebgjat\u00ebsi. Nuk do t\u00eb guxoja ta rekomandoja RabbitMQ me klasterizim n\u00eb situatat e m\u00ebposhtme:<\/p>\n<ul>\n<li>Rrjeti i pasigurt.\n<\/li>\n<li>Ruajtja e pasigurt.\n<\/li>\n<li>Radh\u00ebt shum\u00eb t\u00eb m\u00ebdha.<\/li>\n<\/ul>\n<p>\nSa i p\u00ebrket konfigurimeve p\u00ebr disponueshm\u00ebri 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 lidhen me nyj\u00ebn aktive kur ndonj\u00eb nyje d\u00ebshton<\/li>\n<\/ul>\n<p>\nP\u00ebr q\u00ebndrueshm\u00ebrin\u00eb (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 provojn\u00eb s\u00ebrish m\u00eb von\u00eb dhe n\u00ebse keni nj\u00eb ruajtje shum\u00eb t\u00eb besueshme! N\u00eb t\u00eb kund\u00ebrt, vendosni <code>=always<\/code>.\n<\/li>\n<li><code>ha-sync-mode=automatic<\/code> (por p\u00ebr radh\u00ebt e m\u00ebdha t\u00eb pap\u00ebrfshira, mund t\u00eb nevojitet nj\u00eb modalitet manual; gjithashtu, mendoni n\u00ebse papashtm\u00ebria do t\u00eb shkaktoj\u00eb humbje mesazhesh)\n<\/li>\n<li>modaliteti Pause Minority\n<\/li>\n<li>mesazhe t\u00eb q\u00ebndrueshme<\/li>\n<\/ul>\n<p>\nNuk i kemi shqyrtuar ende t\u00eb gjitha \u00e7\u00ebshtjet e q\u00ebndrueshm\u00ebris\u00eb dhe disponueshm\u00ebris\u00eb s\u00eb lart\u00eb; p\u00ebr shembull, si t\u00eb kryhen procedurat administrative n\u00eb m\u00ebnyr\u00eb t\u00eb sigurt (si\u00e7 jan\u00eb p\u00ebrdit\u00ebsimet gradualisht). Duhet t\u00eb flasim gjithashtu p\u00ebr federimin dhe plugin-in Shovel.<\/p>\n<p>N\u00ebse kam humbur ndonj\u00eb gj\u00eb tjet\u00ebr, ju lutem m\u00eb njoftoni.<\/p>\n<p>Shih gjithashtu <noindex><a rel=\"nofollow\" href=\"https:\/\/jack-vanlightly.com\/blog\/2018\/9\/10\/how-to-lose-messages-on-a-rabbitmq-cluster\">post<\/a><\/noindex>, ku realizoj nj\u00eb analiz\u00eb n\u00eb klasterin RabbitMQ me ndihm\u00ebn e Docker dhe Blockade p\u00ebr t\u00eb testuar disa skenar\u00eb t\u00eb humbjes s\u00eb mesazheve t\u00eb p\u00ebrshkruar n\u00eb k\u00ebt\u00eb artikull.<\/p>\n<p>Artikujt e m\u00ebparsh\u00ebm t\u00eb seris\u00eb: <br \/>\n\u21161 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/416629\/\">habr.com\/ru\/company\/itsumma\/blog\/416629<\/a><\/noindex> <br \/>\n\u21162 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/418389\/\">habr.com\/ru\/company\/itsumma\/blog\/418389<\/a><\/noindex> <br \/>\n\u21163 \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.0.1 - 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.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"sq_AL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\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 kundrejt Kafka: q\u00ebndrueshm\u00ebria dhe disponueshm\u00ebria e 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}]}}