{"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: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/d8e584d210a6a016a962ad6f956a2078.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nT\u00f6\u00f6kindlus ja k\u00f5rge saadavus on suured teemad, seega p\u00fchendame RabbitMQ-le ja Kafka-le eraldi artiklid. K\u00e4esolev artikkel k\u00e4sitleb RabbitMQ-d, j\u00e4rgmine aga Kafka-t, v\u00f5rreldes RabbitMQ-ga. Artikkel on pikk, seega tehke end mugavaks.<\/p>\n<p>Vaatame l\u00e4bi t\u00f6\u00f6kindluse, j\u00e4rjepidevuse ja k\u00f5rge saadavuse (HA) strateegiad, samuti kompromissid, millega iga strateegia puhul arvestada tuleb. RabbitMQ v\u00f5ib t\u00f6\u00f6tada klastrite s\u00f5lmedes \u2014 ja seet\u00f5ttu kaalutakse seda jaotatud s\u00fcsteemina. Kui r\u00e4\u00e4gime jaotatud s\u00fcsteemidest, siis mainime sageli j\u00e4rjepidevust ja saadavust. <\/p>\n<p>Needused m\u00f5isted kirjeldavad, kuidas s\u00fcsteem k\u00e4itub rikke korral. V\u00f5rguside katkemine, serveri rike, k\u00f5vaketta rike, serveri ajutine k\u00e4ttesaamatus pr\u00fcgikogumise t\u00f5ttu, pakettide kadumine v\u00f5i v\u00f5rgu\u00fchenduse aeglustumine. K\u00f5ik need v\u00f5ivad p\u00f5hjustada andmekadu v\u00f5i konflikte. Selgub, et on praktiliselt v\u00f5imatu t\u00f5usta s\u00fcsteem, mis oleks samal ajal t\u00e4ielikult j\u00e4rjepidev (ilma andmekadudeta, ilma andmete lahknevusteta) ja k\u00e4tte saadav (v\u00f5tab vastu lugemis- ja kirjutamisoperatsioone) k\u00f5igi rikke variantide korral.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nN\u00e4eme, et j\u00e4rjepidevus ja k\u00e4ttesaadavus on spektri vastasotsades ning peate valima, millises suunas optimeerida. Hea uudis on see, et RabbitMQ puhul on see valik v\u00f5imalik. Teil on sellised \"geeniuse\" nupud, et tasakaalu nihutada suurema j\u00e4rjepidevuse v\u00f5i suurema k\u00e4ttesaadavuse suunas.<\/p>\n<p>Eriti t\u00e4helepanu p\u00f6\u00f6rame sellele, millised konfiguratsioonid v\u00f5ivad p\u00f5hjustada andmete kadumist kinnitatud kirjade t\u00f5ttu. On vastutuse ahel, mis h\u00f5lmab v\u00e4ljaandjaid, vahendajaid ja tarbijaid. P\u00e4rast s\u00f5numi edastamist vahendajale on see tema \u00fclesanne \u2014 mitte s\u00f5numit kaotada. Kui vahendaja kinnitab v\u00e4ljaandjale s\u00f5numi saamist, ei oota me, et see kaoks. Kuid me n\u00e4eme, et see v\u00f5ib t\u00f5eliselt juhtuda, s\u00f5ltuvalt teie vahendaja ja v\u00e4ljaandja konfiguratsioonist.<\/p>\n<h1>\u00dche s\u00f5lme vastupidavuse primitiivid<\/h1>\n<p><\/p>\n<h3>P\u00fcsivad j\u00e4rjekorrad\/routing<\/h3>\n<p>\nRabbitMQ-s on kaks t\u00fc\u00fcpi j\u00e4rjekorda: pikaajalised\/p\u00fcsivad (durable) ja mitte-p\u00fcsivad (non-durable). K\u00f5ik j\u00e4rjekorrad salvestatakse Mnesia andmebaasi. P\u00fcsivad j\u00e4rjekorrad kuulutatakse uuesti v\u00e4lja s\u00f5lme k\u00e4ivitamisel ja seega ellu j\u00e4\u00e4vad s\u00fcsteemi taask\u00e4ivitamisel, rikkena v\u00f5i serveri krahhi korral (niikaua kui andmed s\u00e4ilivad). See t\u00e4hendab, et seni, kuni deklareerite routing (exchange) ja j\u00e4rjekorra p\u00fcsivana, tagastab j\u00e4rjekordade\/routing infrastruktuur t\u00f6\u00f6re\u017eiimi.<\/p>\n<p>Mittep\u00fcsivad j\u00e4rjekorrad ja routing eemaldatakse s\u00f5lme taask\u00e4ivitamisel.<\/p>\n<h3>P\u00fcsivad s\u00f5numid<\/h3>\n<p>\nLihtsalt 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, mis on publeerija poolt m\u00e4\u00e4ratud <i>p\u00fcsivaks<\/i> (p\u00fcsiv). P\u00fcsivad s\u00f5numid t\u00f5epoolest loovad lisakoormuse edastuskeskusele, kuid kui s\u00f5numi kaotus ei ole vastuv\u00f5etav, ei ole muud v\u00f5imalust.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/8b8e2de4ef82bf8497960657aac0ddb0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 1. P\u00fcsivuse maatriks<\/i><\/p>\n<h1>J\u00e4rjekorra peegeldamine r\u00fchmitatult<\/h1>\n<p>\nKuna me vajame andmeedastuse s\u00e4ilitamiseks \u00fclem\u00e4\u00e4rasust. Saame liita mitu RabbitMQ s\u00f5lme klastrisse ja seej\u00e4rel lisada t\u00e4iendava \u00fclem\u00e4\u00e4rasuse, kopeerides j\u00e4rjekorrad mitme s\u00f5lme vahel. Nii, kui \u00fcks s\u00f5lm peaks kokku kukkuma, ei kaota me andmeid ja j\u00e4\u00e4me k\u00e4ttesaadavaks. <\/p>\n<p>J\u00e4rjekorra peegeldamine:<\/p>\n<ul>\n<li>\u00fcks peamine j\u00e4rjekord (meister), mis saab k\u00f5ik kirjutamise ja lugemise k\u00e4sud\n<\/li>\n<li>\u00fcks v\u00f5i mitu peeglit, mis saavad k\u00f5ik s\u00f5numid ja metaandmed peamisest j\u00e4rjekorrast. Need peeglid ei eksisteeri skaleerimiseks, vaid ainult \u00fclem\u00e4\u00e4rasuse tagamiseks.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/35f3d4bdc4f5e10da0e40eb91c5d8280.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 2. J\u00e4rjekorra peegeldamine<\/i><\/p>\n<p>Peegeldamine kehtib vastava poliitika alusel. Seal saab valida replikatsiooni koefitsiendi ja isegi s\u00f5lmed, millel j\u00e4rjekord peab asuma. N\u00e4ited:<\/p>\n<ul>\n<li><code>ha-mode: all<\/code>\n<\/li>\n<li><code>ha-re\u017eiim: t\u00e4pselt, ha-parameetrid: 2<\/code> (\u00fcks meister ja \u00fcks peegel)\n<\/li>\n<li><code>ha-re\u017eiim: s\u00f5lmed, ha-parameetrid: rabbit@node1, rabbit@node2<\/code><\/li>\n<\/ul>\n<p><\/p>\n<h1>Kinnitamine v\u00e4ljaandjale<\/h1>\n<p>\nJ\u00e4rjepideva salvestamise saavutamiseks on vajalikud kinnitused v\u00e4ljaandjale (Publisher Confirms). Ilma nendeta on s\u00f5numite kadumise oht. Kinnitus saadetakse v\u00e4ljaandjale p\u00e4rast s\u00f5numi plaadile salvestamist. RabbitMQ salvestab s\u00f5numid plaadile mitte nende saamisel, vaid perioodiliselt, m\u00f5ne saja millisekundi p\u00e4rast. Kui j\u00e4rjekord peegeldatakse, saadetakse kinnitus alles p\u00e4rast seda, kui k\u00f5ik peeglid on samuti salvestanud oma koopia s\u00f5numist plaadile. See t\u00e4hendab, et kinnituste kasutamine toob juurde viivituse, 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, k\u00f5ik esmased j\u00e4rjekorrad (meistrid) sellel s\u00f5lmel lakkavad t\u00f6\u00f6tamast koos sellega. Seej\u00e4rel valib klaster iga meistri k\u00f5ige vanema peegli ja edendab selle uueks meistriks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/8d8227c00643f35e0dc752b6617e18fb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 3. Mitme peegeldatud j\u00e4rjekorra ja nende poliitikad<\/i><\/p>\n<p>Brokker 3 kukkub. Pange t\u00e4hele, et j\u00e4rjekorra C peegel t\u00f5useb brokker 2-l meistriks. Samuti m\u00e4rkige, et j\u00e4rjekorra C jaoks on loodud uus peegel brokker 1-l. RabbitMQ p\u00fc\u00fcab alati s\u00e4ilitada replikatsiooni suhet, nagu on m\u00e4\u00e4ratletud teie poliitikates.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/d08b3ada22e79686d448714f7bab009a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 4. Brokker 3 laguneb, mis p\u00f5hjustab j\u00e4rjekorra C seiskumise<\/i> <\/p>\n<p>J\u00e4rgmine brokker 1 kukub! Meil on j\u00e4\u00e4nud ainult \u00fcks brokker. J\u00e4rjekorra B peegel t\u00f5useb meistriks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/dcc1d542c40c441194fd07e51046c619.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 5<\/i><\/p>\n<p>Me oleme brokker 1 tagasi saanud. Olenemata sellest, kui edukalt andmed ellu j\u00e4\u00e4vad brokkeri kadumise ja taastumise korral, loob k\u00f5ik peegeldatud s\u00f5numid j\u00e4rjekorras k\u00e4ivitamisel. On oluline see m\u00e4rkida, kuna sellel on tagaj\u00e4rjed. Peagi vaatame neid tagaj\u00e4rgi. Seega on brokker 1 n\u00fc\u00fcd uuesti klastrisse kuuluja, ja klaster p\u00fc\u00fcab j\u00e4rgida poliitikaid, mist\u00f5ttu loob see peegleid brokker 1-l.<\/p>\n<p>Sel juhul oli brokker 1 kadumine t\u00e4ielik, samuti andmete suremine, mist\u00f5ttu on peegeldamata j\u00e4rjekord B t\u00e4ielikult kadunud.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/7ac7ab65ea6dff9c5a49372c04c83a37.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 6. Brokker 1 naaseb teenistusse<\/i><\/p>\n<p>Brokker 3 on taastatud, nii et j\u00e4rjekorrad A ja B saavad tagasi loodud peegelid, et rahuldada oma HA poliitikaid. Kuid n\u00fc\u00fcd on k\u00f5ik peamised j\u00e4rjekorrad \u00fchel s\u00f5lmel! See pole ideaalne, parem oleks \u00fchtlane jaotumine s\u00f5lmede vahel. Kahjuks ei ole siin erilisi v\u00f5imalusi meisterde \u00fcmberjaotamiseks. Tagasi selle probleemi juurde hiljem, kuna esmalt tuleb k\u00e4sitleda j\u00e4rjekorra s\u00fcnkroniseerimist. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/a54e53bb01e2f830a54f88acaa668984.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 7. Brokker 3 naaseb t\u00f6\u00f6le. K\u00f5ik peamised j\u00e4rjekorrad \u00fchel s\u00f5lmel!<\/i><\/p>\n<p>Nii et n\u00fc\u00fcd peaks teil olema ettekujutus sellest, kuidas peeglid tagavad \u00fcleliigsuse ja talitlush\u00e4ired. See tagab k\u00e4ttesaadavuse \u00fche s\u00f5lme rikete korral ja kaitseb andmete kadumise eest. Kuid 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 k\u00f5ikidele teistele. Mis puudutab olemasolevaid andmeid peamiselt j\u00e4rjekorras, saame need replikeerida uuele peeglile, mis muutub t\u00e4ielikuks koopiaks p\u00f5hiversioonist. Samuti v\u00f5ime mitte replikeerida olemasolevaid s\u00f5numeid ja lasta peamisel j\u00e4rjekorral ja uuel peeglil ajas \u00fchtida, kui uued s\u00f5numid liiguvad sabasse ja olemasolevad s\u00f5numid v\u00e4ljuvad peamise j\u00e4rjekorra peast.<\/p>\n<p>Selline s\u00fcnkroonimine toimub automaatselt v\u00f5i k\u00e4sitsi ning seda juhitakse j\u00e4rjekordade poliitika kaudu. Vaatame n\u00e4idet.<\/p>\n<p>Meil on kaks peegeldatud j\u00e4rjekorda. J\u00e4rjekord A s\u00fcnkroonitakse automaatselt, ja J\u00e4rjekord B \u2013 k\u00e4sitsi. M\u00f5lemas j\u00e4rjekorras on k\u00fcmme s\u00f5numit.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus 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\u00fcnkroonimisre\u017eiimidega<\/i><\/p>\n<p>N\u00fc\u00fcd kaotame Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus 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>Brokker 3 naaseb t\u00f6\u00f6le. Klasster loob iga j\u00e4rjekorra jaoks peegli uuel s\u00f5lmel ja s\u00fcnkroniseerib automaatselt uue J\u00e4rjekorra A meistriga. Siiski j\u00e4\u00e4b uue J\u00e4rjekorra B peegel t\u00fchjaks. Seega on meil t\u00e4ielik \u00fclekattuvus J\u00e4rjekorra A jaoks ja ainult \u00fcks peegel olemasolevate s\u00f5numite jaoks J\u00e4rjekorras B.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/adffc1f5eff8806edbd83772f338d67f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 10. Uus J\u00e4rjekorra A peegel saab k\u00f5ik olemasolevad s\u00f5numid, kuid uus J\u00e4rjekorra B peegel ei saa.<\/i><\/p>\n<p>M\u00f5lemasse j\u00e4rjekorda j\u00f5uab veel k\u00fcmme s\u00f5numit. Seej\u00e4rel langeb Brokker 2 ja J\u00e4rjekord A naaseb oma vanimale peeglile, mis asub Brokker 1-l. Rikkega ei toimu andmete kadu. J\u00e4rjekorras B on meistris kaksk\u00fcmmend s\u00f5numit ja peeglis ainult k\u00fcmme, kuna see j\u00e4rjekord ei ole kunagi replitseerinud algseid k\u00fcmmet s\u00f5numit.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/c6cfef4bced5627bf243c2f020a42646.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 11. J\u00e4rjekord A naaseb Brokker 1-le ilma s\u00f5numite kadumiseta.<\/i><\/p>\n<p>M\u00f5lemasse j\u00e4rjekorda j\u00f5uab veel k\u00fcmme s\u00f5numit. N\u00fc\u00fcd kukub Brokker 1. J\u00e4rjekord A vahetab probleemideta peegli \u00fcle ilma s\u00f5numite kadumiseta. Siiski on J\u00e4rjekorra B-l probleeme. Sel hetkel saame optimeerida kas k\u00e4ttesaadavust v\u00f5i koosk\u00f5la. <\/p>\n<p>Kui soovime optimeerida k\u00e4ttesaadavust, siis peaks poliitika <b><i>ha-promote-on-failure<\/i><\/b> olema seadistatud <b><i>always<\/i><\/b>. See on vaikimisi v\u00e4\u00e4rtus, seega v\u00f5ib poliitikat \u00fcldse mitte m\u00e4rkida. Sellisel juhul lubame eba\u00f5nnestumisi s\u00fcnkroonimata peegeldustes. See toob kaasa s\u00f5numite kaotuse, kuid j\u00e4rjekord j\u00e4\u00e4b lugemiseks ja kirjutamiseks k\u00e4ttesaadavaks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/cd704cf4397184c212e1576b986abbaa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 12. J\u00e4rjekord A tagastatakse Broker 3-le ilma s\u00f5numite kaotuseta. J\u00e4rjekord B tagastatakse Broker 3-le, kaotades k\u00fcmme s\u00f5numit.<\/i><\/p>\n<p>Saame ka seadistada <code>ha-promote-on-failure<\/code> v\u00e4\u00e4rtuse <code>when-synced<\/code>. Sel juhul ei tagastata j\u00e4rjekorda peegeldusse, vaid j\u00e4rjekord ootab, kuni Broker 1 oma andmetega tagasi operatiivre\u017eiimi j\u00f5uab. P\u00e4rast selle tagasij\u00f5udmist asub peamine j\u00e4rjekord uuesti Broker 1-le ilma andmete kaotuseta. K\u00e4ttesaadavus toob andmete turvalisuse ohvriks. Kuid see on riskantne re\u017eiim, mis v\u00f5ib isegi t\u00e4ieliku andmekao p\u00f5hjustada, millest r\u00e4\u00e4gime varsti.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/03fed936fe75220e22f68432ca81b654.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 13. J\u00e4rjekord B j\u00e4\u00e4b p\u00e4rast Broker 1 kaotust k\u00e4ttesaamatuks.<\/i><\/p>\n<p>V\u00f5ite k\u00fcsida: \u00abKas automaatset s\u00fcnkroniseerimist peaks kunagi kasutama?\u00bb. Vastus on see, et s\u00fcnkroniseerimine on blokeeriv operatsioon. S\u00fcnkroniseerimise ajal ei saa peamine j\u00e4rjekord teha mingeid lugemis- v\u00f5i kirjutamisoperatsioone!<\/p>\n<p>Vaatame n\u00e4idet. Praegu on meil v\u00e4ga suured j\u00e4rjekorrad. Kuidas nad v\u00f5ivad kasvada selliseks suuruseks? Mitmel p\u00f5hjusel:<\/p>\n<ul>\n<li>J\u00e4rjekordi ei kasutata aktiivselt\n<\/li>\n<li>Need on kiire juurdep\u00e4\u00e4suga j\u00e4rjekorrad ja praegu t\u00f6\u00f6tavad tarbijad aeglaselt \n<\/li>\n<li>Need on kiire juurdep\u00e4\u00e4suga j\u00e4rjekorrad, eba\u00f5nnestumine on toimunud ja tarbijad j\u00e4tkavad<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus 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\u00fcnkroniseerimisre\u017eiimidega<\/i><\/p>\n<p>N\u00fc\u00fcd n\u00f5rgeneb Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/8c31cfdf485ab4c9dfe13e86a151df4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 15. Broker 3 langeb, j\u00e4ttes igas j\u00e4rjekorras \u00fche meistrite ja peegli<\/i><\/p>\n<p>Broker 3 naaseb teenistusse ja luuakse uued peeglid. Peamine J\u00e4rjekord A hakkab replikatsioonimeetodeid olemasolevatele s\u00f5numitele uude peeglisse, ja selle aja jooksul on j\u00e4rjekord mitte saadaval. Andmete replikatsiooniks on vaja kahte tundi, mis toob kaasa kahe tunni seismise selle j\u00e4rjekorra jaoks!<\/p>\n<p>Queue B j\u00e4\u00e4b k \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u043c kogu perioodi v\u00e4ltel. Ta ohverdas m\u00f5ningase \u00fclemuslikkuse saadavuse nimel.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/28e641300a1c3f4d70e29a16db51521e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 16. Ooteaeg on s\u00fcnkroniseerimise ajal j\u00e4lle k \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u043c.<\/i><\/p>\n<p>Kaks tundi hiljem muutub ka Queue A k \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u043c ja v\u00f5ib uuesti hakata vastuv\u00f5tma lugemis- ja kirjutamisoperatsioone.<\/p>\n<h3>Uuendused<\/h3>\n<p>\nSelline blokeeritav k\u00e4itumine s\u00fcnkroniseerimise ajal muudab v\u00e4ga suurte j\u00e4rjekordade klasterdamise keeruliseks. \u00dchel hetkel tuleb peatada pealin, mis t\u00e4hendab kas \u00fcleminekut peegli peale v\u00f5i j\u00e4rjekorra v\u00e4ljal\u00fclitamist serveri uuendamise ajal. Kui valime \u00fclemineku, kaotame s\u00f5numid, kui peeglid ei ole s\u00fcnkroniseeritud. Vaikimisi ei teostata \u00fcleminekut s\u00fcnkroniseerimata peeglitele broseri v\u00e4ljal\u00fclitamise ajal. See t\u00e4hendab, et niipea kui broser naaseb, ei kaota me \u00fchtegi s\u00f5numit, ainus kahju oli lihtsalt j\u00e4rjekorrast. Rootsi k\u00e4itumise reeglid broseri v\u00e4ljal\u00fclitamisel m\u00e4\u00e4ratakse poliitikaga. <code>ha-promote-on-shutdown<\/code>. \u00dcks kahest v\u00e4\u00e4rtusest on v\u00f5imalik seada:<\/p>\n<ul>\n<li><code>always<\/code>= lubatud \u00fcleminek s\u00fcnkroniseerimata peeglitele\n<\/li>\n<li><code>when-synced<\/code>= \u00fcleminek ainult s\u00fcnkroniseeritud peeglikohta, vastasel juhul muutub j\u00e4rjekord lugemis- ja kirjutamispuuduks. J\u00e4rjekord taastub, kui vahendaja tagasi tuleb.<\/li>\n<\/ul>\n<p>\nIgal juhul tuleb suurte j\u00e4rjekordade puhul valida andmete kaotuse ja k\u00e4ttesaamatuse vahel.<\/p>\n<h3>Kui k\u00e4ttesaadavus suurendab andmete turvalisust<\/h3>\n<p>\nEnne otsuse tegemist tuleb arvesse v\u00f5tta veel \u00fcks komplikatsioon. Kuigi automaatne s\u00fcnkroniseerimine on parem soovitavuse jaoks, kuidas see m\u00f5jutab andmete turvalisust? Muidugi, graafikut paremate soovitustega on RabbitMQ v\u00e4hem t\u00f5en\u00e4oliselt olemasolevaid s\u00f5numeid kaotamas, kuid kuidas uute s\u00f5numitega, mille saadavad avaldajad?<\/p>\n<p>Siin tuleb arvesse v\u00f5tta j\u00e4rgmist:<\/p>\n<ul>\n<li>Kas avaldaja saab lihtsalt veateate tagasi saata ning k\u00f5rgem teenus v\u00f5i kasutaja proovib hiljem uuesti?\n<\/li>\n<li>Kas avaldaja saab s\u00f5numi kohapeal v\u00f5i andmebaasis salvestada, et hiljem uuesti proovida?<\/li>\n<\/ul>\n<p>\nKui avaldaja suudab vaid s\u00f5numi k\u00f5rvale j\u00e4tta, siis t\u00f5eliselt k\u00e4ttesaadavuse parandamine suurendab 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> meie saavutame selle, et takistame s\u00fcnkroonimata peegli kasutamist ning seel\u00e4bi v\u00e4ltime andmete kaotamist. J\u00e4rjekord j\u00e4\u00e4b lugemiseks v\u00f5i kirjutamiseks k\u00e4ttesaamatuks. Selle asemel p\u00fc\u00fcame taastada kokku kukkunud vahendaja puutumatute andmetega, et see saaks j\u00e4lle peamise meisterina t\u00f6\u00f6tada andmete kaotamata. <\/p>\n<p>Aga (ja see on suur kuid) kui vahendaja on oma andmed kaotanud, siis seisame silmitsi suure probleemiga: j\u00e4rjekord on kadunud! K\u00f5ik andmed on kadunud! Isegi kui teil on peeglid, mis p\u00f5him\u00f5tteliselt j\u00f5uavad peamise j\u00e4rjekorraga j\u00e4rgi, siis need peeglid j\u00e4etakse samuti k\u00f5rvale.<\/p>\n<p>Sama nimega s\u00f5lme uuesti lisamiseks \u00fctleb me klastrile, et unustatakse kadunud s\u00f5lm (k\u00e4sk <i>rabbitmqctl forget_cluster_node<\/i>) ja k\u00e4ivitame uue vahendaja sama hostinimega. Niikaua kui klaster m\u00e4letab kadunud s\u00f5lme, m\u00e4letab see vana j\u00e4rjekorda ja s\u00fcnkroonimata peegleid. Kui klastrile \u00f6eldakse, et unustame kadunud s\u00f5lme, unustatakse ka see j\u00e4rjekord. N\u00fc\u00fcd tuleb see uuesti kuulutada. Oleme kaotanud k\u00f5ik andmed, kuigi meil oli peegleid osalise andmekogumiga. Oluliselt parem oleks olnud kasutada s\u00fcnkroonimata peeglit!<\/p>\n<p>Seet\u00f5ttu on k\u00e4sitsi s\u00fcnkroniseerimine (ja s\u00fcnkroniseerimise tegemata j\u00e4tmine) koos <code>ha-promote-on-failure=when-synced<\/code>, minu arvates, \u00fcsna riskantne. Dokumendid v\u00e4idavad, et selline variant on olemas andmete turvalisuse nimel, kuid see on kaheteistk\u00fcmnes nuhtlus.<\/p>\n<h1>Meistrite \u00fcmberbalanseerimine<\/h1>\n<p>\nNagu lubatud, naaseme probleemi juurde, kus k\u00f5ik meistrid koonduvad \u00fchele v\u00f5i kahele s\u00f5lmele. See v\u00f5ib juhtuda isegi \"liuguri\" (rolling) klastriv\u00e4rskenduse tagaj\u00e4rjel. Kolme s\u00f5lmega klastris koonduvad k\u00f5ik peamised j\u00e4rjekorrad \u00fchele v\u00f5i kahele s\u00f5lmele.<\/p>\n<p>Meistrite \u00fcmberbalanseerimine v\u00f5ib osutuda probleemseks kahel p\u00f5hjusel:<\/p>\n<ul>\n<li>Hea t\u00f6\u00f6riistade puudumine \u00fcmberbalanseerimise teostamiseks<\/li>\n<li>J\u00e4rjekordade s\u00fcnkroniseerimine<\/li>\n<\/ul>\n<p>\n\u00dcmberbalanseerimiseks on kolmandate osapoolte <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Ayanda-D\/rabbitmq-queue-master-balancer\">plugin<\/a><\/noindex>, mis ei ole ametlikult toetatud. RabbitMQ juhendis mainitakse kolmandate osapoolte pluginate kohta, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.rabbitmq.com\/upgrade.html\">\u00f6eldakse<\/a><\/noindex>: \u201ePlugin pakub lisav\u00f5imalusi seadmise ja aruandluse jaoks, kuid ei ole toetatud ega testitud RabbitMQ meeskonna poolt. Kasutage omal vastutusel.\u201c<\/p>\n<p>On veel \u00fcks nipp, et peamine j\u00e4rjekord liigutada 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> selleks. See t\u00f6\u00f6tab j\u00e4rgmiselt:<\/p>\n<ul>\n<li>Eemaldab k\u00f5ik peeglid ajutise poliitika abil, millel on k\u00f5rgem prioriteet kui olemasoleval HA poliitikal.\n<\/li>\n<li>Muudab HA ajutist poliitikat, et kasutada 's\u00f5lmede' re\u017eiimi, m\u00e4\u00e4rates kindlaks s\u00f5lme, kuhu peamine j\u00e4rjekord tuleb liikuda.\n<\/li>\n<li>S\u00fcnkroniseerib j\u00e4rjekorra sundmigreerimiseks.\n<\/li>\n<li>P\u00e4rast migratsiooni l\u00f5petamist eemaldatakse ajutine poliitika. Kehtib 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 \u00fclekande n\u00f5uded.<\/p>\n<p>N\u00fc\u00fcd vaatame, kuidas RabbitMQ klastrid t\u00f6\u00f6tavad v\u00f5rgu jagunemistega.<\/p>\n<h1>\u00dchenduse rikkumine<\/h1>\n<p>\nJaotatud s\u00fcsteemi s\u00f5lmed on omavahel \u00fchendatud v\u00f5rgu\u00fchenduste kaudu, ning v\u00f5rgu\u00fchendused v\u00f5ivad ja kindlasti ka katkeda. Katkestuste sagedus s\u00f5ltub kohalikest infrastruktuuridest v\u00f5i valitud pilve usaldusv\u00e4\u00e4rsusest. Igal juhul peavad jaotatud s\u00fcsteemid olema v\u00f5imelised nendega hakkama saama. Taas on meil valida k\u00e4ttesaadavuse ja j\u00e4rjepidevuse vahel, ning taas on hea uudis, et RabbitMQ tagab m\u00f5lemad variandid (lihtsalt mitte korraga).<\/p>\n<p>RabbitMQ-l on meil kaks peamist valikut:<\/p>\n<ul>\n<li>Lubada loogiline jagunemine (split-brain). See tagab k\u00e4ttesaadavuse, kuid v\u00f5ib p\u00f5hjustada andmete kaotust.\n<\/li>\n<li>Keelata loogiline jagunemine. See v\u00f5ib p\u00f5hjustada l\u00fchiajalist k\u00e4ttesaadavuse kaotust s\u00f5ltuvalt sellest, kuidas kliendid klastriga \u00fchenduvad. Samuti v\u00f5ib see viia kahe s\u00f5lmega klastris t\u00e4ieliku k\u00e4ttesaamatuse.<\/li>\n<\/ul>\n<p>\nKuid mis on loogiline jagunemine? See on siis, kui klaster jaguneb kahte ossa v\u00f5rgu\u00fchenduste kadumise t\u00f5ttu. Igal pool t\u00f5usevad peegeldused meesteriks, nii et l\u00f5puks on iga j\u00e4rjekorra jaoks mitu meest.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus 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\u00fcks eraldi s\u00f5lmes. Siis toimub v\u00f5rgu rike ning \u00fcks peegel eraldub. Eraldunud s\u00f5lm n\u00e4eb, et kaks muud on kadunud, ja edastab oma peeglid meistrile. N\u00fc\u00fcd on meil kaks peamist j\u00e4rjekorda, ja m\u00f5lemad lubavad kirjutamist ja lugemist.<\/i> <\/p>\n<p>Kui avaldajad saadavad andmeid m\u00f5lemasse meistrisse, saame kaks erinevat j\u00e4rjekonna koopiat.<\/p>\n<p>Erinevad RabbitMQ re\u017eiimid tagavad kas k\u00e4ttesaadavuse v\u00f5i j\u00e4rjepidevuse.<\/p>\n<h3>Ignoreeri re\u017eiim (vaikimisi)<\/h3>\n<p>\nSee re\u017eiim tagab k\u00e4ttesaadavuse. P\u00e4rast \u00fchenduse kadumist toimub loogiline eraldamine. \u00dchenduse taastumise korral peab administraator otsustama, kumma osa eelistada. Kaotav poole rekonstrueeritakse, ja k\u00f5ik sellelt poolelt kogunenud andmed kaovad.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/4d82c13b5ef21837ba819f5c246a1e41.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 18. Kolm avaldajat on \u00fchendatud kolme maakleriga. Sisev\u00f5rgus suunab klaster k\u00f5ik p\u00e4ringud peamisele j\u00e4rjekorrale Maakler 2-l.<\/i><\/p>\n<p>N\u00fc\u00fcd kaotame Maakler 3. Ta n\u00e4eb, et teised maaklerid on kadunud, ja edastab oma peegli meistriks. Nii toimub loogiline eraldamine.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/c7e01d51b24023bacdd93cfad95c9eab.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 19. Loogiline jagunemine (split-brain). Kirjed liiguvad kahte peamist j\u00e4rjekorda ja kaks koopiat hajuvad.<\/i><\/p>\n<p>Sidusus taastatakse, kuid loogiline jagunemine j\u00e4\u00e4b. Administraator peab k\u00e4sitsi valima kaotaja poole. Allpool olevas n\u00e4ites k\u00e4ivitab administraator Broker 3. K\u00f5ik s\u00f5numid, mida see ei j\u00f5udnud edastada, kaovad.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/51c3ee15024d3c83ba625e3ff9cdeb90.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 20. Administraator v\u00e4ljub Broker 3.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/0bac8e33de25c0c5381d336d26464858.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joon. 21. Administraator k\u00e4ivitab Broker 3 ja see liitub klastriga, kaotades k\u00f5ik s\u00f5numid, mis seal olid.<\/i><\/p>\n<p>Sidususe kaotamise ajal ja p\u00e4rast selle taastamist oli klaster ja see j\u00e4rjekord lugemiseks ja kirjutamiseks saadaval.<\/p>\n<h3>Autotervenduse re\u017eiim<\/h3>\n<p>\nT\u00f6\u00f6tleb sarnaselt Ignore re\u017eiimile, v\u00e4lja arvatud see, et klaster valib automaatselt kaotaja poole p\u00e4rast jagunemist ja sidususe taastamist. Kaotaja pool naaseb klastrisse t\u00fchjana ning j\u00e4rjekord kaotab k\u00f5ik s\u00f5numid, mis olid saadetud ainult sellele poolele.<\/p>\n<h3>Minori Pause re\u017eiim<\/h3>\n<p>\nKui me ei taha loogilist eraldumist lubada, on meie ainus variant loobuda v\u00e4iksemal pool lugemisest ja kirjutamisest p\u00e4rast klastrit. Kui broker n\u00e4eb, et ta on v\u00e4iksemal poolel, peatab ta t\u00f6\u00f6, sulgeb k\u00f5ik olemasolevad \u00fchendused ja loobub uutest. Ta kontrollib \u00fchenduse taastumist kord sekundis. Kui \u00fchendus on taastatud, j\u00e4tkab ta t\u00f6\u00f6 ja liitub klastriga.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/7a51cf509b2c94e2ae100c7dedd9d21a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 22. Kolm v\u00e4ljaandjat on \u00fchendatud kolme brokera. Sisemiselt suunab klaster k\u00f5ikp\u00e4ringud peadis_queue Borkeris 2.<\/i><\/p>\n<p>Siis eraldavad Brokerid 1 ja 2 end Brokerist 3. Selle asemel, et oma peeglit meistriks t\u00f5sta, peatab Broker 3 oma t\u00f6\u00f6 ja muutub k\u00e4ttesaamatuks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/c12ec38a47e1f8ccceebfa1854f54f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 23. Broker 3 peatab t\u00f6\u00f6, \u00fchendab k\u00f5ik kliendid ja loobub \u00fchendusetaotlustest.<\/i><\/p>\n<p>Kui \u00fchendus on taastatud, naaseb ta klastrisse.<\/p>\n<p>Vaadakem teist n\u00e4idet, kus peadis_queue asub Brokeris 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/4cc6a28270f00a280ecb5af5252f4e07.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 24. Peadis_queue on Brokeris 3.<\/i><\/p>\n<p>Seej\u00e4rel toimub sama \u00fchenduvuse kadu. Broker 3 pannakse pausile, kuna see on v\u00e4iksemas otsas. Teisel pool n\u00e4evad s\u00f5lmed, et Broker 3 on kadunud, nii et vanem peegeldus Brokeritest 1 ja 2 t\u00f5stetakse meistriks.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/d0d032385533bb53c5a95927afcd3119.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 25. \u00dcleminek Brokerile 2, kui Broker 3 ei ole saadaval.<\/i><\/p>\n<p>Kui \u00fchenduvus taastatakse, liitub Broker 3 klastriga.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs Kafka: t\u00f6\u00f6kindlus ja k\u00f5rge saadavus klastrites\" src=\"\/wp-content\/uploads\/2019\/11\/53f8186a040ae07724ef59cf79b72a0c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 26. Klaster on naasnud normaalsesse t\u00f6\u00f6seisundisse.<\/i><\/p>\n<p>Siin on oluline m\u00f5ista, et me saame j\u00e4rjepidevuse, kuid v\u00f5ime samuti saavutada k\u00e4ttesaadavuse, <i><b>kui<\/b><\/i> me edastame klientide \u00fclemineku suuremale osale jaotusest edukalt. Enamikus olukordades valiksin isiklikult Paus V\u00e4hemuse re\u017eiimi, kuid see s\u00f5ltub t\u00f5eliselt konkreetsest juhtumist.<\/p>\n<p>K\u00e4ttesaadavuse tagamiseks on oluline veenduda, et kliendid suudavad edukalt s\u00f5lme \u00fchenduda. Vaatame meie v\u00f5imalusi.<\/p>\n<h1>Kliendi \u00fchenduvuse tagamine<\/h1>\n<p>\nMeie s\u00fcsteem pakub mitmeid viise, kuidas suunata kliente klastrisse v\u00f5i toimivatesse s\u00f5lmedesse p\u00e4rast \u00fchenduse katkemist (kui \u00fcks s\u00f5lm eba\u00f5nnestub). Esiteks, pidagem meeles, et konkreetne j\u00e4rjekord on paigutatud kindlasse s\u00f5lme, kuid marsruutimine ja poliitikad replitseeruvad k\u00f5ikides s\u00f5lmedes. Klendid saavad \u00fchenduda mis tahes s\u00f5lmest, ja sisemine marsruutimine suunab nad \u00f5igesse kohta. Kui aga s\u00f5lm peatatakse, l\u00fckatakse \u00fchendused tagasi, seega peavad kliendid \u00fchenduma m\u00f5ne teise s\u00f5lmaga. Kui s\u00f5lm on alla kukkunud, ei saa ta \u00fcldse midagi teha.<\/p>\n<p>Meie valikud:<\/p>\n<ul>\n<li>Klastrisse p\u00e4\u00e4seb juurde koormuse tasakaalustaja kaudu, mis lihtsalt ts\u00fckliliselt j\u00e4rjestab s\u00f5lmi, ning kliendid proovivad uuesti \u00fchendust kuni eduka l\u00f5puni. Kui s\u00f5lm ei t\u00f6\u00f6ta v\u00f5i on peatatud, siis katse\u00fchendused selle s\u00f5lmaga eba\u00f5nnestuvad, kuid j\u00e4rgmised katsed suunatakse teistele serveritele (ts\u00fckliliselt). See sobib l\u00fchiajalise \u00fchenduse katkemise v\u00f5i eba\u00f5nnestunud serveri korral, mis taask\u00e4ivitub kiiresti.\n<\/li>\n<li>Ligip\u00e4\u00e4s klastrile l\u00e4bi koormuse tasakaalustaja ja peatatud\/lagunenud s\u00f5lmede eemaldamine loendist kohe, kui nad avastatakse. Kui teha seda kiiresti ja kui kliendid suudavad uuesti \u00fchendust v\u00f5tta, tagame pideva k\u00e4ttesaadavuse.\n<\/li>\n<li>Andke iga kliendi kohta nimekiri k\u00f5igist s\u00f5lmedest, ja klient valib \u00fchendamisel juhuslikult \u00fche neist. Kui \u00fchenduse loomisel tekib viga, siirdub ta j\u00e4rgmisele s\u00f5lmele loendis, kuni \u00fchendus \u00f5nnestub.\n<\/li>\n<li>Eemaldage liiklus lagunenud\/peatatud s\u00f5lmelt DNS-i abil. Seda tehakse l\u00fchikese TTL-iga.<\/li>\n<\/ul>\n<p><\/p>\n<h1>J\u00e4reldused<\/h1>\n<p>\nRabbitMQ klasterdamisel on oma eelised ja puudused. T\u00f5sisemad puudused on j\u00e4rgmised:<\/p>\n<ul>\n<li>klastrisse liitumisel s\u00f5lmed loobuvad oma andmetest;\n<\/li>\n<li>blokeeriv s\u00fcnkroniseerimine toob kaasa j\u00e4rjekorra k\u00e4ttesaamatuse.<\/li>\n<\/ul>\n<p>\nK\u00f5ik keerulised otsused tulenevad nendest kahest arhitektuuri omadusest. Kui RabbitMQ saaks s\u00e4ilitada andmeid klastriga uuesti \u00fchendamisel, toimuks s\u00fcnkroniseerimine kiiremini. Kui tal oleks v\u00f5ime mitteblokeerivaks s\u00fcnkroniseerimiseks, toetaks see paremini suuri j\u00e4rjekordi. Nende kahe probleemi lahendamine parandaks m\u00e4rkimisv\u00e4\u00e4rselt RabbitMQ omadusi kui t\u00f5rgetevaba ja k\u00f5rge k\u00e4ttesaadavusega s\u00f5numivahetustehnoloogiat. Ma ei soovitaks RabbitMQ klasterdamiseks j\u00e4rgmistel juhtudel:<\/p>\n<ul>\n<li>Usaldusv\u00e4\u00e4rne v\u00f5rk.\n<\/li>\n<li>Usaldusv\u00e4\u00e4rne salvestus.\n<\/li>\n<li>V\u00e4ga suured j\u00e4rjekorrad.<\/li>\n<\/ul>\n<p>\nMis puutub k\u00f5rge k\u00e4ttesaadavuse seadistamisse, siis 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 \u00fchenduksid aktiivse s\u00f5lmega, kui m\u00f5ni s\u00f5lm eba\u00f5nnestub<\/li>\n<\/ul>\n<p>\nKonsistentsi (andmete turvalisuse) jaoks 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 v\u00f5ivad hiljem uuesti proovida 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> (kuid suurte passiivsete j\u00e4rjekordade puhul v\u00f5ib osutuda vajalikuks manuaalne re\u017eiim; samuti m\u00f5elge, kas k\u00e4ttesaamatuse t\u00f5ttu v\u00f5idakse kaduda s\u00f5numeid)\n<\/li>\n<li>Pause Minority re\u017eiim\n<\/li>\n<li>p\u00fcsivad s\u00f5numid<\/li>\n<\/ul>\n<p>\nOleme veel k\u00f5iki t\u00f5rketeabe ja k\u00f5rge k\u00e4ttesaadavuse k\u00fcsimusi l\u00e4bi arutanud; n\u00e4iteks, kuidas soodsal viisil t\u00e4ita haldustooted (n\u00e4iteks sujuvad uuendused). Peame r\u00e4\u00e4kima ka fedeerimisest ja Shoveli pluginast.<\/p>\n<p>Kui ma midagi unustasin, palun andke teada.<\/p>\n<p>Vaata ka minu <noindex><a rel=\"nofollow\" href=\"https:\/\/jack-vanlightly.com\/blog\/2018\/9\/10\/how-to-lose-messages-on-a-rabbitmq-cluster\">post<\/a><\/noindex>, kus viin l\u00e4bi RabbitMQ klastriga eksperimentide ja Blockade abil, et testida artiklis kirjeldatud s\u00f5numite kadumise stsenaariume.<\/p>\n<p>Seeria varasemad artiklid: <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.0.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.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47RabbitMQ \u043f\u0440\u043e\u0442\u0438\u0432 Kafka: \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c \u0438 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c \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}]}}