В viimeinen artikkeli Tarkastelimme RabbitMQ-klusterointia vikasietoisuuden ja korkean käytettävyyden suhteen. Kaivataan nyt syvälle Apache Kafkaan.

Tässä replikointiyksikkö on osio. Jokaisessa aiheessa on yksi tai useampi osio. Jokaisella osastolla on johtaja seuraajien kanssa tai ilman. Kun luot aihetta, määrität osioiden lukumäärän ja toisinnuskertoimen. Tavallinen arvo on 3, mikä tarkoittaa kolmea kopiota: yhtä johtajaa ja kahta seuraajaa.

Riisi. 1. Neljä osastoa on jaettu kolmen välittäjän kesken

Kaikki luku- ja kirjoituspyynnöt menevät johtajalle. Seuraajat lähettävät ajoittain pyyntöjä johtajalle saada uusimmat viestit. Kuluttajat eivät koskaan käänny seuraajien puoleen; jälkimmäiset ovat olemassa vain redundanssin ja vikasietoisuuden vuoksi.

Osiovirhe

Kun välittäjä epäonnistuu, useiden osastojen johtajat epäonnistuvat usein. Jokaisessa niistä seuraaja toisesta solmusta tulee johtajaksi. Itse asiassa näin ei aina ole, koska synkronointitekijä vaikuttaa myös: onko synkronoituja seuraajia, ja jos ei, niin sallitaanko vaihtaminen synkronoimattomaan replikaan. Mutta älkäämme nyt monimutkaisko asioita.

Välittäjä 3 jättää verkoston ja osastolle 2 valitaan uusi johtaja välittäjällä 2.

Riisi. 2. Välittäjä 3 kuolee ja hänen seuraajansa välittäjällä 2 valitaan osion 2 uudeksi johtajaksi

Silloin välittäjä 1 lähtee ja osasto 1 menettää myös johtajansa, jonka rooli siirtyy välittäjälle 2.

Riisi. 3. Yksi välittäjä on jäljellä. Kaikki johtajat ovat yhdellä välittäjällä ilman irtisanomisia

Kun välittäjä 1 palaa verkkoon, se lisää neljä seuraajaa, mikä tarjoaa redundanssia jokaiselle osiolle. Mutta kaikki johtajat pysyivät edelleen välittäjällä 2.

Riisi. 4. Johtajat pysyvät välittäjällä 2

Kun broker 3 tulee esiin, palaamme kolmeen kopioon osiota kohti. Mutta kaikki johtajat ovat edelleen välittäjällä 2.

Riisi. 5. Johtajien epätasapainoinen sijoittelu välittäjien 1 ja 3 palauttamisen jälkeen

Kafkalla on työkalu paremman johtajan tasapainottamiseen kuin RabbitMQ. Siellä sinun piti käyttää kolmannen osapuolen laajennusta tai komentosarjaa, joka muutti pääsolmun siirtokäytäntöjä vähentämällä redundanssia siirron aikana. Lisäksi suurien jonojen kohdalla jouduimme hyväksymään epäkäytettävyyden synkronoinnin aikana.

Kafkalla on käsite "ensisijaiset jäljennökset" johtajarooliin. Kun aiheosioita luodaan, Kafka yrittää jakaa johtajat tasaisesti solmujen kesken ja merkitsee nuo ensimmäiset johtajat ensisijaisiksi. Ajan myötä palvelimen uudelleenkäynnistysten, vikojen ja yhteyshäiriöiden vuoksi johtajat voivat päätyä muihin solmuihin, kuten yllä kuvatussa ääritapauksessa.

Tämän korjaamiseksi Kafka tarjoaa kaksi vaihtoehtoa:

Vaihtoehto auto.leader.rebalance.enable=true sallii ohjainsolmun määrittää automaattisesti johtajat takaisin ensisijaisiin replikoihin ja palauttaa siten yhtenäisen jakelun.
Järjestelmänvalvoja voi suorittaa skriptin kafka-preferred-replica-election.sh manuaalista uudelleenmäärittelyä varten.

Riisi. 6. Jäljennökset tasapainotuksen jälkeen

Tämä oli yksinkertaistettu versio epäonnistumisesta, mutta todellisuus on monimutkaisempi, vaikka tässä ei ole mitään liian monimutkaista. Kaikki perustuu synkronoituihin replikoihin (In-Sync Replicas, ISR).

Synkronoidut jäljennökset (ISR)

ISR on "synkronoiduksi" (synkronoiduksi) katsotun osion kopioiden joukko. Johtaja on, mutta seuraajia ei välttämättä ole. Seuraaja katsotaan synkronoituksi, jos se on tehnyt tarkat kopiot kaikista johtajan viesteistä ennen aikavälin umpeutumista replica.lag.time.max.ms.

Seuraaja poistetaan ISR-joukosta, jos se:

ei pyytänyt valita aikaväliä replica.lag.time.max.ms (oletetaan kuolleena)
ei onnistunut päivittämään välin aikana replica.lag.time.max.ms (pidetty hitaana)

Seuraajat tekevät näytteenottopyyntöjä välissä replica.fetch.wait.max.ms, jonka oletusarvo on 500 ms.

Selvittääksemme selkeästi ISR:n tarkoituksen, meidän on tarkasteltava tuottajan vahvistuksia ja joitain epäonnistumisskenaarioita. Tuottajat voivat valita, milloin välittäjä lähettää vahvistuksen:

acks=0, vahvistusta ei lähetetä
acks=1, vahvistus lähetetään, kun johtaja on kirjoittanut viestin paikalliseen lokiinsa
acks=all, vahvistus lähetetään, kun kaikki ISR:n replikat ovat kirjoittaneet viestin paikallisiin lokeihin

Kafka-terminologiassa, jos ISR on tallentanut viestin, se on "sitoutunut". Acks=all on turvallisin vaihtoehto, mutta myös lisää viivettä. Katsotaanpa kahta esimerkkiä epäonnistumisesta ja siitä, kuinka erilaiset "acks"-vaihtoehdot ovat vuorovaikutuksessa ISR-konseptin kanssa.

Acks=1 ja ISR

Tässä esimerkissä näemme, että jos johtaja ei odota kaikkien seuraajien jokaisen viestin tallentamista, tietojen menetys on mahdollista, jos johtaja epäonnistuu. Navigoiminen synkronoimattomaan seuraajaan voidaan ottaa käyttöön tai poistaa käytöstä asetuksilla unclean.leader.election.enable.

Tässä esimerkissä valmistajalla on arvo acks=1. Osio on jaettu kaikille kolmelle välittäjälle. Broker 3 on takana, se synkronoitui johtajan kanssa kahdeksan sekuntia sitten ja on nyt 7456 viestiä jäljessä. Välittäjä 1 oli vain sekunnin jäljessä. Tuottajamme lähettää viestin ja saa nopeasti kuittauksen takaisin ilman hitaita tai kuolleita seuraajia, joita johtaja ei odota.

Riisi. 7. ISR kolmella kopiolla

Broker 2 epäonnistuu ja tuottaja saa yhteysvirheen. Kun johtajuus siirtyy välittäjälle 1, menetämme 123 viestiä. Broker 1:n seuraaja oli osa ISR:ää, mutta se ei ollut täysin synkronoitu johtajan kanssa, kun se putosi.

Riisi. 8. Viestit katoavat, kun se kaatuu

Konfiguraatiossa bootstrap.servers Valmistajalla on luettelossa useita välittäjiä, ja hän voi kysyä toiselta välittäjältä, joka on uusi osion johtaja. Sitten se muodostaa yhteyden välittäjään 1 ja jatkaa viestien lähettämistä.

Riisi. 9. Viestien lähettäminen jatkuu lyhyen tauon jälkeen

Broker 3 on vieläkin jäljessä. Se tekee noutopyyntöjä, mutta ei voi synkronoida. Tämä voi johtua hitaasta verkkoyhteydestä välittäjien välillä, tallennusongelmasta jne. Se poistetaan ISR:stä. Nyt ISR koostuu yhdestä kopiosta - johtajasta! Valmistaja jatkaa viestien lähettämistä ja vahvistusten vastaanottamista.

Riisi. 10. Välittäjän 3 seuraaja poistetaan ISR:stä

Välittäjä 1 kaatuu ja johtajan rooli siirtyy välittäjälle 3 menettäen 15286 viestiä! Valmistaja saa yhteyden virheilmoituksen. Siirtyminen ISR:n ulkopuoliseksi johtajaksi oli mahdollista vain asetelman ansiosta unclean.leader.election.enable=true. Jos se on asennettu sisään väärä, silloin siirtoa ei tapahtuisi ja kaikki luku- ja kirjoituspyynnöt hylätään. Tässä tapauksessa odotamme välittäjää 1 palaavan eheillä tiedoillaan replikassa, joka ottaa jälleen johtajuuden.

Riisi. 11. Välittäjä 1 kaatuu. Vian sattuessa suuri määrä viestejä katoaa

Tuottaja muodostaa yhteyden viimeiseen välittäjään ja näkee, että hän on nyt osion johtaja. Hän alkaa lähettää viestejä välittäjälle 3.

Riisi. 12. Lyhyen tauon jälkeen viestit lähetetään uudelleen osioon 0

Näimme, että lyhyitä keskeytyksiä uusien yhteyksien luomiseen ja uuden johtajan etsimiseen lukuun ottamatta valmistaja lähetti jatkuvasti viestejä. Tämä kokoonpano varmistaa saatavuuden johdonmukaisuuden (tietoturvan) kustannuksella. Kafka menetti tuhansia viestejä, mutta jatkoi uusien kirjoitusten hyväksymistä.

Acks=all ja ISR

Toistetaan tämä skenaario uudelleen, mutta kanssa acks = kaikki. Broker 3:n keskimääräinen latenssi on neljä sekuntia. Valmistaja lähettää viestin kanssa acks = kaikki, ja nyt ei saa nopeaa vastausta. Johtaja odottaa, että kaikki ISR:n kopiot tallentavat viestin.

Riisi. 13. ISR kolmella kopiolla. Yksi on hidas, mikä aiheuttaa tallennusviiveitä

Neljän sekunnin lisäviiveen jälkeen välittäjä 2 lähettää kuittauksen. Kaikki kopiot on nyt päivitetty täysin.

Riisi. 14. Kaikki kopiot tallentavat viestit ja lähettävät kuittauksen

Broker 3 on nyt entistä enemmän jäljessä ja poistetaan ISR:stä. Latenssi vähenee merkittävästi, koska ISR:ssä ei ole enää hitaita kopioita. Välittäjä 2 odottaa nyt vain välittäjää 1, ja hänen keskimääräinen viive on 500 ms.

Riisi. 15. Välittäjällä 3 oleva kopio poistetaan ISR:stä

Sitten välittäjä 2 kaatuu ja johtajuus siirtyy välittäjälle 1 menettämättä viestejä.

Riisi. 16. Välittäjä 2 kaatuu

Valmistaja löytää uuden johtajan ja alkaa lähettää hänelle viestejä. Latenssia pienennetään entisestään, koska ISR koostuu nyt yhdestä kopiosta! Siksi vaihtoehto acks = kaikki ei lisää redundanssia.

Riisi. 17. Välittäjä 1:n replika ottaa johtoaseman menettämättä viestejä

Sitten välittäjä 1 kaatuu ja johto siirtyy välittäjälle 3 menettäen 14238 viestiä!

Riisi. 18. Broker 1 kuolee ja johtajuuden siirtyminen epäpuhtaalla asetuksella johtaa laajaan tietojen menetykseen

Emme voineet asentaa vaihtoehtoa unclean.leader.election.enable merkitykseen totta. Oletuksena se on yhtä suuri väärä. asetukset acks = kaikki с unclean.leader.election.enable=true tarjoaa saavutettavuuden lisätyllä tietoturvalla. Mutta kuten näet, voimme silti menettää viestejä.

Mutta entä jos haluamme lisätä tietoturvaa? Voit laittaa unclean.leader.election.enable = false, mutta tämä ei välttämättä suojaa meitä tietojen katoamiselta. Jos johtaja kaatui lujasti ja otti tiedot mukanaan, niin viestit menetetään edelleen ja saatavuus menetetään, kunnes järjestelmänvalvoja palauttaa tilanteen.

On parempi varmistaa, että kaikki viestit ovat redundantteja, ja muuten hylätä tallenne. Tällöin ainakin välittäjän näkökulmasta tietojen häviäminen on mahdollista vain kahden tai useamman samanaikaisen vian sattuessa.

Acks=all, min.insync.replicas ja ISR

Aihemäärityksellä min.insync.replicas Lisäämme tietoturvan tasoa. Käydään läpi edellisen skenaarion viimeinen osa uudelleen, mutta tällä kertaa min.insync.replicas=2.

Joten välittäjällä 2 on replikajohtaja ja välittäjän 3 seuraaja poistetaan ISR:stä.

Riisi. 19. ISR kahdesta kopiosta

Välittäjä 2 kaatuu ja johtajuus siirtyy välittäjälle 1 menettämättä viestejä. Mutta nyt ISR koostuu vain yhdestä kopiosta. Tämä ei täytä tietueiden vastaanottamisen vähimmäismäärää, ja siksi välittäjä vastaa kirjoitusyritykseen virheellä NotEnoughReplicas.

Riisi. 20. ISR:ien määrä on yksi pienempi kuin kohdassa min.insync.replicas on määritetty

Tämä kokoonpano uhraa saatavuuden johdonmukaisuuden vuoksi. Ennen viestin kuittaamista varmistamme, että se on kirjoitettu vähintään kahteen replikaan. Tämä antaa valmistajalle paljon enemmän luottamusta. Tässä viestin katoaminen on mahdollista vain, jos kaksi kopiota epäonnistuu samanaikaisesti lyhyen aikavälin sisällä, kunnes viesti replikoidaan uudelle seuraajalle, mikä on epätodennäköistä. Mutta jos olet erittäin vainoharhainen, voit asettaa replikointikertoimeksi 5 ja min.insync.replicas 3. Tässä kolmen välittäjän täytyy kaatua samanaikaisesti menettääkseen ennätyksen! Tietenkin maksat tästä luotettavuudesta lisäviiveenä.

Kun saavutettavuus on tarpeen tietoturvallisuuden vuoksi

Kuten kotelo RabbitMQ:lla, joskus saavutettavuus on tarpeen tietoturvan vuoksi. Tässä on mitä sinun on mietittävä:

Voiko julkaisija yksinkertaisesti palauttaa virheilmoituksen ja pyytää palvelua tai käyttäjää yrittämään myöhemmin uudelleen?
Voiko julkaisija tallentaa viestin paikallisesti tai tietokantaan yrittääkseen myöhemmin uudelleen?

Jos vastaus on ei, saatavuuden optimointi parantaa tietoturvaa. Menetät vähemmän dataa, jos valitset saatavuuden tallentamisen sijaan. Siten kaikki riippuu tasapainon löytämisestä, ja päätös riippuu tilanteesta.

ISR:n merkitys

ISR-sarjan avulla voit valita optimaalisen tasapainon tietoturvan ja latenssin välillä. Varmista esimerkiksi käytettävyys useimpien replikoiden epäonnistuessa ja minimoi kuolleiden tai hitaiden kopioiden vaikutus latenssiin nähden.

Valitsemme merkityksen itse replica.lag.time.max.ms tarpeidesi mukaan. Pohjimmiltaan tämä parametri tarkoittaa, kuinka paljon viivettä olemme valmiita hyväksymään milloin acks = kaikki. Oletusarvo on kymmenen sekuntia. Jos tämä on sinulle liian pitkä, voit vähentää sitä. Sitten ISR:n muutosten tiheys kasvaa, koska seuraajia poistetaan ja lisätään useammin.

RabbitMQ on yksinkertaisesti joukko peilejä, jotka on kopioitava. Hitaat peilit lisäävät latenssia, ja kuolleet peilit voivat odottaa, kunnes paketit, jotka tarkistavat kunkin solmun saatavuuden (net tick), vastaavat. ISR on mielenkiintoinen tapa välttää nämä latenssiongelmat. Mutta olemme vaarassa menettää redundanssin, koska ISR voi vain kutistua johtajaksi. Vältä tämä riski käyttämällä asetusta min.insync.replicas.

Asiakasyhteyden takuu

Asetuksissa bootstrap.servers tuottaja ja kuluttaja voivat määrittää useita välittäjiä asiakkaiden yhdistämiseksi. Ajatuksena on, että kun yksi solmu kaatuu, jäljelle jää useita ylimääräisiä, joilla asiakas voi avata yhteyden. Nämä eivät välttämättä ole lohkojohtajia, vaan yksinkertaisesti ponnahduslauta alkulataukseen. Asiakas voi kysyä heiltä, mikä solmu isännöi luku-/kirjoitusosion johtajaa.

RabbitMQ:ssa asiakkaat voivat muodostaa yhteyden mihin tahansa solmuun, ja sisäinen reititys lähettää pyynnön sinne, minne sen täytyy mennä. Tämä tarkoittaa, että voit asentaa kuormantasauslaitteen RabbitMQ:n eteen. Kafka vaatii asiakkaita muodostamaan yhteyden solmuun, joka isännöi vastaavaa osion johtajaa. Tällaisessa tilanteessa et voi asentaa kuormitustasainta. Lista bootstrap.servers On erittäin tärkeää, että asiakkaat voivat käyttää ja löytää oikeat solmut vian jälkeen.

Kafka Consensus -arkkitehtuuri

Emme ole toistaiseksi pohtineet, miten klusteri saa tietää välittäjän kaatumisesta ja miten uusi johtaja valitaan. Ymmärtääksesi, kuinka Kafka toimii verkkoosioiden kanssa, sinun on ensin ymmärrettävä konsensusarkkitehtuuri.

Jokainen Kafka-klusteri otetaan käyttöön yhdessä Zookeeper-klusterin kanssa, joka on hajautettu konsensuspalvelu, jonka avulla järjestelmä voi päästä yhteisymmärrykseen tietystä tilasta priorisoimalla johdonmukaisuuden saatavuuden edelle. Luku- ja kirjoitustoimintojen hyväksyminen edellyttää useimpien Zookeeper-solmujen suostumusta.

Zookeeper tallentaa klusterin tilan:

Luettelo aiheista, osioista, määrityksistä, nykyiset johtajakopiot, ensisijaiset replikat.
Klusterin jäsenet. Jokainen välittäjä pingaa Zookeeper-klusteria. Jos se ei saa pingiä tietyn ajan kuluessa, Zookeeper kirjaa välittäjän olevan tavoitettavissa.
Ohjaimen pää- ja varasolmun valinta.

Ohjainsolmu on yksi Kafka-välittäjistä, joka vastaa replikajohtajien valinnasta. Zookeeper lähettää rekisterinpitäjälle ilmoitukset klusterin jäsenyyteen ja aiheeseen liittyvistä muutoksista, ja rekisterinpitäjän on toimittava näiden muutosten johdosta.

Otetaan esimerkiksi uusi aihe, jossa on kymmenen osiota ja replikointikerroin 3. Ohjaimen on valittava jokaiselle osiolle johtaja yrittäen jakaa johtajat optimaalisesti välittäjien kesken.

Jokaiselle lohkoohjaimelle:

päivittää Zookeeperin tietoja ISR:stä ja johtajasta;
Lähettää LeaderAndISRC-komennon jokaiselle välittäjälle, joka isännöi tämän osion kopiota, ja ilmoittaa välittäjille ISR:stä ja johtajasta.

Kun välittäjä, jolla on johtaja, kaatuu, Zookeeper lähettää ilmoituksen valvojalle ja se valitsee uuden johtajan. Jälleen ohjain päivittää ensin Zookeeperin ja lähettää sitten kullekin välittäjälle komennon, joka ilmoittaa heille johtajuuden vaihdosta.

Jokainen johtaja on vastuussa ISR: n värväämisestä. asetukset replica.lag.time.max.ms määrää kuka sinne tulee. Kun ISR muuttuu, johtaja välittää uudet tiedot Zookeeperille.

Eläintarhanhoitajalle tiedotetaan aina muutoksista, jotta johto vaihtuu vian sattuessa sujuvasti uudelle johtajalle.

Riisi. 21. Kafka-konsensus

Replikointiprotokolla

Replikoinnin yksityiskohtien ymmärtäminen auttaa sinua ymmärtämään paremmin mahdollisia tietojen menetysskenaarioita.

Otantakyselyt, lokin loppusiirtymä (LEO) ja korkeavesimerkki (HW)

Katsoimme, että seuraajat lähettävät ajoittain noutopyyntöjä johtajalle. Oletusarvo on 500 ms. Tämä eroaa RabbitMQ:sta siinä, että RabbitMQ:ssa replikointia ei aloita jonopeili vaan isäntä. Mestari työntää vaihdot peileihin.

Johtaja ja kaikki seuraajat tallentavat Log End Offset (LEO) ja Highwater (HW) -merkinnän. LEO-merkki tallentaa viimeisen viestin siirtymän paikalliseen replikaan, ja HW säilyttää viimeisen vahvistuksen siirtymän. Muista, että vahvistustila edellyttää, että sanoma säilyy kaikissa ISR-kopioissa. Tämä tarkoittaa, että LEO on yleensä hieman HW:tä edellä.

Kun johtaja vastaanottaa viestin, se tallentaa sen paikallisesti. Seuraaja tekee noutopyynnön lähettämällä LEOnsa. Johtaja lähettää sitten joukon viestejä alkaen tästä LEO:sta ja lähettää myös nykyisen HW:n. Kun johtaja saa tiedon, että kaikki replikat ovat tallentaneet viestin annetulla siirtymällä, se siirtää HW-merkkiä. Vain johtaja voi siirtää HW:tä, joten kaikki seuraajat tietävät senhetkisen arvon pyyntöihinsä olevissa vastauksissa. Tämä tarkoittaa, että seuraajat voivat jäädä johtajasta jälkeen sekä viestissä että HW-tiedoissa. Kuluttajat saavat viestejä vain nykyiseen HW:hen asti.

Huomaa, että "pysyi" tarkoittaa kirjoitettua muistiin, ei levylle. Suorituskykyä varten Kafka synkronoi levylle tietyin väliajoin. Myös RabbitMQ:lla on tällainen aikaväli, mutta se lähettää kuittauksen julkaisijalle vasta kun isäntä ja kaikki peilit ovat kirjoittaneet viestin levylle. Kafkan kehittäjät päättivät suorituskykysyistä lähettää kuittauksen heti, kun viesti on kirjoitettu muistiin. Kafka vetoaa, että redundanssi kompensoi sen riskin, että kuitatut viestit tallennetaan hetkeksi vain muistiin.

Johtajan epäonnistuminen

Kun johtaja kaatuu, Zookeeper ilmoittaa ohjaajalle ja se valitsee uuden johtajakopion. Uusi johtaja asettaa uuden HW-merkin LEO:nsa mukaan. Seuraajat saavat sitten tietoa uudesta johtajasta. Kafkan versiosta riippuen seuraaja valitsee yhden kahdesta skenaariosta:

Se katkaisee paikallisen lokin tunnetuksi HW:ksi ja lähettää uudelle johtajalle tämän merkin jälkeisiä viestejä.
Lähettää johtajalle pyynnön selvittää HW silloin, kun hänet valittiin johtajaksi, ja katkaisee lokin tämän siirroksen mukaan. Sen jälkeen se alkaa tehdä säännöllisiä noutopyyntöjä tästä siirrosta alkaen.

Seuraajan on ehkä katkaistava loki seuraavista syistä:

Kun johtaja epäonnistuu, ensimmäinen Zookeeperiin rekisteröity seuraaja ISR-joukossa voittaa vaalit ja hänestä tulee johtaja. Kaikki ISR:n seuraajat, vaikka niitä pidetään "synkronoituina", eivät ehkä ole saaneet kopioita kaikista viesteistä entiseltä johtajalta. On täysin mahdollista, että suositellulla seuraajalla ei ole viimeisintä kopiota. Kafka varmistaa, ettei kopioiden välillä ole eroja. Näin ollen erojen välttämiseksi jokaisen seuraajan on lyhennettävä lokinsa uuden johtajan HW-arvoksi hänen valintansa aikaan. Tämä on toinen syy asettamiseen acks = kaikki niin tärkeää johdonmukaisuuden kannalta.
Viestit kirjoitetaan säännöllisesti levylle. Jos kaikki klusterin solmut epäonnistuvat samanaikaisesti, levyille tallennetaan replikoita, joilla on eri siirtymät. On mahdollista, että kun välittäjät palaavat verkkoon, valittu uusi johtaja jää seuraajiensa taakse, koska hänet on tallennettu levylle ennen muita.

Tapaaminen klusterin kanssa

Liittyessään uudelleen klusteriin kopiot tekevät samoin kuin johtajan epäonnistuessa: ne tarkistavat johtajan replikan ja lyhentävät lokinsa sen HW:ksi (valinnan aikaan). Vertailun vuoksi RabbitMQ kohtelee uudelleen yhdistettyjä solmuja täysin uusina. Molemmissa tapauksissa välittäjä hylkää kaikki olemassa olevat tilat. Jos käytetään automaattista synkronointia, isäntälaitteen on kopioitava ehdottomasti kaikki nykyinen sisältö uuteen peiliin "anna koko maailman odottaa" -menetelmällä. Isäntä ei hyväksy mitään luku- tai kirjoitustoimintoja tämän toiminnon aikana. Tämä lähestymistapa aiheuttaa ongelmia suurissa jonoissa.

Kafka on hajautettu loki ja yleensä se tallentaa enemmän viestejä kuin RabbitMQ-jono, jossa tiedot poistetaan jonosta sen lukemisen jälkeen. Aktiivisten jonojen tulisi pysyä suhteellisen pieninä. Mutta Kafka on loki, jolla on oma säilytyskäytäntönsä, joka voi asettaa ajanjakson päiviä tai viikkoja. Jonon estoa ja täydellistä synkronointia ei voida hyväksyä hajautetun lokin tapauksessa. Sen sijaan Kafkan seuraajat yksinkertaisesti katkaisivat lokinsa johtajan HW:ksi (hänen valinnan aikaan), jos heidän kopionsa on johtajaa edellä. Todennäköisemmässä tapauksessa, kun seuraaja on jäljessä, se yksinkertaisesti alkaa tehdä noutopyyntöjä alkaen nykyisestä LEO:sta.

Uudet tai uudelleen liittyneet seuraajat aloittavat ISR:n ulkopuolelta eivätkä osallistu sitoumuksiin. He yksinkertaisesti työskentelevät ryhmän rinnalla ja saavat viestejä niin nopeasti kuin voivat, kunnes he tavoittavat johtajan ja tulevat ISR:ään. Ei lukitusta, eikä kaikkia tietojasi tarvitse heittää pois.

Yhteyden katkeaminen

Kafkassa on enemmän komponentteja kuin RabbitMQ:ssa, joten sen käyttäytyminen on monimutkaisempaa, kun klusteri katkeaa. Mutta Kafka on alun perin suunniteltu klustereita varten, joten ratkaisut ovat hyvin harkittuja.

Alla on useita yhteyshäiriöskenaarioita:

Skenaario 1: Seuraaja ei näe johtajaa, mutta näkee silti eläintarhanhoitajan.
Skenaario 2: Johtaja ei näe seuraajia, mutta näkee silti Zookeeperin.
Skenaario 3: Seuraaja näkee johtajan, mutta ei näe eläintarhanhoitajaa.
Skenaario 4: Johtaja näkee seuraajat, mutta ei näe eläintarhanhoitajaa.
Skenaario 5: Seuraaja on täysin erillään sekä muista Kafka-solmuista että Zookeeperistä.
Skenaario 6: Johtaja on täysin erillään sekä muista Kafka-solmuista että Zookeeperistä.
Skenaario 7: Kafka-ohjainsolmu ei näe toista Kafka-solmua.
Skenaario 8: Kafka-ohjain ei näe Zookeeperiä.

Jokaisella skenaariolla on oma käyttäytymisensä.

Skenaario 1: Seuraaja ei näe johtajaa, mutta näkee silti Zookeeperin

Riisi. 22. Skenaario 1: Kolmen replikan ISR

Yhteysvirhe erottaa välittäjän 3 välittäjistä 1 ja 2, mutta ei Zookeeperistä. Broker 3 ei voi enää lähettää noutopyyntöjä. Kun aika on kulunut replica.lag.time.max.ms se poistetaan ISR:stä eikä osallistu viestisitoumuksiin. Kun yhteys on palautettu, se jatkaa pyyntöjen noutoa ja liittyy ISR:ään, kun se tavoittaa johtajan. Zookeeper vastaanottaa edelleen pingit ja olettaa, että välittäjä on elossa ja voi hyvin.

Riisi. 23. Skenaario 1: Välittäjä poistetaan ISR:stä, jos siltä ei saada noutopyyntöä replica.lag.time.max.ms aikavälillä

Ei ole jaettua aivo- tai solmususpensiota, kuten RabbitMQ:ssa. Sen sijaan redundanssia vähennetään.

Skenaario 2: Leader ei näe seuraajia, mutta näkee silti Zookeeperin

Riisi. 24. Skenaario 2. Johtaja ja kaksi seuraajaa

Verkkoyhteyden katkeaminen erottaa johtajan seuraajista, mutta välittäjä voi silti nähdä Zookeeperin. Kuten ensimmäisessä skenaariossa, ISR kutistuu, mutta tällä kertaa vain johtajalle, koska kaikki seuraajat lopettavat noutopyyntöjen lähettämisen. Jälleen kerran, ei ole loogista jakoa. Sen sijaan uusien viestien redundanssi häviää, kunnes yhteys palautetaan. Zookeeper saa edelleen pingejä ja uskoo, että välittäjä on elossa ja voi hyvin.

Riisi. 25. Skenaario 2. ISR on kutistunut vain johtajaksi

Skenaario 3. Seuraaja näkee johtajan, mutta ei näe eläintarhanhoitajaa

Seuraaja on erotettu Zookeeperista, mutta ei välittäjästä johtajan kanssa. Tämän seurauksena seuraaja jatkaa hakupyyntöjen tekemistä ja on ISR:n jäsen. Zookeeper ei enää saa pingejä ja rekisteröi välittäjän kaatuman, mutta koska se on vain seuraaja, toipumisen jälkeen ei ole seurauksia.

Riisi. 26. Skenaario 3: Seuraaja jatkaa hakupyyntöjen lähettämistä johtajalle

Skenaario 4. Johtaja näkee seuraajia, mutta ei Zookeeperia

Riisi. 27. Skenaario 4. Johtaja ja kaksi seuraajaa

Johtaja on erotettu Zookeeperista, mutta ei välittäjistä, joilla on seuraajia.

Riisi. 28. Skenaario 4: Johtaja eristetty Zookeeperista

Jonkin ajan kuluttua Zookeeper rekisteröi välittäjän vian ja ilmoittaa siitä rekisterinpitäjälle. Hän valitsee uuden johtajan seuraajiensa joukosta. Alkuperäinen johtaja ajattelee kuitenkin edelleen olevansa johtaja ja hyväksyy edelleen ilmoittautumiset acks=1. Seuraajat eivät enää lähetä hänelle noutopyyntöjä, joten hän pitää niitä kuolleina ja yrittää kutistaa ISR:n itselleen. Mutta koska sillä ei ole yhteyttä Zookeeperiin, se ei voi tehdä tätä ja kieltäytyy siinä vaiheessa hyväksymästä muita merkintöjä.

Сообщения acks = kaikki ei saa kuittausta, koska ISR käynnistää ensin kaikki kopiot, eivätkä viestit saavuta niitä. Kun alkuperäinen johtaja yrittää poistaa ne ISR:stä, se ei voi tehdä niin ja lakkaa hyväksymästä viestejä ollenkaan.

Asiakkaat huomaavat pian johtajan muutoksen ja alkavat lähettää tietueita uudelle palvelimelle. Kun verkko on palautettu, alkuperäinen johtaja näkee, ettei se ole enää johtaja, ja katkaisee lokinsa HW-arvoksi, joka uudella johtajalla oli epäonnistumishetkellä lokien eron välttämiseksi. Sen jälkeen se alkaa lähettää hakupyyntöjä uudelle johtajalle. Kaikki alkuperäisen johtajan tietueet, joita ei kopioida uudelle johtajalle, menetetään. Toisin sanoen viestit, joita alkuperäinen johtaja ei kuitannut niiden muutaman sekunnin aikana, kun kaksi johtajaa työskenteli, menetetään.

Riisi. 29. Skenaario 4. Välittäjä 1:n johtajasta tulee seuraaja, kun verkko on palautettu

Skenaario 5: Seuraaja on täysin erillään sekä muista Kafka-solmuista että Zookeeperistä

Seuraaja on täysin eristetty sekä muista Kafka-solmuista että Zookeeperistä. Hän yksinkertaisesti poistaa itsensä ISR:stä, kunnes verkko on palautettu, ja tavoittaa sitten muut.

Riisi. 30. Skenaario 5: Eristetty seuraaja poistetaan ISR:stä

Skenaario 6: Johtaja on täysin erillään sekä muista Kafka-solmuista että Zookeeperistä

Riisi. 31. Skenaario 6. Johtaja ja kaksi seuraajaa

Johtaja on täysin eristetty seuraajistaan, valvojasta ja eläintarhanhoitajasta. Lyhyen ajan se ottaa vastaan ilmoittautumisia alkaen acks=1.

Riisi. 32. Skenaario 6: Johtajan eristäminen muista Kafka- ja Zookeeper-solmuista

Koska pyyntöjä ei ole saatu vanhenemisen jälkeen replica.lag.time.max.ms, se yrittää kutistaa ISR:n itselleen, mutta ei voi tehdä niin, koska Zookeeperin kanssa ei ole yhteyttä, niin se lakkaa hyväksymästä kirjoituksia.

Sillä välin Zookeeper merkitsee eristetyn välittäjän kuolleeksi ja valvoja valitsee uuden johtajan.

Riisi. 33. Skenaario 6. Kaksi johtajaa

Alkuperäinen johtaja voi hyväksyä merkintöjä muutaman sekunnin ajan, mutta lakkaa sitten hyväksymästä viestejä. Asiakkaat päivitetään uusimmilla metatiedoilla 60 sekunnin välein. Heille ilmoitetaan johtajan vaihdosta ja he alkavat lähettää merkintöjä uudelle johtajalle.

Riisi. 34. Skenaario 6: Valmistajat vaihtavat uuteen johtajaan

Kaikki vahvistetut merkinnät, jotka alkuperäinen johtaja on tehnyt yhteyden katkeamisen jälkeen, menetetään. Kun verkko on palautettu, alkuperäinen johtaja huomaa Zookeeperin kautta, ettei hän ole enää johtaja. Sitten se katkaisee lokinsa uuden johtajan HW:ksi valintahetkellä ja alkaa lähettää pyyntöjä seuraajana.

Riisi. 35. Skenaario 6: Alkuperäisestä johtajasta tulee seuraaja, kun verkkoyhteys on palautettu

Tässä tilanteessa looginen erottelu voi tapahtua lyhyeksi ajaksi, mutta vain jos acks=1 и min.insync.replicas myös 1. Looginen erottelu päättyy automaattisesti joko verkon palauttamisen jälkeen, kun alkuperäinen johtaja tajuaa, ettei hän enää ole johtaja, tai kun kaikki asiakkaat ymmärtävät johtajan vaihtuneen ja alkavat kirjoittaa uudelle johtajalle - kumpi tapahtuu ensin. Joka tapauksessa jotkut viestit menetetään, mutta vain acks=1.

Tästä skenaariosta on toinen muunnelma, jossa juuri ennen verkon jakautumista seuraajat jäivät jälkeen ja johtaja pakkasi ISR:n vain itselleen. Sitten se eristyy yhteyden katkeamisen vuoksi. Uusi johtaja valitaan, mutta alkuperäinen johtaja hyväksyy edelleen ilmoittautumiset acks = kaikki, koska ISR:ssä ei ole ketään muuta kuin hän. Nämä tietueet menetetään, kun verkko palautetaan. Ainoa tapa välttää tämä vaihtoehto on min.insync.replicas = 2.

Skenaario 7: Kafka-ohjainsolmu ei näe toista Kafka-solmua

Yleensä, kun yhteys Kafka-solmuun katkeaa, ohjain ei voi lähettää sille mitään johtajan muutostietoja. Pahimmassa tapauksessa tämä johtaa lyhytaikaiseen loogiseen eroon, kuten skenaariossa 6. Useimmiten välittäjästä ei yksinkertaisesti tule johtajaehdokasta, jos jälkimmäinen epäonnistuu.

Skenaario 8: Kafka-ohjain ei näe Zookeeperiä

Zookeeper ei saa pingiä kaatuneelta ohjaimelta ja valitsee ohjaimeksi uuden Kafka-solmun. Alkuperäinen ohjain voi edelleen esitellä itsensä sellaisenaan, mutta se ei saa ilmoituksia Zookeeperilta, joten sillä ei ole tehtäviä suoritettavana. Kun verkko on palautettu, hän ymmärtää, ettei hän ole enää ohjain, vaan hänestä on tullut tavallinen Kafka-solmu.

Johtopäätökset skenaarioista

Näemme, että seuraajayhteyden menetys ei johda viestien katoamiseen, vaan se yksinkertaisesti vähentää väliaikaisesti redundanssia, kunnes verkko palautetaan. Tämä voi tietysti johtaa tietojen menetykseen, jos yksi tai useampi solmu katoaa.

Jos johtaja eroaa Zookeeperista yhteyden katkeamisen vuoksi, tämä voi johtaa viestien katoamiseen acks=1. Viestinnän puute Zookeeperin kanssa aiheuttaa lyhyen loogisen eron kahden johtajan välillä. Tämä ongelma ratkaistaan parametrilla acks = kaikki.

Parametri min.insync.replicas kahteen tai useampaan kopioon tarjoaa lisävarmuutta siitä, että tällaiset lyhyen aikavälin skenaariot eivät johda kadonneisiin viesteihin, kuten skenaariossa 6.

Yhteenveto kadonneista viesteistä

Listataan kaikki tavat, joilla voit menettää tietoja Kafkassa:

Mikä tahansa johtajavirhe, jos viestit vahvistettiin käyttämällä acks=1
Mikä tahansa epäpuhdas siirtyminen johtajuudesta, eli seuraajaksi ISR:n ulkopuolella, jopa sen kanssa acks = kaikki
Johtajan eristäminen Zookeeperista, jos viestit vahvistettiin käyttämällä acks=1
Johtajan täydellinen eristäminen, joka on jo kutistanut ISR-ryhmän itselleen. Kaikki viestit menetetään, jopa acks = kaikki. Tämä on totta vain, jos min.insync.replicas=1.
Kaikkien osiosolmujen samanaikaiset viat. Koska viestit kuitataan muistista, joitain viestejä ei ehkä vielä ole kirjoitettu levylle. Palvelinten uudelleenkäynnistyksen jälkeen jotkut viestit saattavat puuttua.

Epäpuhtaat johtajuuden siirtymät voidaan välttää joko kieltämällä ne tai varmistamalla vähintään kaksi irtisanomista. Kestävin kokoonpano on yhdistelmä acks = kaikki и min.insync.replicas lisää 1.

Suora vertailu RabbitMQ:n ja Kafkan luotettavuudesta

Luotettavuuden ja korkean käytettävyyden varmistamiseksi molemmat alustat toteuttavat ensisijaisen ja toissijaisen replikointijärjestelmän. RabbitMQ:lla on kuitenkin akilleen kantapää. Kun yhteys muodostetaan uudelleen epäonnistumisen jälkeen, solmut hylkäävät tietonsa ja synkronointi estetään. Tämä kaksinkertainen hämäys asettaa kyseenalaiseksi suurten jonojen keston RabbitMQ:ssa. Sinun on hyväksyttävä joko vähennetty redundanssi tai pitkät estoajat. Redundanssin vähentäminen lisää suuren datan menetyksen riskiä. Mutta jos jonot ovat pieniä, voidaan redundanssin vuoksi käsitellä lyhyitä poissaolojaksoja (muutama sekunti) käyttämällä toistuvia yhteysyrityksiä.

Kafkalla ei ole tätä ongelmaa. Se hylkää tiedot vain johtajan ja seuraajan välisestä erosta. Kaikki jaetut tiedot tallennetaan. Lisäksi replikointi ei estä järjestelmää. Johtaja ottaa vastaan viestejä samalla kun uusi seuraaja saa kiinni, joten devopsille klusteriin liittyminen tai siihen liittyminen on triviaali tehtävä. Tietenkin on edelleen ongelmia, kuten verkon kaistanleveys replikoinnin aikana. Jos lisäät useita seuraajia samanaikaisesti, saatat kohdata kaistanleveysrajoituksen.

RabbitMQ on Kafkaa parempi luotettavuudessa, kun useat klusterin palvelimet epäonnistuvat samanaikaisesti. Kuten olemme jo sanoneet, RabbitMQ lähettää vahvistuksen julkaisijalle vasta, kun isäntä ja kaikki peilit ovat kirjoittaneet viestin levylle. Mutta tämä lisää viivettä kahdesta syystä:

fsync muutaman sadan millisekunnin välein
Peilin epäonnistuminen voidaan havaita vasta, kun kunkin solmun (net tick) saatavuutta tarkistavien pakettien käyttöikä on umpeutunut. Jos peili hidastuu tai putoaa, tämä lisää viivettä.

Kafkan veto on, että jos viesti on tallennettu useisiin solmuihin, se voi kuitata viestit heti, kun ne osuvat muistiin. Tästä johtuen on olemassa vaara minkä tahansa tyyppisten viestien katoamisesta (jopa acks = kaikki, min.insync.replicas=2) samanaikaisen vian sattuessa.

Kaiken kaikkiaan Kafka tarjoaa paremman ohjelmiston suorituskyvyn ja on suunniteltu alusta alkaen klustereita varten. Seuraajien määrä voidaan nostaa 11:een, jos se on tarpeen luotettavuuden vuoksi. Replikointitekijä 5 ja kopioiden vähimmäismäärä synkronoinnissa min.insync.replicas=3 tekee viestin katoamisesta erittäin harvinaisen tapahtuman. Jos infrastruktuurisi tukee tätä replikointisuhdetta ja redundanssitasoa, voit valita tämän vaihtoehdon.

RabbitMQ-klusterointi on hyvä pienille jonoille. Mutta pienetkin jonot voivat kasvaa nopeasti, kun liikennettä on paljon. Kun jonot kasvavat suuriksi, sinun on tehtävä vaikeita valintoja saatavuuden ja luotettavuuden välillä. RabbitMQ-klusterointi soveltuu parhaiten epätyypillisiin tilanteisiin, joissa RabbitMQ:n joustavuuden edut ovat suuremmat kuin sen klusteroinnin haitat.

Yksi vastalääke RabbitMQ:n haavoittuvuudelle suuria jonoja vastaan on jakaa ne useisiin pienempiin jonoihin. Jos et vaadi koko jonon täydellistä tilaamista, vaan vain asiaankuuluvat viestit (esimerkiksi tietyn asiakkaan viestit) tai et tilaa mitään, tämä vaihtoehto on hyväksyttävä: katso projektini Tasapainotin jakaa jonon (projekti on vielä alkuvaiheessa).

Lopuksi, älä unohda lukuisia virheitä sekä RabbitMQ:n että Kafkan klusterointi- ja replikointimekanismeissa. Ajan myötä järjestelmistä on tullut kypsempiä ja vakaampia, mutta mikään viesti ei ole koskaan 100 % turvassa katoamiselta! Lisäksi datakeskuksissa tapahtuu suuria onnettomuuksia!

Jos minulta jäi jotain huomaamatta, tein virheen tai olet eri mieltä jostakin kohdasta, kirjoita kommentti tai ota minuun yhteyttä.

Minulta kysytään usein: "Mitä valita, Kafka vai RabbitMQ?", "Kumpi alusta on parempi?". Totuus on, että se riippuu todella tilanteestasi, tämän hetkisestä kokemuksesta jne. En epäröi antaa mielipidettäni, koska olisi liikaa yksinkertaistusta suositella yhtä alustaa kaikkiin käyttötapauksiin ja mahdollisiin rajoituksiin. Kirjoitin tämän artikkelisarjan, jotta voit muodostaa oman mielipiteesi.

Haluan sanoa, että molemmat järjestelmät ovat johtavia tällä alalla. Saatan olla hieman puolueellinen, koska kokemukseni projekteista minulla on tapana arvostaa asioita, kuten taattua viestien järjestystä ja luotettavuutta.

Näen muita teknologioita, joista puuttuu tämä luotettavuus ja taattu tilaus. Sitten katson RabbitMQ:ta ja Kafkaa ja ymmärrän näiden molempien järjestelmien uskomattoman arvon.

Lähde: will.com

RabbitMQ vs Kafka: Vikasietokyky ja korkea saatavuus