{"id":52541,"date":"2019-11-11T00:00:00","date_gmt":"2019-11-10T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost"},"modified":"2020-02-18T14:00:17","modified_gmt":"2020-02-18T11:00:17","slug":"rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","title":{"rendered":"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/6557ce69c2b3070622feca8b3c228b09.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nV <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/471858\/\">eelmisel artiklil<\/a><\/noindex> Oleme uurinud RabbitMQ klasterdamist, et tagada t\u00f5rkeotsing ja k\u00f5rge k\u00e4ttesaadavus. N\u00fc\u00fcd sukeldume s\u00fcgavamale Apache Kafka sellesse teema.<\/p>\n<p>Siin on replikatsiooniks \u00fcksus jao (partition). Igal teema puhul on \u00fcks v\u00f5i mitu jao. Igas jaos on juht ja j\u00e4rgijad v\u00f5i ilma nendeta. Teema loomisel on m\u00e4\u00e4ratud jao arv ja replikatsiooni koefitsient. Tavaline v\u00e4\u00e4rtus on 3, see t\u00e4hendab kolme koopiat: \u00fcks juht ja kaks j\u00e4rgijat.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/36deb6d506223c2ee2ec147d5c215789.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 1. Neli jaod on jaotatud kolme maaklerite vahel<\/i><\/p>\n<p>K\u00f5ik lugemis- ja kirjutamisettepanekud suunatakse juhile. J\u00e4rgijad saadavad perioodiliselt juhile p\u00e4ringuid viimaste s\u00f5numite saamiseks. Tarbijad ei p\u00f6\u00f6rdu kunagi j\u00e4rgijate poole, viimased eksisteerivad ainult \u00fcleliigsuse ja t\u00f5rkeotsingu jaoks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/715c51d75cb45863cfad4b37e81b9a9a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Jaotuse t\u00f5rge<\/h1>\n<p>\nKui broker v\u00e4lja kukub, kaovad sageli mitme jao liidrid. Igas neist saab liidriks teise s\u00f5lme j\u00e4rgija. Tegelikult ei ole see alati nii, kuna m\u00f5jutab ka s\u00fcnkroniseerimise tegur: kas on olemas s\u00fcnkroniseeritud j\u00e4rgijad ja kui ei, siis kas on lubatud \u00fcleminek s\u00fcnkroniseerimata replikale. Kuid \u00e4rme n\u00fc\u00fcd asju keeruliseks muuda.<\/p>\n<p>V\u00f5rgust kaob broker 3 \u2014 ja jaos 2 valitakse uueks liidriks broker 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/b8cfce64cf6b848b0659de023f9d9b63.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 2. Broker 3 sureb ning tema j\u00e4rgija broker 2-l valitakse uueks liidriks jaos 2.<\/i><\/p>\n<p>Seej\u00e4rel kaob broker 1 ning jao 1 kaotab samuti oma liidri, kelle roll l\u00e4heb \u00fcle broker 2-le.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/9f5409c723da7ff059b93f9b23e7d5f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 3. J\u00e4i alles \u00fcks broker. K\u00f5ik liidrid asuvad \u00fches brokeris nullr\u00e4\u00e4ndusega.<\/i><\/p>\n<p>Kui broker 1 naaseb v\u00f5rku, lisab ta neli j\u00e4rgijat, tagades igale jaole teatud \u00fcleliigsuse. Kuid k\u00f5ik liidrid on endiselt broker 2-l.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/f9c8e42f51258b7fd7f6f35dc7b8cc3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 4. Liidrid j\u00e4\u00e4vad broker 2-le.<\/i><\/p>\n<p>Kui broker 3 t\u00f5useb, naaseme kolme replikaga jaosse. Kuid k\u00f5ik liidrid j\u00e4\u00e4vad endiselt broker 2-le.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/9c8c02be4161f8468b5dbc1e3f6ecb3a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 5. Liidrite tasakaalustamata jaotumine p\u00e4rast brokerite 1 ja 3 taastamist.<\/i><\/p>\n<p>Kafkal on t\u00f6\u00f6riist, mis v\u00f5imaldab kvaliteetsemat liidrite tasakaalustamist kui RabbitMQ. Seal tuli kasutada kolmandate osapoolte pluginaid v\u00f5i skripte, mis muutsid poliitikaid peamise s\u00f5lme migratsiooni ajal, v\u00e4hendades \u00fcleliigset koormust. Suuremate j\u00e4rjekordade korral tuli leppida ka katkestustega s\u00fcnkroonimise ajal.<\/p>\n<p>Kafkal on kontseptsioon \u201eeelisarvestitest\u201c liidri rolli jaoks. Teemasid luues p\u00fc\u00fcab Kafka liidreid \u00fchtlaselt s\u00f5lmedele jaotada ning m\u00e4rgistab need esimesed liidrid eelisarvustiteks. Aja jooksul, serverite taask\u00e4ivituste, t\u00f5rgete ja \u00fchenduse katkemise t\u00f5ttu v\u00f5ivad liidrid sattuda teistele s\u00f5lmedele, nagu eespool kirjeldatud \u00e4\u00e4rmuslikul juhul.<\/p>\n<p>Selle parandamiseks pakub Kafka kahte v\u00f5imalust:<\/p>\n<ul>\n<li>Valik <i>auto.leader.rebalance.enable=true<\/i> see v\u00f5imaldab kontrolleris\u00f5lmel automaatselt liidreid tagasi eelisarvestitele \u00fcmber jaotada, taastades seel\u00e4bi \u00fchtlase jaotuse.\n<\/li>\n<li>Administraator v\u00f5ib k\u00e4sitsi \u00fcmberjaotamiseks k\u00e4ivitada skripti <i>kafka-preferred-replica-election.sh<\/i> Kujutis 6. Replikad p\u00e4rast tasakaalustamist<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/831930b06809637018fecb6d7d5a558d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 6. Replika p\u00e4rast \u00fcmbertasakaalustamist<\/i><\/p>\n<p>See oli lihtsustatud versioon t\u00f5rkest, kuid reaalsus on keerulisem, kuigi siin pole midagi liiga keerulist. K\u00f5ik taandub s\u00fcnkroniseeritud replikatele (In-Sync Replicas, ISR).<\/p>\n<h1>S\u00fcnkroniseeritud replikad (ISR)<\/h1>\n<p>\nISR on jaotuse replikate kogum, mida peetakse \u201es\u00fcnkroniseeritud\u201c (in-sync). Seal on juht ja j\u00e4rgijad v\u00f5ivad puududa. J\u00e4rgija loetakse s\u00fcnkroniseerituks, kui ta on teinud juhtide k\u00f5igi s\u00f5numite t\u00e4psed koopiad enne intervalli l\u00f5ppu. <i>replica.lag.time.max.ms<\/i>.<\/p>\n<p>J\u00e4rgija eemaldatakse ISR-ist, kui ta:<\/p>\n<ul>\n<li>ei ole intervalli jooksul p\u00e4ringut teinud <i>replica.lag.time.max.ms<\/i> (loetakse surnuks)\n<\/li>\n<li>ei ole intervalli jooksul suutnud uuendada <i>replica.lag.time.max.ms<\/i> (loetakse aeglaseks)<\/li>\n<\/ul>\n<p>\nJ\u00e4rgijad teevad p\u00e4ringuid intervalli jooksul <i>replica.fetch.wait.max.ms<\/i>, mis vaikimisi on 500 ms.<\/p>\n<p>ISR-i eesm\u00e4rgi selgeks m\u00f5istmiseks tuleb vaadata tootja (producer) kinnitusprotsesse ja m\u00f5ningaid t\u00f5rke stsenaariume. Tootjad v\u00f5ivad valida, millal maakler saadab kinnituse:<\/p>\n<ul>\n<li>acks=0, kinnitust ei saadeta\n<\/li>\n<li>acks=1, kinnitus saadetakse p\u00e4rast seda, kui juht on s\u00f5numi oma kohalikku logisse salvestanud.\n<\/li>\n<li>acks=all, kinnitatud saadetakse p\u00e4rast seda, kui k\u00f5ik repliigid ISR on salvestanud s\u00f5numi kohalikes logides.<\/li>\n<\/ul>\n<p>\nKafka terminoloogias, kui ISR on s\u00e4ilitanud s\u00f5numi, toimub selle \"komiteerimine\". Acks=all on k\u00f5ige turvalisem valik, kuid see toob kaasa ka t\u00e4iendava viivituse. Vaatame kahte n\u00e4idet, kus esinevad t\u00f5rked ja kuidas erinevad 'acks' valikud suhtlevad ISR kontseptsiooniga.<\/p>\n<h3>Acks=1 ja ISR<\/h3>\n<p>\nSelles n\u00e4ites n\u00e4eme, et kui juht ei oota, kuni iga s\u00f5num salvestatakse k\u00f5igilt j\u00e4rgijatest, v\u00f5ib juhi t\u00f5rke korral andmeid kaotada. \u00dcleminek s\u00fcnhroniseerimata j\u00e4rgijale v\u00f5ib olla lubatud v\u00f5i keelatud seade abil. <i>unclean.leader.election.enable<\/i>.<\/p>\n<p>Selles n\u00e4ites on tootjal m\u00e4\u00e4ratud v\u00e4\u00e4rtus acks=1. Jaotuse korraldavad k\u00f5ik kolm maaklerit. Maakler 3 on ajas maha j\u00e4\u00e4nud, ta on juhtiga s\u00fcnkroonitud kaheksa sekundi eest ja praegu j\u00e4\u00e4b 7456 s\u00f5numi v\u00f5rra maha. Maakler 1 on maha j\u00e4\u00e4nud ainult \u00fche sekundi. Meie tootja saadab s\u00f5numi ja saab kiiresti tagasi ack, ilma viivituseta aeglaste v\u00f5i surnud j\u00e4rgijate t\u00f5ttu, keda juht ei oota.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/f194e6309b732b772574392eff482a8b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 7. ISR kolme repliigiga<\/i><\/p>\n<p>Broker 2 ei t\u00f6\u00f6ta ja tootja saab \u00fchendusviga. P\u00e4rast juhi vahetumist Broker 1-ks kaotame 123 s\u00f5numit. J\u00e4rgneja Broker 1-s kuulus ISR-i, kuid ei s\u00fcnkroonitud t\u00e4ielikult juhiga, kui see eba\u00f5nnestus.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/367f219daebafefe585059f67fdedf6f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 8. S\u00f5numid kaovad t\u00f5rgumise korral.<\/i><\/p>\n<p>Konfiguratsioonis <i>bootstrap.servers<\/i> on tootjal loetletud mitu brookera, ja ta v\u00f5ib teiselt brookerilt k\u00fcsida, kes on saanud uue jaotuse juhi. Seej\u00e4rel loob ta \u00fchenduse Broker 1-ga ja j\u00e4tkab s\u00f5numite saatmist.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/ba45c51f4ce1f63f10b2fa0e1487b223.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 9. S\u00f5numite saatmine taastatakse p\u00e4rast l\u00fchikest katkestust.<\/i><\/p>\n<p>Broker 3 j\u00e4\u00e4b veelgi maha. Ta teeb p\u00e4ringuid, kuid ei suuda s\u00fcnkroonida. See v\u00f5ib olla tingitud aeglasest v\u00f5rguside\u00fchendusest brokerite vahel, salvestamisprobleemidest jne. Ta eemaldatakse ISR-ist. N\u00fc\u00fcd koosneb ISR \u00fchest replikast \u2014 juhist! Toetaja j\u00e4tkab s\u00f5numite saatmist ja kinnituste saamist.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/592c74632e3a8d80c2b4fc15bde5d401.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 10. J\u00e4rgneja Broker 3 eemaldatakse ISR-ist.<\/i><\/p>\n<p>Brokker 1 kukub ja liidri roll l\u00e4heb brokkerile 3, kaotades 15286 s\u00f5numit! Tootja saab \u00fchenduse loomise t\u00f5rketeate. Liidri vahetus ISR-ist v\u00e4lja oli v\u00f5imalik ainult seadistuse t\u00f5ttu. <i>unclean.leader.election.enable=true<\/i>. Kui see on seadistatud <i>false<\/i>, siis vahetust ei toimuks ja k\u00f5ik lugemis- ja kirjutamisettepanekud l\u00fckataks tagasi. Sel juhul ootame brokkert 1 naasmist koos tema puutumatute andmetega replikas, mis taasliidaks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/30f01ca715ccc194890ae061a3ef7396.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 11. Brokker 1 kukub. Rikke korral kaob suur hulk s\u00f5numeid.<\/i><\/p>\n<p>Tootja loob \u00fchenduse viimase brokkeriga ja n\u00e4eb, et see on n\u00fc\u00fcd jao liider. Ta hakkab saatma s\u00f5numeid brokkerile 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/986532d9b22b6514b6039c8460b1beb4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 12. P\u00e4rast l\u00fchikest pausi saadetakse s\u00f5numid taas jao 0.<\/i><\/p>\n<p>Oleme n\u00e4inud, et peale l\u00fchikestest katkestustest uute \u00fchenduste loomisel ja uue juhi otsimisel, saatis tootja pidevalt s\u00f5numeid. Selline konfiguratsioon tagab k\u00e4ttesaadavuse andmete j\u00e4rjepidevuse arvelt. Kafka kaotas tuhandeid s\u00f5numeid, kuid j\u00e4tkas uute kirgede vastuv\u00f5tmist.<\/p>\n<h3>Acks=all ja ISR<\/h3>\n<p>\nKorratakse seda stsenaariumi veelkord, kuid <i>acks=all<\/i>. Brokeri 3 viivitus on keskmiselt neli sekundit. Tootja saadab s\u00f5numi <i>acks=all<\/i>, ja n\u00fc\u00fcd ei saa ta kiiret vastust. Juht ootab, kuni s\u00f5num on k\u00f5ikide replikate poolt ISR-is salvestatud.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/95b1abdc92e699f7bc41ebab249a2e08.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 13. ISR kolme replikaga. \u00dcks t\u00f6\u00f6tab aeglaselt, mis toob kaasa salvestamise viivituse.<\/i><\/p>\n<p>P\u00e4rast nelja sekundi pikka t\u00e4iendavat viivitust saadab broker 2 ack. K\u00f5ik replikad on n\u00fc\u00fcd t\u00e4ielikult ajakohased.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/64356dc8d2641a3e22947126dd047f39.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 14. K\u00f5ik replikad salvestavad s\u00f5numid ja saadetakse ack.<\/i><\/p>\n<p>Broker 3 j\u00e4\u00e4b n\u00fc\u00fcd veelgi maha ja eemaldatakse ISR-ist. Viivitus v\u00e4heneb m\u00e4rgatavalt, kuna ISR-is ei ole enam aeglaseid replikasid. Broker 2 ootab n\u00fc\u00fcd ainult broker 1, kellel on keskmine viivitus 500 ms.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/5d3bd67dc53cb868fa40b358ed483a1d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 15. Replika brokeris 3 eemaldatakse ISR-ist.<\/i><\/p>\n<p>Siis kukub broker 2 ja juhtimine l\u00e4heb brokerile 1 ilma s\u00f5numite kaota.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/e3f0417aa7714ea5eae8a8e8d61662bd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 16. Broker 2 kukub.<\/i><\/p>\n<p>Tootja leiab uue juhi ja hakkab talle s\u00f5numeid saatma. Viivitus v\u00e4heneb veelgi, kuna n\u00fc\u00fcd koosneb ISR \u00fchest replikast! Seet\u00f5ttu valik <i>acks=all<\/i> ei lisa \u00fcleliigsust.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/fec9aae9977757d5f61c2909ceae0536.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 17. Replika brokeris 1 v\u00f5tab juhtimise ilma s\u00f5numite kaota.<\/i><\/p>\n<p>Siis kukub broker 1 ja juhtimine l\u00e4heb brokerile 3 koos 14238 s\u00f5numi kaotusega!<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/730b3951fb75ab3a782fc6d064615212.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 18. Broker 1 sureb, samas kui juhtimise \u00fcleminek unclean seadistusega viib ulatuslikku andmekadudeni<\/i><\/p>\n<p>Me ei peaks v\u00f5ib-olla valikut seadma <i>unclean.leader.election.enable<\/i> v\u00e4\u00e4rtuse <i>true<\/i>. Vaikimisi on see <i>false<\/i>. Seadistus <i>acks=all<\/i> koos <i>unclean.leader.election.enable=true<\/i> tagab kergelt suurendatud andmete turvalisuse. Kuid nagu n\u00e4ete, v\u00f5ime ikkagi s\u00f5numeid kaotada.<\/p>\n<p>Aga mis siis, kui soovime andmete turvalisust suurendada? Saame seada <i>unclean.leader.election.enable = false<\/i>, kuid see ei kaitse meid tingimata andmekadude eest. Kui juht on k\u00f5vasti langend ja viis andmed endaga, siis s\u00f5numid on endiselt kadunud, lisaks kaob kergelt k\u00e4ttesaadavus, kuni administraator olukorra taastab.<\/p>\n<p>Parim on tagada, et k\u00f5ik s\u00f5numid oleksid \u00fcleliigsed, vastasel juhul tuleks loobuda salvestamisest. Nii on v\u00e4hemalt brokeri seisukohast andmekadu v\u00f5imalik ainult kahe v\u00f5i enama samaaegse t\u00f5rke korral.<\/p>\n<h3>Acks=all, min.insync.replicas ja ISR<\/h3>\n<p>\nTeema konfiguratsiooniga <i>min.insync.replicas<\/i> suurendame andmete turvalisuse taset. Vaadakem veel kord \u00fcle eelmise stsenaariumi viimane osa, kuid seekord koos <i>min.insync.replicas=2<\/i>.<\/p>\n<p>Nii et brokeril 2 on repliikide juht ja j\u00e4rgija brokeril 3 on ISR-ist eemaldatud.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/5831463293f1837d3232756894e97162.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 19. ISR, kus on kaks repliiki<\/i><\/p>\n<p>Broker 2 kukub ja juhtpositsioon l\u00e4heb Broker 1-ile ilma s\u00f5numite kaotuseta. Kuid n\u00fc\u00fcd koosneb ISR vaid \u00fchest replikast. See ei vasta minimaalsetele n\u00f5uetele kirje saamiseks ja seet\u00f5ttu vastab broker kirjutamiskatses veaga. <i>NotEnoughReplicas<\/i>.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/6b2ee477f4c33ec84f3068b792814e5d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 20. ISR number on \u00fcks v\u00e4hem kui min.insync.replicas-s.<\/i><\/p>\n<p>See konfiguratsioon ohverdab k\u00e4ttesaadavuse j\u00e4rjepidevuse nimel. Enne s\u00f5numi kinnitamise v\u00f5imaldamist tagame, et see salvestatakse v\u00e4hemalt kahele replikale. See annab tootjale palju suurema kindluse. Siin on s\u00f5numite kaotamine v\u00f5imalik ainult juhul, kui kaks replikat eba\u00f5nnestuvad samal ajal l\u00fchikese aja jooksul, kuni s\u00f5num ei ole lisaj\u00e4lgijale replitseeritud, mis on ebat\u00f5en\u00e4oline. Kuid kui olete superparanoiline, v\u00f5ite seada replikatsioonikordaja 5, ja <i>min.insync.replicas<\/i> 3. Siin peab korraga kolm brookerit kokku kukkuma, et kirje kaotada! Muidugi maksate sellise usaldusv\u00e4\u00e4rsuse eest t\u00e4iendava viivituse.<\/p>\n<h1>Kui k\u00e4ttesaadavus on vajalik andmete turvalisuse tagamiseks<\/h1>\n<p>\nNii nagu <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/471858\/\">RabbitMQ puhul<\/a><\/noindex>, m\u00f5nikord on k\u00e4ttesaadavus vajalik andmete turvalisuse tagamiseks. Tuleb m\u00f5elda j\u00e4rgnevatele asjadele:<\/p>\n<ul>\n<li>Kas saab v\u00e4ljaandja lihtsalt vea tagastada, nii et k\u00f5rgem teenus v\u00f5i kasutaja proovib hiljem uuesti?\n<\/li>\n<li>Kas avaldaja saab s\u00f5numi kohapeal v\u00f5i andmebaasis salvestada, et hiljem uuesti proovida?<\/li>\n<\/ul>\n<p>\nKui vastus on eitav, siis kergendab k\u00e4ttesaadavuse optimeerimine andmete turvalisust. Te kaotate v\u00e4hem andmeid, kui valite k\u00e4ttesaadavuse, mitte kirjutise keelamise. K\u00f5ik s\u00f5ltub tasakaalu leidmisest ja otsus s\u00f5ltub konkreetsest olukorrast.<\/p>\n<h1>ISR m\u00f5te<\/h1>\n<p>\nISR komplekt v\u00f5imaldab leida parima tasakaalu andmete turvalisuse ja latentsuse vahel. N\u00e4iteks tagab see k\u00e4ttesaadavuse enamikus koopia rikeolukordades, minimeerides samal ajal surnud v\u00f5i aeglaste koopia m\u00f5ju latentsuse osas.<\/p>\n<p>Me ise valime v\u00e4\u00e4rtuse <i>replica.lag.time.max.ms<\/i> vastavalt oma vajadustele. Sisuliselt t\u00e4hendab see parameeter, kui suure latentsuse oleme valmis aktsepteerima <i>acks=all<\/i>. Vaikimisi on see k\u00fcmme sekundit. Kui see on teie jaoks liiga kaua, saate seda v\u00e4hendada. Sel juhul suureneb ISR-i muutuste sagedus, kuna j\u00e4rgijad eemaldatakse ja lisatakse sagedamini.<\/p>\n<p>RabbitMQ on lihtsalt peeglite komplekt, mida tuleb replikeerida. Aeglasemad peeglid toovad kaasa lisal\u00e4bivuse, ja surnud peeglite vastust v\u00f5ib oodata kuni pakettide eluea m\u00f6\u00f6dumiseni, mis kontrollib iga s\u00f5lme saadavust (net tick). ISR on huvitav viis nende edasil\u00fckkamiste probleemide v\u00e4ltimiseks. Kuid me riskime, et kaotame \u00fcleliigsuse, kuna ISR v\u00f5ib langeda ainult liidri tasemele. Selle riski v\u00e4ltimiseks kasutage konfiguratsiooni. <i>min.insync.replicas<\/i>.<\/p>\n<h1>Kliendi\u00fchenduse garantii<\/h1>\n<p>\nSeadetes <i>bootstrap.servers<\/i> tootjana ja tarbijana saab m\u00e4\u00e4rata mitu brokerm\u00fc\u00fcjat kliendi \u00fchendamiseks. Idee on selles, et \u00fche s\u00f5lme v\u00e4ljal\u00fclitamisel on paar varus\u00f5lme, millega klient saab \u00fchenduse luua. Need ei pea olema osa liidrist, vaid lihtsalt platvorm alglaadimiseks. Klient v\u00f5ib k\u00fcsida nende k\u00e4est, millisel s\u00f5lmel asub jaotuse liider lugemiseks\/kirjutamiseks.<\/p>\n<p>RabbitMQ-s saavad kliendid \u00fchenduda iga s\u00f5lmega, samas kui sisemine marsruutimine saadab p\u00e4ringud \u00f5igesse kohta. See t\u00e4hendab, et saate seadistada RabbitMQ ette koormuse tasakaalustaja. Kafka n\u00f5uab, et kliendid \u00fchenduksid s\u00f5lmega, kus asub vastava jao juht. Sellises olukorras ei saa koormuse tasakaalustajat paigaldada. Loend <i>bootstrap.servers<\/i> on kriitilise t\u00e4htsusega, et kliendid saaksid p\u00f6\u00f6rduda sobivate s\u00f5lmede poole ja leida need p\u00e4rast rikkeid.<\/p>\n<h1>Kafka konsensuse arhitektuur<\/h1>\n<p>\nKuni praeguseni ei ole me arutanud, kuidas klaster saab teada brokermi kukkumisest ja kuidas valitakse uus juht. Et m\u00f5ista, kuidas Kafka t\u00f6\u00f6tab v\u00f5rgu jagunemistega, tuleb esmalt m\u00f5ista konsensuse arhitektuuri.<\/p>\n<p>Iga Kafka klaster paigaldatakse koos Zookeeperi klastriga \u2014 see on jaotatud konsensuse teenus, mis v\u00f5imaldab s\u00fcsteemil saavutada konsensust mingis eelnevalt m\u00e4\u00e4ratletud seisundis, andes prioriteedi j\u00e4rjepidevusele \u00fcle k\u00e4ttesaadavuse. Lugemist ja kirjutamist k\u00e4sitlevate toimingute heakskiitmiseks n\u00f5utakse enamiku Zookeeperi s\u00f5lmede n\u00f5usolekut.<\/p>\n<p>Zookeeper salvestab klandi seisundi:<\/p>\n<ul>\n<li>Teemade, jaotuste, konfiguratsiooni, praeguste juhtide ja eelistatud koopiate nimekiri.\n<\/li>\n<li>Klastri liikmed. Iga maakler pings Zookeperisse. Kui see ei saa teatud aja jooksul pinget, registreerib Zookeeper maakleri mitte\u00fchtlasena.\n<\/li>\n<li>Peamise ja varu s\u00f5lme valimine kontrollerile.<\/li>\n<\/ul>\n<p>\nKontroller s\u00f5lm on \u00fcks Kafka maakleritest, mis vastutab replikate juhtide valimise eest. Zookeeper saadab kontrollerile teateid klastri liikmetest ja teema muudatustest, ning kontroller peab tegutsema vastavalt nendele muudatustele.<\/p>\n<p>N\u00e4iteks v\u00f5tame uue teema, millel on k\u00fcmme jaotust ja replikatsiooni koefitsient 3. Kontroller peab valima iga jaotuse juhi, p\u00fc\u00fcdes optimaalselt jaotada juhte maaklerite vahel. <\/p>\n<p>Iga jaotuse puhul kontroller:<\/p>\n<ul>\n<li>uuendab Zookeeperis teavet ISR ja juhi kohta;\n<\/li>\n<li>saadetakse k\u00e4tte LeaderAndISRCommand igale maaklerile, mis majutab selle jaotuse koopiat, teavitades maaklereid ISR ja juhist.<\/li>\n<\/ul>\n<p>\nKui maakler, kellele juht kuulub, kukub, saadab Zookeeper teate kontrollerile, kes valib uue juhi. Kontroller v\u00e4rskendab esmalt Zookeeperit ja seej\u00e4rel saadab igale maaklerile k\u00e4sku, teavitades neid juhtimismuutusest.<\/p>\n<p>Iga juht vastutab ISR-i m\u00e4\u00e4ramise eest. Konfiguratsioon <i>replica.lag.time.max.ms<\/i> m\u00e4\u00e4reb, kes sinna kuulub. ISR-i muutumisel edastab juht Zookeeperile uue teabe.<\/p>\n<p>Zookeeper on alati teadlik k\u00f5igist muutustest, et juhtimine saaks sujuvalt uuele juhile \u00fcle minna juhuks, kui esinevad probleemid.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/3adb1d204b28e3ed85bef3530fa2b738.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 21. Kafka konsensus<\/i><\/p>\n<h1>Replikatsiooniprotokoll<\/h1>\n<p>\nReplikatsiooni \u00fcksikasjade m\u00f5istmine aitab paremini m\u00f5ista v\u00f5imalikke andmete kadu stsenaariume.<\/p>\n<h3>T\u00f5mbep\u00e4ringud, Log End Offset (LEO) ja Highwater Mark (HW)<\/h3>\n<p>\nOleme arutanud, et j\u00e4rgijad saadavad perioodiliselt juhile t\u00f5mbep\u00e4ringuid (fetch). Vaikeintervall on 500 ms. See erineb RabbitMQ-st, kus replikatsioon algatatakse mitte j\u00e4rjekorra peeglist, vaid peameistrist. Peameister edastab muudatused peeglitele.<\/p>\n<p>Juht ja k\u00f5ik j\u00e4lgijad s\u00e4ilitavad logi l\u00f5pu nihke (Log End Offset, LEO) ja Highwater (HW) m\u00e4rgi. LEO m\u00e4rk hoiab kohaliku koopia viimase s\u00f5numi nihet, samas kui HW t\u00e4histab viimase commit'i nihet. Pidage meeles, et 'commit' oleku puhul peab s\u00f5num olema salvestatud k\u00f5igis replikates ISR. See t\u00e4hendab, et LEO on tavaliselt HW-st veidi ettepoole.<\/p>\n<p>Kui juht saab s\u00f5numi, salvestab ta selle kohapeal. J\u00e4lgija esitab p\u00e4ringu, edastades oma LEO. Siis saadab juht s\u00f5numite paketi alates sellest LEO-st ning edastab ka hetkelise HW. Kui juht saab kinnituse, et k\u00f5ik replikad on salvestanud s\u00f5numi antud nihkega, liigutab ta HW m\u00e4rk. Ainult juht saab HW-d liigutada, ja seega saavad k\u00f5ik j\u00e4lgijad oma p\u00e4ringute vastustes praeguse v\u00e4\u00e4rtuse teada. See t\u00e4hendab, et j\u00e4lgijad v\u00f5ivad j\u00e4\u00e4da juhist maha nii s\u00f5numite kui ka HW teadlikkuse osas. Tarbijad saavad s\u00f5numeid ainult kuni praeguse HW-ni.<\/p>\n<p>Pange t\u00e4hele, et \u201esalvestatud\u201c (persisted) t\u00e4hendab m\u00e4lu, mitte ketast. Toimivuse nimel synchroniseerib Kafka andmed kettale teatud intervalli j\u00e4rel. RabbitMQ-l on samuti selline intervall, kuid see saadab kinnituse veebilehe omanikule alles p\u00e4rast seda, kui peamine ja k\u00f5ik peeglid on s\u00f5numi kettale salvestanud. Kafka arendajad otsustasid toimivuse kaalutlustel saata ack kohe, kui s\u00f5num on m\u00e4llu salvestatud. Kafka loodab, et \u00fcleliigsus kompenseerib l\u00fchiajalise riski, et kinnitatud s\u00f5numid on ainult m\u00e4lus.<\/p>\n<h1>Juhi n\u00f5rgenemine<\/h1>\n<p>\nKui juht kukub v\u00e4lja, teavitab Zookeeper kontrollerit, kes valib uue juhi repliigi. Uus juht m\u00e4\u00e4rab uue HW m\u00e4rgi vastavalt oma LEO-le. Seej\u00e4rel saavad j\u00e4rgijad teavet uue juhi kohta. S\u00f5ltuvalt Kafka versioonist valib j\u00e4rgija \u00fche kahest stsenaariumist:<\/p>\n<ol>\n<li>L\u00f5ikab kohaliku logi teadaoleva HW-ni ja saadab uuele juhile p\u00e4ringu sellest m\u00e4rgist p\u00e4rast s\u00f5numeid.\n<\/li>\n<li>Saadetakse liidrile p\u00e4ring, et teada saada HW tema valimise hetkel liidriks, ja seej\u00e4rel k\u00e4rbitakse logi kuni selle nihkeni. Alustatakse seej\u00e4rel perioodilisi p\u00e4ringuid valimise korraldamiseks, alustades sellest nihkest.<\/li>\n<\/ol>\n<p>\nJ\u00e4rgneval v\u00f5ib olla vajalik logi k\u00e4rpida j\u00e4rgmiste p\u00f5hjuste t\u00f5ttu:<\/p>\n<ul>\n<li>Kui liider eba\u00f5nnestub, siis esimene j\u00e4rgija ISR-kogumist, kes on registreeritud Zookeeperis, v\u00f5idab valimised ja saab liidriks. K\u00f5ik j\u00e4rgijad ISR-is, kuigi neid peetakse \u201es\u00fcnkroniseerituks\u201c, ei pruugi endiselt vana liidrilt k\u00f5iki s\u00f5numeid koopiaid saada. On t\u00e4iesti v\u00f5imalik, et valitud j\u00e4rgijal ei ole k\u00f5ige ajakohasemat koopiat. Kafka garanteerib, et replika vahel ei ole erinevusi. Seet\u00f5ttu peab iga j\u00e4rgija oma logi k\u00e4rpima uue liidri HW v\u00e4\u00e4rtuseni tema valimise hetkel, et v\u00e4ltida erinevusi. See on veel \u00fcks p\u00f5hjus, miks seadistamine <i>acks=all<\/i> on \u00fchtsuse jaoks nii oluline.\n<\/li>\n<li>S\u00f5numid salvestatakse perioodiliselt kettale. Kui k\u00f5ik klastris olevad s\u00f5lmed eba\u00f5nnestuvad, j\u00e4\u00e4vad kettale salvestatud koopiad erineva nihkega. On t\u00e4iesti v\u00f5imalik, et kui maaklerid naasevad v\u00f5rku, valitakse uus juht, kes v\u00f5ib oma j\u00e4lgijatest maha j\u00e4\u00e4da, kuna ta salvestati kettale enne teisi.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Taaskoondumine klasstriga<\/h3>\n<p>\nKlastriga taaskoondumisel saavad koopiad samamoodi nagu juhi eba\u00f5nnestumise korral: nad kontrollivad juhi koopiat ja l\u00f5ikavad oma logi tema HW (valimise hetkel) j\u00e4rgi. V\u00f5rdluseks, RabbitMQ peab taaskoondunud s\u00f5lmi t\u00e4iesti uuteks. M\u00f5lemas juhul heidab maakler tagasi k\u00f5ik olemasolevad olekud. Kui kasutatakse automaatset s\u00fcnkroniseerimist, peab juht koondama absoluutselt k\u00f5ik praegused andmed uude peegeldusse viisil, et 'kogu maailmal aitab'. Selle operatsiooni ajal ei aktsepteeri juht mingeid lugemis- v\u00f5i kirjutamisoperatsioone. See l\u00e4henemine tekitab probleeme suurtes j\u00e4rjekordades.<\/p>\n<p>Kafka on jaotatud logi, mis hoiab kokku rohkem s\u00f5numeid kui RabbitMQ j\u00e4rjekord, kus andmed p\u00e4rast lugemist j\u00e4rjekorrast eemaldatakse. Aktiivsed j\u00e4rjekorrad peavad olema suhteliselt v\u00e4ikesed. Kuid Kafka on log, millel on oma salvestuspoliitika, mis v\u00f5ib m\u00e4\u00e4rata s\u00e4ilitamise kestuse p\u00e4evades v\u00f5i n\u00e4dalates. J\u00e4rjekorra blokeerimise ja t\u00e4ieliku s\u00fcnkroniseerimise l\u00e4henemine on jaotatud logi jaoks absoluuselt vastuv\u00f5etamatu. Selle asemel k\u00e4rbivad Kafka j\u00e4lgijad lihtsalt oma logi HW juhtpositsioonile (selle valimise ajal), kui nende koopia juhist ette j\u00e4\u00e4b. T\u00f5en\u00e4olisemas olukorras, kus j\u00e4lgija on taga, hakkab ta lihtsalt k\u00fcsima andmeid, alustades oma praegusest LEO-st.<\/p>\n<p>Uued v\u00f5i uuesti \u00fchendatud j\u00e4lgijad alustavad v\u00e4ljaspool ISR-i ega osale komiteerimistes. Nad t\u00f6\u00f6tavad lihtsalt grupi k\u00f5rval, saades s\u00f5numeid nii kiiresti kui v\u00f5imalik, kuni nad juhtidest j\u00e4rgi j\u00f5uavad ja ISR-i sisse astuvad. Siin ei ole blokeerimist ja ei ole vaja k\u00f5iki oma andmeid v\u00e4lja visata.<\/p>\n<h1>\u00dchenduse rikkumine<\/h1>\n<p>\nKafkal on rohkem komponente kui RabbitMQ-l, mist\u00f5ttu on siin keerukam k\u00e4itumiste kogum, kui klastris tekib \u00fchenduse katkemine. Kuid Kafka on algselt loodud klastreid silmas pidades, seet\u00f5ttu on lahendused h\u00e4sti l\u00e4bi m\u00f5eldud.<\/p>\n<p>Allpool on m\u00f5ned \u00fchenduse katkemise stsenaariumid:<\/p>\n<ul>\n<li>Stsenaarium 1. J\u00e4rgneja ei n\u00e4e liidrit, kuid n\u00e4eb Zookeeperit.\n<\/li>\n<li>Stsenaarium 2. Liider ei n\u00e4e \u00fchtegi j\u00e4rgnejat, kuid n\u00e4eb Zookeeperit.\n<\/li>\n<li>Stsenaarium 3. J\u00e4rgneja n\u00e4eb liidrit, kuid ei n\u00e4e Zookeeperit.\n<\/li>\n<li>Stsenaarium 4. Liider n\u00e4eb j\u00e4rgnejaid, kuid ei n\u00e4e Zookeeperit.\n<\/li>\n<li>Stsenaarium 5. J\u00e4rgneja on t\u00e4ielikult eraldatud nii teistest Kafka s\u00f5lmedest kui ka Zookeeperist.\n<\/li>\n<li>Stsenaarium 6. Liider on t\u00e4ielikult eraldatud nii teistest Kafka s\u00f5lmedest kui ka Zookeeperist.\n<\/li>\n<li>Stsenaarium 7. Kafka kontroller ei n\u00e4e teist Kafka s\u00f5lme.\n<\/li>\n<li>Stsenaarium 8. Kafka kontroller ei n\u00e4e Zookeeperit.<\/li>\n<\/ul>\n<p>\nIga stsenaariumi jaoks on etten\u00e4htud oma k\u00e4itumine.<\/p>\n<h3>Stsenaarium 1. J\u00e4rgneja ei n\u00e4e liidrit, kuid n\u00e4eb Zookeeperit<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/5f51ae679933b2b5a69e21831465d121.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 22. Stsenaarium 1. ISR kolme koopiaga<\/i><\/p>\n<p>\u00dchenduse katkemine eraldab maakler 3 maakleritest 1 ja 2, kuid mitte Zookeeperist. Maakler 3 ei saa enam p\u00e4ringutele vastata. Aja m\u00f6\u00f6dudes <i>replica.lag.time.max.ms<\/i> ta eemaldatakse ISR-ist ja ei osale s\u00f5numite kinnitamisel. Kui \u00fchendus taastatakse, j\u00e4tkub ta p\u00e4ringute tegemine ja liitub ISR-iga, kui on saavutanud juhi. Zookeeper j\u00e4tkab pingide saamist ja arvab, et maakler on elus ja terve.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/976b7ff080ee6a6d76a165f614f40e95.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 23. Stsenaarium 1. Maakler eemaldatakse ISR-ist, kui temalt ei saa p\u00e4ringut saada vahemikus replica.lag.time.max.ms<\/i><\/p>\n<p>Ei ole mingit loogilist jagunemist (split-brain) ega s\u00f5lme peatamist nagu RabbitMQ-s. Selle asemel v\u00e4hendatakse \u00fcleliigsust. <\/p>\n<h3>Stsenaarium 2. Juht ei n\u00e4e \u00fchtki j\u00e4lgijat, kuid n\u00e4eb j\u00e4tkuvalt Zookeeperi<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/ff6aaa053d73e8b7c97111979bcf97aa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 24. Stsenaarium 2. Juht ja kaks j\u00e4lgijat<\/i><\/p>\n<p>V\u00f5rgu\u00fchenduse katkestamine eraldab juhi j\u00e4lgijatest, kuid maakler n\u00e4eb ikka veel Zookeeperi. Nagu esimeses stsenaariumis, kokku t\u00f5mbub ISR, kuid seekord ainult juhini, kuna k\u00f5ik j\u00e4lgijad l\u00f5petavad p\u00e4ringute saatmise. Taaskord ei ole mingit loogilist jagunemist. Selle asemel tekib uute s\u00f5numite korral \u00fcleliigsuse kadu, kuni \u00fchendus taastatakse. Zookeeper j\u00e4tkab pingide saamist ja arvab, et maakler on elus ja terve.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/3c69e8327da241407f76719fc022c37a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 25. Stsenaarium 2. ISR on kokku t\u00f5mbunud ainult juhini<\/i><\/p>\n<h3>Skenaario 3. J\u00e4lgija n\u00e4eb liidrit, aga ei n\u00e4e Zookeeperi<\/h3>\n<p>\nJ\u00e4lgija eraldub Zookeeperist, kuid mitte liidri brokerist. Selle tulemusena j\u00e4tkab j\u00e4lgija p\u00e4ringute tegemist ja j\u00e4\u00e4b ISR-i liikmeks. Zookeeper ei saa enam pingeid ja registreerib brokera langemise, kuid kuna see on ainult j\u00e4lgija, pole taastumise j\u00e4rel mingeid tagaj\u00e4rgi.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/1183bcfe45a3225ae3ef1a0651f61350.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kuvat\u00f5mmis 26. Skenaario 3. J\u00e4lgija j\u00e4tkab liidrile p\u00e4ringute saatmist<\/i><\/p>\n<h3>Skenaario 4. Liider n\u00e4eb j\u00e4lgijaid, aga ei n\u00e4e Zookeeperi<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/b3bf27fcb0eb806b27ad00f098e50a26.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kuvat\u00f5mmis 27. Skenaario 4. Liider ja kaks j\u00e4lgijat<\/i><\/p>\n<p>Liider on eraldatud Zookeeperist, kuid mitte j\u00e4rgnevatest j\u00e4lgijate brokeritest. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/82d9f2e5868566678befc414d1885bfd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kuvat\u00f5mmis 28. Skenaario 4. Liider on isoleeritud Zookeeperist<\/i><\/p>\n<p>M\u00f5ne aja p\u00e4rast registreerib Zookeeper brokera langemise ja teavitab sellest kontrollerit. See valib j\u00e4lgijate seast uue liidri. Siiski j\u00e4tkab algne liider arvamist, et ta on liider ja j\u00e4tkab kirjade vastuv\u00f5tmist. <i>acks=1<\/i>. J\u00e4lgijad ei saada talle enam p\u00e4ringuid, seega peab ta neid surnud ja \u00fcritab ISR-i v\u00e4hendada vaid enda peale. Kuid kuna tal pole Zookeeperiga \u00fchendust, ei suuda ta seda teha ja loobub edaspidisest kirjade vastuv\u00f5tmisest. <\/p>\n<p>Teated <i>acks=all<\/i> ei saa kinnitust, kuna esmalt ISR sisaldab k\u00f5iki koopiaid ja enne neid teated ei j\u00f5ua. Kui algne juht proovib need ISR-ist eemaldada, ei saa ta seda teha ja l\u00f5petab \u00fcldse teadete vastuv\u00f5tmise.<\/p>\n<p>Klientidel on peagi m\u00e4rgata juhi vahetust ning nad hakkavad edastama kirjeid uuele serverile. Kui v\u00f5rk taastub, n\u00e4eb algne juht, et ta ei ole enam juht ja k\u00e4rbib oma logi HW v\u00e4\u00e4rtuseni, mis oli uuel liidril katkestuse hetkel, et v\u00e4ltida logide lahknevust. Siis hakkab ta saatma p\u00e4ringuid uuele juhile. K\u00f5ik algse juhi kirjed, mida uuele juhile ei replikeeritud, on kadunud. See t\u00e4hendab, et kaotatakse teated, mida algne juht ei kinnitanud nende paarik\u00fcmne sekundi jooksul, mil kaks juhti t\u00f6\u00f6tasid.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/d88d6f33c13dccb814c0f206ec72512b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 29. Stsenaarium 4. Juht brokeris 1 muutub j\u00e4rgijaks p\u00e4rast v\u00f5rgu taastumist<\/i><\/p>\n<h3>Stsenaarium 5. J\u00e4rgija on t\u00e4ielikult eraldatud nii teistest Kafka s\u00f5lmedest kui ka Zookeeperist<\/h3>\n<p>\nJ\u00e4rgija on t\u00e4ielikult eraldatud nii teistest Kafka s\u00f5lmedest kui ka Zookeeperist. Ta eemaldatakse lihtsalt ISR-ist, kuni v\u00f5rk taastub, ja siis p\u00fc\u00fcab ta teisi j\u00e4rele.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/b092607f777014fd945f18734dd7f4e7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 30. Stsenaarium 5. Isoleeritud j\u00e4rgija eemaldatakse ISR-ist<\/i><\/p>\n<h3>Stsenaarium 6. Juht on t\u00e4ielikult eraldatud nii teistest Kafka s\u00f5lmedest kui ka Zookeeperist<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/bb808d534dbf65748eb0b481f86b4926.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 31. Stsenaarium 6. Juht ja kaks j\u00e4rgijat<\/i><\/p>\n<p>Juht on t\u00e4ielikult isoleeritud oma j\u00e4rgijatest, kontrollerist ja Zookeeperist. L\u00fchikese ajaperioodi jooksul j\u00e4tkab ta kirjade vastuv\u00f5tmist <i>acks=1<\/i>.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/6fda78bcd26ef6b916579d447e9fb1f0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 32. Stsenaarium 6. Juhi isoleerimine teistest Kafka s\u00f5lmedest ja Zookeeperist<\/i><\/p>\n<p>P\u00e4rast p\u00e4ringute mitte saamist <i>replica.lag.time.max.ms<\/i>, p\u00fc\u00fcab ta ISR-i enda peale kokku suruda, kuid ei saa seda teha, kuna \u00fchendust Zookeeperiga pole, siis l\u00f5petab ta kirjade vastuv\u00f5tmise. <\/p>\n<p>Samal ajal m\u00e4rgib Zookeeper isoleeritud maakleri kui surnud, ja kontroller valib uue juhi.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/73d611a411fc64d835af2c714e9eba0a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 33. Stsenaarium 6. Kaks juhti<\/i><\/p>\n<p>Algne juht saab kirju vastu v\u00f5tta m\u00f5ne sekundi jooksul, kuid seej\u00e4rel l\u00f5petab ta igasuguste s\u00f5numite vastuv\u00f5tmise. Klientide uuendused toimuvad iga 60 sekundi tagant viimaste metaandmete jaoks. Neid teavitatakse juhi vahetusest ja nad hakkavad kirju saatma uuele juhile.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/ae99380c8a84fac15f440b699b9c552b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 34. Stsenaarium 6. Tootjad l\u00fclituvad uuele juhile<\/i><\/p>\n<p>Kuni kaovad k\u00f5ik kinnitatud kirjed, mis tehti algse liidri poolt alates \u00fchenduse kadumisest. Kui v\u00f5rk taastatakse, tuvastab algne juht Zookeeperi kaudu, et ta ei ole enam juht. Seej\u00e4rel k\u00e4rbib ta oma logi uue juhi HW j\u00e4rgi valimise hetkel ja hakkab saadetama p\u00e4ringuid f\u00e4nnina.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rketaluvus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/10f0983a829b03ca9bbc62e12cbf8a5d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 35. Stsenaarium 6. Algne juht muutub f\u00e4nniks p\u00e4rast v\u00f5rgu \u00fchenduse taastamist<\/i><\/p>\n<p>Selles olukorras v\u00f5ib l\u00fchikese perioodi jooksul esineda loogiline jagunemine, kuid ainult kui <i>acks=1<\/i> ja <i>min.insync.replicas<\/i> ka 1. Loogiline jagunemine l\u00f5peb automaatselt kas p\u00e4rast v\u00f5rgu taastamist, kui algne juht m\u00f5istab, et ta ei ole enam juht, v\u00f5i kui k\u00f5ik kliendid m\u00f5istavad, et juht on muutunud ja hakkavad kirjutama uuele juhile \u2014 olenevalt sellest, mis juhtub varem. Nii v\u00f5i teisiti toimub m\u00f5nede s\u00f5numite kaotus, kuid ainult <i>acks=1<\/i>.<\/p>\n<p>On olemas teine \u200b\u200bselle stsenaariumi variant, kus kohe enne v\u00f5rgu jagamist j\u00e4\u00e4vad j\u00e4lgijad maha ja juht tihendab ISR kuni enda isikuni. Siis isoleeritakse ta \u00fchenduse kadumise t\u00f5ttu. Valitakse uus juht, kuid algne juht j\u00e4tkab kirjade vastuv\u00f5tmist, isegi <i>acks=all<\/i>, kuna ISR-is pole kedagi peale tema. Need kirjad kaovad v\u00f5rgu taastumise j\u00e4rel. Ainus viis sellise stsenaariumi v\u00e4ltimiseks on <i>min.insync.replicas = 2<\/i>.<\/p>\n<h3>Stsenaarium 7. Kafka juhtr\u00f5ngas ei n\u00e4e teist Kafka s\u00f5lme<\/h3>\n<p>\n\u00dcldiselt, p\u00e4rast \u00fchenduse kaotamist Kafka s\u00f5lmega ei suuda juht edastada sellele mingeid teavet juhi muutmise kohta. Halvimal juhul toob see kaasa l\u00fchiajalise loogilise eraldumise, nagu stsenaariumis 6. T\u00f5en\u00e4olisemalt ei saa maakler lihtsalt juhtkandidaadiks, kui viimane eba\u00f5nnestub.<\/p>\n<h3>Stsenaarium 8. Kafka juht ei n\u00e4e Zookeeperit<\/h3>\n<p>\nKui Zookeeperi kontrollija on kadunud, ei saa see pinget ja valib uut Kafka s\u00f5lme kontrollijana. Algne kontrollija v\u00f5ib endiselt esindada ennast kui kontrollijat, kuid ta ei saa Zookeeperilt teateid, seega ei ole tal \u00fchtegi \u00fclesannet t\u00e4itmiseks. Kui v\u00f5rk taastub, m\u00f5istab ta, et ei ole enam kontrollija, vaid on muutunud tavaliseks Kafka s\u00f5lmeks.<\/p>\n<h3>J\u00e4reldused stsenaariumeist<\/h3>\n<p>\nN\u00e4htav on, et j\u00e4lgijate \u00fchenduse kaotus ei too kaasa s\u00f5numite kaotust, vaid lihtsalt ajutiselt v\u00e4hendab \u00fcleliigsust, kuni v\u00f5rk taastub. See v\u00f5ib loomulikult viia andmete kadumiseni, kui \u00fcks v\u00f5i mitu s\u00f5lme on kaotsis.<\/p>\n<p>Kui juht kaotab \u00fchenduse Zookeeperiga, v\u00f5ib see viia s\u00f5numite kadumiseni <i>acks=1<\/i>. \u00dchenduse puudumine Zookeeperiga p\u00f5hjustab l\u00fchiajalise loogilise jagunemise kahe juhi vahel. Selle probleemi lahendab parameeter <i>acks=all<\/i>.<\/p>\n<p>Parameeter <i>min.insync.replicas<\/i> kahes v\u00f5i enamas koopias, mis annab t\u00e4iendavaid garantiisid, et sellised l\u00fchiajalised stsenaariumid ei too kaasa s\u00f5numite kaotust, nagu stsenaariumis 6.<\/p>\n<h1>Kokkuv\u00f5te s\u00f5numite kaotusest<\/h1>\n<p>\nLoetleme k\u00f5ik viisid, kuidas andmeid Kafka's kaotada v\u00f5ib:<\/p>\n<ul>\n<li>Iga juhi t\u00f5rge, kui s\u00f5numid kinnitati kasutades <i>acks=1<\/i>\n<\/li>\n<li>Iga ebat\u00e4pne (unclean) juhtimise \u00fcleminek, st j\u00e4rgija piiridest v\u00e4ljapoole ISR, isegi <i>acks=all<\/i>\n<\/li>\n<li>Juhi isoleerimine Zookeeperist, kui s\u00f5numid kinnitati kasutades <i>acks=1<\/i>\n<\/li>\n<li>T\u00e4ielik juhi isoleerimine, kes on juba v\u00e4hendanud ISR grupi iseendaks. K\u00f5ik s\u00f5numid kaovad, isegi <i>acks=all<\/i>. See kehtib ainult juhul, kui <i>min.insync.replicas=1<\/i>.\n<\/li>\n<li>K\u00f5ikide jaotuse s\u00f5lmede samaaegne t\u00f5rge. Kuna s\u00f5numid kinnitatakse m\u00e4lust, v\u00f5ivad m\u00f5ned veel mitte kettale salvestuda. P\u00e4rast serverite taask\u00e4ivitamist v\u00f5ib puududa m\u00f5ni s\u00f5num.<\/li>\n<\/ul>\n<p>\nEbat\u00e4psete juhtimis\u00fcleminekute v\u00e4ltimiseks saab kas neid keelata v\u00f5i tagada v\u00e4hemalt kahe peale. K\u00f5ige usaldusv\u00e4\u00e4rsem konfiguratsioon on kombinatsioon <i>acks=all<\/i> ja <i>min.insync.replicas<\/i> rohkem kui 1.<\/p>\n<h1>RabbitMQ ja Kafka usaldusv\u00e4\u00e4rsuse otsene v\u00f5rdlemine<\/h1>\n<p>\nKuna usaldusv\u00e4\u00e4rsuse ja k\u00f5rge k\u00e4ttesaadavuse tagamiseks rakendavad m\u00f5lemad platvormid primaarse ja sekundaarse replikatsiooni s\u00fcsteemi. Kuid RabbitMQ-l on oma n\u00f5rk koht. \u00dchenduse taastamisel p\u00e4rast riket viskavad s\u00f5lmed oma andmed \u00e4ra ja s\u00fcnkroniseerimine peatub. See kahekordne l\u00f6\u00f6k seab kahtluse alla suurte j\u00e4rjekordade kestvuse RabbitMQ-s. Peate leppima kas v\u00e4hendatud \u00fcleliigsusega v\u00f5i pikaajaliste lukustustega. \u00dcksnes \u00fcleliigsuse v\u00e4hendamine suurendab massilise andmekao riski. Kuid kui j\u00e4rjekorrad on v\u00e4ikesed, on \u00fcleliigsuse kindlustamiseks l\u00fchikeste toodete katkemistega (m\u00f5ned sekundid) v\u00f5imalik toime tulla uuesti \u00fchenduse loomise katsete abil.<\/p>\n<p>Kafkas ei ole sellist probleemi. See loob andmeid tagasi ainult siis, kui liidri ja j\u00e4rgija vahel on erinevus. K\u00f5ik \u00fchised andmed s\u00e4ilitatakse. Lisaks ei blokeeri replikatsioon s\u00fcsteemi. Liider j\u00e4tkab kirjade vastuv\u00f5tmist, kuni uus j\u00e4rgija tema j\u00e4rele j\u00f5uab, nii et DevOps'i jaoks on klastrisse liitmine v\u00f5i uuesti liitmine triviaalne \u00fclesanne. Muidugi j\u00e4\u00e4vad endiselt probleemid, nagu v\u00f5rgu l\u00e4bilaskev\u00f5ime replikatsiooni ajal. Kui mitu j\u00e4rgijat lisatakse samal ajal, v\u00f5ib esineda l\u00e4bilaskev\u00f5ime piirangut.<\/p>\n<p>RabbitMQ \u00fcletab Kafkat usaldusv\u00e4\u00e4rsuses, kui mitu serverit klastris kokku kuivavad. Nagu me juba mainisime, saadab RabbitMQ avaldaja kinnituse alles p\u00e4rast s\u00f5numi kirjutamist meistrisse ja k\u00f5ikidesse peegeldustesse. Kuid see toob kaasa t\u00e4iendava viivituse kahes osas:<\/p>\n<ul>\n<li>fsync iga paari sadade millisekundi tagant\n<\/li>\n<li>Peegli rike v\u00f5ib olla m\u00e4rgatav alles siis, kui pakettide eluea ajal, mis kontrollib iga s\u00f5lme k\u00e4ttesaadavust (net tick), on m\u00f6\u00f6dunud. Kui peegel reageerib aeglaselt v\u00f5i on kokku kukkunud, lisab see viivituse.<\/li>\n<\/ul>\n<p>\nKafka usubub, et kui s\u00f5num on talletatud mitmel s\u00f5lmel, saab s\u00f5numeid kinnitada kohe, kui need m\u00e4llu j\u00f5uavad. Selle t\u00f5ttu tekib riski igasuguste s\u00f5numite (isegi <i>acks=all<\/i>, <i>min.insync.replikad=2<\/i>) kaotamise korral samaaegse t\u00f5rke korral.<\/p>\n<p>\u00dcldiselt n\u00e4itab Kafka k\u00f5rgemat j\u00f5udlust ja on algselt loodud klastrite jaoks. J\u00e4lgijate arvu saab suurendada kuni 11-ni, kui see on vajalik usaldusv\u00e4\u00e4rsuse tagamiseks. Replikatsioonikoefitsient 5 ja minimaalne s\u00fcnkroonsete replikate arv <i>min.insync.replicas=3<\/i> teevad s\u00f5numite kaotuse v\u00e4ga harvaks juhuseks. Kui teie infrastruktuur suudab tagada sellise replikatsioonikoefitsiendi ja \u00fcleliigsuse taseme, siis v\u00f5ite valida selle variandi.<\/p>\n<p>RabbitMQ klasterdamine sobib h\u00e4sti v\u00e4ikestele j\u00e4rjekordadele. Kuid isegi v\u00e4ikesed j\u00e4rjekorrad v\u00f5ivad suure liikluse korral kiiresti kasvama hakata. Kui j\u00e4rjekorrad muutuvad suurteks, tuleb teha karm valik saadaolevuse ja usaldusv\u00e4\u00e4rsuse vahel. RabbitMQ klasterdamine sobib k\u00f5ige paremini ebatavaliste olukordade jaoks, kus RabbitMQ paindlikkuse eelised kaaluvad \u00fcles k\u00f5ik klasterdamise puudused.<\/p>\n<p>\u00dcks ravimeetod suurte RabbitMQ j\u00e4rjekordade haavatavuse vastu on jagada need v\u00e4iksemateks. Kui ei n\u00f5uta kogu j\u00e4rjekorra t\u00e4ielikku j\u00e4rjestust, vaid ainult teatud s\u00f5numite (n\u00e4iteks konkreetse kliendi s\u00f5numite) v\u00f5i mitte midagi j\u00e4rjestada, on see variant vastuv\u00f5etav: vaadake minu projekti. <noindex><a rel=\"nofollow\" href=\"https:\/\/jack-vanlightly.com\/blog\/2018\/7\/22\/creating-consumer-groups-in-rabbitmq-with-rebalanser-part-1\">Rebalanser<\/a><\/noindex> j\u00e4rjekorra jagamiseks (projekt on hetkel varajases staadiumis). <\/p>\n<p>L\u00f5puks, \u00e4rge unustage mitmeid vigu nii RabbitMQ kui ka Kafka klasterdamise ja replikatsiooni mehhanismides. Aja jooksul on s\u00fcsteemid muutunud kypsamaks ja stabiilsemaks, kuid \u00fckski s\u00f5num ei ole kunagi 100% kaitstud kadumise eest! Lisaks v\u00f5ivad andmekeskustes juhtuda ulatuslikud \u00f5nnetused!<\/p>\n<p>Kui ma midagi j\u00e4tsin vahele, tegin vea v\u00f5i te ei n\u00f5ustu m\u00f5ne v\u00e4itega, uurige julgelt kommenteerida v\u00f5i minuga \u00fchendust v\u00f5tta.<\/p>\n<p>Mind k\u00fcsitakse sageli: \u201eMida valida, Kafka v\u00f5i RabbitMQ?\u201c, \u201eMilline platvorm on parem?\u201c. T\u00f5de on see, et see s\u00f5ltub t\u00f5eliselt teie olukorrast, hetke kogemusest jne. Ma ei julge oma arvamust avaldada, sest oleks liiga suur \u00fcldistus soovitada \u00fchte platvormi k\u00f5ikide kasutusjuhtumite ja v\u00f5imalike piirangute jaoks. Kirjutasin selle artiklite ts\u00fckli, et saaksite oma arvamuse kujundada.<\/p>\n<p>Tahaksin \u00f6elda, et m\u00f5lemad s\u00fcsteemid on selles valdkonnas liidrid. V\u00f5ib-olla olen ma pisut kallutatud, kuna oma projektide kogemuste p\u00f5hjal hindan rohkem selliseid aspekte nagu s\u00f5numite garanteeritud j\u00e4rjestus ja usaldusv\u00e4\u00e4rsus. <\/p>\n<p>N\u00e4en teisi tehnoloogiaid, millel puudub see usaldusv\u00e4\u00e4rsus ja garanteeritud j\u00e4rjestus, vaatan seej\u00e4rel RabbitMQ ja Kafka poole \u2014 ja m\u00f5istan nende kahe s\u00fcsteemi tohutut v\u00e4\u00e4rtust.<br \/>\n<br \/>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/474984\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u043f\u0440\u043e\u0448\u043b\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0435\u043b\u0438 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0438\u0437\u0430\u0446\u0438\u044e RabbitMQ \u0434\u043b\u044f \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u0438 \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u0438. \u0422\u0435\u043f\u0435\u0440\u044c \u0433\u043b\u0443\u0431\u043e\u043a\u043e \u043f\u043e\u043a\u043e\u043f\u0430\u0435\u043c\u0441\u044f \u0432 Apache Kafka. \u0417\u0434\u0435\u0441\u044c \u0435\u0434\u0438\u043d\u0438\u0446\u0435\u0439 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0440\u0430\u0437\u0434\u0435\u043b (partition). \u0423 \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u0442\u043e\u043f\u0438\u043a\u0430 \u043e\u0434\u0438\u043d \u0438\u043b\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0440\u0430\u0437\u0434\u0435\u043b\u043e\u0432. \u0412 \u043a\u0430\u0436\u0434\u043e\u043c \u0440\u0430\u0437\u0434\u0435\u043b\u0435 \u0435\u0441\u0442\u044c \u043b\u0438\u0434\u0435\u0440 \u0441 \u0444\u043e\u043b\u043b\u043e\u0432\u0435\u0440\u0430\u043c\u0438 \u0438\u043b\u0438 \u0431\u0435\u0437 \u043d\u0438\u0445. \u041f\u0440\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0438 \u0442\u043e\u043f\u0438\u043a\u0430 \u0443\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u0440\u0430\u0437\u0434\u0435\u043b\u043e\u0432 \u0438 \u043a\u043e\u044d\u0444\u0444\u0438\u0446\u0438\u0435\u043d\u0442 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438. \u041e\u0431\u044b\u0447\u043d\u043e\u0435 \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0435 3, \u044d\u0442\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52541","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47RabbitMQ \u043f\u0440\u043e\u0442\u0438\u0432 Kafka: \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c \u0438 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-11-10T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:00:17+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus | ProHoster","description":"V","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47RabbitMQ \u043f\u0440\u043e\u0442\u0438\u0432 Kafka: \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c \u0438 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c | ProHoster","og:description":"\u0412","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-10T21:00:00+00:00","article:modified_time":"2020-02-18T11:00:17+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52541","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 03:57:21","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:41:24","updated":"2026-01-24 03:57:22","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/52541","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=52541"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/52541\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=52541"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=52541"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=52541"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}