{"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\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/6557ce69c2b3070622feca8b3c228b09.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUues <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/471858\/\">eelmisel artiklil<\/a><\/noindex> Me arutasime RabbitMQ klasterdamist, et tagada talitlush\u00e4irete ja k\u00f5rge k\u00e4ttesaadavuse. N\u00fc\u00fcd s\u00fcveneme Apache Kafka.<\/p>\n<p>Siin on replikatsiooni\u00fcksuseks partitsioon (partition). Igal teemal on \u00fcks v\u00f5i mitu partitsiooni. Igas partitsioonis on juht ja v\u00f5imalikud j\u00e4rgijad v\u00f5i mitte. Teema loomisel m\u00e4\u00e4ratakse partitsioonide arv ja replikatsiooni koefitsient. Tavaline v\u00e4\u00e4rtus on 3, mis t\u00e4hendab kolme replikatsiooni: \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\u00f5rgeteta t\u00f6\u00f6kindlus 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 partitsiooni on jaotatud kolme maakleri vahel<\/i><\/p>\n<p>K\u00f5ik lugemis- ja kirjutamissoovid suunatakse juhile. J\u00e4rgijad saadavad juhile perioodiliselt p\u00e4ringuid viimaste s\u00f5numite saamiseks. Tarbijad ei p\u00f6\u00f6rdu kunagi j\u00e4rgijate poole, viimased eksisteerivad ainult \u00fcleliigsuse ja talitlush\u00e4irete kindlustamiseks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/715c51d75cb45863cfad4b37e81b9a9a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Partitsiooni rike<\/h1>\n<p>\nKui maakler kaob, j\u00e4\u00e4vad sageli mitme partitsioonijuhid ilma. Igas nendes m\u00e4\u00e4ratakse uueks juhiks teine s\u00f5lm. Tegelikult ei pruugi see alati nii olla, kuna m\u00f5jutab ka s\u00fcnkroniseerimise tegur: kas on s\u00fcnkroniseeritud j\u00e4rgijaid ja kui neid ei ole, kas on lubatud \u00fcleminek s\u00fcnkroniseerimata replikale. Aga hetkel ei hakka me seda keeruliseks muutma.<\/p>\n<p>V\u00f5rgust kaob maakler 3 \u2014 ja partitsioonile 2 valitakse uus juht maakleris 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/b8cfce64cf6b848b0659de023f9d9b63.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 2. Maakler 3 sureb ja tema j\u00e4rgija maakleris 2 valitakse partitsiooni 2 uueks juhiks<\/i><\/p>\n<p>Seej\u00e4rel kaob maakler 1 ja partitsioon 1 kaotab oma juhi, mille roll l\u00e4heb maaklerile 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/9f5409c723da7ff059b93f9b23e7d5f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 3. J\u00e4rele on j\u00e4\u00e4nud ainult \u00fcks maakler. K\u00f5ik juhid asuvad \u00fches maakleris nulli \u00fcleliigsusega<\/i><\/p>\n<p>Kui maakler 1 tuleb v\u00f5rku tagasi, lisab ta neli j\u00e4rgijat, tagades igale partitsioonile teatava \u00fcleliigsuse. Kuid k\u00f5ik juhid j\u00e4\u00e4vad endiselt maaklerisse 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/f9c8e42f51258b7fd7f6f35dc7b8cc3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 4. Juhid j\u00e4\u00e4vad maaklerisse 2<\/i><\/p>\n<p>Kui maakler 3 k\u00e4ivitatakse, naaseme kolme replikatsiooni juurde partitsioonis. Kuid k\u00f5ik juhid j\u00e4\u00e4vad endiselt maaklerisse 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/9c8c02be4161f8468b5dbc1e3f6ecb3a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 5. Eba\u00fchtlane juhtide paigutus p\u00e4rast maaklerite 1 ja 3 taastumist<\/i><\/p>\n<p>Kafkal on t\u00f6\u00f6riist juhtide t\u00f5husamaks \u00fcmberjaotamiseks kui RabbitMQ-l. Seal tuli kasutada kolmandate osapoolte pistikut v\u00f5i skripti, mis muutis poliitikaid peamise s\u00f5lme migreerimise nimel, v\u00e4hendades samal ajal \u00fcleliigsust migreerimise ajal. Lisaks pidid suurte j\u00e4rjekordade korral leppima k\u00e4ttesaamatusega s\u00fcnkroniseerimise ajal.<\/p>\n<p>Kafkal on m\u00f5isted \u201esoovitavad koopiaid\u201c liidri rolli jaoks. Kui teema osad luuakse, p\u00fc\u00fcab Kafka juhtide jaotuse tasakaalu ning m\u00e4rgib need esimesed juhid kui soovitatavad. Aja jooksul serverite taask\u00e4ivituste, t\u00f5rgete ja \u00fchenduse katkemise t\u00f5ttu v\u00f5ivad juhid sattuda teistele s\u00f5lmedele, nagu eelnevalt kirjeldatud \u00e4\u00e4rmuslikul juhul.<\/p>\n<p>Selle parandamiseks pakub Kafka kahte varianti:<\/p>\n<ul>\n<li>Valik <i>auto.leader.rebalance.enable=true<\/i> see v\u00f5imaldab kontrolleri s\u00f5lmel automaatselt juhtida juhte tagasi soovitatavatele koopiatele ja taastada seel\u00e4bi tasakaalustatud jaotuse.\n<\/li>\n<li>Administraator saab k\u00e4ivitada skripti <i>kafka-preferred-replica-election.sh<\/i> kopeerimise k\u00e4sitsi \u00fcmbernimetamiseks.<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/831930b06809637018fecb6d7d5a558d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kujutis 6. Koopiad p\u00e4rast \u00fcmberjaotust<\/i><\/p>\n<p>See oli lihtsustatud t\u00f5rkeversioon, kuid reaalsus on keerulisem, kuigi siin pole midagi liiga keerulist. K\u00f5ik tugineb s\u00fcnkroonitud koopiatele (In-Sync Replicas, ISR).<\/p>\n<h1>S\u00fcnkroonitud koopiad (ISR)<\/h1>\n<p>\nISR on sektsiooni koopiate kogum, mida peetakse \u201es\u00fcnkroonitud\u201c (in-sync). Siin on juht, kuid j\u00e4rgijaid ei pruugi olla. J\u00e4rgija loetakse s\u00fcnkroonitud, kui ta on teinud t\u00e4psed kopeerimised k\u00f5ikidest s\u00f5numitest liider enne vaheaja m\u00f6\u00f6dumist <i>replica.lag.time.max.ms<\/i>.<\/p>\n<p>J\u00e4rjeks hodpareltakse ISR-st, kui ta:<\/p>\n<ul>\n<li>ei ole kutsunud kaevet vooru jooksul <i>replica.lag.time.max.ms<\/i> (loetakse surnuks)\n<\/li>\n<li>ei ole ajaga v\u00e4rskendatud <i>replica.lag.time.max.ms<\/i> (loetakse aeglaseks)<\/li>\n<\/ul>\n<p>\nJ\u00e4rgjad teevad kaevet vooru intervallis <i>replica.fetch.wait.max.ms<\/i>, mis vaikimisi on 500 ms.<\/p>\n<p>ISR-i eesm\u00e4rgi selgeks tegemiseks tuleb vaadata tootjalt saabuvaid kinnitusd ja m\u00f5ned v\u00e4ljalangemisstsenaariumid. Tootjad v\u00f5ivad valida, millal maakler saadab kinnituse:<\/p>\n<ul>\n<li>acks=0, kinnitust ei saadeta\n<\/li>\n<li>acks=1, kinnitust saadetakse p\u00e4rast seda, kui liider on s\u00f5numi oma kohalikku logi salvestanud\n<\/li>\n<li>acks=all, kinnitust saadetakse p\u00e4rast seda, kui k\u00f5ik koopiad ISR-is on s\u00f5numi kohalikesse logidesse salvestanud<\/li>\n<\/ul>\n<p>\nKafka terminoloogias toimub s\u00f5numi \u201ekomiteerimine\u201c, kui ISR on selle salvestanud. Acks=all on k\u00f5ige turvalisem variant, kuid see toob kaasa ka lisaviivituse. Vaatame kaht t\u00f5rke n\u00e4idet ja kuidas erinevad \u201eacks\u201c valikud suhtlevad ISR kontseptsiooniga.<\/p>\n<h3>Acks=1 ja ISR<\/h3>\n<p>\nSelles n\u00e4ites n\u00e4eme, et kui liider ei oota, et iga s\u00f5num k\u00f5ikidelt j\u00e4lgijatelt salvestatakse, v\u00f5ib juhi t\u00f5rke korral andmeid kaotsi minna. \u00dcleminek s\u00fcnkroonimata j\u00e4lgijale v\u00f5ib olla lubatud v\u00f5i keelatud seadistusega <i>unclean.leader.election.enable<\/i>.<\/p>\n<p>Selles n\u00e4ites on tootjal seadistatud acks=1. Jagune on jaotatud kolme maakleri vahel. Maakler 3 on maas, ta s\u00fcnkroonis liidriga kaheksa sekundit tagasi ja n\u00fc\u00fcd on tal 7456 s\u00f5numi kaugus. Maakler 1 on maas vaid \u00fche sekundi. Meie tootja saadab s\u00f5numi ja saab kiiresti ack'i tagasi, ilma \u00fclekoormuseta aeglastele v\u00f5i surnud j\u00e4lgijatele, kes liidrit ei oota.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/f194e6309b732b772574392eff482a8b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 7. ISR kolme replikaga<\/i><\/p>\n<p>Maakler 2 langeb v\u00e4lja ja tootja saab \u00fchenduse t\u00f5rke. P\u00e4rast juhtimise \u00fcleminekut maaklerile 1 kaotame 123 s\u00f5numit. J\u00e4lgija maakleris 1 oli ISR-is, kuid ei olnud t\u00e4ielikult liidriga s\u00fcnkroonitud, kui too kukkus.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/367f219daebafefe585059f67fdedf6f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 8. T\u00f5rke korral kaovad s\u00f5numid<\/i><\/p>\n<p>Konfiguratsioonis <i>bootstrap.servers<\/i> on tootjal loetletud mitu maaklerit ja ta v\u00f5ib k\u00fcsida teiselt maaklerilt, kes on saanud jagundi uue liidri. Seej\u00e4rel loob ta \u00fchenduse maakleriga 1 ja j\u00e4tkab s\u00f5numite saatmist.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus 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 j\u00e4tkub p\u00e4rast l\u00fchikest pausi<\/i><\/p>\n<p>Maakler 3 on veelgi rohkem mahaj\u00e4\u00e4muses. Ta teeb p\u00e4ringuid, kuid ei saa s\u00fcnkroonida. See v\u00f5ib olla tingitud aeglasest v\u00f5rgu\u00fchendusest maaklerite vahel, salvestamise probleemidest jne. Ta eemaldatakse ISR-ist. N\u00fc\u00fcd koosneb ISR \u00fchest replikast \u2014 liidrist! Tootja j\u00e4tkab s\u00f5numite saatmist ja kinnituste saamist.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus 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\u00e4lgija maakleris 3 eemaldatakse ISR-ist<\/i><\/p>\n<p>Maakler 1 kukub ja liidri roll l\u00e4heb maaklerile 3, kaotades 15286 s\u00f5numit! Tootja saab \u00fchenduse t\u00f5rke teate. \u00dcleminek liidrile v\u00e4ljaspool ISR-i oli v\u00f5imaldanud ainult seadistuse t\u00f5ttu <i>unclean.leader.election.enable=true<\/i>. Kui see on seadistatud <i>false<\/i>, siis \u00fcleminekut ei toimuks ja k\u00f5ik lugemise ja kirjutamise p\u00e4ringud oleksid tagasi l\u00fckatud. Sellisel juhul ootame maakler 1 naasmist tema puutumatute andmetega replikas, mis taas v\u00f5tab juhi rolli.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/30f01ca715ccc194890ae061a3ef7396.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 11. Maakler 1 kukub. Suur osa s\u00f5numitest kaob t\u00f5rke korral<\/i><\/p>\n<p>Tootja loob \u00fchenduse viimase maakleriga ja n\u00e4eb, et see on n\u00fc\u00fcd jaotise juht. Ta hakkab saatma s\u00f5numeid maaklerile 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus 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 uuesti jaotisse 0.<\/i><\/p>\n<p>Oleme n\u00e4inud, et lisaks l\u00fchikestele pausidele uute \u00fchenduste seadistamiseks ja uue juhi leidmiseks, saatis tootja pidevalt s\u00f5numeid. See konfiguratsioon tagab k\u00e4ttesaadavuse koos j\u00e4rjepidevuse (andmete turvalisuse) n\u00f5udega. Kafka kaotas tuhandeid s\u00f5numeid, kuid j\u00e4tkas uute kirjade vastuv\u00f5tmist.<\/p>\n<h3>Acks=all ja ISR.<\/h3>\n<p>\nKorrake seda stsenaariumi veel kord, kuid koos <i>acks=all<\/i>. Maakleri 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 k\u00f5ik koopiad ISR-is s\u00f5numi salvestavad.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus 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 koopiaga. \u00dcks t\u00f6\u00f6tab aeglaselt, mis p\u00f5hjustab salvestamise viivituse.<\/i><\/p>\n<p>P\u00e4rast nelja sekundi lisaviivitust saadab maakler 2 ack. K\u00f5ik koopiad on n\u00fc\u00fcd t\u00e4ielikult uuendatud.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus 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 koopiad salvestavad s\u00f5numeid ja saadavad acki.<\/i><\/p>\n<p>Maakler 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 koopiaid. Maakler 2 ootab n\u00fc\u00fcd ainult maaklerit 1, kellel on keskmine viivitus 500 ms.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/5d3bd67dc53cb868fa40b358ed483a1d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 15. Koopia maakleris 3 eemaldatakse ISR-ist.<\/i><\/p>\n<p>Siis kukub maakler 2 ja juhtimine l\u00e4heb maaklerile 1 ilma s\u00f5numite kadumiseta.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/e3f0417aa7714ea5eae8a8e8d61662bd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 16. Maakler 2 kukub.<\/i><\/p>\n<p>Tootja leiab uue juhi ja hakkab sellele s\u00f5numeid saatma. Viivitus v\u00e4heneb veelgi, kuna n\u00fc\u00fcd koosneb ISR \u00fchest koopiast! Seet\u00f5ttu v\u00f5imalus <i>acks=all<\/i> ei lisa liigset turvalisust.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/fec9aae9977757d5f61c2909ceae0536.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 17. Koopia maakleris 1 v\u00f5tab juhtimise \u00fcle ilma s\u00f5numite kadumiseta.<\/i><\/p>\n<p>Siis kukub maakler 1 ja juhtimine l\u00e4heb maaklerile 3, mille k\u00e4igus kaob 14238 s\u00f5numit!<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/730b3951fb75ab3a782fc6d064615212.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 18. Maakler 1 sureb ja juhtimise \u00fcleminek m\u00e4\u00e4ranguga unclean toob kaasa ulatusliku andmekao.<\/i><\/p>\n<p>Me oleksime v\u00f5inud mitte seada v\u00f5imalust <i>unclean.leader.election.enable<\/i> v\u00e4\u00e4rtuseks <i>true<\/i>. Vaikimisi on see <i>false<\/i>. Seadistus <i>acks=all<\/i> jot <i>unclean.leader.election.enable=true<\/i> tagab k\u00e4ttesaadavuse koos m\u00f5ningase t\u00e4iendava andmete turvalisusega. Kuid nagu n\u00e4ete, v\u00f5ime siiski s\u00f5numeid kaotada.<\/p>\n<p>Aga mis siis, kui me tahame andmete turvalisust suurendada? Saame seadistada <i>unclean.leader.election.enable = false<\/i>, kuid see ei pruugi meid kaitsta andmete kaotuse eest. Kui juht t\u00f5siselt kokku kukub ja andmed kaovad, on s\u00f5numid endiselt kadunud ning juurdep\u00e4\u00e4s on kadunud, kuni administraator olukorra taastab.<\/p>\n<p>Parim on tagada k\u00f5igi s\u00f5numite mitmekesisus, vastasel juhul loobuda registreerimisest. Nii et v\u00e4hemalt maaklerina on andmete kaotus v\u00f5imalik ainult kahe v\u00f5i enama samaaegse rikke korral.<\/p>\n<h3>Acks=all, min.insync.replicas ja ISR<\/h3>\n<p>\nTeema konfiguratsiooniga <i>min.insync.replicas<\/i> t\u00f5stame andmete turvalisuse taset. Kordame veel kord eelmise stsenaariumi viimast osa, kuid seekord koos <i>min.insync.replicas=2<\/i>.<\/p>\n<p>Nii et maakleril 2 on replikatsiooni juht ja j\u00e4lgija maakleril 3 on ISR-ist eemaldatud.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/5831463293f1837d3232756894e97162.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 19. ISR kahest replikast<\/i><\/p>\n<p>Maakler 2 kukub kokku ja juhtimine \u00fcleminek maaklerile 1 ilma s\u00f5numite kaotuseta. Kuid n\u00fc\u00fcd koosneb ISR ainult \u00fchest replikast. See ei vasta minimaalsetele n\u00f5uetele kirje saamiseks ja seet\u00f5ttu vastab maakler kirje tegemise katsele veaga. <i>NotEnoughReplicas<\/i>.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/6b2ee477f4c33ec84f3068b792814e5d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 20. ISR arv on \u00fcks v\u00e4hem, kui on n\u00e4idatud min.insync.replicas<\/i><\/p>\n<p>See konfigureerimine ohverdab k\u00e4ttesaadavuse \u00fchtsuse nimel. Enne s\u00f5numi kinnitamist tagame, et see salvestatakse v\u00e4hemalt kahele replikale. See annab tootjale palju suurema kindluse. Siin on s\u00f5numite kaotus v\u00f5imalik ainult kahe replikasi samaaegse rikke korral l\u00fchikeses ajavahemikus, enne kui s\u00f5num on replikatsiooniks lisaj\u00e4lgijale, mis on ebat\u00f5en\u00e4oline. Kuid kui olete superparanoiline, v\u00f5ite seadistada replikatsiooni koefitsiendi 5 ja <i>min.insync.replicas<\/i> 3. Siin peavad kohe kolm maaklerit kokku kukkuma, et kirje kaotada! Muidugi, sellise usaldusv\u00e4\u00e4rsuse eest maksate lisaviivituse.<\/p>\n<h1>Kui k\u00e4ttesaadavus on andmete turvalisuse jaoks vajalik<\/h1>\n<p>\nNagu ka <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/471858\/\">RabbitMQ puhul<\/a><\/noindex>, m\u00f5nikord on k\u00e4ttesaadavus andmete turvalisuse jaoks vajalik. Peate m\u00f5tlema j\u00e4rgmisele:<\/p>\n<ul>\n<li>Kas avaldaja saab lihtsalt vea tagastada ja \u00fclemine teenus v\u00f5i kasutaja proovida hiljem uuesti?\n<\/li>\n<li>Kas avaldaja saab s\u00f5numi kohapeal v\u00f5i andmebaasis hoida, et proovida hiljem uuesti?<\/li>\n<\/ul>\n<p>\nKui vastus on negatiivne, siis k\u00e4ttesaadavuse optimeerimine suurendab andmete turvalisust. Te kaotate v\u00e4hem andmeid, kui valite k\u00e4ttesaadavuse salvestamise keeldumise asemel. Seega on k\u00f5ik tasakaalu leidmise k\u00fcsimus ja otsus s\u00f5ltub konkreetsest olukorrast.<\/p>\n<h1>ISR t\u00e4hendus<\/h1>\n<p>\nISR komplekt v\u00f5imaldab leida optimaalse tasakaalu andmete turvalisuse ja viivituse vahel. N\u00e4iteks tagab see k\u00e4ttesaadavuse enamiku koopiate rikke korral, minimeerides surnud v\u00f5i aeglaste koopiate viivituse m\u00f5ju.<\/p>\n<p>Me ise valime v\u00e4\u00e4rtuse <i>replica.lag.time.max.ms<\/i> vastavalt oma vajadustele. Sisuliselt t\u00e4hendab see parameeter, millise viivituse oleme valmis aktsepteerima <i>acks=all<\/i>. Vaikimisi on v\u00e4\u00e4rtus k\u00fcmme sekundit. Kui see on teie jaoks liiga kaua, siis v\u00f5ite seda v\u00e4hendada. Sel juhul suureneb ISR-i muutuste sagedus, kuna j\u00e4rgijad eemaldatakse ja lisatakse sagedamini.<\/p>\n<p>RabbitMQ-s on lihtsalt peegelduse komplekt, mida tuleb replitseerida. Aeglaselt toimivad peegeldused toovad kaasa lisaviivituse ja surnud peegelduste vastamist v\u00f5ib oodata pakettide eluea l\u00f5ppemiseni, mis kontrollivad iga s\u00f5lme k\u00e4ttesaadavust (net tick). ISR on huvitav viis nende viivituse probleemide v\u00e4ltimiseks. Kuid me riskime \u00fcleliigsuse kaotamisega, kuna ISR v\u00f5ib l\u00fcheneda ainult liidrini. Selle riski v\u00e4ltimiseks kasutage seadistust. <i>min.insync.replicas<\/i>.<\/p>\n<h1>Kliendi\u00fchenduse garantii<\/h1>\n<p>\nSeadetes <i>bootstrap.servers<\/i> tootjat ja tarbijat saab m\u00e4\u00e4rata mitmeid brokereid klientide \u00fchendamiseks. Idee on, et \u00fche s\u00f5lme v\u00e4ljalangemise korral j\u00e4\u00e4b veel mitu varus\u00f5lme, millega klient saab \u00fchenduse luua. Need ei pea olema jagamise liidrid, vaid lihtsalt tugipunkt alglaadimiseks. Klient v\u00f5ib nende k\u00e4est k\u00fcsida, millisel s\u00f5lmel asub jagamise liider lugemiseks\/kirjeldamiseks.<\/p>\n<p>RabbitMQ-s saavad kliendid \u00fchenduda mis tahes s\u00f5lmega ning sisemine marsruutimine saadab p\u00e4ringu sinna, kuhu vaja. See t\u00e4hendab, et saate seadistada koormuse tasakaalustaja RabbitMQ ees. Kafka n\u00f5uab, et kliendid \u00fchenduksid s\u00f5lmega, kus asub vastava jagamise liider. Sellises olukorras ei saa koormuse tasakaalustajat seadistada. Loend <i>bootstrap.servers<\/i> on kriitilise t\u00e4htsusega, et kliendid saaksid suhelda vajalike s\u00f5lmedega ja leida need p\u00e4rast riket.<\/p>\n<h1>Kafka konsensuse arhitektuur<\/h1>\n<p>\nKlassi senik ei ole k\u00e4sitlenud, kuidas klaster saadab teate v\u00f5rgu puudumise kohta ja kuidas valitakse uus juht. Et m\u00f5ista, kuidas Kafka t\u00f6\u00f6tab v\u00f5rgu osadega, on k\u00f5igepealt vajalik m\u00f5ista konsensuse arhitektuuri.<\/p>\n<p>Iga Kafka klaster on seadistatud koos Zookeeper klastri - see on jaotatud konsensuse teenus, mis v\u00f5imaldab s\u00fcsteemil saavutada konsensust teatud oleku kohta prioriteediga j\u00e4rjepidevuse \u00fcle kerguse. Lugemise ja kirjutamise toimingute heakskiitmiseks on vajalik Zookeeper'i enamus n\u00f5usolek.<\/p>\n<p>Zookeeper salvestab klastri oleku:<\/p>\n<ul>\n<li>Teemade, osade, seadistuse, praeguste liidrite koopia, eelistatud koopiate loetelu.\n<\/li>\n<li>Klastri liikmed. Iga broker saadab pingi Zookeeper'i. Kui Zookeeper ei saa pingi teate antud ajavahemiku jooksul, registreerib ta brokero kui k\u00e4ttesaamata.\n<\/li>\n<li>Peamise ja varu s\u00f5lmede valimine kontrollerile.<\/li>\n<\/ul>\n<p>\nKontrolleri s\u00f5lm on \u00fcks Kafka brokereid, kes vastutab koopiate liidrite valimise eest. Zookeeper saadab kontrollerile teateid klastri liikmelisuse ja teema muudatuste kohta ning kontroller peab nende muudatustega arvestama.<\/p>\n<p>N\u00e4iteks, v\u00f5tame uue teema k\u00fcmne osaga ja koopiate suhe 3. Kontroller peab valima iga osa liidri, p\u00fc\u00fcdes optimaalselt jagada liidreid brokede vahel. <\/p>\n<p>Iga osa puhul kontroller:<\/p>\n<ul>\n<li>uuendab Zookeeperis ISR ja liidri teavet;\n<\/li>\n<li>saadab iga brokeri, kes haldab selle osa koopiat, LeaderAndISRCommand'i k\u00e4su, teavitades brokereid ISR ja liidri kohta.<\/li>\n<\/ul>\n<p>\nKui liidri broker kukub, saadab Zookeeper teate kontrollerile ja see valib uue liidri. Veel kord, kontroller uuendab esmalt Zookeeperit ja seej\u00e4rel saadab igale brokerile k\u00e4su, teavitades neid juhtimisvahetusest.<\/p>\n<p>Iga liider vastutab ISR komplekti eest. Konfiguratsioon <i>replica.lag.time.max.ms<\/i> m\u00e4\u00e4rab, kes sinna kuulub. Kui ISR muutub, edastab liider Zookeeperile uue teabe.<\/p>\n<p>Zookeeper on alati teadlik igasugustest muudatustest, et juhatus saaks sujuvalt uuele liidrile liikuda, kui juhi v\u00f5i s\u00fcsteemi katkestus toimub.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus 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>Replikatsiooni protokoll<\/h1>\n<p>\nReplikatsiooni \u00fcksikasjade m\u00f5istmine aitab paremini aru saada potentsiaalsetest andmete kadumise stsenaariumidest.<\/p>\n<h3>P\u00e4ringud, eralduse l\u00f5pp-punkt (LEO) ja K\u00f5rgeim Vee Mark (HW)<\/h3>\n<p>\nMe oleme uurinud, et j\u00e4rgijad saadavad juhile aeg-ajalt p\u00e4ringuid andmete t\u00f5mbamiseks (fetch). Vaikimisi intervall on 500 ms. See erineb RabbitMQ-st, kuna RabbitMQ-s algatatakse replikatsioon mitte j\u00e4rje peegelduse, vaid meistri poolt. Meister saadab muudatused peegeldustele.<\/p>\n<p>Juht ja k\u00f5ik j\u00e4rgijad s\u00e4ilitavad logi l\u00f5pu nihke (Log End Offset, LEO) ja k\u00f5rge veetase (Highwater, HW). LEO m\u00e4rk s\u00e4ilitab viimase s\u00f5numi nihke kohalikus replikas, samas kui HW \u2013 viimase kinnituse nihke. Pidage meeles, et \u00abkinnituse\u00bb staatuse jaoks peab s\u00f5num olema salvestatud k\u00f5igisse replikatesse ISR. See t\u00e4hendab, et LEO j\u00e4\u00e4b tavaliselt natuke HW-st ette.<\/p>\n<p>Kui juht saab s\u00f5numi, salvestab ta selle kohapeal. J\u00e4rgija teeb t\u00f5mbep\u00e4ringu, edastades oma LEO. Siis saadab juht s\u00f5numite paketti alates sellest LEO-st ja edastab ka aktuaalse HW. Kui juht saab teavet, et k\u00f5ik replikad on s\u00e4ilitanud s\u00f5numi antud nihkega, liigub ta HW m\u00e4rgi edasi. Ainult juht v\u00f5ib HW-d edasi liikuda ning seega saavad k\u00f5ik j\u00e4rgijad selle aktuaalse v\u00e4\u00e4rtuse oma p\u00e4ringute vastustes. See t\u00e4hendab, et j\u00e4rgijad v\u00f5ivad juhtist maha j\u00e4\u00e4da nii s\u00f5numites kui ka teadmises HW-st. Tarbijad saavad s\u00f5numeid ainult kuni aktuaalse HW-ni.<\/p>\n<p>Pange t\u00e4hele, et \u00abs\u00e4ilitatud\u00bb (persisted) t\u00e4hendab salvestatud m\u00e4lu, mitte kettale. J\u00f5udluse huvides viib Kafka kettale s\u00fcnkroonimise kindla intervalliga. RabbitMQ-l on samuti selline intervall, kuid see saadab kinnituse v\u00e4ljaandjale alles p\u00e4rast seda, kui meister ja k\u00f5ik peegeldused on s\u00f5numi kettale salvestanud. Kafka arendajad otsustasid j\u00f5udluse kaalutlustel saata ack nii kiiresti, kui s\u00f5num on m\u00e4lu salvestatud. Kafka panustab, et liigse replikatsiooni kasutamine kompenseerib l\u00fchiajalise kinnitatud s\u00f5numite salvestamise ainult m\u00e4llu tekkiva riski.<\/p>\n<h1>Juhi rike<\/h1>\n<p>\nKui juht langeb, teavitab Zookeeper kontrollerit, kes valib uue juhi replikana. Uus juht seab uue HW m\u00e4rgi vastavalt oma LEO-le. Siis saavad j\u00e4rgijad oma teavet uue juhi kohta. Olenevalt Kafka versioonist valib j\u00e4rgija \u00fche kahest stsenaariumist:<\/p>\n<ol>\n<li>L\u00fchendab kohaliku logi tuntud HW-ni ja saadab uuele juhile p\u00e4ringu selle m\u00e4rgi j\u00e4rel olevate s\u00f5numite kohta.\n<\/li>\n<li>Saadetab liidrile p\u00e4ringu, et teada saada HW tema liidriks valimise hetkel, ja seej\u00e4rel k\u00e4rbib logi kuni sellele nihkele. Seej\u00e4rel hakkab ta perioodiliselt p\u00e4ringuid tegema valimise algusest peale.<\/li>\n<\/ol>\n<p>\nJ\u00e4rgnejal v\u00f5ivad tekkida vajadus logi k\u00e4rpimise j\u00e4rele j\u00e4rgmistel p\u00f5hjustel:<\/p>\n<ul>\n<li>Kui liider eba\u00f5nnestub, saab esimene j\u00e4rgija ISR-ist, kes on registreeritud Zookeeperis, valimistel v\u00f5idu ja temast saab liider. K\u00f5ik ISR-is olevad j\u00e4rgijad, kuigi neid peetakse \"s\u00fcnkroniseeritud\", ei pruugi endiselt olla saanud endiselt liidri koopiaid k\u00f5igist teadetest. On t\u00e4iesti v\u00f5imalik, et valitud j\u00e4rgijal ei ole k\u00f5ige ajakohasemat koopiaid. Kafka tagab, et replikate vahel ei esine lahknevusi. Seet\u00f5ttu peab iga j\u00e4rgija k\u00e4rpima oma logi uue liidri HW v\u00e4\u00e4rtuseni tema valimise hetkel, et v\u00e4ltida lahknevusi. See on veel \u00fcks p\u00f5hjus, miks seadistamine <i>acks=all<\/i> on n\u00f5udlik koosk\u00f5la tagamise jaoks.\n<\/li>\n<li>Teated kirjutatakse perioodiliselt kettale. Kui k\u00f5ik klastrite s\u00f5lmed eba\u00f5nnestuvad samal ajal, salvestatakse kettale replikad erineva nihkega. On t\u00e4iesti v\u00f5imalik, et kui maaklerid naasevad v\u00f5rku, osutub uus valitud liider oma j\u00e4rgijatest maha j\u00e4\u00e4vaks, kuna ta salvestati kettale varem kui teised.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Klastriga taaskoondumine<\/h3>\n<p>\nKlastriga taaskoondumisel replikad k\u00e4ituvad samamoodi nagu liidri eba\u00f5nnestumisel: nad kontrollivad liidri replit ja k\u00e4rbivad oma logi tema HW-le (valimise hetkel). V\u00f5rdlemiseks k\u00e4sitleb RabbitMQ taaskoondatud s\u00f5lmi t\u00e4iesti uutena. M\u00f5lemal juhul loob maakler iga olemasoleva oleku. Kui kasutatakse automaatset s\u00fcnkroniseerimist, peab meister replitseerima kogu praeguse sisu uude peegeldusse viisil \"ja las kogu maailm ootab\". Selle operatsiooni ajal ei aktsepteeri meister \u00fchtegi lugemise v\u00f5i kirjutamise toimingut. Selline l\u00e4henemine tekitab probleeme suurte j\u00e4rjekordade korral.<\/p>\n<p>Kafka on hajutatud p\u00e4evik, ja \u00fcldiselt s\u00e4ilitab see rohkem s\u00f5numeid kui RabbitMQ j\u00e4rjekord, kus andmed eemaldatakse j\u00e4rjekorrast p\u00e4rast nende lugemist. Aktiivsed j\u00e4rjekorrad peaksid j\u00e4\u00e4ma suhteliselt v\u00e4ikesteks. Kuid Kafka on p\u00e4evik oma hoidmisreeglitega, mis v\u00f5ivad seadistada t\u00e4htaja p\u00e4evade v\u00f5i n\u00e4dalate kaupa. J\u00e4rjekorra lukustamise ja t\u00e4ieliku s\u00fcnkroniseerimise l\u00e4henemine ei ole hajutatud p\u00e4eviku jaoks t\u00e4iesti vastuv\u00f5etav. Selle asemel l\u00f5ikavad Kafka j\u00e4rgijad lihtsalt oma p\u00e4eviku HW liidri peale (hetkel, mil ta valitakse), juhul kui nende koopia on liidrist ette. Enamasti, kui j\u00e4rgija on maas, alustab ta lihtsalt p\u00e4ringute tegemist, alates oma praegsest LEO-st.<\/p>\n<p>Uued v\u00f5i taas\u00fchendatud j\u00e4rgijad alustavad v\u00e4ljaspool ISR-i ja ei osale komiteeringutes. Nad t\u00f6\u00f6tavad lihtsalt r\u00fchma k\u00f5rval, saades s\u00f5numeid nii kiiresti kui saavad, kuni nad j\u00f5uavad liidrini ja sisenevad ISR-i. Siin ei ole lukustamist ja pole vaja visata \u00e4ra k\u00f5iki oma andmeid.<\/p>\n<h1>Sidususe rikkumine<\/h1>\n<p>\nKafkal on rohkem komponente kui RabbitMQ-l, seega on siin keerulisem k\u00e4itumiste kogum, kui klastris esineb sidususe rikkumine. Kuid Kafka kavandati algselt klastrite jaoks, seega on lahendused v\u00e4ga h\u00e4sti l\u00e4bi m\u00f5eldud.<\/p>\n<p>Allpool on toodud m\u00f5ned sidususe rikkumise stsenaariumid:<\/p>\n<ul>\n<li>Stsenaarium 1. J\u00e4rgija ei n\u00e4e liidrit, kuid n\u00e4eb endiselt Zookeeperi.\n<\/li>\n<li>Stsenaarium 2. Liider ei n\u00e4e \u00fchtegi j\u00e4rgijat, kuid n\u00e4eb endiselt Zookeeperi.\n<\/li>\n<li>Stsenaarium 3. J\u00e4rgija n\u00e4eb liidrit, kuid ei n\u00e4e Zookeeperi.\n<\/li>\n<li>Stsenaarium 4. Liider n\u00e4eb j\u00e4rgijaid, kuid ei n\u00e4e Zookeeperi.\n<\/li>\n<li>Stsenaarium 5. J\u00e4rgija 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 kontrolls\u00f5lm ei n\u00e4e teist Kafka s\u00f5lme.\n<\/li>\n<li>Stsenaarium 8. Kafka kontrolls\u00f5lm ei n\u00e4e Zookeeperit.<\/li>\n<\/ul>\n<p>\nIga stsenaariumi jaoks on ette n\u00e4htud oma k\u00e4itumine.<\/p>\n<h3>Stsenaarium 1. J\u00e4rgija ei n\u00e4e liidrit, kuid n\u00e4eb endiselt Zookeeperi<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus 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 replikaga<\/i><\/p>\n<p>Sidususe rikkumine eraldab maakler 3 maakleritest 1 ja 2, kuid mitte Zookeeperist. Maakler 3 ei saa enam p\u00e4ringute tegemisega edasi minna. Aja m\u00f6\u00f6dudes <i>replica.lag.time.max.ms<\/i> ta eemaldatakse ISR-ist ja ei osale s\u00f5numite commit'ides. Niipea, kui \u00fchenduvus on taastatud, j\u00e4tkab ta andmete p\u00e4ringute saatmist ja liitub ISR-iga, kui j\u00f5uab juhitajale j\u00e4rele. Zookeeper j\u00e4tkab pingide vastuv\u00f5tmist ja peab brokereid elusateks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/976b7ff080ee6a6d76a165f614f40e95.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kujund 23. Stsenaarium 1. Broker eemaldatakse ISR-ist, kui sellelt ei saadeta andmete p\u00e4ringut replica.lag.time.max.ms intervali jooksul<\/i><\/p>\n<p>Ei ole mingit loogilist jagunemist (split-brain) ega s\u00f5lme peatamist, nagu RabbitMQ-s. Selle asemel v\u00e4hendada \u00fcleliigsust. <\/p>\n<h3>Stsenaarium 2. Juhataja ei n\u00e4e \u00fchtegi j\u00e4rgijat, kuid n\u00e4eb siiski Zookeeperit<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/ff6aaa053d73e8b7c97111979bcf97aa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kujund 24. Stsenaarium 2. Juhataja ja kaks j\u00e4rgijat<\/i><\/p>\n<p>V\u00f5rgupuutumatuse rikkumine eraldab juhataja j\u00e4rgijatelt, kuid broker n\u00e4eb Zookeeperit endiselt. Nagu esimese stsenaariumi puhul, ISR kokku t\u00f5mbub, kuid seekord ainult juhatajani, kuna k\u00f5ik j\u00e4rgijad l\u00f5petavad andmete p\u00e4ringute saatmise. Taaskord, puudub loogiline jagunemine. Selle asemel toimub uute s\u00f5numite osas \u00fcleliigsuse kadu, kuni \u00fchenduvus on taastatud. Zookeeper j\u00e4tkab pingide vastuv\u00f5tmist ja peab brokereid elusateks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/3c69e8327da241407f76719fc022c37a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kujund 25. Stsenaarium 2. ISR t\u00f5mbus kokku ainult juhatajani<\/i><\/p>\n<h3>Stsenaarium 3. J\u00e4rgjat n\u00e4eb juhatajat, kuid ei n\u00e4e Zookeeperit<\/h3>\n<p>\nJ\u00e4rgjat eraldatakse Zookeeperist, kuid mitte juhatajast koos brokeritega. Selle tulemusena j\u00e4tkab j\u00e4rgija andmete p\u00e4ringute saatmist ja on ISR-i liige. Zookeeper ei saa enam pingisid ja registreerib brokera kukkumise, kuid kuna tegemist on ainult j\u00e4rgijaga, pole taastumise j\u00e4rel mingeid tagaj\u00e4rgi.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/1183bcfe45a3225ae3ef1a0651f61350.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kujund 26. Stsenaarium 3. J\u00e4rgjat j\u00e4tkab andmete p\u00e4ringute saatmist juhatajale<\/i><\/p>\n<h3>Stsenaarium 4. Juhataja n\u00e4eb j\u00e4rgijaid, kuid ei n\u00e4e Zookeeperit<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/b3bf27fcb0eb806b27ad00f098e50a26.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kujund 27. Stsenaarium 4. Juhataja ja kaks j\u00e4rgijat<\/i><\/p>\n<p>Juhataja on eraldatud Zookeeperist, kuid mitte brokeritest koos j\u00e4rgijatega. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/82d9f2e5868566678befc414d1885bfd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kujund 28. Stsenaarium 4. Juhataja on Zookeeperist isoleeritud<\/i><\/p>\n<p>M\u00f5ne aja p\u00e4rast registreerib Zookeeper brokera kukkumise ja teavitab sellest kontrollerit. See valib j\u00e4rgijate hulgast uue juhataja. Kuid algne juhataja peab endiselt end juhatajaks ja j\u00e4tkab kirjeid vastuv\u00f5tmist <i>acks=1<\/i>. J\u00e4rgjad ei saada enam andmete p\u00e4ringuid, seega peab ta neid surnud ja \u00fcritab ISR-i kokku t\u00f5mmata enda peale. Kuid kuna tal puudub \u00fchendus Zookeeperiga, ei saa ta seda teha ja loobub edasise kirje vastuv\u00f5tmisest. <\/p>\n<p>S\u00f5numid <i>acks=all<\/i> ei saa kinnitust, kuna esmalt h\u00f5lmab ISR k\u00f5iki replikaate ja s\u00f5numid ei j\u00f5ua nende juurde. Kui algne juht \u00fcritab neid ISR-ist eemaldada, ei saa ta seda teha ja l\u00f5petab igasuguste s\u00f5numite vastuv\u00f5tmise.<\/p>\n<p>Kliendid m\u00e4rkavad peagi juhi vahetust ja hakkavad saatma 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\u00e4rtusele, mis oli uuel juhil enamiku katkestuse hetkel, et v\u00e4ltida logide erinevust. Siis hakkab ta saatma p\u00e4ringuid uuele juhile. K\u00f5ik algse juhi kirjed, mis ei olnud uuele juhile replitseeritud, kaovad. See t\u00e4hendab, et kaovad s\u00f5numid, mis algne juht ei ole nende paar sekundi jooksul kinnitanud, mil kaks juhti t\u00f6\u00f6tasid.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/d88d6f33c13dccb814c0f206ec72512b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 29. Stseen 4. Juht brokeris 1 muutub j\u00e4rgijaks v\u00f5rgu taastumise peale<\/i><\/p>\n<h3>Stseen 5. J\u00e4rgija on t\u00e4ielikult eraldatud teistest Kafka s\u00f5lmedest ja Zookeeperist<\/h3>\n<p>\nJ\u00e4rgija on t\u00e4ielikult isoleeritud teistest Kafka s\u00f5lmedest ja Zookeeperist. Ta eemaldatakse ISR-ist, kuni v\u00f5rk taastub, ja seej\u00e4rel j\u00e4rgib ta teisi.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/b092607f777014fd945f18734dd7f4e7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 30. Stseen 5. Isoleeritud j\u00e4rgija eemaldatakse ISR-ist<\/i><\/p>\n<h3>Stseen 6. Juht on t\u00e4ielikult eraldatud teistest Kafka s\u00f5lmedest ja Zookeeperist<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/bb808d534dbf65748eb0b481f86b4926.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 31. Stseen 6. Juht ja kaks j\u00e4rgijat<\/i><\/p>\n<p>Juht on t\u00e4ielikult isoleeritud oma j\u00e4rgijatest, kontrollerist ja Zookeeperist. L\u00fchikese aja jooksul j\u00e4tkab ta kirjeid vastu v\u00f5tmist. <i>acks=1<\/i>.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/6fda78bcd26ef6b916579d447e9fb1f0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 32. Stseen 6. Juhi isoleerimine teistest Kafka s\u00f5lmedest ja Zookeeperist<\/i><\/p>\n<p>Ei saa p\u00e4ringuid p\u00e4rast <i>replica.lag.time.max.ms<\/i>, ta \u00fcritab ISR-i endaks kokku suruda, kuid ei saa seda teha, kuna Zookeeperiga pole \u00fchendust, siis l\u00f5petab ta kirjeid vastu v\u00f5tmise. <\/p>\n<p>Samaan, Zookeeper m\u00e4rkab isoleeritud brokerit kui surnud, ja kontroller valib uue juhi.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/73d611a411fc64d835af2c714e9eba0a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 33. Stseen 6. Kaks juhti<\/i><\/p>\n<p>Algne juht v\u00f5ib v\u00f5tta kirjeid vastu paar sekundi jooksul, kuid seej\u00e4rel l\u00f5petab ta igasuguste s\u00f5numite vastuv\u00f5tmise. Kliendid uuendavad iga 60 sekundi tagant viimaseid metaandmeid. Nad saavad teate juhi vahetusest ja hakkavad saatma kirjeid uuele juhile.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus ja k\u00f5rge k\u00e4ttesaadavus\" src=\"\/wp-content\/uploads\/2019\/11\/ae99380c8a84fac15f440b699b9c552b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 34. Stseen 6. Tootjad l\u00fclituvad uuele juhile<\/i><\/p>\n<p>K\u00f5ik kinnitatud kirjed, mille on teinud algne juht alates \u00fchenduse kadumisest, l\u00e4hevad kaotsi. Kui v\u00f5rk on taastatud, avastab algne juht Zookeeperi kaudu, et ta ei ole enam juht. Seej\u00e4rel l\u00fckkab ta oma logi tagasi uue juhi HW-le hetkest, mil ta valiti, ja hakkab saatma p\u00e4ringuid j\u00e4rgijana.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f5rgeteta t\u00f6\u00f6kindlus 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 j\u00e4rgijaks p\u00e4rast v\u00f5rgu \u00fchenduse taastamist<\/i><\/p>\n<p>Selles olukorras v\u00f5ib l\u00fchikese perioodi jooksul t\u00e4heldada loogilist eraldatust, kuid ainult juhul kui <i>acks=1<\/i> ja <i>min.insync.replicas<\/i> loogiline eraldatus l\u00f5ppeb 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 s\u00f5ltuvalt sellest, mis juhtub varem. Igal juhul toimub alguns s\u00f5numite kadu, kuid ainult <i>acks=1<\/i>.<\/p>\n<p>On olemas teine variant sellest stsenaariumist, kus vahetult enne v\u00f5rgu eraldumist j\u00e4id j\u00e4rgijad maha, ja juht l\u00fchendas ISR-i vaid endani. Siis eraldub ta \u00fchenduse kaotamise t\u00f5ttu. Valitakse uus juht, kuid algne juht j\u00e4tkab kirjete vastuv\u00f5ttu isegi <i>acks=all<\/i>, kuna ISR-is pole kedagi peale tema. Need kirjed l\u00e4hevad v\u00f5rgu taastamisel kaotsi. Ainus viis sellise variandi v\u00e4ltimiseks on <i>min.insync.replicas = 2<\/i>.<\/p>\n<h3>Stsenaarium 7. Kafka kontroller ei n\u00e4e teist Kafka s\u00f5lme<\/h3>\n<p>\n\u00dcldiselt, p\u00e4rast \u00fchenduse katkemist Kafka s\u00f5lmega ei suuda kontroller edastada sellele mingit teavet juhi vahetamise kohta. Halvimal juhul toob see kaasa l\u00fchiajalise loogilise eraldatuse, nagu stsenaarium 6. Enamasti ei saa maakler lihtsalt juhtivaks kandidaadiks, kui viimane eba\u00f5nnestub.<\/p>\n<h3>Stsenaarium 8. Kafka kontroller ei n\u00e4e Zookeeperi<\/h3>\n<p>\nEbatavalise Zookeeperi kontroller ei saa pinget ja valib uue Kafka s\u00f5lme kontrolleriks. Algne kontroller v\u00f5ib j\u00e4tkata enda esindamist kui sellist, kuid ei saa Zookeeperilt teateid, seega puuduvad tal \u00fclesanded t\u00e4itmiseks. Kui v\u00f5rk taastub, m\u00f5istab ta, et ta ei ole enam kontroller, vaid saanud tavaline Kafka s\u00f5lm.<\/p>\n<h3>J\u00e4reldused stsenaariumitest<\/h3>\n<p>\nN\u00e4eme, et j\u00e4lgijate \u00fchenduse kadumine ei too kaasa s\u00f5numite kaotust, vaid lihtsalt ajutiselt v\u00e4hendab \u00fclej\u00e4\u00e4tuvust, kuni v\u00f5rk taastub. See v\u00f5ib muidugi p\u00f5hjustada andmete kaotust, kui \u00fcks v\u00f5i mitu s\u00f5lme on kadunud.<\/p>\n<p>Kui \u00fchenduse kadumise t\u00f5ttu juhi\u00fchendus Zookeeperist katkeb, v\u00f5ib see tuua kaasa s\u00f5numite kadumise. <i>acks=1<\/i>. \u00dchenduse puudumine Zookeeperiga p\u00f5hjustab l\u00fchiajalise loogilise jagunemise kahe juhiga. Selle probleemi lahendab parameeter <i>acks=all<\/i>.<\/p>\n<p>Parameeter <i>min.insync.replicas<\/i> kahe v\u00f5i enama replikaga, mis annab t\u00e4iendavaid garanteeringuid, et sellised l\u00fchiajalised stsenaariumid ei too kaasa s\u00f5numite kaotust, nagu stsenaariumis 6.<\/p>\n<h1>S\u00f5numite kaotuse kokkuv\u00f5te<\/h1>\n<p>\nLoetleme k\u00f5ik viisid, kuidas andmed Kafka-s v\u00f5ivad kaduda:<\/p>\n<ul>\n<li>Iga juhi rike, kui s\u00f5numid on kinnitatud <i>acks=1<\/i>\n<\/li>\n<li>Iga r\u00e4pane juhtimise \u00fcleminek, st j\u00e4lgijale, mis on v\u00e4ljaspool ISR-i, isegi <i>acks=all<\/i>\n<\/li>\n<li>Juhi isoleerimine Zookeeperist, kui s\u00f5numid on kinnitatud <i>acks=1<\/i>\n<\/li>\n<li>Juhi t\u00e4ielik isoleerimine, kes on juba t\u00f5mmanud ISR-i r\u00fchma endast alla. K\u00f5ik s\u00f5numid on kadunud, isegi <i>acks=all<\/i>. See on t\u00f5si ainult juhul, kui <i>min.insync.replicas=1<\/i>.\n<\/li>\n<li>K\u00f5ikide jaotuse s\u00f5lmede samal ajal rikke. Kuna s\u00f5numid kinnitatakse m\u00e4lust, v\u00f5ib osa neist veel ketta kirjutamata j\u00e4\u00e4da. Serverite taask\u00e4ivitamisel v\u00f5ib m\u00f5nest s\u00f5numist puudu olla.<\/li>\n<\/ul>\n<p>\nR\u00e4pase juhtimise \u00fcleminekuid saab v\u00e4ltida kas nende keelamise v\u00f5i v\u00e4hemalt kahe replikatsiooni tagamisega. K\u00f5ige usaldusv\u00e4\u00e4rsem konfiguratsioon on kombinatsioon <i>acks=all<\/i> ja <i>min.insync.replicas<\/i> rohkem kui 1.<\/p>\n<h1>Langetades RabbitMQ ja Kafka usaldusv\u00e4\u00e4rsuse vahetut v\u00f5rdlust.<\/h1>\n<p>\nUsaldusv\u00e4\u00e4rsuse ja k\u00f5rge k\u00e4ttesaadavuse tagamiseks on m\u00f5lemal platvormil rakendatud peamise ja sekundaarse replikatsiooni s\u00fcsteem. Kuid RabbitMQ-l on Achilleuse kand. Vigade taastumisel viskavad s\u00f5lmed oma andmed \u00e4ra ja s\u00fcnkroonimine blokeeritakse. See kahekordne l\u00f6\u00f6k seab kahtluse alla suurte j\u00e4rjekordade pikaealisuse RabbitMQ-s. Peate leppima kas v\u00e4hendatud \u00fclej\u00e4\u00e4tuvuse v\u00f5i pikaajaliste blokeeringutega. \u00dclej\u00e4\u00e4tuvuse v\u00e4hendamine suurendab massiliste andmekao riski. Ent kui j\u00e4rjekorrad on v\u00e4ikesed, saab \u00fclej\u00e4\u00e4tuvuse tagamiseks l\u00fchikeste mittesaadavuse perioodide (m\u00f5ned sekundid) t\u00f5ttu hakkama \u00fchenduse uuesti proovimisega.<\/p>\n<p>Kafkas ei ole sellist probleemi. See viskab andmed k\u00f5rvale ainult liidri ja j\u00e4rgija vaheline erinevuse kohalt. K\u00f5ik \u00fchised andmed s\u00e4ilivad. Lisaks ei blokeeri replikatsioon s\u00fcsteemi. Liider j\u00e4tkab sisestuste vastuv\u00f5tmist, samal ajal kui uus j\u00e4rgija teda j\u00e4rele j\u00f5uab, mist\u00f5ttu on devops'i jaoks klastriga liitumine v\u00f5i uuesti liitumine triviaalne \u00fclesanne. Loomulikult j\u00e4\u00e4vad k\u00f5rvale ka probleemid, nagu replikatsiooni ajal v\u00f5rgu l\u00e4bilaskev\u00f5ime. Kui korraga lisatakse mitu j\u00e4rgijat, v\u00f5ib esineda l\u00e4bilaskev\u00f5ime piirangut.<\/p>\n<p>RabbitMQ \u00fcletab Kafkat usaldusv\u00e4\u00e4rsuses, kui mitme serveri rike klastris on samaaegselt toimunud. Nagu me juba r\u00e4\u00e4kisime, saadab RabbitMQ avaldajale kinnituse alles p\u00e4rast s\u00f5numi kirjutamist kettale peamisel ja k\u00f5ikidel peegeldustel. Kuid see toob kaasa t\u00e4iendava viivituse kahe p\u00f5hjuse t\u00f5ttu:<\/p>\n<ul>\n<li>fsync iga paari sajandi millisekundi j\u00e4rel\n<\/li>\n<li>Peegeldamise katkestust saab m\u00e4rgata alles pakettide eluea m\u00f6\u00f6dumisel, mis kontrollivad iga s\u00f5lme k\u00e4ttesaadavust (net tick). Kui peegel on blokeeritud v\u00f5i v\u00e4ljas, lisab see viivituse.<\/li>\n<\/ul>\n<p>\nKafka panustab sellele, et kui s\u00f5num on salvestatud mitmele s\u00f5lmele, saab s\u00f5numeid kinnitada, niipea kui need on m\u00e4llu j\u00f5udnud. Seet\u00f5ttu on oht kaotada s\u00f5numeid igasuguses vormis (isegi <i>acks=all<\/i>, <i>min.insync.replikad=2<\/i>) juhul, kui samal ajal toimub rike.<\/p>\n<p>\u00dcldiselt n\u00e4itab Kafka k\u00f5rgemat j\u00f5udlust ja on algselt projekteeritud klastrite jaoks. J\u00e4rgjate arvu saab suurendada kuni 11-ni, kui see on vajalik usaldusv\u00e4\u00e4rsuse saavutamiseks. Replikatsiooni suhe 5 ja miniaalne arv s\u00fcnkroonitud replikate <i>min.insync.replicas=3<\/i> teevad s\u00f5numi kaotamise v\u00e4ga harvaks s\u00fcndmuseks. Kui teie infrastruktuur suudab pakkuda sellist replikatsiooni suhet ja taseme \u00fcleliigsust, v\u00f5ite valida selle variandi.<\/p>\n<p>RabbitMQ klasterdamine sobib v\u00e4ikeste j\u00e4rjekordade jaoks. Kuid isegi v\u00e4ikesed j\u00e4rjekorrad v\u00f5ivad suure liikluse korral kiiresti kasvada. Kui j\u00e4rjekorrad saavad suurteks, tuleb teha kindel valik k\u00e4ttesaadavuse ja usaldusv\u00e4\u00e4rsuse vahel. RabbitMQ klasterdamine sobib k\u00f5ige paremini ebat\u00fc\u00fcpiliste olukordade jaoks, kus RabbitMQ paindlikkuse eelised kaaluvad \u00fcles selle klasterdamise puudused.<\/p>\n<p>\u00dcks vastum\u00fcrk RabbitMQ haavatavusele suurte j\u00e4rjekordade osas on jagada need paljudeks v\u00e4iksemateks. Kui ei n\u00f5uta kogu j\u00e4rjekorra t\u00e4ielikku j\u00e4rjestamist, vaid ainult konkreetsete s\u00f5numite (n\u00e4iteks konkreetse kliendi s\u00f5numite) v\u00f5i hoopis midagi ei j\u00e4rjestata, on see variant aktsepteeritav: 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 veel varases staadiumis). <\/p>\n<p>L\u00f5puks \u00e4rge unustage rida vigu klastrite ja replikatsiooni mehhanismides nii RabbitMQ-s kui ka Kafka-s. Aja jooksul on s\u00fcsteemid muutunud k\u00fcpsemaks ja stabiilsemaks, kuid \u00fckski s\u00f5num ei ole kunagi 100% kaitstud kadumise eest! Lisaks esinevad andmekeskustes suured \u00f5nnetused!<\/p>\n<p>Kui olen midagi vahele j\u00e4tnud, teinud vea v\u00f5i te ei n\u00f5ustu m\u00f5ne v\u00e4itega, \u00e4rge kartke kirjutada kommentaar v\u00f5i v\u00f5tta minuga \u00fchendust.<\/p>\n<p>K\u00fcsimus, mida sageli k\u00fcsin: \"Mida valida, Kafka v\u00f5i RabbitMQ?\", \"Milline platvorm on parem?\". T\u00f5de on see, et see s\u00f5ltub t\u00f5eliselt teie olukorrast, praegusest kogemusest jne. Ma ei julge oma arvamust avaldada, kuna oleks liiga suur lihtsustamine soovitada \u00fcksikut platvormi k\u00f5ikide kasutusv\u00f5imaluste ja v\u00f5imalike piirangute jaoks. Olen kirjutanud selle artiklite seeria, et saaksite kujundada oma arvamuse.<\/p>\n<p>Tahan \u00f6elda, et m\u00f5lemad s\u00fcsteemid on valdkonna liidrid. V\u00f5ib-olla olen ma veidi kallutatud, kuna oma projektide kogemuse p\u00f5hjal hindan rohkem selliseid asju nagu s\u00f5numite garantii j\u00e4rjekord ja usaldusv\u00e4\u00e4rsus. <\/p>\n<p>N\u00e4en teisi tehnoloogiaid, millel puudub see usaldusv\u00e4\u00e4rsus ja garanteeritud j\u00e4rjestamine, seej\u00e4rel vaatan RabbitMQ-d ja Kafka-d \u2014 ja m\u00f5istan, kui uskumatu v\u00e4\u00e4rtus on m\u00f5lemas nendes s\u00fcsteemides.<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.1.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.1.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: veakindlus ja k\u00f5rge k\u00e4ttesaadavus | ProHoster","description":"Uues","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}]}}