{"id":52525,"date":"2019-11-10T00:00:00","date_gmt":"2019-11-09T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah"},"modified":"2020-02-18T14:00:16","modified_gmt":"2020-02-18T11:00:16","slug":"rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","title":{"rendered":"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/d8e584d210a6a016a962ad6f956a2078.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJ\u00f5udlus ja k\u00f5rge k\u00e4ttesaadavus on suured teemad, seega p\u00fchendame RabbitMQ ja Kafka k\u00e4sitlemisele eraldi artiklid. See artikkel k\u00e4sitleb RabbitMQ-d, j\u00e4rgmine aga Kafka-d v\u00f5rreldes RabbitMQ-ga. Artikkel on pikk, seega minge mugavale positsioonile.<\/p>\n<p>Kaalume t\u00f5rkealtiuse, koosk\u00f5lastatuse ja k\u00f5rge k\u00e4ttesaadavuse (HA) strateegiaid ning kompromisse, millega iga strateegia puhul silmitsi seisame. RabbitMQ saab t\u00f6\u00f6tada s\u00f5lmede klastris \u2014 sel juhul liigitatakse see jaotatud s\u00fcsteemiks. R\u00e4\u00e4gime jaotatud s\u00fcsteemidest, r\u00e4\u00e4kides r\u00e4\u00e4gime sageli koosk\u00f5lastatusest ja k\u00e4ttesaadavusest. <\/p>\n<p>Need m\u00f5isted kirjeldavad, kuidas s\u00fcsteem k\u00e4itub eba\u00f5nnestumise korral. V\u00f5rguyhenduse eba\u00f5nnestumine, serveri eba\u00f5nnestumine, k\u00f5vaketta eba\u00f5nnestumine, serveri ajutine k\u00e4ttesaamatus pr\u00fcgikoristuse t\u00f5ttu, paketikaotus v\u00f5i v\u00f5rgu\u00fchenduse aeglustumine. K\u00f5ik need v\u00f5ivad p\u00f5hjustada andmete kaotsimineku v\u00f5i konfliktid. On selge, et on peaaegu v\u00f5imatu luua s\u00fcsteemi, mis oleks korraga t\u00e4ielikult koosk\u00f5las (ilma andmete kaotamiseta, ilma andmete lahknevuseta) ja k\u00e4ttesaadav (ootab lugemis- ja kirjutamise operatsioone) k\u00f5ikide eba\u00f5nnestumise variantide puhul.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nN\u00e4htame, et koosk\u00f5lastatus ja k\u00e4ttesaadavus asuvad spektri eri otsades ning teil tuleb valida, mille suunas optimeerida. Hea uudis on see, et RabbitMQ puhul on selline valik v\u00f5imalik. Teil on teatavad \u00abgeeniuse\u00bb nupud, et tasakaalu suunata suurema koosk\u00f5lastatuse v\u00f5i suurema k\u00e4ttesaadavuse poole.<\/p>\n<p>Eraldi t\u00e4helepanu p\u00f6\u00f6rame sellele, millised konfiguratsioonid viivad andmete kaotamiseni kinnitatud salvestuste t\u00f5ttu. On vastutusketi sidusus pubiisherite, vahendajate ja tarbijate vahel. Kui s\u00f5num on edastatud vahendajale, on tema \u00fclesanne \u2014 mitte s\u00f5numit kaotada. Kui vahendaja kinnitab pubiisherile s\u00f5numi vastuv\u00f5tmist, siis ei oota me, et see kaoks. Kuid n\u00e4eme, et tegelikult v\u00f5ib see juhtuda s\u00f5ltuvalt teie vahendaja ja v\u00e4ljaandja konfiguratsioonist.<\/p>\n<h1>\u00dche s\u00f5lme vastupidavuse primitiivid<\/h1>\n<p><\/p>\n<h3>Vastupidavad j\u00e4rjekorrad\/routimiseks<\/h3>\n<p>\nRabbitMQ-s on kaks t\u00fc\u00fcpi j\u00e4rjekordi: p\u00fcsivad (durable) ja ebap\u00fcsivad (non-durable). K\u00f5ik j\u00e4rjekorrad salvestatakse Mnesia andmebaasi. P\u00fcsivad j\u00e4rjekorrad kuulutatakse uuesti v\u00e4lja s\u00f5lme k\u00e4ivitamisel ja seet\u00f5ttu ellu j\u00e4\u00e4vad need k\u00e4ivitamisest, s\u00fcsteemih\u00e4irest v\u00f5i serverih\u00e4irest (niikaua kuni andmed on salvestatud). See t\u00e4hendab, et seni kuni kuulutate marsruutimise (exchange) ja j\u00e4rjekorra p\u00fcsivaks, tagastatakse j\u00e4rjekordade\/marsruutimise infrastruktuur t\u00f6\u00f6korda.<\/p>\n<p>Ebap\u00fcsivad j\u00e4rjekorrad ja marsruutimine eemaldatakse s\u00f5lme taask\u00e4ivitamisel.<\/p>\n<h3>P\u00fcsivad s\u00f5numid<\/h3>\n<p>\nJuba see, et j\u00e4rjekord on p\u00fcsiv, ei t\u00e4henda, et k\u00f5ik selle s\u00f5numid ellu j\u00e4\u00e4vad s\u00f5lme taask\u00e4ivitamisel. Taask\u00e4ideldud saavad ainult need s\u00f5numid, mille avaldaja on m\u00e4\u00e4ranud <i>p\u00fcsivaks<\/i> (persistent). P\u00fcsivad s\u00f5numid t\u00f5epoolest suurendavad maakleri koormust, kuid kui s\u00f5numi kadu on vastuv\u00f5etamatu, siis pole muud v\u00f5imalust.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/8b8e2de4ef82bf8497960657aac0ddb0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 1. P\u00fcsivuse maatriks<\/i><\/p>\n<h1>Klastrimine peegeldusega j\u00e4rjekorras<\/h1>\n<p>\nKuna me vajame maakleri kaotuse ellu j\u00e4\u00e4miseks \u00fclem\u00e4\u00e4rasust. Saame \u00fchendada mitu RabbitMQ s\u00f5lme klastriks ja seej\u00e4rel lisada t\u00e4iendava \u00fclem\u00e4\u00e4rasuse, kopeerides j\u00e4rjekorrad mitme s\u00f5lme vahel. Nii et kui \u00fcks s\u00f5lm eba\u00f5nnestub, ei kaota me andmeid ja j\u00e4\u00e4me ligip\u00e4\u00e4setavaks. <\/p>\n<p>J\u00e4rjekorra peegelduse:<\/p>\n<ul>\n<li>\u00fches peaj\u00e4rjekorras (master), mis saab k\u00f5ik kirjutamise ja lugemise k\u00e4sud\n<\/li>\n<li>\u00fche v\u00f5i mitme peegli, mis saavad k\u00f5ik s\u00f5numid ja metaandmed peaj\u00e4rjekorrast. Need peeglid eksisteerivad mitte skaleerimiseks, vaid ainult \u00fclem\u00e4\u00e4rasuse t\u00f5ttu.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/35f3d4bdc4f5e10da0e40eb91c5d8280.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 2. J\u00e4rjekorra peegelduse seadistamine<\/i><\/p>\n<p>Peegelduse seadistamine toimub vastava poliitika kaudu. Selles saab valida kopeerimise m\u00e4\u00e4ra ja isegi s\u00f5lmed, kus j\u00e4rjekord peaks asuma. N\u00e4ited:<\/p>\n<ul>\n<li><code>ha-mode: all<\/code>\n<\/li>\n<li><code>ha-mode: exactly, ha-params: 2<\/code> (\u00fcks master ja \u00fcks peegel)\n<\/li>\n<li><code>ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2<\/code><\/li>\n<\/ul>\n<p><\/p>\n<h1>Kinnitamine avaldajale<\/h1>\n<p>\nJ\u00e4rjepideva salvestuse saavutamiseks on vajalikud kinnitused v\u00e4ljastajalt (Publisher Confirms). Ilma nendeta on s\u00f5numite kadumise oht. Kinnitus saadetakse v\u00e4ljastajale p\u00e4rast s\u00f5numi salvestamist kettale. RabbitMQ salvestab s\u00f5numeid kettale mitte vastuv\u00f5tmise hetkel, vaid perioodiliselt, vahemikus mitusada millisekundit. Kui j\u00e4rjekord on peegeldatud, saadetakse kinnitus ainult siis, kui k\u00f5ik peeglid on samuti salvestanud oma koopia s\u00f5numist kettale. See t\u00e4hendab, et kinnituste kasutamine lisab viivitust, kuid kui andmete turvalisus on oluline, on need vajalikud.<\/p>\n<h1>Vastupidav j\u00e4rjekord<\/h1>\n<p>\nKui vahendaja l\u00f5petab t\u00f6\u00f6 v\u00f5i kukub kokku, siis k\u00f5ik peamised j\u00e4rjekorrad (meistrid) sellel s\u00f5lmel kukuvad koos temaga. Siis valib klaster igast meistrist k\u00f5ige vanema peegli ja edendab selle uueks meistriks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/8d8227c00643f35e0dc752b6617e18fb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 3. Mitmed peegeldatud j\u00e4rjekorrad ja nende poliitikad<\/i><\/p>\n<p>Vahendaja 3 kukub kokku. Pange t\u00e4hele, et J\u00e4rjekorra C peegel Vahendaja 2-l t\u00f5useb meistriks. Samuti tehke t\u00e4hele, et J\u00e4rjekorra C jaoks on loodud uus peegel Vahendaja 1-l. RabbitMQ p\u00fc\u00fcab alati s\u00e4ilitada teie poliitikates m\u00e4\u00e4ratud replikatsiooni suhet.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/d08b3ada22e79686d448714f7bab009a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 4. Vahendaja 3 kukub kokku, mis p\u00f5hjustab J\u00e4rjekorra C eba\u00f5nnestumise<\/i> <\/p>\n<p>Kukub j\u00e4rgmine Vahendaja 1! Meil on j\u00e4\u00e4nud ainult \u00fcks vahendaja. J\u00e4rjekorra B peegel t\u00f5useb meistriks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/dcc1d542c40c441194fd07e51046c619.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 5<\/i><\/p>\n<p>Me oleme taastanud Vahendaja 1. Olenemata sellest, kui edukalt andmed \u00fcle elasid vahendaja kadumise ja taastumise, visatakse k\u00f5ik peegeldatud s\u00f5numid j\u00e4rjekorrast k\u00e4ivitamisel minema. See on oluline m\u00e4rkida, kuna see toob kaasa tagaj\u00e4rjed. K\u00f5ige peagi k\u00e4sitleme neid tagaj\u00e4rgi. Nii on Vahendaja 1 n\u00fc\u00fcd taas klastris, ja klaster p\u00fc\u00fcab j\u00e4rgida poliitikaid ning seet\u00f5ttu loob peegleid Vahendaja 1-l.<\/p>\n<p>Sellisel juhul oli Vahendaja 1 kadu t\u00e4ielik, nagu ka andmete kadu, seega on peegeldamata J\u00e4rjekord B t\u00e4ielikult kadunud.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/7ac7ab65ea6dff9c5a49372c04c83a37.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 6. Vahendaja 1 naaseb teenistusse<\/i><\/p>\n<p>Broker 3 on taas aktiivne, seega saavad j\u00e4rjekorrad A ja B tagasi loodud peeglid, et rahuldada oma HA poliitikaid. Kuid n\u00fc\u00fcd asuvad k\u00f5ik peaj\u00e4rjekorrad \u00fchel s\u00f5lmendel! See pole ideaalne, parem oleks \u00fchtlane jaotus s\u00f5lmede vahel. Kahjuks ei ole siin mingeid erilisi v\u00f5imalusi meistrite \u00fcmberjaotamiseks. Naaseme selle probleemiga hiljem, sest esmalt tuleb vaadata j\u00e4rjekorra s\u00fcnkroniseerimist. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/a54e53bb01e2f830a54f88acaa668984.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 7. Broker 3 naaseb teenistusse. K\u00f5ik peaj\u00e4rjekorrad \u00fchel s\u00f5lmendel!<\/i><\/p>\n<p>Nii et teil peaks n\u00fc\u00fcd olema arusaam, kuidas peeglid tagavad \u00fclem\u00e4\u00e4rasuse ja t\u00f5rkekindluse. See tagab k\u00e4ttesaadavuse, kui \u00fcks s\u00f5lm langeb ja kaitseb andmete kadumise eest. Aga me pole veel l\u00f5petanud, sest tegelikult on k\u00f5ik palju keerulisem.<\/p>\n<h1>S\u00fcnkroniseerimine<\/h1>\n<p>\nUue peegli loomisel replikatakse k\u00f5ik uued s\u00f5numid alati sellele peeglile ja muudele. Mis puutub olemasolevaid andmeid peaj\u00e4rjekorras, saame need replikeerida uude peeglisse, mis muutub meistri t\u00e4iskoopiaks. Samuti v\u00f5ime mitte replikeerida olemasolevaid s\u00f5numeid ja lasta peaj\u00e4rjekorral ja uuel peeglil aja jooksul kokku tulla, kui uued s\u00f5numid sisenevad sabasse ja olemasolevad s\u00f5numid lahkuvad peaj\u00e4rjekorra algusest.<\/p>\n<p>Selline s\u00fcnkroniseerimine toimub automaatselt v\u00f5i k\u00e4sitsi ja seda hallatakse j\u00e4rjekorra poliitika abil. Vaatame n\u00e4idet.<\/p>\n<p>Meil on kaks peegeldatud j\u00e4rjekorda. J\u00e4rjekord A s\u00fcnkroniseeritakse automaatselt, samas kui j\u00e4rjekord B k\u00e4sitsi. M\u00f5lemas j\u00e4rjekorras on k\u00fcmme s\u00f5numit.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/304f2a475fdd0cb6d3069140c667a0a7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 8. Kaks j\u00e4rjekorda erinevate s\u00fcnkroniseerimisre\u017eiimidega<\/i><\/p>\n<p>N\u00fc\u00fcd kaotame Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/49114966f440c407488bb467ff6dbf93.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 9. Broker 3 kukkus<\/i><\/p>\n<p>Broker 3 naaseb teenistusse. Klaster loob igale j\u00e4rjekorrale uue peegli uuel s\u00f5lmendel ja s\u00fcnkroniseerib automaatselt uue J\u00e4rjekorra A meistriga. Kuid uue J\u00e4rjekorra B peegel j\u00e4\u00e4b tyhjaks. Seega on meil t\u00e4ielik \u00fcleliigsus J\u00e4rjekorras A ja ainult \u00fcks peegel olemasolevate s\u00f5numite jaoks J\u00e4rjekorras B.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/adffc1f5eff8806edbd83772f338d67f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 10. Uus peegel J\u00e4rjekorras A saab k\u00f5ik olemasolevad s\u00f5numid, kuid uus peegel J\u00e4rjekorras B ei saa.<\/i><\/p>\n<p>M\u00f5lemasse j\u00e4rjekorda tuleb veel k\u00fcmme teadet. Siis kukub Broker 2 ja J\u00e4rjekord A p\u00f6\u00f6rab tagasi k\u00f5ige vanemale peegeldisele, mis asub Broker 1-l. Rikkumise korral andmeid ei kaotata. J\u00e4rjekorras B on kaksk\u00fcmmend teadet isikus ja ainult k\u00fcmme peegelduses, kuna see j\u00e4rjekord ei ole kunagi algset k\u00fcmmet teadet replikoinud.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/c6cfef4bced5627bf243c2f020a42646.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 11. J\u00e4rjekord A p\u00f6\u00f6rdub tagasi Broker 1-le ilma teadete kaotamiseta<\/i><\/p>\n<p>M\u00f5lemasse j\u00e4rjekorda tuleb veel k\u00fcmme teadet. N\u00fc\u00fcd kukub Broker 1. J\u00e4rjekord A \u00fcmberl\u00fclitub probleemideta peegeldisele ilma teadete kaotamiseta. Siiski on J\u00e4rjekorras B probleeme. Sel hetkel saame optimeerida kas k\u00e4ttesaadavust v\u00f5i j\u00e4rjepidevust. <\/p>\n<p>Kui soovime optimeerida k\u00e4ttesaadavust, siis seadke poliitika <b><i>ha-promote-on-failure<\/i><\/b> asetamiseks peaks olema <b><i>always<\/i><\/b>. See on vaikimisi v\u00e4\u00e4rtus, seega v\u00f5ib poliitikat lihtsalt mitte m\u00e4\u00e4rata. Sel juhul laseme tegelikult esineda t\u00f5rkeid s\u00fcnkroniseerimata peegeldistes. See toob kaasa teadete kaotuse, kuid j\u00e4rjekord j\u00e4\u00e4b lugemiseks ja kirjutamiseks k\u00e4ttesaadavaks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/cd704cf4397184c212e1576b986abbaa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 12. J\u00e4rjekord A p\u00f6\u00f6rdub Broker 3-le ilma teadete kaotamiseta. J\u00e4rjekord B p\u00f6\u00f6rdub Broker 3-le, kaotades k\u00fcmme teadet<\/i><\/p>\n<p>Saame ka seadistada <code>ha-promote-on-failure<\/code> v\u00e4\u00e4rtuseks <code>when-synced<\/code>. Sel juhul ootab j\u00e4rjekord peegeldisele tagasip\u00f6\u00f6rdumist Broker 1-l koos tema andmetega. P\u00e4rast tema tagasitulekut on peamine j\u00e4rjekord taas Broker 1-l ilma andmete kaotamiseta. K\u00e4ttesaadavuse nimel on ohutus ohverdatud. Kuid see on riskantne re\u017eiim, mis v\u00f5ib isegi kaasa tuua t\u00e4ieliku andmete kaotuse, mida me peagi vaatame.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/03fed936fe75220e22f68432ca81b654.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 13. J\u00e4rjekord B j\u00e4\u00e4b p\u00e4rast Broker 1 kaotust k\u00e4ttesaamatuks<\/i><\/p>\n<p>V\u00f5ite esitada k\u00fcsimuse: \"Kas v\u00f5ib-olla pole parem kunagi automaatset s\u00fcnkroonimist kasutada?\" Vastus on see, et s\u00fcnkroonimine on blokeeriv operatsioon. S\u00fcnkroonimise ajal ei saa peamine j\u00e4rjekord teha mingeid lugemis- v\u00f5i kirjutamist\u00f6id!<\/p>\n<p>Vaatame n\u00e4iteks. Praegu on meil v\u00e4ga suured j\u00e4rjekorrad. Kuidas need saavad kasvada nii suurteks? M\u00f5ne p\u00f5hjuse t\u00f5ttu:<\/p>\n<ul>\n<li>J\u00e4rjekordi ei kasutata aktiivselt\n<\/li>\n<li>Need on k\u00f5rge kiirusj\u00e4rjekorrad ja praegu t\u00f6\u00f6tavad tarbijad aeglaselt \n<\/li>\n<li>Need on k\u00f5rge kiirusj\u00e4rjekorrad, esines t\u00f5rge ja tarbijad j\u00f5uavad j\u00e4rjele<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/dd4b0fd70cbbc0b7defc06536157770d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 14. Kaks suurt j\u00e4rjekorda erinevate s\u00fcnkroonimisre\u017eiimidega<\/i><\/p>\n<p>N\u00fc\u00fcd kukub Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/8c31cfdf485ab4c9dfe13e86a151df4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 15. Broker 3 kukub, j\u00e4ttes igasse j\u00e4rjekorda \u00fche meistri ja peegli<\/i><\/p>\n<p>Broker 3 taastub ja luuakse uued peeglid. Peamine J\u00e4rjekord A hakkab olemasolevaid s\u00f5numeid uuele peeglile replikeerima, ja selle aja jooksul on j\u00e4rjekord saadaval. Andmete replikeerimiseks on vajalik kaks tundi, mis toob kaasa kahe tunni seisaku selle j\u00e4rjekorra jaoks!<\/p>\n<p>Kuid J\u00e4rjekord B j\u00e4\u00e4b kogu selle aja jooksul saadavaks. Ta ohverdas osa liigsetest ressurssidest saadavuse nimel.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/28e641300a1c3f4d70e29a16db51521e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 16. J\u00e4rjekord j\u00e4\u00e4b s\u00fcnkroonimise ajal saadavaks<\/i><\/p>\n<p>Kaks tundi hiljem on J\u00e4rjekord A samuti taas saadaval ja v\u00f5ib uuesti alustada lugemise ja kirjutamise toimingutega.<\/p>\n<h3>Uuendused<\/h3>\n<p>\nSelline blokeeriv k\u00e4itumine s\u00fcnkroonimise ajal raskendab klastrite v\u00e4rskendamist v\u00e4ga suurte j\u00e4rjekordadega. \u00dches etapis tuleb meistriga s\u00f5lm taask\u00e4ivitada, mis t\u00e4hendab kas peeglisse \u00fcleminekut v\u00f5i j\u00e4rjekorra v\u00e4ljal\u00fclitamist serveri v\u00e4rskendamise ajal. Kui valime \u00fclemineku, kaotame s\u00f5numid, kui peeglid ei ole s\u00fcnkroniseeritud. Vaikimisi ei tehta v\u00e4ljal\u00fclitatava brokera puhul \u00fcleminekut mitte-s\u00fcnkroniseeritud peeglisse. See t\u00e4hendab, et niipea kui broker taastub, ei kaota me \u00fchtegi s\u00f5numit, ainus kahju oli j\u00e4rjekorra seiskamine. Brokera v\u00e4ljal\u00fclitamise k\u00e4itumise reeglid m\u00e4\u00e4ratakse poliitika kaudu <code>ha-promote-on-shutdown<\/code>. Saate seada \u00fche kahest v\u00e4\u00e4rtusest:<\/p>\n<ul>\n<li><code>always<\/code>= s\u00fcnkroniseerimata peeglitele \u00fcleminek on lubatud\n<\/li>\n<li><code>when-synced<\/code>= \u00fcleminek ainult s\u00fcnkroniseeritud peeglile, vastasel juhul j\u00e4rjekord ei ole saadaval lugemiseks ja kirjutamiseks. J\u00e4rjekord taastub, niipea kui broker naaseb<\/li>\n<\/ul>\n<p>\nIgal juhul tuleb suurte j\u00e4rjekordade puhul valida andmete kadumise ja saadavuse vahel.<\/p>\n<h3>Kui saadavus suurendab andmete turvalisust<\/h3>\n<p>\nEnne otsuse tegemist tuleb arvesse v\u00f5tta veel \u00fcks keeruline aspekt. Kuigi automaatne s\u00fcnkroonimine on parem liigsete ressursside puhul, kuidas see m\u00f5jutab andmete turvalisust? Loomulikult on parema liigsetega RabbitMQ-l v\u00e4iksem t\u00f5en\u00e4osus olemasolevate s\u00f5numite kaotada, kuid kuidas on uute s\u00f5numitega, mis saadetakse avaldajatelt?<\/p>\n<p>Siin tuleb arvesse v\u00f5tta j\u00e4rgmist:<\/p>\n<ul>\n<li>Kas v\u00f5ib publisher lihtsalt veateate tagasi saata, ja \u00fclemine teenistus v\u00f5i kasutaja proovivad 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 publisher suudab ainult s\u00f5numi tagasi l\u00fckata, siis parandab ligip\u00e4\u00e4setavuse suurendamine ka andmete turvalisust.<\/p>\n<p>Seega tuleb leida tasakaal ning lahendus s\u00f5ltub konkreetsest olukorrast.<\/p>\n<h1>Probleemid ha-promote-on-failure=when-synced<\/h1>\n<p>\nIdee <i><b>ha-promote-on-failure<\/b><\/i>= <i><b>when-synced<\/b><\/i> on selles, et me takistame \u00fcleminekuid s\u00fcnkroniseerimata peeglitele ja seel\u00e4bi v\u00e4ltida andmete kadumist. Quee j\u00e4\u00e4b lugemiseks v\u00f5i kirjutamiseks k\u00e4ttesaamatuks. Selle asemel proovime taastada kukkunud brokori puutumatute andmetega, et see suudaks j\u00e4tkata t\u00f6\u00f6d peamina ilma andmete kadumiseta. <\/p>\n<p>Aga (ja see on suur aga) kui brokori andmed on kadunud, siis on meil suur probleem: j\u00e4rjekord on kadunud! K\u00f5ik andmed on kadunud! Isegi kui teil on peeglid, mis enamasti j\u00f5uavad peaj\u00e4rjekorrale j\u00e4rele, visatakse need peeglid samuti v\u00e4lja.<\/p>\n<p>Kuna soovime sama nimega s\u00f5lme uuesti lisada, k\u00e4sime klastril unustada kadunud s\u00f5lm (k\u00e4sk <i>rabbitmqctl forget_cluster_node<\/i>) ja k\u00e4ivitame uue brokori sama hostinimega. Niikauaks, kui klaster m\u00e4letab kadunud s\u00f5lme, m\u00e4letab see vana j\u00e4rjekorda ja s\u00fcnkroniseerimata peegleid. Kui klastrile \u00f6eldakse unustada kadunud s\u00f5lm, unustatakse ka see j\u00e4rjekord. N\u00fc\u00fcd tuleb see uuesti v\u00e4lja kuulutada. Oleme kaotanud k\u00f5ik andmed, kuigi meil olid peeglid osalise andmekogumiga. Oleks parem minna \u00fcle s\u00fcnkroniseerimata peeglile!<\/p>\n<p>Seet\u00f5ttu on k\u00e4sitsi s\u00fcnkroniseerimine (ja s\u00fcnkroniseerimise mitteteostamine) koos <code>ha-promote-on-failure=when-synced<\/code>, minu arvates \u00fcsna riskantne. Dokumendid \u00fctlevad, et selline valik eksisteerib andmete turvalisuse nimel, kuid see on kahepoolselt terav nuga.<\/p>\n<h1>Meistrite \u00fcmberbalanseerimine<\/h1>\n<p>\nNagu lubatud, naaseme probleemi juurde, et k\u00f5ik meistrid on koondunud \u00fchele v\u00f5i mitmele s\u00f5lmele. See v\u00f5ib juhtuda isegi 'libiseva' (rolling) klastri v\u00e4rskendamise t\u00f5ttu. Kolme s\u00f5lmega klastris koonduvad k\u00f5ik peaj\u00e4rjekorrad \u00fchele v\u00f5i kahele s\u00f5lmele.<\/p>\n<p>Meistrite \u00fcmberbalanseerimine v\u00f5ib osutuda keeruliseks kahel p\u00f5hjusel:<\/p>\n<ul>\n<li>Heade t\u00f6\u00f6riistade puudumine \u00fcmberbalanseerimise teostamiseks<\/li>\n<li>J\u00e4rjekordade s\u00fcnkroniseerimine<\/li>\n<\/ul>\n<p>\n\u00dcmberbalanseerimiseks on kolmanda osapoole <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Ayanda-D\/rabbitmq-queue-master-balancer\">plugin<\/a><\/noindex>, mida ametlikult ei toetata. RabbitMQ juhendis mainitakse kolmandate osapoolte pluginaid. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.rabbitmq.com\/upgrade.html\">\u00f6eldakse<\/a><\/noindex>: \u00abPlugin pakub m\u00f5ned lisavahendid seadistamiseks ja aruandluseks, kuid ei ole RabbitMQ meeskonna poolt toetatud ega kontrollitud. Kasutada oma riskil\u00bb.<\/p>\n<p>On veel \u00fcks nipp, et liigutada peamine j\u00e4rjekord HA poliitikate kaudu. Juhendis mainitakse <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/rabbitmq\/support-tools\/blob\/master\/scripts\/rebalance-queue-masters\">skripti<\/a><\/noindex> selle jaoks. See t\u00f6\u00f6tab j\u00e4rgmiselt:<\/p>\n<ul>\n<li>Eemaldab k\u00f5ik peeglid k\u00f5rgema prioriteediga ajutise poliitika abil kui eksisteeriv HA poliitika.\n<\/li>\n<li>Muudab ajutise HA poliitika nii, et see kasutab 's\u00f5lmed' re\u017eiimi, m\u00e4\u00e4rates s\u00f5lme, kuhu peamine j\u00e4rjekord liigutatakse.\n<\/li>\n<li>S\u00fcnkroniseerib j\u00e4rjekorra sundmigratsiooni teostamiseks.\n<\/li>\n<li>P\u00e4rast migratsiooni l\u00f5petamist eemaldab ajutise poliitika. Kehtima hakkab algne HA poliitika ja luuakse vajalik arv peegleid.<\/li>\n<\/ul>\n<p>\nPuuduseks on see, et selline l\u00e4henemine ei pruugi toimida, kui teil on suured j\u00e4rjekorrad v\u00f5i ranged \u00fcleliigsuse n\u00f5uded.<\/p>\n<p>N\u00fc\u00fcd vaatame, kuidas RabbitMQ klastrid t\u00f6\u00f6tavad v\u00f5rgu jaotustega.<\/p>\n<h1>Sidususe rikkumine<\/h1>\n<p>\nKaasaegse s\u00fcsteemi s\u00f5lmed on omavahel \u00fchendatud v\u00f5rgu\u00fchendustes ning v\u00f5rgu\u00fchendused v\u00f5ivad ja t\u00f5en\u00e4oliselt katkeda. Katkestuste sagedus s\u00f5ltub kohalikust infrastruktuurist v\u00f5i valitud pilve usaldusv\u00e4\u00e4rsusest. Igatahes peavad hajutatud s\u00fcsteemid olema v\u00f5imelised nendega toime tulema. J\u00e4llegi on meil valik k\u00e4ttesaadavuse ja j\u00e4rjepidevuse vahel ning taas on hea uudis see, et RabbitMQ tagab m\u00f5lemad v\u00f5imalused (kuid mitte samaaegselt).<\/p>\n<p>RabbitMQ puhul on meil kaks peamist valikut:<\/p>\n<ul>\n<li>Luba loogiline jaotus (split-brain). See tagab k\u00e4ttesaadavuse, kuid v\u00f5ib p\u00f5hjustada andmekaotust.\n<\/li>\n<li>Keela loogiline jaotus. See v\u00f5ib p\u00f5hjustada l\u00fchiajalist k\u00e4ttesaadavuse kadumist s\u00f5ltuvalt sellest, kuidas kliendid klastrisse \u00fchenduvad. See v\u00f5ib samuti viia kahe s\u00f5lmega klastris t\u00e4ieliku k\u00e4ttesaamatuse.<\/li>\n<\/ul>\n<p>\nAga mis on loogiline jaotus? See on olukord, kui klaster jaguneb kaheks v\u00f5rgu\u00fchenduste kaotuse t\u00f5ttu. Igal pool t\u00f5usevad peeglid meistriks, nii et l\u00f5puks on iga j\u00e4rjekorra puhul mitu meistrit.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/d880a935df450fb994edfed0715e026e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 17. Peamine j\u00e4rjekord ja kaks peeglit, iga\u00fche oma eraldi s\u00f5lmes. Siis tekib v\u00f5rgu katkestus ja \u00fcks peegel eemaldub. Eemaldunud s\u00f5lm n\u00e4eb, et kaks teist on katkenud, ja t\u00f5ukab oma peeglid meistriks. N\u00fc\u00fcd on meil kaks peamist j\u00e4rjekorda, ja m\u00f5lemad lubavad kirjutamist ja lugemist.<\/i> <\/p>\n<p>Kui v\u00e4ljaandjad saadavad andmeid m\u00f5lemale meistrile, saame kaks lahknevat j\u00e4rjekorra koopiat.<\/p>\n<p>Erinevad RabbitMQ re\u017eiimid tagavad kas k\u00e4ttesaadavuse v\u00f5i koosk\u00f5lastatuse.<\/p>\n<h3>Ignoreeri re\u017eiim (vaikimisi)<\/h3>\n<p>\nSee re\u017eiim tagab k\u00e4ttesaadavuse. P\u00e4rast \u00fchenduse kadumist toimub loogiline jaotumine. P\u00e4rast \u00fchenduse taastumist peab administraator otsustama, kummale jaotusele eelisse anda. Kaotav pool taask\u00e4ivitub ja k\u00f5ik selle poole kogunenud andmed kaovad.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/4d82c13b5ef21837ba819f5c246a1e41.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 18. Kolm v\u00e4ljaandjat on seotud kolme maakleri jaotisega. Sisemiselt suunab klaster k\u00f5ik taotlused peamisse j\u00e4rjekorda Maakler 2 juures.<\/i><\/p>\n<p>N\u00fc\u00fcd kaotame Maakleri 3. Ta n\u00e4eb, et teised maaklerid on katkenud, ja t\u00f5ukab oma peegli meistriks. Nii toimub loogiline jaotumine.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/c7e01d51b24023bacdd93cfad95c9eab.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 19. Loogiline jaotumine (split-brain). Kirjad l\u00e4hevad kahte peamisse j\u00e4rjekorda ja kaks koopiat lahknevad.<\/i><\/p>\n<p>\u00dchendus taastatakse, kuid loogiline jaotumine j\u00e4\u00e4b. Administraator peab k\u00e4sitsi valima kaotava poole. Antud juhul taask\u00e4ivitab administraator Maakler 3. Kaovad k\u00f5ik s\u00f5numid, mida ta ei j\u00f5udnud edastada.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/51c3ee15024d3c83ba625e3ff9cdeb90.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 20. Administraator keelab Maakler 3.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/0bac8e33de25c0c5381d336d26464858.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 21. Administraator k\u00e4ivitab Maakler 3, ja ta liitub klastriga, kaotades k\u00f5ik s\u00f5numid, mis seal olid.<\/i><\/p>\n<p>\u00dchenduse kadumise ajal ja p\u00e4rast selle taastumist olid klaster ja see j\u00e4rjekord saadaval lugemiseks ja kirjutamiseks.<\/p>\n<h3>Autoheal re\u017eiim<\/h3>\n<p>\nT\u00f6\u00f6tleb sarnaselt Ignoreeri re\u017eiimile, v\u00e4lja arvatud see, et klaster valib automaatselt kaotava poole p\u00e4rast jaotust ja \u00fchenduse taastamist. Kaotav pool naaseb klastrisse t\u00fchi, ja j\u00e4rjekord kaotab k\u00f5ik s\u00f5numid, mis olid saadetud ainult sellele poolele.<\/p>\n<h3>Pause Minority re\u017eiim<\/h3>\n<p>\nKui me ei soovi j\u00e4tta loogilist l\u00f5het, on meie ainus v\u00f5imalus loobuda lugemisest ja kirjutamisest v\u00e4iksemas osas p\u00e4rast klastrit. Kui maakler n\u00e4eb, et ta on v\u00e4iksemas osas, peatab ta t\u00f6\u00f6, st sulgeb k\u00f5ik olemasolevad \u00fchendused ja loobub igasugustest uutest. Ta kontrollib \u00fchenduse taastumist kord sekundis. Niikaua kui \u00fchendus on taastatud, taastab ta t\u00f6\u00f6 ja liitub klassiga.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/7a51cf509b2c94e2ae100c7dedd9d21a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 22. Kolm publikut on seotud kolme maakleriga. Klastri sees suunatakse k\u00f5ik p\u00e4ringud peaj\u00e4rjekorda Maakler 2-l.<\/i><\/p>\n<p>Seej\u00e4rel lahknevad Maaklerid 1 ja 2 Maaklerist 3. Selle asemel, et oma peeglit meistriks t\u00f5sta, peatab Maakler 3 t\u00f6\u00f6 ja muutub k\u00e4ttesaamatuks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/c12ec38a47e1f8ccceebfa1854f54f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 23. Maakler 3 peatab t\u00f6\u00f6, v\u00e4ljal\u00fclitab k\u00f5ik kliendid ja keeldub \u00fchenduste vastuv\u00f5tmisest.<\/i><\/p>\n<p>Kui \u00fchendus on taastatud, naaseb ta klassi.<\/p>\n<p>Vaadakem teist n\u00e4idet, kus peaj\u00e4rjekord asub Maakler 3-l.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/4cc6a28270f00a280ecb5af5252f4e07.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 24. Peaj\u00e4rjekord Maakler 3-l.<\/i><\/p>\n<p>Seej\u00e4rel toimub sama \u00fchenduse kadumine. Maakler 3 peatub, kuna ta on v\u00e4iksemas osas. Teisel poolel n\u00e4evad s\u00f5lmed, et Maakler 3 on kukkunud, nii et vanem peegel Maakleritest 1 ja 2 t\u00f5stetakse meistriks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/d0d032385533bb53c5a95927afcd3119.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 25. \u00dcleminek Maakler 2-le Maakler 3 puudumise korral.<\/i><\/p>\n<p>Kui \u00fchendus on taastatud, liitub Maakler 3 klassiga.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: k\u00f5rge saadaolevus ja talitlush\u00e4ired klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/53f8186a040ae07724ef59cf79b72a0c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 26. Klastri t\u00f6\u00f6 on taastunud.<\/i><\/p>\n<p>Siin on oluline m\u00f5ista, et saavutame j\u00e4rjepidevuse, kuid saame ka k\u00e4ttesaadavuse. <i><b>kui<\/b><\/i> edukalt suuname kliendid suuremale osale l\u00f5hest. Enamikus olukordades valiksin isiklikult Pause Minority re\u017eiimi, kuid see s\u00f5ltub t\u00f5eliselt konkreetsetest juhtumitest.<\/p>\n<p>K\u00e4ttesaadavuse tagamiseks on oluline veenduda, et kliendid saavad edukalt s\u00f5lmele \u00fchenduda. Vaadakem meie v\u00f5imalusi.<\/p>\n<h1>Kliendi \u00fchenduse tagamine<\/h1>\n<p>\nMeil on mitu v\u00f5imalust, kuidas suunata kliente peamiseks klastriks v\u00f5i toimivatele s\u00f5lmedele p\u00e4rast \u00fchenduse kadu (\u00fcks s\u00f5lm on eba\u00f5nnestunud). Esiteks tuletame meelde, et konkreetne j\u00e4rjekord on paigaldatud teatud s\u00f5lme, kuid marsruutimine ja poliitikad replikeeritakse k\u00f5igil s\u00f5lmedel. Kliendid saavad \u00fchenduda mis tahes s\u00f5lmega ja sisemine marsruutimine suunab nad \u00f5igesse kohta. Kuid kui s\u00f5lm on peatatud, l\u00fckkab see tagasi \u00fchendused, seega peavad kliendid \u00fchenduma teise s\u00f5lmiga. Kui s\u00f5lm on eba\u00f5nnestunud, ei saa ta \u00fcldse midagi teha.<\/p>\n<p>Meie v\u00f5imalused:<\/p>\n<ul>\n<li>Juurdep\u00e4\u00e4s klastrile toimub koormuse tasakaalustaja kaudu, mis lihtsalt ts\u00fckliliselt vahetab s\u00f5lmi, ning kliendid proovivad uuesti \u00fchendust luua kuni edukani. Kui s\u00f5lm ei t\u00f6\u00f6ta v\u00f5i on peatatud, siis \u00fchenduse loomise katsed selle s\u00f5lmega eba\u00f5nnestuvad, kuid j\u00e4rgnevad katsed l\u00e4hevad teistele serveritele (ts\u00fcklilisel viisil). See sobib l\u00fchiajalise \u00fchenduse kadumise v\u00f5i langenud serveri jaoks, mis t\u00f5stetakse kiiresti \u00fcles.\n<\/li>\n<li>Juurdep\u00e4\u00e4s klastrile koormuse tasakaalustaja kaudu ja peatatud\/veel langevate s\u00f5lmede eemaldamine nimekirjast niipea, kui nad avastatakse. Kui seda teha kiiresti ning klientidel on v\u00f5imalus proovida uuesti \u00fchendust luua, saavutame pideva k\u00e4ttesaadavuse.\n<\/li>\n<li>Anda igale kliendile k\u00f5igi s\u00f5lmede nimekiri, ning klient valib \u00fchendamise ajal juhuslikult \u00fche neist. Kui \u00fchenduse loomise katsel ilmneb viga, siirdub ta j\u00e4rgmisele s\u00f5lmele nimekirjas, kuni \u00fchendub.\n<\/li>\n<li>Eemaldada liiklus langenud\/peatatud s\u00f5lmest DNS-i kaudu. See toimub v\u00e4ikese TTL-i kasutamisega.<\/li>\n<\/ul>\n<p><\/p>\n<h1>J\u00e4reldused<\/h1>\n<p>\nRabbitMQ klastril on oma eelised ja puudused. K\u00f5ige t\u00f5sisemad puudused on:<\/p>\n<ul>\n<li>kliendi liitumisel klastriga s\u00f5lmed loobuvad oma andmetest;\n<\/li>\n<li>blokkeeriv s\u00fcnkroniseerimine toob kaasa j\u00e4rjekorra k\u00e4ttesaamatuse.<\/li>\n<\/ul>\n<p>\nK\u00f5ik rasked otsused tulenevad neist kahest arhitektuuri omadusest. Kui RabbitMQ suudaks andmeid hoida klastriga uuesti \u00fchendamisel, toimuks s\u00fcnkroniseerimine kiiremini. Kui see suudaks mitteblokeerivat s\u00fcnkroniseerimist, toetaks see paremini suuri j\u00e4rjekordi. Nende kahe probleemi lahendamine parandaks t\u00f5siselt RabbitMQ j\u00f5udlust usaldusv\u00e4\u00e4rse ja k\u00f5rge k\u00e4ttesaadavuse s\u00f5numitehnoloogiana. Ei soovitaks RabbitMQ-d klastrimise kasutamiseks j\u00e4rgmistel juhtudel:<\/p>\n<ul>\n<li>Ebastabiilne v\u00f5rk.\n<\/li>\n<li>Ebastabiilne salvestus.\n<\/li>\n<li>V\u00e4ga suured j\u00e4rjekorrad.<\/li>\n<\/ul>\n<p>\nK\u00f5rge k\u00e4ttesaadavuse seadistuste osas kaaluge j\u00e4rgmisi:<\/p>\n<ul>\n<li><code>ha-promote-on-failure=always<\/code>\n<\/li>\n<li><code>ha-sync-mode=manual<\/code>\n<\/li>\n<li><code>cluster_partition_handling=ignore<\/code> (v\u00f5i <code>autoheal<\/code>)\n<\/li>\n<li>p\u00fcsivad s\u00f5numid\n<\/li>\n<li>veenduge, et kliendid \u00fchinevad aktiivse s\u00f5lmega, kui mingi s\u00f5lm t\u00f5rkub<\/li>\n<\/ul>\n<p>\nAndmete j\u00e4rjepidevuse (turvalisuse) tagamiseks kaaluge j\u00e4rgmisi seadeid:<\/p>\n<ul>\n<li>Publisher Confirms ja Manual Acknowledgements tarbija poolel\n<\/li>\n<li><code>ha-promote-on-failure=when-synced<\/code>, kui v\u00e4ljaandjad saavad hiljem katsetada ja kui teil on v\u00e4ga usaldusv\u00e4\u00e4rne salvestus! Vastasel juhul seadke <code>=always<\/code>.\n<\/li>\n<li><code>ha-sync-mode=automatic<\/code> (aga suurte mitteaktiivsete j\u00e4rjekordade puhul v\u00f5ib osutuda vajalikuks k\u00e4sitsi re\u017eiim; lisaks m\u00f5elge, kas k\u00e4ttesaamatus v\u00f5ib p\u00f5hjustada s\u00f5numite kadu)\n<\/li>\n<li>Pause Minority re\u017eiim\n<\/li>\n<li>p\u00fcsivad s\u00f5numid<\/li>\n<\/ul>\n<p>\nOleme arutanud veel kaugele mitte j\u00f5udnud usaldusv\u00e4\u00e4rsuse ja k\u00f5rge k\u00e4ttesaadavuse k\u00fcsimusi; n\u00e4iteks, kuidas ohutult l\u00e4bida administratiivseid protseduure (n\u00e4iteks libisev uuendamine). Peaksime arutama ka f\u00f6deratsiooni ja Shovel plugina.<\/p>\n<p>Kui ma veel midagi unustasin, palun andke teada.<\/p>\n<p>Vaadake ka minu <noindex><a rel=\"nofollow\" href=\"https:\/\/jack-vanlightly.com\/blog\/2018\/9\/10\/how-to-lose-messages-on-a-rabbitmq-cluster\">postitus<\/a><\/noindex>, kus viin l\u00e4bi RabbitMQ klastri purustamise Docker'i ja Blockade'iga, et testida m\u00f5ningaid selle artikli s\u00f5numikadumise stsenaariume.<\/p>\n<p>Seeria eelmine artikkel: <br \/>\nNr 1 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/416629\/\">habr.com\/et\/company\/itsumma\/blog\/416629<\/a><\/noindex> <br \/>\nNr 2 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/418389\/\">habr.com\/et\/company\/itsumma\/blog\/418389<\/a><\/noindex> <br \/>\nNr 3 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/437446\/\">habr.com\/et\/company\/itsumma\/blog\/437446<\/a><\/noindex><br \/>\n<br \/>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/471858\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c \u0438 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c \u2014 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0442\u0435\u043c\u044b, \u0442\u0430\u043a \u0447\u0442\u043e \u043f\u043e\u0441\u0432\u044f\u0442\u0438\u043c RabbitMQ \u0438 Kafka \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0435 \u0441\u0442\u0430\u0442\u044c\u0438. \u0414\u0430\u043d\u043d\u0430\u044f \u0441\u0442\u0430\u0442\u044c\u044f \u043e RabbitMQ, \u0430 \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u2014 \u043e Kafka, \u0432 \u0441\u0440\u0430\u0432\u043d\u0435\u043d\u0438\u0438 \u0441 RabbitMQ. \u0421\u0442\u0430\u0442\u044c\u044f \u0434\u043b\u0438\u043d\u043d\u0430\u044f, \u0442\u0430\u043a \u0447\u0442\u043e \u0443\u0441\u0442\u0440\u0430\u0438\u0432\u0430\u0439\u0442\u0435\u0441\u044c \u043f\u043e\u0443\u0434\u043e\u0431\u043d\u0435\u0435. \u0420\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0441\u0442\u0440\u0430\u0442\u0435\u0433\u0438\u0438 \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438, \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u0438 \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u0438 (HA), \u0430 \u0442\u0430\u043a\u0436\u0435 \u043a\u043e\u043c\u043f\u0440\u043e\u043c\u0438\u0441\u0441\u044b, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0438\u0434\u0442\u0438 \u0432 \u043a\u0430\u0436\u0434\u043e\u0439 \u0441\u0442\u0440\u0430\u0442\u0435\u0433\u0438\u0438. RabbitMQ \u043c\u043e\u0436\u0435\u0442 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52525","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\".\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah\" \/>\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 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\".\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-11-09T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:00:16+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47RabbitMQ vs Kafka: usaldusv\u00e4\u00e4rsus ja k\u00f5rge k\u00e4ttesaadavus klastrites | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","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 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 | ProHoster","og:description":".","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-09T21:00:00+00:00","article:modified_time":"2020-02-18T11:00:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52525","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 03:54:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:41:25","updated":"2026-01-24 03:54:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/52525","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=52525"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/52525\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=52525"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=52525"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=52525"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}