Tulles üle kümne aasta arendatud toote juurde, pole sugugi üllatav leida selles aegunud tehnoloogiaid. Aga mis siis, kui kuue kuu jooksul peate hoidma koormust 10 korda suuremana ja kukkumiste hind tõuseb sadu kordi? Sel juhul vajate lahedat Highload Engineerit. Kuid neiu puudumisel usaldasid nad minule probleemi lahendamise. Artikli esimeses osas räägin teile, kuidas me Redisest Redis-klastrisse liikusime ning teises osas annan nõu, kuidas klastrit kasutama hakata ja millele selle kasutamisel tähelepanu pöörata.

Tehnoloogia valik

Kas see on nii halb? eraldi Redis (eraldi redis) konfiguratsioonis 1 ülem ja N alamseadet? Miks ma nimetan seda vananenud tehnoloogiaks?

Ei, Redis pole nii hull... Siiski on mõned puudused, millest ei saa mööda vaadata.

• Esiteks ei toeta Redis avariitaastemehhanisme pärast põhitõrget. Selle probleemi lahendamiseks kasutasime konfiguratsiooni VIP-ide automaatse ülekandmisega uuele ülemale, muutes ühe alluva rolli ja vahetades ülejäänud. See mehhanism töötas, kuid seda ei saanud nimetada usaldusväärseks lahenduseks. Esiteks tekkisid valehäired ja teiseks oli see ühekordselt kasutatav ning vedru laadimiseks tuli pärast kasutamist käsitsi toimida.

• Teiseks tõi ainult ühe meistri olemasolu kaasa killustumise probleemi. Tuli luua mitu sõltumatut klastrit “1 master ja N slaves”, seejärel jaotada andmebaasid käsitsi nende masinate vahel ja loota, et homme ei paisu üks andmebaasidest nii suureks, et see tuleb eraldi eksemplari viia.

Millised on võimalused?

• Kõige kallim ja rikkalikum lahendus on Redis-Enterprise. See on täieliku tehnilise toega kastilahendus. Hoolimata asjaolust, et see näeb tehnilisest küljest ideaalne välja, ei sobinud see meile ideoloogilistel põhjustel.
• Redis-klaster. Karbist väljas on tugi peamise tõrkesiirde ja jagamise jaoks. Liides ei erine peaaegu üldse tavalisest versioonist. See tundub paljutõotav, lõksudest räägime hiljem.
• Tarantool, Memcache, Aerospike ja teised. Kõik need tööriistad teevad peaaegu sama asja. Kuid igal neist on oma puudused. Otsustasime, et ei pane kõiki mune ühte korvi. Muudeks ülesanneteks kasutame Memcache'i ja Tarantooli ning tulevikku vaadates ütlen, et meie praktikas oli nendega rohkem probleeme.

Kasutamise eripära

Vaatame, milliseid probleeme oleme Redisega ajalooliselt lahendanud ja milliseid funktsioone kasutasime:

• Vahemälu enne kaugteenuste (nt 2GIS |) päringuid Golang
  

  GET SET MGET MSET "SELECT DB"

• Vahemälu enne MYSQL-i | PHP
  

  GET SET MGET MSET SCAN "KEY BY PATTERN" "SELECT DB"

• Seansside ja juhi koordinaatidega töötamise teenuse põhimälu | Golang
  

  GET SET MGET MSET "SELECT DB" "ADD GEO KEY" "GET GEO KEY" SCAN

Nagu näete, pole kõrgemat matemaatikat. Milles siis raskus seisneb? Vaatame iga meetodit eraldi.

Meetod
Kirjeldus
Redis-klastri omadused
otsus

SAADA Sättida
Kirjutamis-/lugemisklahv

MGET MSET
Mitme klahvi kirjutamine/lugemine
Võtmed asuvad erinevates sõlmedes. Valmis teegid saavad teha mitut toimingut ainult ühes sõlmes
Asendage MGET N GET-toimingu konveieriga

VALI DB
Valige alus, millega töötame
Ei toeta mitut andmebaasi
Pange kõik ühte andmebaasi. Lisage klahvidele eesliited

SCAN
Vaadake läbi kõik andmebaasis olevad võtmed
Kuna meil on üks andmebaas, on klastri kõigi võtmete läbimine liiga kallis
Säilitage invariant ühes võtmes ja tehke sellel võtmel HSCAN. Või keelduda täielikult

GEO
Toimingud geovõtmega
Geovõtit pole killustatud

VÕTI MUSTRI JÄRGI
Võtme otsimine mustri järgi
Kuna meil on üks andmebaas, otsime klastri kõigi võtmete järgi. Liiga kallis
Keelduge invariantist või säilitage see, nagu SCAN-i puhul

Redis vs Redis-klaster

Mida me klastrile üleminekul kaotame ja mida võidame?

• Puudused: kaotame mitme andmebaasi funktsionaalsuse.
  • Kui tahame salvestada loogiliselt mitteseotud andmeid ühes klastris, peame tegema kargud eesliidete kujul.
  • Kaotame kõik "baas" toimingud, nagu SCAN, DBSIZE, CLEAR DB jne.
  • Mitmiktoiminguid on palju keerulisem rakendada, kuna see võib nõuda juurdepääsu mitmele sõlmele.
• Plussid:
  • Veataluvus põhitõrkesiirde kujul.
  • Jagamine Redise poolel.
  • Andmete ülekandmine sõlmede vahel aatomiliselt ja ilma seisakuta.
  • Lisage ja jaotage võimsust ja koormusi ilma seisakuta ümber.

Järeldaksin, et kui te ei pea tagama kõrget tõrketaluvust, siis pole klastrisse kolimine seda väärt, sest see võib olla mittetriviaalne ülesanne. Aga kui valite esialgu eraldi versiooni ja klastriversiooni vahel, siis peaksite valima klastri, kuna see pole halvem ja lisaks vabastab teid mõnest peavalust

Liikumiseks valmistumine

Alustame kolimise nõuetega:

• See peaks olema õmblusteta. Täielik teeninduse peatumine 5 minutiks meile ei sobi.
• See peaks olema võimalikult ohutu ja järkjärguline. Ma tahan omada olukorra üle kontrolli. Me ei taha kõike korraga maha jätta ja tagasipööramisnupu üle palvetada.
• Minimaalne andmekadu kolimisel. Mõistame, et atomaarselt liikuda on väga raske, seetõttu lubame tavalises ja rühmitatud Redis andmete vahel mõningast desünkroniseerimist.

Klastrite hooldus

Vahetult enne kolimist tuleks mõelda, kas saame klastrit toetada:

• Diagrammid. Me kasutame Prometheust ja Grafanat CPU koormuse, mälukasutuse, klientide arvu, GET-i, SET-i, AUTH-operatsioonide jne graafiku tegemiseks.
• Ekspertiis. Kujutage ette, et homme on teie vastutusel tohutu klaster. Kui see katki läheb, ei saa keegi peale teie seda parandada. Kui ta hakkab hoogu maha võtma, jooksevad kõik sinu poole. Kui teil on vaja ressursse lisada või koormust ümber jaotada, pöörduge tagasi. Et mitte 25-aastaselt halliks muutuda, on soovitatav need juhtumid ette näha ja eelnevalt kontrollida, kuidas tehnoloogia teatud toimingute korral käitub. Räägime sellest üksikasjalikumalt jaotises “Ekspertiis”.
• Jälgimine ja hoiatused. Kui klaster laguneb, soovite sellest esimesena teada saada. Siin piirdusime märguandega, et kõik sõlmed tagastavad klastri oleku kohta sama teabe (jah, see juhtub erinevalt). Ja muid probleeme saab Redise klienditeeninduste hoiatuste abil kiiremini märgata.

Liikuma

Kuidas me liigume:

• Kõigepealt peate klastriga töötamiseks ette valmistama raamatukogu. Võtsime Go-versiooni aluseks go-redise ja muutsime seda veidi enda jaoks sobivaks. Rakendasime mitu meetodit torujuhtmete kaudu ja parandasime veidi ka korduvate päringute reegleid. PHP versiooniga oli rohkem probleeme, kuid lõpuks otsustasime php-redisega. Nad võtsid hiljuti kasutusele klastri toe ja meie arvates tundub see hea.
• Järgmisena peate juurutama klastri enda. Seda tehakse sõna otseses mõttes kahe käsuga, mis põhinevad konfiguratsioonifailil. Allpool käsitleme seadet üksikasjalikumalt.
• Järkjärguliseks teisaldamiseks kasutame kuivrežiimi. Kuna meil on kaks sama liidesega teegi versiooni (üks tavaversiooni jaoks, teine ​​klastri jaoks), ei maksa luua ümbrist, mis töötab eraldi versiooniga ja dubleerib paralleelselt kõik päringud klastrile, võrrelge vastuseid ja kirjutage logidesse lahknevused (meie puhul NewRelicis). Seega, isegi kui klastri versioon levitamise ajal puruneb, ei mõjuta see meie tootmist.
• Olles klastri kuivas režiimis välja veeretanud, saame rahulikult vaadata vastuste lahknevuste graafikut. Kui veamäär liigub aeglaselt, kuid kindlalt mõne väikese konstandi poole, siis on kõik korras. Miks on ikka veel lahknevusi? Kuna eraldi versioonis salvestamine toimub veidi varem kui klastris ja mikrolagi tõttu võivad andmed erineda. Jääb üle vaid vaadata lahknevuse logisid ja kui need kõik on seletatavad kirje mitteaatomilisusega, siis võib edasi minna.
• Nüüd saate lülitada kuivatusrežiimi vastupidises suunas. Kirjutame ja loeme klastrist ning dubleerime selle eraldi versiooniks. Milleks? Järgmise nädala jooksul tahaksin klastri tööd jälgida. Kui äkki selgub, et tippkoormusel on probleeme või me ei võtnud midagi arvesse, on meil alati tänu kuivrežiimile vana koodi ja praeguste andmete erakorraline tagasipööramine.
• Jääb vaid kuivrežiim keelata ja eraldi versioon lahti võtta.

Ekspertiisid

Esiteks lühidalt klastri disainist.

Esiteks on Redis võtmeväärtuste pood. Võtmetena kasutatakse meelevaldseid stringe. Väärtustena saab kasutada numbreid, stringe ja terveid struktuure. Viimaseid on väga palju, kuid üldise struktuuri mõistmiseks pole see meie jaoks oluline.
Järgmine abstraktsioonitase pärast võtmeid on pesad (SLOTS). Iga võti kuulub ühte 16 383 pesast. Igas pesas võib olla suvaline arv võtmeid. Seega on kõik võtmed jaotatud 16 383 lahutatud komplektiks.

Järgmiseks peab klastris olema N põhisõlme. Iga sõlme võib pidada eraldiseisvaks Redise eksemplariks, mis teab kõike klastri teiste sõlmede kohta. Iga põhisõlm sisaldab mitmeid pesasid. Iga pesa kuulub ainult ühele põhisõlmele. Kõik pesad tuleb sõlmede vahel ära jagada. Kui mõnda pesa ei eraldata, on nendesse salvestatud võtmed kättesaamatud. Mõistlik on käivitada iga peasõlm eraldi loogilises või füüsilises masinas. Samuti tasub meeles pidada, et iga sõlm töötab ainult ühes tuumas ja kui soovite samas loogilises masinas käitada mitut Redise eksemplari, veenduge, et need töötaksid erinevatel tuumadel (me pole seda proovinud, kuid teoreetiliselt peaks see toimima) . Põhisõlmed pakuvad sisuliselt regulaarset jaotust ja rohkem peasõlmi võimaldavad kirjutamis- ja lugemistaotlusi skaleerida.

Pärast seda, kui kõik võtmed on pesade vahel jaotatud ja pesad on hajutatud peasõlmede vahel, saab igale ülemsõlmele lisada suvalise arvu alluvaid sõlmi. Iga sellise ülem-alluv lingi puhul töötab tavaline replikatsioon. Slave on vaja lugemistaotluste skaleerimiseks ja peamise tõrke korral tõrkevahetuseks.

Räägime nüüd operatsioonidest, mida oleks parem teha.

Juurdepääseme süsteemile Redis-CLI kaudu. Kuna Redisel pole ühte sisenemispunkti, saate teha järgmisi toiminguid mis tahes sõlmega. Igas punktis juhin eraldi tähelepanu võimalusele sooritada operatsioon koormuse all.

• Esimene ja kõige olulisem asi, mida vajame, on klastri sõlmede toimimine. See tagastab klastri oleku, näitab sõlmede loendit, nende rolle, pesade jaotust jne. Lisateavet saate klastri teabe ja klastri pesade abil.
• Tore oleks sõlmede lisamine ja eemaldamine. Selleks on klastri kohtumise ja klastri unustamise toimingud. Pange tähele, et klastri unustamist tuleb rakendada IGALE sõlmele, nii juhtseadmetele kui ka koopiatele. Ja klastri kohtumist tuleb kutsuda ainult ühes sõlmes. See erinevus võib tekitada hämmingut, seega on parem tutvuda sellega enne, kui alustate oma klastriga otseülekannet. Sõlme lisamine toimub lahingus ohutult ja see ei mõjuta kuidagi klastri tööd (mis on loogiline). Kui kavatsete sõlme klastrist eemaldada, peaksite veenduma, et sellele ei jääks pesasid (vastasel juhul võite kaotada juurdepääsu kõigile selle sõlme võtmetele). Samuti ärge kustutage juhti, millel on orjad, vastasel juhul hääletatakse tarbetu uue ülemuse poolt. Kui sõlmedel pole enam pesasid, on see väike probleem, kuid milleks on vaja lisavalikuid, kui saame kõigepealt orjad kustutada.
• Kui peate ülem- ja alampositsioone jõuliselt vahetama, teeb seda klastri tõrkesiirde käsk. Lahingus kutsudes peate mõistma, et kapten pole operatsiooni ajal saadaval. Tavaliselt toimub lülitus vähem kui sekundiga, kuid see ei ole aatomiline. Võite eeldada, et selle aja jooksul ebaõnnestuvad mõned kaptenile saadetud taotlused.
• Enne sõlme eemaldamist klastrist ei tohiks sellel olla pesasid. Parem on need ümber levitada, kasutades käsku cluster reshard. Slotid kantakse üle ühelt meistrilt teisele. Kogu toiming võib kesta mitu minutit, see sõltub edastatavate andmete mahust, kuid edastusprotsess on ohutu ega mõjuta klastri tööd kuidagi. Seega saab kõiki andmeid ühest sõlmest teise üle kanda otse koormuse all ja muretsemata nende kättesaadavuse pärast. Siiski on ka peensusi. Esiteks on andmeedastus seotud teatud koormusega saaja ja saatja sõlmedele. Kui vastuvõtja sõlm on protsessoris juba tugevalt koormatud, siis ei tohiks te seda uute andmete vastuvõtmisega laadida. Teiseks, niipea, kui saatval ülemal pole enam ühtegi pesa, lähevad kõik selle alluvad kohe ülemseadmele, kuhu need pesad üle kanti. Ja probleem on selles, et kõik need orjad tahavad andmeid korraga sünkroonida. Ja teil veab, kui see on pigem osaline kui täielik sünkroonimine. Võtke seda arvesse ja ühendage pesade teisaldamise ja alamseadmete keelamise/ülekandmise toimingud. Või loota, et teil on piisav ohutusvaru.
• Mida teha, kui ülekande ajal avastate, et olete oma teenindusajad kuhugi kaotanud? Loodan, et see probleem teid ei puuduta, kuid kui see puudutab, on klastri parandamise toiming. Vähemalt hajutab ta pilud sõlmede vahel juhuslikus järjekorras. Soovitan kontrollida selle toimimist, eemaldades kõigepealt klastrist hajutatud pesadega sõlme. Kuna jaotamata pesades olevad andmed pole juba saadaval, on liiga hilja muretseda nende teenindusaegade saadavuse probleemide pärast. Toiming omakorda ei mõjuta hajutatud teenindusaegu.
• Teine kasulik toiming on monitor. See võimaldab teil reaalajas näha kogu sõlmele suunatud päringute loendit. Lisaks saate seda grepida ja uurida, kas seal on vajalik liiklus.

Samuti tasub mainida peamist tõrkeotsingu protseduuri. Lühidalt, see on olemas ja minu arvates töötab see suurepäraselt. Kuid ärge arvake, et kui eemaldate põhisõlmega masina toitejuhtme, lülitub Redis kohe ümber ja kliendid ei märka kaotust. Minu praktikas toimub ümberlülitamine mõne sekundiga. Selle aja jooksul ei ole osa andmeid saadaval: tuvastatakse ülemseadme kättesaamatus, sõlmed hääletavad uue poolt, alamseadmed vahetatakse, andmed sünkroonitakse. Parim viis skeemi toimimises veendumiseks on kohalike õppuste läbiviimine. Tõstke oma sülearvuti klaster üles, andke sellele minimaalne koormus, simuleerige krahhi (näiteks blokeerides pordid) ja hinnake lülituskiirust. Minu meelest võib alles pärast päeva või paar niimoodi mängides olla tehnika toimimises kindel. Noh, või loota, et tarkvara, mida pool internetti kasutab, ilmselt töötab.

Konfiguratsioon

Sageli on konfiguratsioon esimene asi, mida peate tööriistaga töötama. Ja kui kõik töötab, ei taha te isegi konfiguratsiooni puudutada. Selleks, et sundida end seadete juurde tagasi pöörduma ja need hoolikalt läbi vaatama, on vaja pingutust. Minu mäletamist mööda oli meil vähemalt kaks tõsist riket konfiguratsiooni tähelepanematuse tõttu. Pöörake erilist tähelepanu järgmistele punktidele:

• ajalõpp 0
  Aeg, mille möödudes passiivsed ühendused suletakse (sekundites). 0 - ära sulge
  Mitte iga meie raamatukogu ei suutnud ühendusi õigesti sulgeda. Selle seade keelamisel on oht, et saavutame klientide arvu piirangu. Teisest küljest, kui selline probleem on olemas, siis katkenud ühenduste automaatne katkestamine varjab seda ja me ei pruugi seda märgata. Lisaks ei tohiks te püsivate ühenduste kasutamisel seda sätet lubada.
• Salvestage xy ja lisage ainult jah
  RDB hetktõmmise salvestamine.
  RDB/AOF-i probleeme käsitleme üksikasjalikult allpool.
• stop-writes-on-bgsave-error ei & slave-serve-stale-data jah
  Kui see on lubatud, siis kui RDB hetktõmmis katkeb, lõpetab juht muudatustaotluste vastuvõtmise. Kui ühendus ülemseadmega katkeb, saab alamseade jätkata päringutele vastamist (jah). Või lõpetab reageerimise (ei)
  Me ei ole rahul olukorraga, kus Redis muutub kõrvitsaks.
• repl-ping-slave-periood 5
  Pärast seda perioodi hakkame muretsema, et kapten on katki läinud ja on aeg läbi viia tõrkeotsingu protseduur.
  Peate käsitsi leidma tasakaalu valepositiivsete ja tõrkesiirde käivitamise vahel. Meie praktikas on see 5 sekundit.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  Täpselt nii palju andmeid saame puhvrisse salvestada ebaõnnestunud koopia jaoks. Kui puhver saab otsa, peate täielikult sünkroonima.
  Praktika näitab, et parem on määrata suurem väärtus. Põhjuseid, miks koopia võib hakata hilinema, on palju. Kui see jääb maha, siis tõenäoliselt on teie meistril juba raske toime tulla ja täielik sünkroonimine on viimane piisk karikasse.
• max kliente 10000
  Maksimaalne ühekordsete klientide arv.
  Meie kogemuse kohaselt on parem määrata suurem väärtus. Redis saab suurepäraselt hakkama 10 XNUMX ühendusega. Lihtsalt veenduge, et süsteemis oleks piisavalt pistikupesasid.
• maxmemory-policy volatile-ttl
  Reegel, mille järgi võtmed kustutatakse, kui vaba mälupiir on täis.
  Siin pole oluline mitte reegel ise, vaid arusaam, kuidas see juhtub. Redist saab kiita selle eest, et mälulimiit täis saab normaalselt töötada.

RDB ja AOF probleemid

Kuigi Redis ise salvestab kogu teabe RAM-i, on olemas ka mehhanism andmete kettale salvestamiseks. Täpsemalt kolm mehhanismi:

• RDB-hetktõmmis – kõigi andmete täielik hetktõmmis. Seadistage, kasutades konfiguratsiooni SAVE XY ja sõnum "Salvesta kõigi andmete täielik hetktõmmis iga X sekundi järel, kui vähemalt Y klahvi on muutunud."
• Lisatav fail – toimingute loend nende sooritamise järjekorras. Lisab faili iga X sekundi või iga Y toimingu järel uued sissetulevad toimingud.
• RDB ja AOF on kahe eelmise kombinatsioon.

Kõigil meetoditel on oma eelised ja puudused, ma ei loetle neid kõiki, juhin lihtsalt tähelepanu punktidele, mis minu arvates pole ilmsed.

Esiteks nõuab RDB hetktõmmise salvestamine FORKi helistamist. Kui andmeid on palju, võib see mõne millisekundi kuni sekundi jooksul kogu Redise riputada. Lisaks peab süsteem eraldama sellise hetktõmmise jaoks mälu, mis toob kaasa vajaduse hoida loogilises masinas topelt RAM-i: kui Redise jaoks on eraldatud 8 GB, siis virtuaalses masinas peaks olema 16 GB. seda.

Teiseks on probleeme osalise sünkroonimisega. AOF-režiimis, kui alamseade on uuesti ühendatud, saab osalise sünkroonimise asemel teostada täieliku sünkroonimise. Miks see juhtub, ma ei saanud aru. Kuid seda tasub meeles pidada.

Need kaks punkti panevad juba mõtlema, kas meil on neid andmeid kettal tõesti vaja, kui kõik on juba orjade poolt dubleeritud. Andmed võivad kaduda ainult siis, kui kõik alamseadmed ebaõnnestuvad ja see on "alalisvoolu tulekahju" taseme probleem. Kompromissina võite teha ettepaneku salvestada andmed ainult alamseadmete kohta, kuid sel juhul peate tagama, et need orjad ei muutuks avariitaaste ajal kunagi peremeesteks (selleks on nende konfiguratsioonis alamprioriteedi seadistus). Enda jaoks mõtleme igal konkreetsel juhul selle üle, kas andmeid on vaja kettale salvestada, ja enamasti on vastus "ei".

Järeldus

Kokkuvõtteks loodan, et suutsin anda üldise ettekujutuse redis-klastri toimimisest neile, kes pole sellest veel midagi kuulnud, ning juhtisin tähelepanu ka mõnele ebaselgele punktile, mis seda kasutanud on. pikka aega.
Täname aja eest ja nagu alati, on kommentaarid teema kohta teretulnud.

Allikas: www.habr.com