{"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\/cs\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","title":{"rendered":"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/d8e584d210a6a016a962ad6f956a2078.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOdolnost proti chyb\u00e1m a vysok\u00e1 dostupnost jsou rozs\u00e1hl\u00e1 t\u00e9mata, proto v\u011bnujeme RabbitMQ a Kafka samostatn\u00e9 \u010dl\u00e1nky. Tento \u010dl\u00e1nek je o RabbitMQ a n\u00e1sleduj\u00edc\u00ed bude o Kafka, ve srovn\u00e1n\u00ed s RabbitMQ. \u010cl\u00e1nek je dlouh\u00fd, tak\u017ee se pohodln\u011b usa\u010fte.<\/p>\n<p>Pod\u00edv\u00e1me se na strategie odolnosti proti chyb\u00e1m, konzistence a vysok\u00e9 dostupnosti (HA), a tak\u00e9 na kompromisy, kter\u00fdm je t\u0159eba \u010delit v ka\u017ed\u00e9 strategii. RabbitMQ m\u016f\u017ee fungovat na clusteru uzl\u016f \u2014 a pak je klasifikov\u00e1no jako distribuovan\u00fd syst\u00e9m. Kdy\u017e mluv\u00edme o distribuovan\u00fdch syst\u00e9mech, \u010dasto hovo\u0159\u00edme o konzistenci a dostupnosti. <\/p>\n<p>Tyto pojmy popisuj\u00ed, jak se syst\u00e9m chov\u00e1 p\u0159i selh\u00e1n\u00ed. Selh\u00e1n\u00ed s\u00ed\u0165ov\u00e9ho p\u0159ipojen\u00ed, selh\u00e1n\u00ed serveru, selh\u00e1n\u00ed pevn\u00e9ho disku, do\u010dasn\u00e1 nedostupnost serveru kv\u016fli vy\u010di\u0161t\u011bn\u00ed pam\u011bti, ztr\u00e1ta paket\u016f nebo zpomalen\u00ed s\u00ed\u0165ov\u00e9ho p\u0159ipojen\u00ed. To v\u0161e m\u016f\u017ee v\u00e9st ke ztr\u00e1t\u011b dat nebo konflikt\u016fm. Ukazuje se, \u017ee je prakticky nemo\u017en\u00e9 vybudovat syst\u00e9m, kter\u00fd by byl sou\u010dasn\u011b \u00fapln\u011b konzistentn\u00ed (bez ztr\u00e1ty dat, bez nesouladu dat) a dostupn\u00fd (bude akceptovat operace \u010dten\u00ed a z\u00e1pisu) pro v\u0161echny typy selh\u00e1n\u00ed.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nUvid\u00edme, \u017ee konzistence a dostupnost jsou na opa\u010dn\u00fdch konc\u00edch spektra, a mus\u00edte si vybrat, kterou stranu chcete optimalizovat. Dobrou zpr\u00e1vou je, \u017ee s RabbitMQ je takov\u00e1 volba mo\u017en\u00e1. M\u016f\u017eete manipula\u010dn\u00edmi 'nerdy' p\u00e1\u010dkami posouvat rovnov\u00e1hu sm\u011brem k v\u011bt\u0161\u00ed konzistenci nebo v\u011bt\u0161\u00ed dostupnosti.<\/p>\n<p>Zvl\u00e1\u0161tn\u00ed pozornost v\u011bnujeme tomu, jak\u00e9 konfigurace vedou ke ztr\u00e1t\u011b dat v d\u016fsledku potvrzen\u00fdch z\u00e1znam\u016f. Existuje \u0159et\u011bzec odpov\u011bdnosti mezi publik\u00e1tory, brokery a spot\u0159ebiteli. Jakmile je zpr\u00e1va p\u0159ed\u00e1na brokerovi, je jeho \u00fakolem zpr\u00e1vu neztratit. Kdy\u017e broker potvrd\u00ed publik\u00e1torovi p\u0159ijet\u00ed zpr\u00e1vy, ne\u010dek\u00e1me, \u017ee bude ztracena. Ale uvid\u00edme, \u017ee se to skute\u010dn\u011b m\u016f\u017ee st\u00e1t v z\u00e1vislosti na konfiguraci va\u0161eho brokera a vydavatele.<\/p>\n<h1>Primitivy odolnosti jednoho uzlu<\/h1>\n<p><\/p>\n<h3>Odoln\u00e9 fronty\/\u0159e\u0161en\u00ed<\/h3>\n<p>\nV RabbitMQ existuj\u00ed dva typy front: trval\u00e9 (durable) a netrval\u00e9 (non-durable). V\u0161echny fronty jsou ukl\u00e1d\u00e1ny do datab\u00e1ze Mnesia. Trval\u00e9 fronty se znovu deklaruj\u00ed p\u0159i spu\u0161t\u011bn\u00ed uzlu a t\u00edm p\u00e1dem p\u0159e\u017eij\u00ed restart, selh\u00e1n\u00ed syst\u00e9mu nebo selh\u00e1n\u00ed serveru (pokud jsou data uchov\u00e1na). To znamen\u00e1, \u017ee pokud deklarujete sm\u011brov\u00e1n\u00ed (exchange) a frontu jako trval\u00e9, infrastruktura front\/sm\u011brov\u00e1n\u00ed se vr\u00e1t\u00ed do provozn\u00edho re\u017eimu.<\/p>\n<p>Netrval\u00e9 fronty a sm\u011brov\u00e1n\u00ed se odstra\u0148uj\u00ed p\u0159i restartu uzlu.<\/p>\n<h3>Trval\u00e9 zpr\u00e1vy<\/h3>\n<p>\nJednodu\u0161e to, \u017ee je fronta trval\u00e1, neznamen\u00e1, \u017ee v\u0161echny jej\u00ed zpr\u00e1vy p\u0159e\u017eij\u00ed restart uzlu. Obnoveny budou pouze zpr\u00e1vy, kter\u00e9 pubisher ozna\u010dil jako <i>trval\u00e9<\/i> (persistent). Trval\u00e9 zpr\u00e1vy skute\u010dn\u011b vytv\u00e1\u0159ej\u00ed dodate\u010dn\u00e9 zat\u00ed\u017een\u00ed pro brokera, ale pokud je ztr\u00e1ta zpr\u00e1vy nep\u0159ijateln\u00e1, nen\u00ed jin\u00e1 mo\u017enost.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/8b8e2de4ef82bf8497960657aac0ddb0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 1. Matice trvanlivosti<\/i><\/p>\n<h1>Klasterizace se zrcadlen\u00edm fronty<\/h1>\n<p>\nAbychom p\u0159e\u017eili ztr\u00e1tu brokera, pot\u0159ebujeme redundanci. M\u016f\u017eeme spojit n\u011bkolik uzl\u016f RabbitMQ do klastru a pot\u00e9 p\u0159idat dal\u0161\u00ed redundanci replikac\u00ed front mezi n\u011bkolika uzly. Tak, i kdy\u017e jeden uzel sel\u017ee, neztr\u00e1c\u00edme data a z\u016fst\u00e1v\u00e1me dostupn\u00ed. <\/p>\n<p>Zrcadlen\u00ed fronty:<\/p>\n<ul>\n<li>jedna hlavn\u00ed fronta (master), kter\u00e1 p\u0159ij\u00edm\u00e1 v\u0161echny p\u0159\u00edkazy k z\u00e1pisu a \u010dten\u00ed\n<\/li>\n<li>jedno nebo v\u00edce zrcadel, kter\u00e9 p\u0159ij\u00edmaj\u00ed v\u0161echny zpr\u00e1vy a metadata z hlavn\u00ed fronty. Tato zrcadla neexistuj\u00ed pro \u0161k\u00e1lov\u00e1n\u00ed, ale v\u00fdhradn\u011b pro redundanci.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/35f3d4bdc4f5e10da0e40eb91c5d8280.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 2. Zrcadlen\u00ed fronty<\/i><\/p>\n<p>Zrcadlen\u00ed se nastavuje odpov\u00eddaj\u00edc\u00ed politikou. V n\u00ed lze zvolit koeficient replikace a dokonce uzly, na kter\u00fdch by m\u011bla b\u00fdt fronta um\u00edst\u011bna. P\u0159\u00edklady:<\/p>\n<ul>\n<li><code>ha-mode: all<\/code>\n<\/li>\n<li><code>ha-mode: exactly, ha-params: 2<\/code> (jeden master a jedno zrcadlo)\n<\/li>\n<li><code>ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2<\/code><\/li>\n<\/ul>\n<p><\/p>\n<h1>Potvrzen\u00ed publisherovi<\/h1>\n<p>\nPro dosa\u017een\u00ed konzistentn\u00edho z\u00e1pisu jsou vy\u017eadov\u00e1na potvrzen\u00ed od publika (Publisher Confirms). Bez nich je pravd\u011bpodobnost ztr\u00e1ty zpr\u00e1v. Potvrzen\u00ed je zas\u00edl\u00e1no publiku po z\u00e1pisu zpr\u00e1vy na disk. RabbitMQ zapisuje zpr\u00e1vy na disk nikoli p\u0159i p\u0159ijet\u00ed, ale na periodick\u00e9 b\u00e1zi, v \u0159\u00e1du n\u011bkolika set milisekund. Kdy\u017e je fronta replikov\u00e1na, potvrzen\u00ed je posl\u00e1no a\u017e pot\u00e9, co v\u0161echna zrcadla tak\u00e9 zapsala svou kopii zpr\u00e1vy na disk. To znamen\u00e1, \u017ee pou\u017eit\u00ed potvrzen\u00ed zvy\u0161uje zpo\u017ed\u011bn\u00ed, ale pokud je d\u016fle\u017eit\u00e1 bezpe\u010dnost dat, jsou nezbytn\u00e1.<\/p>\n<h1>Odoln\u00e1 fronta<\/h1>\n<p>\nKdy\u017e broker skon\u010d\u00ed nebo spadne, v\u0161echny hlavn\u00ed fronty (master) na tomto uzlu sel\u017eou spolu s n\u00edm. Pot\u00e9 klastr vybere nejstar\u0161\u00ed zrcadlo ka\u017ed\u00e9ho masteru a pov\u00fd\u0161\u00ed ho na nov\u00e9ho mastera.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/8d8227c00643f35e0dc752b6617e18fb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 3. N\u011bkolik zrcadlen\u00fdch front a jejich politiky<\/i><\/p>\n<p>Broker 3 spadne. V\u0161imn\u011bte si, \u017ee zrcadlo Fronty C na Brokeru 2 se povy\u0161uje na mastera. Tak\u00e9 si v\u0161imn\u011bte, \u017ee pro Frontu C bylo vytvo\u0159eno nov\u00e9 zrcadlo na Brokeru 1. RabbitMQ se v\u017edy sna\u017e\u00ed udr\u017eovat koeficient replikace, uveden\u00fd ve va\u0161ich politik\u00e1ch.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/d08b3ada22e79686d448714f7bab009a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 4. Broker 3 selh\u00e1v\u00e1, co\u017e zp\u016fsobuje selh\u00e1n\u00ed fronty C<\/i> <\/p>\n<p>Pad\u00e1 tak\u00e9 Broker 1! Z\u016fst\u00e1v\u00e1me pouze s jedn\u00edm brokerem. Zrcadlo Fronty B se povy\u0161uje na mastera.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/dcc1d542c40c441194fd07e51046c619.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 5<\/i><\/p>\n<p>Vr\u00e1tili jsme Broker 1. Bez ohledu na to, jak \u00fasp\u011b\u0161n\u011b data p\u0159e\u017eila ztr\u00e1tu a obnoven\u00ed brokera, v\u0161echny zrcadlen\u00e9 zpr\u00e1vy fronty jsou p\u0159i restartu vy\u0159azeny. Je d\u016fle\u017eit\u00e9 to poznamenat, proto\u017ee to m\u00e1 d\u016fsledky. Tyto d\u016fsledky si brzy probereme. Takto se Broker 1 nyn\u00ed znovu st\u00e1v\u00e1 \u010dlenem klastru a klastr se sna\u017e\u00ed dodr\u017eovat politiky a proto vytv\u00e1\u0159\u00ed zrcadla na Brokeru 1.<\/p>\n<p>V tomto p\u0159\u00edpad\u011b byla ztr\u00e1ta Brokera 1 \u00fapln\u00e1, stejn\u011b jako dat, tak\u017ee nezrcadlen\u00e1 Fronta B byla zcela ztracena.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/7ac7ab65ea6dff9c5a49372c04c83a37.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 6. Broker 1 se vrac\u00ed do provozu<\/i><\/p>\n<p>Broker 3 se vr\u00e1til do provozu, tak\u017ee fronty A a B znovu z\u00edsk\u00e1vaj\u00ed vytvo\u0159en\u00e9 na n\u011bm zrcadla, aby splnily sv\u00e9 HA politiky. Ale nyn\u00ed jsou v\u0161echny hlavn\u00ed fronty na jednom uzlu! To nen\u00ed ide\u00e1ln\u00ed, lep\u0161\u00ed by bylo rovnom\u011brn\u00e9 rozlo\u017een\u00ed mezi uzly. Bohu\u017eel zde nejsou \u017e\u00e1dn\u00e9 speci\u00e1ln\u00ed mo\u017enosti pro p\u0159ebalancov\u00e1n\u00ed master\u016f. K t\u00e9to ot\u00e1zce se vr\u00e1t\u00edme pozd\u011bji, proto\u017ee nejprve mus\u00edme zv\u00e1\u017eit synchronizaci fronty. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/a54e53bb01e2f830a54f88acaa668984.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 7. Broker 3 se vrac\u00ed do provozu. V\u0161echny hlavn\u00ed fronty na jednom uzlu!<\/i><\/p>\n<p>T\u00edmto zp\u016fsobem byste m\u011bli m\u00edt nyn\u00ed p\u0159edstavu o tom, jak zrcadla zaji\u0161\u0165uj\u00ed redundantnost a odolnost v\u016f\u010di v\u00fdpadk\u016fm. To zaru\u010duje dostupnost v p\u0159\u00edpad\u011b selh\u00e1n\u00ed jednoho uzlu a chr\u00e1n\u00ed p\u0159ed ztr\u00e1tou dat. Ale je\u0161t\u011b jsme neskon\u010dili, proto\u017ee je to ve skute\u010dnosti mnohem slo\u017eit\u011bj\u0161\u00ed.<\/p>\n<h1>Synchronizace<\/h1>\n<p>\nP\u0159i vytvo\u0159en\u00ed nov\u00e9ho zrcadla budou v\u0161echny nov\u00e9 zpr\u00e1vy v\u017edy replikov\u00e1ny na toto zrcadlo a jak\u00e1koli dal\u0161\u00ed. Co se t\u00fd\u010de existuj\u00edc\u00edch dat v hlavn\u00ed front\u011b, m\u016f\u017eeme je replikovat do nov\u00e9ho zrcadla, kter\u00e9 se st\u00e1v\u00e1 \u00faplnou kopi\u00ed masteru. Tak\u00e9 m\u016f\u017eeme neprov\u00e1d\u011bt replikaci existuj\u00edc\u00edch zpr\u00e1v a nechat hlavn\u00ed frontu a nov\u00e9 zrcadlo se sch\u00e1zet v \u010dase, kdy\u017e nov\u00e9 zpr\u00e1vy p\u0159ich\u00e1zej\u00ed na konec a existuj\u00edc\u00ed zpr\u00e1vy odch\u00e1zej\u00ed z hlavy hlavn\u00ed fronty.<\/p>\n<p>Takov\u00e1 synchronizace je prov\u00e1d\u011bna automaticky nebo ru\u010dn\u011b a je \u0159\u00edzena politikou front. Zva\u017eme p\u0159\u00edklad.<\/p>\n<p>M\u00e1me dv\u011b zrcadlen\u00e9 fronty. Fronta A se synchronizuje automaticky, zat\u00edmco Fronta B ru\u010dn\u011b. V obou front\u00e1ch je po deseti zpr\u00e1v\u00e1ch.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/304f2a475fdd0cb6d3069140c667a0a7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 8. Dv\u011b fronty s r\u016fzn\u00fdmi re\u017eimy synchronizace<\/i><\/p>\n<p>Nyn\u00ed ztr\u00e1c\u00edme Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/49114966f440c407488bb467ff6dbf93.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 9. Broker 3 selhal<\/i><\/p>\n<p>Broker 3 se vrac\u00ed do provozu. Kluster vytv\u00e1\u0159\u00ed zrcadlo pro ka\u017edou frontu na nov\u00e9m uzlu a automaticky synchronizuje novou Frontu A s masterem. Nicm\u00e9n\u011b zrcadlo nov\u00e9 Fronty B z\u016fst\u00e1v\u00e1 pr\u00e1zdn\u00e9. T\u00edm m\u00e1me plnou redundantnost Fronty A a pouze jedno zrcadlo pro existuj\u00edc\u00ed zpr\u00e1vy Fronty B.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/adffc1f5eff8806edbd83772f338d67f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 10. Nov\u00e9 zrcadlo Fronty A p\u0159ij\u00edm\u00e1 v\u0161echny existuj\u00edc\u00ed zpr\u00e1vy, zat\u00edmco nov\u00e9 zrcadlo Fronty B \u2014 ne.<\/i><\/p>\n<p>Do obou front se p\u0159id\u00e1 je\u0161t\u011b deset zpr\u00e1v. Pot\u00e9 Broker 2 sel\u017ee a Fronta A se vrac\u00ed k nejstar\u0161\u00ed replikaci, kter\u00e1 je na Brokeru 1. P\u0159i selh\u00e1n\u00ed nedoch\u00e1z\u00ed ke ztr\u00e1t\u011b dat. Ve Front\u011b B je dvacet zpr\u00e1v v hlavn\u00edm re\u017eimu a pouze deset v replikaci, proto\u017ee tato fronta nikdy nereplikovala p\u016fvodn\u00edch deset zpr\u00e1v.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/c6cfef4bced5627bf243c2f020a42646.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 11. Fronta A se vrac\u00ed na Broker 1 bez ztr\u00e1ty zpr\u00e1v<\/i><\/p>\n<p>Do obou front se nyn\u00ed p\u0159id\u00e1 je\u0161t\u011b deset zpr\u00e1v. Nyn\u00ed sel\u017ee Broker 1. Fronta A se bez probl\u00e9m\u016f p\u0159epne na replikaci bez ztr\u00e1ty zpr\u00e1v. Nicm\u00e9n\u011b Front\u011b B vzniknou probl\u00e9my. V t\u00e9to f\u00e1zi m\u016f\u017eeme optimalizovat bu\u010f dostupnost, nebo konzistenci. <\/p>\n<p>Pokud chceme optimalizovat dostupnost, m\u011bli bychom nastavit politiku <b><i>ha-promote-on-failure<\/i><\/b> na <b><i>always<\/i><\/b>. Toto je v\u00fdchoz\u00ed hodnota, tak\u017ee politiku lze jednodu\u0161e neuvedout. V takov\u00e9m p\u0159\u00edpad\u011b v podstat\u011b p\u0159ij\u00edm\u00e1me selh\u00e1n\u00ed nesynchronizovan\u00fdch replikac\u00ed. To povede ke ztr\u00e1t\u011b zpr\u00e1v, ale fronta z\u016fstane dostupn\u00e1 pro \u010dten\u00ed a z\u00e1pis.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/cd704cf4397184c212e1576b986abbaa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 12. Fronta A se vrac\u00ed na Broker 3 bez ztr\u00e1ty zpr\u00e1v. Fronta B se vrac\u00ed na Broker 3 se ztr\u00e1tou deseti zpr\u00e1v<\/i><\/p>\n<p>M\u016f\u017eeme tak\u00e9 nastavit <code>ha-promote-on-failure<\/code> na hodnotu <code>when-synced<\/code>. V tomto p\u0159\u00edpad\u011b m\u00edsto vr\u00e1cen\u00ed na replikaci fronta po\u010dk\u00e1, a\u017e se Broker 1 s jeho daty vr\u00e1t\u00ed do provozu. Po jeho n\u00e1vratu se hlavn\u00ed fronta op\u011bt nach\u00e1z\u00ed na Brokeru 1 bez ztr\u00e1ty dat. Dostupnost je ob\u011btov\u00e1na bezpe\u010dnosti dat. Ale je to riskantn\u00ed re\u017eim, kter\u00fd m\u016f\u017ee v\u00e9st dokonce k \u00fapln\u00e9 ztr\u00e1t\u011b dat, co\u017e si brzy uk\u00e1\u017eeme.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/03fed936fe75220e22f68432ca81b654.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 13. Fronta B z\u016fst\u00e1v\u00e1 nedostupn\u00e1 po ztr\u00e1t\u011b Brokeru 1<\/i><\/p>\n<p>M\u016f\u017eete se pt\u00e1t: \u201eMo\u017en\u00e1 je lep\u0161\u00ed nikdy nepou\u017e\u00edvat automatickou synchronizaci?\u201c. Odpov\u011b\u010f spo\u010d\u00edv\u00e1 v tom, \u017ee synchronizace je blokuj\u00edc\u00ed operace. B\u011bhem synchronizace nem\u016f\u017ee hlavn\u00ed fronta prov\u00e1d\u011bt \u017e\u00e1dn\u00e9 \u010dtec\u00ed nebo z\u00e1pisov\u00e9 operace!<\/p>\n<p>Zva\u017ete p\u0159\u00edklad. Nyn\u00ed m\u00e1me velmi velk\u00e9 fronty. Jak se mohou dostat do takov\u00e9 velikosti? Z n\u011bkolika d\u016fvod\u016f:<\/p>\n<ul>\n<li>Fronty nejsou aktivn\u011b vyu\u017e\u00edv\u00e1ny\n<\/li>\n<li>Jedn\u00e1 se o vysokorychlostn\u00ed fronty, a pr\u00e1v\u011b te\u010f spot\u0159ebitel\u00e9 pracuj\u00ed pomalu \n<\/li>\n<li>Jedn\u00e1 se o vysokorychlostn\u00ed fronty, do\u0161lo k selh\u00e1n\u00ed a spot\u0159ebitel\u00e9 doh\u00e1n\u011bj\u00ed<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/dd4b0fd70cbbc0b7defc06536157770d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 14. Dv\u011b velk\u00e9 fronty s r\u016fzn\u00fdmi re\u017eimy synchronizace<\/i><\/p>\n<p>Nyn\u00ed selh\u00e1v\u00e1 Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/8c31cfdf485ab4c9dfe13e86a151df4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 15. Broker 3 selh\u00e1v\u00e1, zanech\u00e1vaj\u00edc\u00ed po jednom masteru a zrcadle v ka\u017ed\u00e9 front\u011b<\/i><\/p>\n<p>Broker 3 se vrac\u00ed do provozu a vytv\u00e1\u0159ej\u00ed se nov\u00e1 zrcadla. Hlavn\u00ed Fronta A za\u010d\u00edn\u00e1 replikovat existuj\u00edc\u00ed zpr\u00e1vy na nov\u00e9 zrcadlo, a b\u011bhem t\u00e9to doby je Fronta nedostupn\u00e1. K replikaci dat jsou pot\u0159ebn\u00e9 dv\u011b hodiny, co\u017e znamen\u00e1 dv\u011b hodiny prostoj\u016f pro tuto Frontu!<\/p>\n<p>Nicm\u00e9n\u011b Fronta B z\u016fst\u00e1v\u00e1 dostupn\u00e1 po cel\u00e9 obdob\u00ed. Ob\u011btovala \u010d\u00e1st nadbyte\u010dnosti pro zaji\u0161t\u011bn\u00ed dostupnosti.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/28e641300a1c3f4d70e29a16db51521e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 16. Fronta z\u016fst\u00e1v\u00e1 nedostupn\u00e1 b\u011bhem synchronizace<\/i><\/p>\n<p>Po dvou hodin\u00e1ch se Fronta A tak\u00e9 st\u00e1v\u00e1 dostupnou a m\u016f\u017ee znovu za\u010d\u00edt p\u0159ij\u00edmat operace \u010dten\u00ed a z\u00e1pisu.<\/p>\n<h3>Aktualizace<\/h3>\n<p>\nTakov\u00e9 blokuj\u00edc\u00ed chov\u00e1n\u00ed b\u011bhem synchronizace zt\u011b\u017euje aktualizaci cluster\u016f s velmi velk\u00fdmi frontami. V ur\u010dit\u00e9m okam\u017eiku je t\u0159eba restartovat uzel s masterem, co\u017e znamen\u00e1 bu\u010f p\u0159epnut\u00ed na zrcadlo, nebo odpojen\u00ed fronty b\u011bhem aktualizace serveru. Pokud zvol\u00edme p\u0159epnut\u00ed, ztrat\u00edme zpr\u00e1vy, pokud zrcadla nejsou synchronizov\u00e1na. Ve v\u00fdchoz\u00edm nastaven\u00ed p\u0159i odpojen\u00ed brokera nedoch\u00e1z\u00ed k p\u0159epnut\u00ed na nesynchronizovan\u00e9 zrcadlo. To znamen\u00e1, \u017ee jakmile se broker vr\u00e1t\u00ed, \u017e\u00e1dn\u00e9 zpr\u00e1vy neztrat\u00edme, jedinou ztr\u00e1tou byl pouze prostoj fronty. Pravidla chov\u00e1n\u00ed p\u0159i odpojen\u00ed brokera jsou ur\u010dena politikou <code>ha-promote-on-shutdown<\/code>. Lze nastavit jednu z dvou hodnot:<\/p>\n<ul>\n<li><code>always<\/code>= je povoleno p\u0159epnut\u00ed na nesynchronizovan\u00e1 zrcadla\n<\/li>\n<li><code>when-synced<\/code>= p\u0159epnut\u00ed pouze na synchronizovan\u00e9 zrcadlo, jinak se fronta st\u00e1v\u00e1 nedostupnou pro \u010dten\u00ed a z\u00e1pis. Fronta se vrac\u00ed do provozu, jakmile se broker vr\u00e1t\u00ed<\/li>\n<\/ul>\n<p>\nA\u0165 tak \u010di onak, s velk\u00fdmi frontami se mus\u00edme rozhodnout mezi ztr\u00e1tou dat a nedostupnost\u00ed.<\/p>\n<h3>Kdy\u017e dostupnost zvy\u0161uje bezpe\u010dnost dat<\/h3>\n<p>\nP\u0159ed p\u0159ijet\u00edm rozhodnut\u00ed je t\u0159eba zohlednit je\u0161t\u011b jedno komplikov\u00e1n\u00ed. I kdy\u017e je automatick\u00e1 synchronizace lep\u0161\u00ed pro nadbyte\u010dnost, jak ovliv\u0148uje bezpe\u010dnost dat? Samoz\u0159ejm\u011b, d\u00edky lep\u0161\u00ed nadbyte\u010dnosti m\u00e1 RabbitMQ men\u0161\u00ed pravd\u011bpodobnost ztr\u00e1ty existuj\u00edc\u00edch zpr\u00e1v, ale co nov\u011b p\u0159ich\u00e1zej\u00edc\u00ed zpr\u00e1vy od publik\u00e1tor\u016f?<\/p>\n<p>Zde je t\u0159eba zv\u00e1\u017eit n\u00e1sleduj\u00edc\u00ed:<\/p>\n<ul>\n<li>M\u016f\u017ee publisher jednodu\u0161e vr\u00e1tit chybu a n\u00e1sledn\u011b se to pokus\u00ed znovu vy\u0161\u0161\u00ed slu\u017eba nebo u\u017eivatel?\n<\/li>\n<li>M\u016f\u017ee publisher ulo\u017eit zpr\u00e1vu lok\u00e1ln\u011b nebo do datab\u00e1ze, aby to zkusil znovu pozd\u011bji?<\/li>\n<\/ul>\n<p>\nPokud publisher m\u016f\u017ee pouze zahodit zpr\u00e1vu, pak vlastn\u011b zlep\u0161en\u00ed dostupnosti tak\u00e9 zvy\u0161uje bezpe\u010dnost dat.<\/p>\n<p>Je tedy nutn\u00e9 hledat rovnov\u00e1hu a rozhodnut\u00ed z\u00e1vis\u00ed na konkr\u00e9tn\u00ed situaci.<\/p>\n<h1>Probl\u00e9my s ha-promote-on-failure=when-synced<\/h1>\n<p>\nN\u00e1pad <i><b>ha-promote-on-failure<\/b><\/i>= <i><b>when-synced<\/b><\/i> spo\u010d\u00edv\u00e1 v tom, \u017ee br\u00e1n\u00edme p\u0159epnut\u00ed na nesynchronizovan\u00e9 zrcadlo a t\u00edm se vyh\u00fdb\u00e1me ztr\u00e1t\u011b dat. Fronta z\u016fst\u00e1v\u00e1 nedostupn\u00e1 pro \u010dten\u00ed nebo z\u00e1pis. M\u00edsto toho se sna\u017e\u00edme obnovit selh\u00e1vaj\u00edc\u00ed broker s neporu\u0161en\u00fdmi daty, aby mohl znovu fungovat jako master bez ztr\u00e1ty dat. <\/p>\n<p>Ale (a to je velk\u00e9 ale) pokud broker ztratil sv\u00e1 data, m\u00e1me velk\u00fd probl\u00e9m: fronta je ztracena! V\u0161echna data zmizela! I kdy\u017e m\u00e1te zrcadla, kter\u00e1 v\u011bt\u0161inou dohon\u00ed hlavn\u00ed frontu, tato zrcadla jsou tak\u00e9 odhozena.<\/p>\n<p>Chcete-li znovu p\u0159idat uzel se stejn\u00fdm n\u00e1zvem, \u0159\u00edk\u00e1me clusteru, aby zapomn\u011bl ztracen\u00fd uzel (p\u0159\u00edkazem <i>rabbitmqctl forget_cluster_node<\/i>) a spustit nov\u00fd broker se stejn\u00fdm n\u00e1zvem hostitele. Dokud cluster pamatuje ztracen\u00fd uzel, pamatuje si tak\u00e9 starou frontu a nesynchronizovan\u00e1 zrcadla. Kdy\u017e je clusteru \u0159e\u010deno, aby zapomn\u011bl ztracen\u00fd uzel, tato fronta je tak\u00e9 zapomenuta. Nyn\u00ed je t\u0159eba ji znovu vyhl\u00e1sit. Ztratili jsme v\u0161echna data, i kdy\u017e jsme m\u011bli zrcadla s \u010d\u00e1ste\u010dnou sadou dat. Bylo by lep\u0161\u00ed p\u0159epnout na nesynchronizovan\u00e9 zrcadlo!<\/p>\n<p>Proto je ru\u010dn\u00ed synchronizace (a neprov\u00e1d\u011bn\u00ed synchronizace) v kombinaci s <code>ha-promote-on-failure=when-synced<\/code>, podle m\u00e9ho n\u00e1zoru, pom\u011brn\u011b riskantn\u00ed. Dokumenty tvrd\u00ed, \u017ee takov\u00e1 varianta existuje pro bezpe\u010dnost dat, ale je to oboustrann\u00fd n\u016f\u017e.<\/p>\n<h1>P\u0159ebalancov\u00e1n\u00ed master\u016f<\/h1>\n<p>\nJak bylo sl\u00edbeno, vrac\u00edme se k probl\u00e9mu shroma\u017e\u010fov\u00e1n\u00ed v\u0161ech master\u016f na jednom nebo v\u00edce uzlech. To m\u016f\u017ee nastat i v d\u016fsledku \"klouzav\u00e9\" (rolling) aktualizace clustru. V clustru se t\u0159emi uzly se v\u0161echny hlavn\u00ed fronty shrom\u00e1\u017ed\u00ed na jednom nebo dvou uzlech.<\/p>\n<p>P\u0159ebalancov\u00e1n\u00ed master\u016f m\u016f\u017ee b\u00fdt problematick\u00e9 ze dvou d\u016fvod\u016f:<\/p>\n<ul>\n<li>Neexistuj\u00ed dobr\u00e9 n\u00e1stroje na prov\u00e1d\u011bn\u00ed p\u0159ebalancov\u00e1n\u00ed<\/li>\n<li>Synchronizace front<\/li>\n<\/ul>\n<p>\nPro p\u0159ebalancov\u00e1n\u00ed existuje t\u0159et\u00ed strana <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Ayanda-D\/rabbitmq-queue-master-balancer\">plugin<\/a><\/noindex>, kter\u00e1 nen\u00ed ofici\u00e1ln\u011b podporov\u00e1na. Co se t\u00fd\u010de plugin\u016f t\u0159et\u00edch stran, v p\u0159\u00edru\u010dce RabbitMQ <noindex><a rel=\"nofollow\" href=\"https:\/\/www.rabbitmq.com\/upgrade.html\">se uv\u00e1d\u00ed<\/a><\/noindex>: \u201ePlugin poskytuje n\u011bkter\u00e9 dal\u0161\u00ed n\u00e1stroje pro konfiguraci a reportov\u00e1n\u00ed, ale nen\u00ed podporov\u00e1n a nebyl zkontrolov\u00e1n t\u00fdmem RabbitMQ. Pou\u017e\u00edvejte na vlastn\u00ed riziko.\u201c<\/p>\n<p>Existuje je\u0161t\u011b jeden trik, jak p\u0159esunout hlavn\u00ed frontu prost\u0159ednictv\u00edm politik HA. V p\u0159\u00edru\u010dce se zmi\u0148uje <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/rabbitmq\/support-tools\/blob\/master\/scripts\/rebalance-queue-masters\">skript<\/a><\/noindex> o tom. Funguje to takto:<\/p>\n<ul>\n<li>Odstran\u00ed v\u0161echna zrcadla pomoc\u00ed do\u010dasn\u00e9 politiky s vy\u0161\u0161\u00ed prioritou ne\u017e st\u00e1vaj\u00edc\u00ed politika HA.\n<\/li>\n<li>Zm\u011bn\u00ed do\u010dasnou politiku HA na re\u017eim \u201euzly\u201c se specifikac\u00ed uzlu, na kter\u00fd je t\u0159eba p\u0159esunout hlavn\u00ed frontu.\n<\/li>\n<li>Synchronizuje frontu pro nucenou migraci.\n<\/li>\n<li>Po dokon\u010den\u00ed migrace odstran\u00ed do\u010dasnou politiku. Aktivuje se p\u016fvodn\u00ed politika HA a vytvo\u0159\u00ed se po\u017eadovan\u00fd po\u010det zrcadel.<\/li>\n<\/ul>\n<p>\nNev\u00fdhodou je, \u017ee takov\u00fd p\u0159\u00edstup nemus\u00ed fungovat, pokud m\u00e1te velk\u00e9 fronty nebo p\u0159\u00edsn\u00e9 po\u017eadavky na redundanci.<\/p>\n<p>Nyn\u00ed se pod\u00edvejme, jak clustery RabbitMQ funguj\u00ed se s\u00ed\u0165ov\u00fdmi odd\u011blen\u00edmi.<\/p>\n<h1>Naru\u0161en\u00ed soudr\u017enosti<\/h1>\n<p>\nUzly distribuovan\u00e9ho syst\u00e9mu jsou propojeny s\u00ed\u0165ov\u00fdmi vazbami, a tyto vazby se mohou a budou odpojovat. Frekvence odpojen\u00ed z\u00e1vis\u00ed na m\u00edstn\u00ed infrastruktu\u0159e nebo spolehlivosti vybran\u00e9ho cloudu. V ka\u017ed\u00e9m p\u0159\u00edpad\u011b by distribuovan\u00e9 syst\u00e9my m\u011bly b\u00fdt schopny se s nimi vyrovnat. Znovu se p\u0159ed n\u00e1mi objevuje volba mezi dostupnost\u00ed a konzistenc\u00ed, a op\u011bt je dobrou zpr\u00e1vou, \u017ee RabbitMQ poskytuje ob\u011b mo\u017enosti (pouze ne sou\u010dasn\u011b).<\/p>\n<p>S RabbitMQ m\u00e1me dv\u011b z\u00e1kladn\u00ed mo\u017enosti:<\/p>\n<ul>\n<li>Povolit logick\u00e9 rozd\u011blen\u00ed (split-brain). To poskytuje dostupnost, ale m\u016f\u017ee vyvolat ztr\u00e1tu dat.\n<\/li>\n<li>Zak\u00e1zat logick\u00e9 rozd\u011blen\u00ed. M\u016f\u017ee to v\u00e9st ke kr\u00e1tkodob\u00e9 ztr\u00e1t\u011b dostupnosti v z\u00e1vislosti na tom, jak se klienti p\u0159ipojuj\u00ed k clustru. Tak\u00e9 m\u016f\u017ee v\u00e9st k \u00fapln\u00e9 nedostupnosti v klastru ze dvou uzl\u016f.<\/li>\n<\/ul>\n<p>\nAle co je to logick\u00e9 rozd\u011blen\u00ed? To nast\u00e1v\u00e1, kdy\u017e se klastr rozd\u011bluje na dv\u011b \u010d\u00e1sti kv\u016fli ztr\u00e1t\u011b s\u00ed\u0165ov\u00fdch vazeb. Na ka\u017ed\u00e9 stran\u011b se zrcadla povy\u0161uj\u00ed na mistra, tak\u017ee v d\u016fsledku toho m\u00e1 ka\u017ed\u00e1 fronta n\u011bkolik mistr\u016f.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/d880a935df450fb994edfed0715e026e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 17. Hlavn\u00ed fronta a dv\u011b zrcadla, ka\u017ed\u00e9 na samostatn\u00e9m uzlu. Pak dojde k s\u00ed\u0165ov\u00e9mu v\u00fdpadku a jedno zrcadlo se odd\u011bl\u00ed. Odd\u011blen\u00fd uzel vid\u00ed, \u017ee dva ostatn\u00ed jsou offline, a povy\u0161uje sv\u00e1 zrcadla na master. Nyn\u00ed m\u00e1me dv\u011b hlavn\u00ed fronty, ob\u011b povoluj\u00ed z\u00e1pis a \u010dten\u00ed.<\/i> <\/p>\n<p>Pokud publik\u00e1to\u0159i pos\u00edlaj\u00ed data do obou master\u016f, vzniknou n\u00e1m dv\u011b rozch\u00e1zej\u00edc\u00ed se kopie fronty.<\/p>\n<p>R\u016fzn\u00e9 re\u017eimy RabbitMQ zaji\u0161\u0165uj\u00ed bu\u010f dostupnost, nebo konzistenci.<\/p>\n<h3>Re\u017eim Ignore (v\u00fdchoz\u00ed)<\/h3>\n<p>\nTento re\u017eim zaji\u0161\u0165uje dostupnost. Po ztr\u00e1t\u011b konektivity dojde k logick\u00e9mu rozd\u011blen\u00ed. Po obnoven\u00ed konektivity mus\u00ed administr\u00e1tor rozhodnout, kter\u00e9 rozd\u011blen\u00ed up\u0159ednostnit. Prohr\u00e1vaj\u00edc\u00ed strana bude restartov\u00e1na a v\u0161echna ulo\u017een\u00e1 data z t\u00e9to strany budou ztracena.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/4d82c13b5ef21837ba819f5c246a1e41.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 18. T\u0159i publik\u00e1to\u0159i jsou spojen\u00ed se t\u0159emi brokery. Vnit\u0159n\u011b klastr sm\u011bruje v\u0161echny po\u017eadavky do hlavn\u00ed fronty na Brokeru 2.<\/i><\/p>\n<p>Nyn\u00ed ztr\u00e1c\u00edme Broker 3. Vid\u00ed, \u017ee ostatn\u00ed broke\u0159i jsou offline, a povy\u0161uje sv\u00e9 zrcadlo na master. Tak doch\u00e1z\u00ed k logick\u00e9mu rozd\u011blen\u00ed.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/c7e01d51b24023bacdd93cfad95c9eab.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 19. Logick\u00e9 rozd\u011blen\u00ed (split-brain). Z\u00e1pisy jsou rozd\u011bleny do dvou hlavn\u00edch front, a dv\u011b kopie se rozch\u00e1zej\u00ed.<\/i><\/p>\n<p>Konektivita se obnovuje, ale logick\u00e9 rozd\u011blen\u00ed z\u016fst\u00e1v\u00e1. Administr\u00e1tor mus\u00ed ru\u010dn\u011b vybrat prohr\u00e1vaj\u00edc\u00ed stranu. V uveden\u00e9m p\u0159\u00edpadu administr\u00e1tor restartuje Broker 3. Ztr\u00e1c\u00ed se v\u0161echny zpr\u00e1vy, kter\u00e9 nestihl p\u0159edat.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/51c3ee15024d3c83ba625e3ff9cdeb90.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 20. Administr\u00e1tor vyp\u00edn\u00e1 Broker 3.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/0bac8e33de25c0c5381d336d26464858.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 21. Administr\u00e1tor spou\u0161t\u00ed Broker 3 a ten se p\u0159ipojuje k klastru, p\u0159i\u010dem\u017e ztr\u00e1c\u00ed v\u0161echny zpr\u00e1vy, kter\u00e9 tam z\u016fstaly.<\/i><\/p>\n<p>B\u011bhem ztr\u00e1ty konektivity a po jej\u00edm obnoven\u00ed byl klastr a tato fronta dostupn\u00e1 pro \u010dten\u00ed a z\u00e1pis.<\/p>\n<h3>Re\u017eim Autoheal<\/h3>\n<p>\nFunguje podobn\u011b jako re\u017eim Ignore, s v\u00fdjimkou toho, \u017ee samotn\u00fd klastr automaticky vyb\u00edr\u00e1 prohr\u00e1vaj\u00edc\u00ed stranu po rozd\u011blen\u00ed a obnoven\u00ed konektivity. Prohr\u00e1vaj\u00edc\u00ed strana se vrac\u00ed do klastru pr\u00e1zdn\u00e1 a fronta ztr\u00e1c\u00ed v\u0161echny zpr\u00e1vy, kter\u00e9 byly zasl\u00e1ny pouze na tuto stranu.<\/p>\n<h3>Re\u017eim Pause Minority<\/h3>\n<p>\nPokud nechceme povolit logick\u00e9 odd\u011blen\u00ed, je na\u0161\u00edm jedin\u00fdm \u0159e\u0161en\u00edm zcela se vzd\u00e1t \u010dten\u00ed a z\u00e1pisu na men\u0161\u00ed stran\u011b po odd\u011blen\u00ed clusteru. Kdy\u017e broker zjist\u00ed, \u017ee se nach\u00e1z\u00ed na men\u0161\u00ed stran\u011b, zastav\u00ed provoz, tedy uzav\u0159e v\u0161echna existuj\u00edc\u00ed spojen\u00ed a odm\u00edtne jak\u00e1koli nov\u00e1. Jednou za sekundu kontroluje obnoven\u00ed konektivity. Jakmile je konektivita obnovena, obnov\u00ed provoz a p\u0159ipoj\u00ed se zp\u011bt do clusteru.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/7a51cf509b2c94e2ae100c7dedd9d21a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 22. T\u0159i publishery jsou spojeny se t\u0159emi brokery. Intern\u011b cluster sm\u011bruje v\u0161echny po\u017eadavky do hlavn\u00ed fronty na Brokeru 2.<\/i><\/p>\n<p>Pot\u00e9 se Brokery 1 a 2 odd\u011bl\u00ed od Brokera 3. M\u00edsto aby zv\u00fd\u0161il sv\u00e9 zrcadlo na master, Broker 3 pozastav\u00ed provoz a stane se nedostupn\u00fdm.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/c12ec38a47e1f8ccceebfa1854f54f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 23. Broker 3 zastavuje provoz, odpojuje v\u0161echny klienty a odm\u00edt\u00e1 po\u017eadavky na p\u0159ipojen\u00ed.<\/i><\/p>\n<p>Jakmile je konektivita obnovena, vrac\u00ed se do clusteru.<\/p>\n<p>Pod\u00edvejme se na jin\u00fd p\u0159\u00edklad, kde je hlavn\u00ed fronta na Brokeru 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/4cc6a28270f00a280ecb5af5252f4e07.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 24. Hlavn\u00ed fronta na Brokeru 3.<\/i><\/p>\n<p>Pak doch\u00e1z\u00ed ke stejn\u00e9 ztr\u00e1t\u011b konektivity. Broker 3 se zastavuje, proto\u017ee je na men\u0161\u00ed stran\u011b. Na druh\u00e9 stran\u011b uzly vid\u00ed, \u017ee Broker 3 vypadl, tak\u017ee star\u0161\u00ed zrcadlo z Broker\u016f 1 a 2 se zvy\u0161uje na master.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/d0d032385533bb53c5a95927afcd3119.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 25. P\u0159echod na Brokera 2 p\u0159i nedostupnosti Brokera 3.<\/i><\/p>\n<p>Kdy\u017e je konektivita obnovena, Broker 3 se p\u0159id\u00e1 do clusteru.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost v\u016f\u010di chyb\u00e1m a vysok\u00e1 dostupnost v clusterech\" src=\"\/wp-content\/uploads\/2019\/11\/53f8186a040ae07724ef59cf79b72a0c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 26. Cluster se vr\u00e1til do norm\u00e1ln\u00edho provozu.<\/i><\/p>\n<p>Je d\u016fle\u017eit\u00e9 pochopit, \u017ee z\u00edsk\u00e1v\u00e1me konzistenci, ale tak\u00e9 m\u016f\u017eeme dos\u00e1hnout dostupnosti, <i><b>pokud<\/b><\/i> \u00fasp\u011b\u0161n\u011b p\u0159evedeme klienty na v\u011bt\u0161\u00ed \u010d\u00e1st sekce. Pro v\u011bt\u0161inu situac\u00ed bych osobn\u011b zvolil re\u017eim Pause Minority, ale to skute\u010dn\u011b z\u00e1vis\u00ed na konkr\u00e9tn\u00edm p\u0159\u00edpadu.<\/p>\n<p>Pro zaji\u0161t\u011bn\u00ed dostupnosti je d\u016fle\u017eit\u00e9 se ujistit, \u017ee se klienti \u00fasp\u011b\u0161n\u011b p\u0159ipojuj\u00ed k uzlu. Pod\u00edvejme se na na\u0161e mo\u017enosti.<\/p>\n<h1>Zaji\u0161t\u011bn\u00ed konektivity klient\u016f<\/h1>\n<p>\nM\u00e1me n\u011bkolik mo\u017enost\u00ed, jak po ztr\u00e1t\u011b konektivity nasm\u011brovat klienty na hlavn\u00ed \u010d\u00e1st clusteru nebo na funk\u010dn\u00ed uzly (po selh\u00e1n\u00ed jednoho uzlu). Nejprve si p\u0159ipome\u0148me, \u017ee konkr\u00e9tn\u00ed fronta je um\u00edst\u011bna na ur\u010dit\u00e9m uzlu, ale sm\u011brov\u00e1n\u00ed a politiky se replikuj\u00ed na v\u0161ech uzlech. Klienti se mohou p\u0159ipojit k libovoln\u00e9mu uzlu a vnit\u0159n\u00ed sm\u011brov\u00e1n\u00ed je nasm\u011bruje tam, kam pot\u0159ebuj\u00ed. Pokud je v\u0161ak uzel pozastaven, odm\u00edt\u00e1 p\u0159ipojen\u00ed, a proto se klienti mus\u00ed p\u0159ipojit k jin\u00e9mu uzlu. Pokud uzel vypadne, m\u016f\u017ee toho ud\u011blat jen m\u00e1lo.<\/p>\n<p>Na\u0161e mo\u017enosti:<\/p>\n<ul>\n<li>P\u0159\u00edstup k clusteru je zaji\u0161t\u011bn pomoc\u00ed vyva\u017eova\u010de z\u00e1t\u011b\u017ee, kter\u00fd prost\u011b cyklicky proch\u00e1z\u00ed uzly, a klienti prov\u00e1d\u011bj\u00ed opakovan\u00e9 pokusy o p\u0159ipojen\u00ed, dokud nedojde k \u00fasp\u011b\u0161n\u00e9mu spojen\u00ed. Pokud uzel nefunguje nebo je pozastaven, pokusy o p\u0159ipojen\u00ed k tomuto uzlu skon\u010d\u00ed ne\u00fasp\u011bchem, ale n\u00e1sleduj\u00edc\u00ed pokusy budou sm\u011b\u0159ovat na jin\u00e9 servery (v cyklick\u00e9m re\u017eimu). To je vhodn\u00e9 pro kr\u00e1tkodobou ztr\u00e1tu konektivity nebo selh\u00e1n\u00ed serveru, kter\u00e9 bude rychle obnoveno.\n<\/li>\n<li>P\u0159\u00edstup k clusteru p\u0159es vyva\u017eova\u010d z\u00e1t\u011b\u017ee a odstran\u011bn\u00ed pozastaven\u00fdch\/selh\u00e1vaj\u00edc\u00edch uzl\u016f ze seznamu, jakmile jsou zji\u0161t\u011bny. Pokud se to ud\u011bl\u00e1 rychle, a pokud jsou klienti schopni prov\u00e1d\u011bt opakovan\u00e9 pokusy o p\u0159ipojen\u00ed, zajist\u00edme t\u00edm trvalou dostupnost.\n<\/li>\n<li>Poskytnout ka\u017ed\u00e9mu klientovi seznam v\u0161ech uzl\u016f, p\u0159i\u010dem\u017e se klient p\u0159i p\u0159ipojen\u00ed n\u00e1hodn\u011b vyb\u00edr\u00e1 jeden z nich. Pokud p\u0159i pokusu o p\u0159ipojen\u00ed dostane chybu, p\u0159ejde na dal\u0161\u00ed uzel v seznamu, dokud se nep\u0159ipoj\u00ed.\n<\/li>\n<li>Odebr\u00e1n\u00ed provozu od selh\u00e1vaj\u00edc\u00edho\/pozastaven\u00e9ho uzlu pomoc\u00ed DNS. To se prov\u00e1d\u00ed pomoc\u00ed mal\u00e9 TTL.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Z\u00e1v\u011bry<\/h1>\n<p>\nKlastry RabbitMQ maj\u00ed sv\u00e9 v\u00fdhody a nev\u00fdhody. Nejz\u00e1va\u017en\u011bj\u0161\u00ed nev\u00fdhody spo\u010d\u00edvaj\u00ed v tom, \u017ee:<\/p>\n<ul>\n<li>p\u0159i p\u0159ipojen\u00ed k clustru uzly ztr\u00e1c\u00ed sv\u00e1 data;\n<\/li>\n<li>blokuj\u00edc\u00ed synchronizace vede k nedostupnosti fronty.<\/li>\n<\/ul>\n<p>\nV\u0161echna obt\u00ed\u017en\u00e1 rozhodnut\u00ed vych\u00e1zej\u00ed z t\u011bchto dvou charakteristik architektury. Kdyby RabbitMQ mohl uchov\u00e1vat data p\u0159i op\u011btovn\u00e9m p\u0159ipojen\u00ed k clustru, synchronizace by prob\u00edhala rychleji. Kdyby byl schopen neblo\u010dn\u00ed synchronizace, l\u00e9pe by podporoval velk\u00e9 fronty. Odstran\u011bn\u00ed t\u011bchto dvou probl\u00e9m\u016f by v\u00e1\u017en\u011b zlep\u0161ilo vlastnosti RabbitMQ jako spolehliv\u00e9 a vysoce dostupn\u00e9 technologie pro v\u00fdm\u011bnu zpr\u00e1v. Doporu\u010dovat RabbitMQ s clusteringem bych se neodv\u00e1\u017eil v n\u00e1sleduj\u00edc\u00edch situac\u00edch:<\/p>\n<ul>\n<li>Nespolehliv\u00e1 s\u00ed\u0165.\n<\/li>\n<li>Nespolehliv\u00e9 \u00falo\u017ei\u0161t\u011b.\n<\/li>\n<li>Velmi velk\u00e9 fronty.<\/li>\n<\/ul>\n<p>\nPokud jde o nastaven\u00ed pro vysokou dostupnost, zva\u017ete n\u00e1sleduj\u00edc\u00ed:<\/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> (nebo <code>autoheal<\/code>)\n<\/li>\n<li>odoln\u00e9 zpr\u00e1vy\n<\/li>\n<li>ujist\u011bte se, \u017ee klienti se p\u0159ipojuj\u00ed k aktivn\u00edmu uzlu, kdy\u017e n\u011bjak\u00fd uzel sel\u017ee<\/li>\n<\/ul>\n<p>\nPro soulad (bezpe\u010dnost dat) zva\u017ete n\u00e1sleduj\u00edc\u00ed nastaven\u00ed:<\/p>\n<ul>\n<li>Publisher Confirms a Manual Acknowledgements na stran\u011b spot\u0159ebitele\n<\/li>\n<li><code>ha-promote-on-failure=when-synced<\/code>, pokud mohou vydavatel\u00e9 retry pozd\u011bji a pokud m\u00e1te velmi spolehliv\u00e9 \u00falo\u017ei\u0161t\u011b! Jinak nastavte <code>=always<\/code>.\n<\/li>\n<li><code>ha-sync-mode=automatic<\/code> (ale pro velk\u00e9 neaktivn\u00ed fronty m\u016f\u017ee b\u00fdt pot\u0159eba ru\u010dn\u00ed re\u017eim; nav\u00edc zva\u017ete, zda nedostupnost nevede ke ztr\u00e1t\u011b zpr\u00e1v)\n<\/li>\n<li>re\u017eim Pause Minority\n<\/li>\n<li>odoln\u00e9 zpr\u00e1vy<\/li>\n<\/ul>\n<p>\nNeprobrali jsme je\u0161t\u011b v\u0161echny ot\u00e1zky spolehlivosti a vysok\u00e9 dostupnosti; nap\u0159\u00edklad jak bezpe\u010dn\u011b prov\u00e1d\u011bt administrativn\u00ed \u00fakony (jako jsou rolling updates). Je t\u0159eba probrat tak\u00e9 federaci a plugin Shovel.<\/p>\n<p>Pokud jsem je\u0161t\u011b n\u011bco opomenul, dejte mi pros\u00edm v\u011bd\u011bt.<\/p>\n<p>Viz tak\u00e9 m\u016fj <noindex><a rel=\"nofollow\" href=\"https:\/\/jack-vanlightly.com\/blog\/2018\/9\/10\/how-to-lose-messages-on-a-rabbitmq-cluster\">p\u0159\u00edsp\u011bvek<\/a><\/noindex>, kde prov\u00e1d\u00edm chaos v clustru RabbitMQ pomoc\u00ed Dockeru a Blockade k testov\u00e1n\u00ed n\u011bkter\u00fdch sc\u00e9n\u00e1\u0159\u016f ztr\u00e1ty zpr\u00e1v popsan\u00fdch v tomto \u010dl\u00e1nku.<\/p>\n<p>P\u0159edchoz\u00ed \u010dl\u00e1nky s\u00e9rie: <br \/>\n\u010d. 1 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/416629\/\">habr.com\/cs\/company\/itsumma\/blog\/416629<\/a><\/noindex> <br \/>\n\u010d. 2 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/418389\/\">habr.com\/cs\/company\/itsumma\/blog\/418389<\/a><\/noindex> <br \/>\n\u010d. 3 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/437446\/\">habr.com\/cs\/company\/itsumma\/blog\/437446<\/a><\/noindex><br \/>\n<br \/>Zdroj: <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.3 - 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\/cs\/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.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"cs_CZ\" \/>\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\/cs\/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 versus Kafka: spolehlivost a vysok\u00e1 dostupnost v clusterech | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"cs_CZ","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\/cs\/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\/cs\/wp-json\/wp\/v2\/posts\/52525","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/comments?post=52525"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/52525\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/media?parent=52525"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/categories?post=52525"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/tags?post=52525"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}