{"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\/hr\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","title":{"rendered":"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/d8e584d210a6a016a962ad6f956a2078.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOtpornost na gre\u0161ke i visoka dostupnost su velike teme, pa \u0107emo RabbitMQ i Kafki posvetiti odvojene \u010dlanke. Ovaj \u010dlanak se bavi RabbitMQ-om, dok \u0107e sljede\u0107i biti o Kafki, u usporedbi s RabbitMQ-om. \u010clanak je duga\u010dak, pa se udobno smjestite.<\/p>\n<p>Pogledajmo strategije otpornosti na gre\u0161ke, dosljednosti i visoke dostupnosti (HA), kao i kompromise koji se moraju praviti u svakoj strategiji. RabbitMQ mo\u017ee raditi na klasteru \u010dvorova \u2014 i tada se klasificira kao distribuirani sustav. Kada govorimo o distribuiranim sustavima, \u010desto raspravljamo o dosljednosti i dostupnosti. <\/p>\n<p>Ovi pojmovi opisuju kako sustav reagira na kvar. Kvar mre\u017ene veze, kvar servera, kvar tvrdog diska, privremena nedostupnost servera zbog sakupljanja sme\u0107a, gubitak paketa ili usporenje mre\u017ene veze. Sve to mo\u017ee dovesti do gubitka podataka ili sukoba. Naime, gotovo je nemogu\u0107e podi\u0107i sustav koji je istovremeno potpuno dosljedan (bez gubitka podataka, bez konflikta podataka) i dostupan (koji \u0107e prihvatiti operacije \u010ditanja i pisanja) za sve slu\u010dajeve kvara.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nVidjet \u0107emo da se dosljednost i dostupnost nalaze na suprotnim krajevima spektra, pa morate odabrati prema kojoj strani \u017eelite optimizirati. Dobra vijest je da je s RabbitMQ-om takav izbor mogu\u0107. Imate gotovo \"nerdovske\" poluge za pomicanje ravnote\u017ee prema ve\u0107oj dosljednosti ili ve\u0107oj dostupnosti.<\/p>\n<p>Posebnu pa\u017enju posvetit \u0107emo onome \u0161to konfiguracije dovode do gubitka podataka zbog potvr\u0111enih zapisa. Postoji lanac odgovornosti izme\u0111u izdava\u010da, posrednika i potro\u0161a\u010da. Nakon \u0161to je poruka predana posredniku, njegova je du\u017enost \u2014 ne izgubiti poruku. Kada posrednik potvrdi izdajatelju da je primio poruku, ne o\u010dekujemo da \u0107e biti izgubljena. No, vidjet \u0107emo da se to zaista mo\u017ee dogoditi ovisno o konfiguraciji va\u0161eg posrednika i izdava\u010da.<\/p>\n<h1>Primitivi otpornosti jednog \u010dvora<\/h1>\n<p><\/p>\n<h3>Otpornim redovima\/mar\u0161rutiranjem<\/h3>\n<p>\nU RabbitMQ postoje dvije vrste redova: trajni (durable) i nestabilni (non-durable). Svi redovi se pohranjuju u Mnesia bazi podataka. Trajni redovi se ponovno deklariraju prilikom pokretanja \u010dvora i na taj na\u010din pre\u017eivljavaju ponovno pokretanje, pad sistema ili pad poslu\u017eitelja (sve dok se podaci pohranjuju). To zna\u010di da dok deklarirate usmjeravanje (exchange) i redove kao trajne, infrastruktura redova\/usmjeravanja \u0107e se vratiti u operativni re\u017eim.<\/p>\n<p>Nestabilni redovi i usmjeravanje se bri\u0161u prilikom ponovnog pokretanja \u010dvora.<\/p>\n<h3>Trajne poruke<\/h3>\n<p>\nSamo to \u0161to je red dugotrajan ne zna\u010di da \u0107e sve njegove poruke pre\u017eivjeti ponovno pokretanje \u010dvora. Obnovit \u0107e se samo poruke koje je publisher ozna\u010dio kao <i>trajni<\/i> (persistent). Trajne poruke zaista stvaraju dodatni teret za brokera, ali ako je gubitak poruke neprihvatljiv, onda nema druge solucije.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/8b8e2de4ef82bf8497960657aac0ddb0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sl. 1. Matrica trajnosti<\/i><\/p>\n<h1>Klastriranje s replikacijom redova<\/h1>\n<p>\nDa bismo pre\u017eivjeli gubitak brokera, potrebna nam je redundancija. Mo\u017eemo spojiti nekoliko RabbitMQ \u010dvorova u klaster, a zatim dodati dodatnu redundanciju replikacijom redova izme\u0111u vi\u0161e \u010dvorova. Na taj na\u010din, ako jedan \u010dvor padne, ne gubimo podatke i ostajemo dostupni. <\/p>\n<p>Replikacija reda:<\/p>\n<ul>\n<li>jedan glavni red (master) koji prima sve upute za pisanje i \u010ditanje\n<\/li>\n<li>jedna ili vi\u0161e replika koje primaju sve poruke i metapodatke iz glavnog reda. Ove replikacije ne postoje za skaliranje, ve\u0107 isklju\u010divo za redundanciju.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/35f3d4bdc4f5e10da0e40eb91c5d8280.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sl. 2. Replikacija reda<\/i><\/p>\n<p>Replikacija se postavlja odgovaraju\u0107om politikom. U njoj se mo\u017ee odabrati koeficijent replikacije i \u010dak \u010dvorovi na kojima bi se red trebao nalaziti. Primjeri:<\/p>\n<ul>\n<li><code>ha-mode: all<\/code>\n<\/li>\n<li><code>ha-mode: exactly, ha-params: 2<\/code> (jedan master i jedna replika)\n<\/li>\n<li><code>ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2<\/code><\/li>\n<\/ul>\n<p><\/p>\n<h1>Potvrda publisheru<\/h1>\n<p>\nZa dosljedno pohranu potrebna su potvr\u0111enja od izdava\u010da (Publisher Confirms). Bez njih postoji rizik od gubitka poruka. Potvrda se \u0161alje izdava\u010du nakon \u0161to je poruka snimljena na disk. RabbitMQ snima poruke na disk ne prilikom primitka, ve\u0107 periodi\u010dno, svakih nekoliko stotina milisekundi. Kada se red zrcali, potvrda se \u0161alje samo nakon \u0161to su sve kopije tako\u0111er snimile svoju verziju poruke na disk. To zna\u010di da kori\u0161tenje potvrda dodaje ka\u0161njenje, no ako je sigurnost podataka va\u017ena, one su neophodne.<\/p>\n<h1>Red s visokom dostupno\u0161\u0107u<\/h1>\n<p>\nKada broker prestane s radom ili do\u017eivi kvar, svi primarni redovi (majstori) na tom \u010dvoru padaju zajedno s njim. Tada klaster odabire najstarije zrcalo svakog majstora i unapre\u0111uje ga u novi majstor.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/8d8227c00643f35e0dc752b6617e18fb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 3. Vi\u0161e zrcaljenih redova i njihove politike<\/i><\/p>\n<p>Broker 3 pada. Primijetite da se zrcalo Reda C na Brokeru 2 unapre\u0111uje u majstora. Tako\u0111er, primijetite da je novo zrcalo za Red C stvoreno na Brokeru 1. RabbitMQ uvijek nastoji odr\u017eavati omjer replikacije naveden u va\u0161im politikama.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/d08b3ada22e79686d448714f7bab009a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 4. Broker 3 pada, \u0161to uzrokuje kvar reda C<\/i> <\/p>\n<p>Pada sljede\u0107i Broker 1! Osta\u0107e nam samo jedan broker. Zrcalo Reda B se unapre\u0111uje u majstora.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/dcc1d542c40c441194fd07e51046c619.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 5<\/i><\/p>\n<p>Vratili smo Broker 1. Bez obzira na to koliko su uspje\u0161no podaci pre\u017eivjeli gubitak i oporavak brokera, sve zrcaljene poruke reda se odbacuju prilikom ponovnog pokretanja. Ovo je va\u017eno napomenuti jer \u0107e biti posljedica. Ubrzo \u0107emo razmotriti te posljedice. Tako da je Broker 1 sada ponovno \u010dlan klastera, a klaster poku\u0161ava po\u0161tovati politike i stoga stvara zrcala na Brokeru 1.<\/p>\n<p>U ovom slu\u010daju, gubitak Brokera 1 bio je potpun, kao i podataka, stoga je nezrcaljeni Red B potpuno izgubljen.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/7ac7ab65ea6dff9c5a49372c04c83a37.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 6. Broker 1 se vra\u0107a u rad<\/i><\/p>\n<p>Broker 3 se vratio u rad, tako da redovi A i B ponovno dobivaju kreirane na njemu zrcalne redove kako bi zadovoljili svoje HA politike. No sada su svi glavni redovi na jednom \u010dvoru! To nije idealno, bolje je ravnomjerno raspore\u0111ivanje izme\u0111u \u010dvorova. Na\u017ealost, ovdje nema posebnih opcija za prebalansiranje majstora. Vratit \u0107emo se ovom problemu kasnije, jer prvo trebamo razmotriti sinhronizaciju reda. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/a54e53bb01e2f830a54f88acaa668984.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sl. 7. Broker 3 se vra\u0107a u rad. Svi glavni redovi na jednom \u010dvoru!<\/i><\/p>\n<p>Dakle, sada biste trebali imati dojam o tome kako zrcala osiguravaju redundanciju i otpornost na kvarove. To jam\u010di dostupnost u slu\u010daju kvara jednog \u010dvora i \u0161titi od gubitka podataka. No, jo\u0161 nismo zavr\u0161ili, jer je sve zapravo mnogo slo\u017eenije.<\/p>\n<h1>Sinhronizacija<\/h1>\n<p>\nKada se kreira novo zrcalo, sve nove poruke uvijek \u0107e se replicirati u to zrcalo i svako drugo. \u0160to se ti\u010de postoje\u0107ih podataka u glavnom redu, mo\u017eemo ih replicirati u novo zrcalo, koje postaje potpuna kopija majstora. Tako\u0111er mo\u017eemo ne replicirati postoje\u0107e poruke i dopustiti glavnom redu i novom zrcalu da se sretnu tijekom vremena kada nove poruke dolaze na kraj, a postoje\u0107e poruke odlaze iz glave glavnog reda.<\/p>\n<p>Takva sinhronizacija se provodi automatski ili ru\u010dno i upravlja se politikom redova. Razmotrite primjer.<\/p>\n<p>Imamo dva zrcaljena reda. Red A se sinhronizira automatski, dok se Red B sinhronizira ru\u010dno. U oba reda ima po deset poruka.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/304f2a475fdd0cb6d3069140c667a0a7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sl. 8. Dva reda s razli\u010ditim na\u010dinima sinhronizacije<\/i><\/p>\n<p>Sada gubimo Brokera 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/49114966f440c407488bb467ff6dbf93.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sl. 9. Broker 3 je pao<\/i><\/p>\n<p>Broker 3 se vra\u0107a u rad. Klaster stvara zrcalo za svaki red na novom \u010dvoru i automatski sinhronizira novi Red A s majstorom. Me\u0111utim, zrcalo novog Reda B ostaje prazno. Tako imamo punu redundanciju Reda A i samo jedno zrcalo za postoje\u0107e poruke Reda B.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/adffc1f5eff8806edbd83772f338d67f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sl. 10. Novo zrcalo Reda A dobiva sve postoje\u0107e poruke, dok novo zrcalo Reda B ne dobiva nijednu<\/i><\/p>\n<p>U oba reda dolazi jo\u0161 po deset poruka. Zatim Broker 2 pada, a Red A se vra\u0107a na najstarije zrcalo koje se nalazi na Brokeru 1. Tijekom kvara ne dolazi do gubitka podataka. U Redu B ima dvadeset poruka u masteru i samo deset u zrcalu, budu\u0107i da ovaj red nikada nije replicirao izvornih deset poruka.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/c6cfef4bced5627bf243c2f020a42646.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sl. 11. Red A se vra\u0107a na Brokera 1 bez gubitka poruka<\/i><\/p>\n<p>U oba reda dolazi jo\u0161 po deset poruka. Sada pada Broker 1. Red A se bez problema prebacuje na zrcalo bez gubitka poruka. Me\u0111utim, Red B ima problema. U ovoj fazi mo\u017eemo optimizirati ili dostupnost ili dosljednost. <\/p>\n<p>Ako \u017eelimo optimizirati dostupnost, tada politiku <b><i>ha-promote-on-failure<\/i><\/b> treba postaviti na <b><i>always<\/i><\/b>. Ova vrijednost je zadana, tako da se politika mo\u017ee jednostavno ne navesti. U tom slu\u010daju, zapravo dopu\u0161tamo kvarove na nesinkroniziranim zrcalima. To \u0107e dovesti do gubitka poruka, ali red ostaje dostupan za \u010ditanje i pisanje.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/cd704cf4397184c212e1576b986abbaa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sl. 12. Red A se vra\u0107a na Brokera 3 bez gubitka poruka. Red B se vra\u0107a na Brokera 3 s gubitkom od deset poruka<\/i><\/p>\n<p>Tako\u0111er mo\u017eemo postaviti <code>ha-promote-on-failure<\/code> na <code>when-synced<\/code>. U tom slu\u010daju, umjesto vra\u0107anja na zrcalo, red \u0107e \u010dekati da se Broker 1 sa svojim podacima vrati u operativni na\u010din rada. Nakon njegovog povratka, glavni red se ponovno nalazi na Brokeru 1 bez gubitka podataka. Dostupnost se \u017ertvuje zbog sigurnosti podataka. No, to je rizi\u010dan na\u010din rada koji mo\u017ee dovesti \u010dak i do potpunog gubitka podataka, \u0161to \u0107emo razmotriti uskoro.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/03fed936fe75220e22f68432ca81b654.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sl. 13. Red B ostaje nedostupan nakon gubitka Brokera 1<\/i><\/p>\n<p>Mo\u017eete postaviti pitanje: \"Mo\u017eda je bolje nikad ne koristiti automatsku sinkronizaciju?\". Odgovor je da je sinkronizacija blokiraju\u0107a operacija. Tijekom sinkronizacije, glavni red ne mo\u017ee izvr\u0161avati nikakve operacije \u010ditanja ili pisanja!<\/p>\n<p>Razmotrimo primjer. Sada imamo vrlo velike redove. Kako su mogli narasti do te veli\u010dine? Iz nekoliko razloga:<\/p>\n<ul>\n<li>Redovi se ne koriste aktivno\n<\/li>\n<li>To su brzi redovi, a trenutno potro\u0161a\u010di rade sporo \n<\/li>\n<li>To su brzi redovi, do\u0161lo je do kvara, a potro\u0161a\u010di susti\u017eu<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/dd4b0fd70cbbc0b7defc06536157770d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 14. Dva velika reda s razli\u010ditim na\u010dinima sinkronizacije<\/i><\/p>\n<p>Sada pada Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/8c31cfdf485ab4c9dfe13e86a151df4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 15. Broker 3 pada, ostavljaju\u0107i po jedan master i ogledalo u svakom redu<\/i><\/p>\n<p>Broker 3 se vra\u0107a u pogon i stvaraju se nova ogledala. Glavni Red A po\u010dinje replicirati postoje\u0107e poruke na novo ogledalo, a za to vrijeme Red nije dostupan. Za replikaciju podataka potrebno je dva sata, \u0161to dovodi do dva sata zastoja za ovaj Red!<\/p>\n<p>Me\u0111utim, Red B ostaje dostupan tokom celog razdoblja. On je \u017ertvovao deo redundancije radi dostupnosti.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/28e641300a1c3f4d70e29a16db51521e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 16. Red ostaje nedostupan tokom sinkronizacije<\/i><\/p>\n<p>Nakon dva sata, Red A tako\u0111e postaje dostupan i mo\u017ee ponovo po\u010deti primati operacije \u010ditanja i pisanja.<\/p>\n<h3>A\u017euriranja<\/h3>\n<p>\nOvo blokiraju\u0107e pona\u0161anje tokom sinkronizacije ote\u017eava a\u017euriranje klastera sa veoma velikim redovima. U nekom trenutku, \u010dvor s masterom treba ponovo pokrenuti, \u0161to zna\u010di ili prelazak na ogledalo, ili isklju\u010denje reda tokom a\u017euriranja servera. Ako odaberemo prelazak, izgubi\u0107emo poruke, ako ogledala nisu sinkronizovana. Po defaultu, tokom isklju\u010divanja brokera, prelazak na nesinkronizovano ogledalo se ne vr\u0161i. To zna\u010di da, kada se broker vrati, ne gubimo nikakve poruke, jedina \u0161teta su samo zastoji reda. Pravila pona\u0161anja pri isklju\u010divanju brokera odre\u0111ena su politikom <code>ha-promote-on-shutdown<\/code>. Mo\u017ee se postaviti jedna od dve vrednosti:<\/p>\n<ul>\n<li><code>always<\/code>= uklju\u010dena promjena na nesinkronizovane ogledale\n<\/li>\n<li><code>when-synced<\/code>= prelazak samo na sinkronizovano ogledalo, ina\u010de red postaje nedostupan za \u010ditanje i pisanje. Red se vra\u0107a u pogon \u010dim se broker vrati<\/li>\n<\/ul>\n<p>\nTako ili onako, sa velikim redovima se mora birati izme\u0111u gubitka podataka i nedostupnosti.<\/p>\n<h3>Kada dostupnost pove\u0107ava sigurnost podataka<\/h3>\n<p>\nPre nego \u0161to donesete odluku, treba uzeti u obzir jo\u0161 jednu komplikaciju. Iako je automatska sinkronizacija bolja za redundanciju, kakav je njen u\u010dinak na sigurnost podataka? Naravno, zahvaljuju\u0107i boljoj redundanciji, RabbitMQ \u0107e sa manjom verovatno\u0107om izgubiti postoje\u0107e poruke, ali \u0161ta je sa novim porukama od izdava\u010da?<\/p>\n<p>Ovde treba uzeti u obzir slede\u0107e:<\/p>\n<ul>\n<li>Mo\u017ee li publiser jednostavno vratiti gre\u0161ku, a vi\u0161a slu\u017eba ili korisnik kasnije poku\u0161ati ponovo?\n<\/li>\n<li>Mo\u017ee li publiser lokalno ili u bazi podataka sa\u010duvati poruku da bi kasnije poku\u0161ao ponovo?<\/li>\n<\/ul>\n<p>\nAko publiser mo\u017ee samo odbaciti poruku, tada pobolj\u0161anje dostupnosti tako\u0111er pove\u0107ava sigurnost podataka.<\/p>\n<p>Tako se mora tra\u017eiti ravnote\u017ea, a rje\u0161enje ovisi o konkretnoj situaciji.<\/p>\n<h1>Problemi s ha-promote-on-failure=when-synced<\/h1>\n<p>\nIdeja <i><b>ha-promote-on-failure<\/b><\/i>= <i><b>when-synced<\/b><\/i> sastoje se u tome da spre\u010davamo prebacivanje na nesinkronizirano ogledalo i tako izbjegavamo gubitak podataka. Red \u010dekanja ostaje nedostupan za \u010ditanje ili pisanje. Umjesto toga, poku\u0161avamo ponovno pokrenuti pali broker s netaknutim podacima kako bi nastavio raditi kao glavni bez gubitka podataka. <\/p>\n<p>Ali (i to je velika ali) ako je broker izgubio svoje podatke, tada imamo veliki problem: red \u010dekanja je izgubljen! Svi podaci su nestali! \u010cak i ako imate ogledala koja ve\u0107inom susti\u017eu glavni red, ta ogledala tako\u0111er se odbacuju.<\/p>\n<p>Kako bismo ponovo dodali \u010dvor s istim imenom, ka\u017eemo klasteru da zaboravi izgubljeni \u010dvor (komandom <i>rabbitmqctl forget_cluster_node<\/i>) i pokrenemo novi broker s istim imenom hosta. Dok klaster pamti izgubljeni \u010dvor, on pamti stari red \u010dekanja i nesinkronizirana ogledala. Kada se klasteru ka\u017ee da zaboravi izgubljeni \u010dvor, taj se red tako\u0111er zaboravlja. Sada ga treba ponovo objaviti. Izgubili smo sve podatke, iako smo imali ogledala s djelomi\u010dnim skupom podataka. Bilo bi bolje pre\u0107i na nesinkronizirano ogledalo!<\/p>\n<p>Stoga je ru\u010dna sinkronizacija (i neizvr\u0161enje sinkronizacije) zajedno s <code>ha-promote-on-failure=when-synced<\/code>, po mom mi\u0161ljenju, prili\u010dno rizi\u010dna. Dokumenti ka\u017eu da takva opcija postoji za sigurnost podataka, ali to je dvostruka o\u0161trica.<\/p>\n<h1>Ponovno ravnote\u017eenje glavnih \u010dvorova<\/h1>\n<p>\nKao \u0161to je obe\u0107ano, vra\u0107amo se na problem nagomilavanja svih glavnih \u010dvorova na jednom ili vi\u0161e \u010dvorova. To se mo\u017ee dogoditi \u010dak i kao rezultat \u201ekliznog\u201c (rolling) a\u017euriranja klastera. U klasteru s tri \u010dvora svi glavni redovi nagomilat \u0107e se na jednom ili dva \u010dvora.<\/p>\n<p>Ponovno ravnote\u017eenje glavnih \u010dvorova mo\u017ee biti problemati\u010dno iz dva razloga:<\/p>\n<ul>\n<li>Nema dobrih alata za izvo\u0111enje ponovnog ravnote\u017eenja<\/li>\n<li>Sinkronizacija redova<\/li>\n<\/ul>\n<p>\nZa rebalance postoji vanjski <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Ayanda-D\/rabbitmq-queue-master-balancer\">plugin<\/a><\/noindex>, koji nije slu\u017ebeno podr\u017ean. O vanjskim pluginima se u uputama RabbitMQ <noindex><a rel=\"nofollow\" href=\"https:\/\/www.rabbitmq.com\/upgrade.html\">navodi<\/a><\/noindex>: \u00abPlugin pru\u017ea neke dodatne alate za konfiguraciju i izvje\u0161tavanje, ali nije podr\u017ean niti provjeren od strane tima RabbitMQ. Koristite na vlastiti rizik\u00bb.<\/p>\n<p>Postoji jo\u0161 jedan trik za premje\u0161tanje glavne queue putem HA politika. U uputama se spominje <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/rabbitmq\/support-tools\/blob\/master\/scripts\/rebalance-queue-masters\">skriptu<\/a><\/noindex> za to. Funkcioni\u0161e na sljede\u0107i na\u010din:<\/p>\n<ul>\n<li>Bri\u0161e sve zrcale pomo\u0107u privremene politike s vi\u0161im prioritetom od postoje\u0107e HA politike.\n<\/li>\n<li>Mijenja privremenu HA politiku za kori\u0161tenje 'nodova' na\u010dina s navedenim nodom na koji se treba premjestiti glavna queue.\n<\/li>\n<li>Sinhronizira queue radi prisilne migracije.\n<\/li>\n<li>Nakon \u0161to se migracija zavr\u0161i, bri\u0161e privremenu politiku. Aktivira se izvorna HA politika i stvara potrebni broj zrcala.<\/li>\n<\/ul>\n<p>\nNedostatak je u tome \u0161to ovakav pristup mo\u017eda ne\u0107e funkcionirati ako imate velike queue ili stroge zahtjeve za redundancijom.<\/p>\n<p>Sada pogledajmo kako RabbitMQ klasteri funkcioni\u0161u s mre\u017enim razdvajanjem.<\/p>\n<h1>Prekid povezanosti<\/h1>\n<p>\n\u010cvorovi distribuiranog sistema su povezani mre\u017enim vezama, a mre\u017ene veze mogu i ho\u0107e prestati raditi. U\u010destalost prekida zavisi od lokalne infrastrukture ili pouzdanosti izabranog oblaka. U svakom slu\u010daju, distribuirani sistemi trebaju biti u stanju nositi se s njima. Ponovo imamo izbor izme\u0111u dostupnosti i dosljednosti, i ponovo je dobra vijest da RabbitMQ omogu\u0107ava obje opcije (samo ne simultano).<\/p>\n<p>S RabbitMQ imamo dvije osnovne opcije:<\/p>\n<ul>\n<li>Dozvoliti logi\u010dko razdvajanje (split-brain). Ovo osigurava dostupnost, ali mo\u017ee izazvati gubitak podataka.\n<\/li>\n<li>Zabraniti logi\u010dko razdvajanje. Mo\u017ee dovesti do kratkotrajnog gubitka dostupnosti ovisno o na\u010dinu povezivanja klijenata s klasterom. Tako\u0111er mo\u017ee dovesti do potpune nedostupnosti u klasteru od dva \u010dvora.<\/li>\n<\/ul>\n<p>\nAli \u0161to je logi\u010dko razdvajanje? To je kada se klaster dijeli na dva dijela zbog gubitka mre\u017enih veza. Na svakoj strani, zrcala postaju glavni, tako da na svaku queue ispada vi\u0161e glavnih.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/d880a935df450fb994edfed0715e026e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 17. Glavna kola i dva zrcala, svako na zasebnom \u010dvoru. Onda se javlja mre\u017eni kvar, i jedno zrcalo se odvoji. Odvojeni \u010dvor vidi da su se dva druga \u010dvora isklju\u010dila, i unapre\u0111uje svoja zrcala do glavnog. Sada imamo dva glavna reda, a oba dopu\u0161taju pisanje i \u010ditanje.<\/i> <\/p>\n<p>Ako izdava\u010di \u0161alju podatke u oba glavna, dobit \u0107emo dvije razdvojene kopije reda.<\/p>\n<p>Razli\u010diti re\u017eimi RabbitMQ osiguravaju ili dostupnost ili konzistentnost.<\/p>\n<h3>Re\u017eim Ignoriraj (zadano)<\/h3>\n<p>\nOvaj re\u017eim osigurava dostupnost. Nakon gubitka povezanosti dolazi do logi\u010dkog razdvajanja. Nakon ponovnog uspostavljanja povezanosti, administrator mora odlu\u010diti kojoj strani dati prednost. Gubi strana \u0107e se ponovo pokrenuti, a svi pohranjeni podaci na toj strani se gube.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/4d82c13b5ef21837ba819f5c246a1e41.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 18. Tri izdava\u010da povezana s tri brokera. Interno, klaster usmjerava sve zahtjeve u glavni red na Brokeru 2.<\/i><\/p>\n<p>Sada gubimo Brokera 3. On vidi da su se drugi brokeri isklju\u010dili, i unapre\u0111uje svoje zrcalo do glavnog. Tako dolazi do logi\u010dkog razdvajanja.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/c7e01d51b24023bacdd93cfad95c9eab.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 19. Logi\u010dko razdvajanje (split-brain). Zapisi idu u dva glavna reda, i dvije kopije se razdvajaju.<\/i><\/p>\n<p>Povezanost se obnavlja, ali logi\u010dko razdvajanje ostaje. Administrator mora ru\u010dno odabrati gube\u0107u stranu. U prikazanom slu\u010daju administrator restartuje Brokera 3. Gube se sve poruke koje nije \u0443\u0441\u043f\u0438\u043e prenijeti.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/51c3ee15024d3c83ba625e3ff9cdeb90.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 20. Administrator isklju\u010duje Brokera 3.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/0bac8e33de25c0c5381d336d26464858.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 21. Administrator pokre\u0107e Brokera 3, i on se pridru\u017euje klasteru, gube\u0107i sve poruke koje su tu ostale.<\/i><\/p>\n<p>Tijekom gubitka povezanosti i nakon njenog obnavljanja, klaster i ovaj red su bili dostupni za \u010ditanje i pisanje.<\/p>\n<h3>Re\u017eim Autoheal<\/h3>\n<p>\nRadi sli\u010dno re\u017eimu Ignoriraj, osim \u0161to sam klaster automatski bira gube\u0107u stranu nakon razdvajanja i obnove povezanosti. Gubi strana se vra\u0107a u klaster prazna, a red gubi sve poruke koje su bile poslane samo na tu stranu.<\/p>\n<h3>Re\u017eim Pauza Manjine<\/h3>\n<p>\nAko ne \u017eelimo dopustiti logi\u010dko razdvajanje, onda je na\u0161a jedina opcija odbiti \u010ditanje i pisanje na manjoj strani nakon podjela klastera. Kada broker vidi da se nalazi na manjoj strani, on obustavlja rad, zatvara sve postoje\u0107e veze i odbija sve nove. Jednom u sekundi provjerava obnovu povezanosti. \u010cim se povezanost obnovi, on ponovno pokre\u0107e rad i pridru\u017euje se klasteru.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/7a51cf509b2c94e2ae100c7dedd9d21a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sl. 22. Tri izdava\u010da povezana su s tri brokera. Interno, klaster proslje\u0111uje sve zahtjeve u glavnu red na Brokeru 2.<\/i><\/p>\n<p>Zatim, Brokera 1 i 2 odvojeni su od Brokera 3. Umjesto da unaprijedi svoje zrcalo u glavnog, Broker 3 obustavlja rad i postaje nedostupan.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/c12ec38a47e1f8ccceebfa1854f54f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sl. 23. Broker 3 obustavlja rad, isklju\u010duje sve klijente i odbija zahtjeve za povezivanje.<\/i><\/p>\n<p>\u010cim se povezanost obnovi, on se vra\u0107a u klaster.<\/p>\n<p>Pogledajmo jo\u0161 jedan primjer, gdje se glavna red nalazi na Brokeru 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/4cc6a28270f00a280ecb5af5252f4e07.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sl. 24. Glavna red na Brokeru 3.<\/i><\/p>\n<p>Tada se doga\u0111a ista gubitak povezanosti. Broker 3 se stavlja na pauzu, budu\u0107i da se nalazi na manjoj strani. Na drugoj strani, \u010dvorovi vide da je Broker 3 ispao, tako da starije zrcalo s Brokera 1 i 2 postaje glavni.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/d0d032385533bb53c5a95927afcd3119.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sl. 25. Prelazak na Brokera 2 kada je Broker 3 nedostupan.<\/i><\/p>\n<p>Kada se povezanost obnovi, Broker 3 \u0107e se pridru\u017eiti klasteru.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ naspram Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima\" src=\"\/wp-content\/uploads\/2019\/11\/53f8186a040ae07724ef59cf79b72a0c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sl. 26. Klaster se vratio u normalan rad.<\/i><\/p>\n<p>Ovdje je va\u017eno razumjeti da dobivamo dosljednost, ali tako\u0111er mo\u017eemo dobiti dostupnost, <i><b>ako<\/b><\/i> uspje\u0161no preusmjerimo klijente na ve\u0107u stranu podjela. Za ve\u0107inu situacija osobno bih izabrao na\u010din Pauza Manjih, ali to zaista ovisi o konkretnoj situaciji.<\/p>\n<p>Za osiguranje dostupnosti va\u017eno je osigurati da se klijenti uspje\u0161no povezuju s \u010dvorom. Razmotrite na\u0161e opcije.<\/p>\n<h1>Osiguranje povezanosti klijenata<\/h1>\n<p>\nImamo nekoliko na\u010dina kako nakon gubitka povezanosti usmjeriti klijente na glavnu komponentu klastera ili na aktivne \u010dvori\u0107e (nakon kvara jednog \u010dvora). Prvo, sjetimo se da je odre\u0111ena redoslijed smje\u0161ten na odre\u0111enom \u010dvoru, ali usmjeravanje i politike repliciraju se na svim \u010dvorovima. Klijenti se mogu spojiti na bilo koji \u010dvor, a unutarnje usmjeravanje \u0107e ih odvesti gdje treba. No, kada je \u010dvor zaustavljen, odbija veze, tako da se klijenti moraju spojiti na drugi \u010dvor. Ako \u010dvor padne, malo toga mo\u017ee u\u010diniti.<\/p>\n<p>Na\u0161e opcije:<\/p>\n<ul>\n<li>Pristup klasteru ostvaruje se preko balansira\u010da optere\u0107enja koji jednostavno cikli\u010dki prolazi kroz \u010dvorove, a klijenti ponavljaju poku\u0161aje povezivanja do uspje\u0161nog zavr\u0161etka. Ako \u010dvor ne radi ili je zaustavljen, poku\u0161aji povezivanja na taj \u010dvor bit \u0107e neuspje\u0161ni, ali sljede\u0107i poku\u0161aji \u0107e i\u0107i na druge servere (u cikli\u010dkom re\u017eimu). Ovo je pogodno za kratkotrajni gubitak povezanosti ili sru\u0161eni server koji \u0107e brzo biti podignut.\n<\/li>\n<li>Pristup klasteru kroz balansira\u010d optere\u0107enja i uklanjanje zaustavljenih\/sru\u0161enih \u010dvorova iz popisa \u010dim budu otkriveni. Ako to brzo u\u010dinimo, i ako su klijenti sposobni na ponovne poku\u0161aje povezivanja, dobit \u0107emo stalnu dostupnost.\n<\/li>\n<li>Dati svakom klijentu popis svih \u010dvorova, a klijent nasumi\u010dno bira jedan od njih prilikom povezivanja. Ako dobije gre\u0161ku prilikom poku\u0161aja povezivanja, prelazi na sljede\u0107i \u010dvor na popisu, dok se ne pove\u017ee.\n<\/li>\n<li>Ukloniti promet s sru\u0161enog\/zaustavljenog \u010dvora putem DNS-a. Ovo se posti\u017ee malim TTL-om.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Zaklju\u010dci<\/h1>\n<p>\nKlasterizacija RabbitMQ-a ima svoje prednosti i nedostatke. Najozbiljniji nedostaci su:<\/p>\n<ul>\n<li>prilikom pridru\u017eivanja klasteru, \u010dvorovi odbacuju svoje podatke;\n<\/li>\n<li>blokiraju\u0107a sinkronizacija dovodi do nedostupnosti reda.<\/li>\n<\/ul>\n<p>\nSve te\u0161ke odluke proizlaze iz ove dvije karakteristike arhitekture. Da RabbitMQ mo\u017ee pohraniti podatke prilikom ponovnog povezivanja klastera, tada bi sinhronizacija bila br\u017ea. Kada bi bio sposoban za neblokiraju\u0107u sinhronizaciju, bolje bi podr\u017eao velike redove. Rje\u0161avanje ova dva problema ozbiljno bi pobolj\u0161alo performanse RabbitMQ kao tehnologije razmjene poruka otporne na gre\u0161ke i visoke dostupnosti. Ne bih preporu\u010dio RabbitMQ s klasterizacijom u sljede\u0107im situacijama:<\/p>\n<ul>\n<li>Nepouzdana mre\u017ea.\n<\/li>\n<li>Nepouzdano skladi\u0161tenje.\n<\/li>\n<li>Ve\u0107i redovi.<\/li>\n<\/ul>\n<p>\n\u0160to se ti\u010de postavki za visoku dostupnost, razmotrite sljede\u0107e:<\/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> (ili <code>autoheal<\/code>)\n<\/li>\n<li>postojane poruke\n<\/li>\n<li>osigurajte da se klijenti povezuju na aktivni \u010dvor kada neki \u010dvor ne uspije<\/li>\n<\/ul>\n<p>\nZa dosljednost (sigurnost podataka) razmotrite sljede\u0107e postavke:<\/p>\n<ul>\n<li>Publisher Confirms i Manual Acknowledgements na strani potro\u0161a\u010da\n<\/li>\n<li><code>ha-promote-on-failure=when-synced<\/code>, ako izdava\u010di mogu ponoviti poku\u0161aj kasnije i ako imate vrlo pouzdano skladi\u0161te! Ina\u010de, stavite <code>=always<\/code>.\n<\/li>\n<li><code>ha-sync-mode=automatic<\/code> (ali za velike neaktivne redove mo\u017eda \u0107e biti potreban ru\u010dni na\u010din; osim toga, razmislite ho\u0107e li nedostupnost dovesti do gubitka poruka)\n<\/li>\n<li>mode Pause Minority\n<\/li>\n<li>postojane poruke<\/li>\n<\/ul>\n<p>\nNismo razmotrili sve aspekte otpornosti na gre\u0161ke i visoke dostupnosti; na primjer, kako sigurno izvr\u0161iti administrativne procedure (kao \u0161to su postupna a\u017euriranja). Tako\u0111e, treba razgovarati o federaciji i pluginu Shovel.<\/p>\n<p>Ako sam ne\u0161to propustio, molim javite mi.<\/p>\n<p>Pogledajte i moj <noindex><a rel=\"nofollow\" href=\"https:\/\/jack-vanlightly.com\/blog\/2018\/9\/10\/how-to-lose-messages-on-a-rabbitmq-cluster\">post<\/a><\/noindex>, gdje sprovodim eksperiment s RabbitMQ klasterom putem Dockera i Blockade, kako bih testirao neke scenarije gubitka poruka opisane u ovom \u010dlanku.<\/p>\n<p>Prethodni \u010dlanci serije: <br \/>\nBr. 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 \/>\nBr. 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 \/>\nBr. 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 \/>Izvor: <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.4 - 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\/hr\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"hr_HR\" \/>\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\/hr\/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 protiv Kafke: otpornost na gre\u0161ke i visoka dostupnost u klasterima | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/52525","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=52525"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/52525\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=52525"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=52525"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=52525"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}