Tuleviku toote puhul, mis on arenenud rohkem kui kümme aastat, ei ole sugugi üllatav kohata vananenud tehnoloogiaid. Kuid mis juhtub, kui kuue kuu pärast peate taluma koormust, mis on kümme korda suurem, ja tõusud kulud ulatuvad sadu kordi? Sellisel juhul on teil vaja tõeliselt head Highload inseneri. Kuid kuna sellist spetsialisti ei olnud, usaldati probleem minu lahendada. Artikli esimeses osas räägin, kuidas me viisime üle Redis'elt Redis-klastrisse, ja teises osas annan nõuandeid, kuidas alustada klastriga töötamist ja millele tähelepanu pöörata operatsioonide käigus.

Tehnoloogia valik

Kas eraldiseisev Redis (standalone redis) konfiguratsioonis 1 master ja N släevad on nii halb? Miks ma kutsun seda vananenud tehnoloogiaks? Ei, Redis ei ole nii halb... Siiski, on mõned puudused, mida ei saa ignoreerida.

Esiteks ei toeta Redis meistrite taastumise mehhanisme pärast rikkeid. Selle probleemi lahendamiseks kasutasime konfiguratsiooni, kus automaatselt suunati VIP-d uuele meistrile, muutes ühe släeva rolli ja lülitades ülejäänud üle. See mehhanism töötas, kuid seda ei saanud usaldusväärseks lahenduseks nimetada. Esiteks, toimusid valehäired ja teiseks, see oli ühe kasutuse jaoks mõeldud ning peale rakendamist olid vajalikud käsitsi toimingud.

• Teiseks, ühe meistri olemasolu tõi kaasa shardimise probleeme. Pidi looma mitu sõltumatut klastri "1 meister ja N släevad", seejärel käsitsi jagama andmebaase nende masinate vahel ja lootes, et järgmisel päeval ei paisu ükski andmebaas nii palju, et see tuleb viia eraldi instantsile.

• Kalleim ja rikkalik lahendus on Redis-Enterprise. See on kastilahendus koos täieliku tehnilise toega. Kuigi see tundub tehniliselt ideaalsena, ei sobinud see meile ideoloogilistel põhjustel.

Millised on variandid?

• Redis-cluster. Tootes on meistri automaatne ülehaarde ja shardimise tugi. Liides ei erine peaaegu üldse tavalise versiooniga. Tundub tõotav, räägime varjatud probleemidest hiljem.
• Redis-kluster. Kasti tohib olla toetust kapitaalide vahetamiseks ja jagamiseks. Liides ei erine peaaegu üldse tavalise versioonist. Näeb paljutõotav välja, arutame muresid hiljem.
• Tarantool, Memcache, Aerospike ja teised. Kõik need tööriistad teevad umbes sama, kuid igaühel on oma puudused. Otsustasime, et ei pane kõiki mune ühte korvi. Memcache ja Tarantool kasutame teiste ülesannete jaoks ning edasiviimiseks võin öelda, et meil on olnud rohkem probleeme nendega.

Kasutuse eripära

Vaadakem, milliseid ülesandeid oleme ajalooliselt Redis’iga lahendanud ja millist funktsionaalsust oleme kasutanud:

• Vahemälu enne päringuid kaugteenustele nagu 2GIS | Golang
  

  GET SET MGET MSET "SELECT DB"

• Vahemälu enne MYSQL | PHP
  

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

• Peamine andmemälu sessioonide ja autojuhtide koordinaatide teenuse jaoks | Golang
  

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

Nagu näete, pole siin mingit kõrgemat matemaatikat. Mis siis ikkagi on keeruline? Vaatame iga meetodit eraldi.

Meetod
Kirjeldus
Redis-klusteri omadused
Lahendus

GET SET
Kirjutamine/lugemine võtme

MGET MSET
Kirjutamine/lugemine mitmeid võtmeid
Võtmed asuvad erinevates nodides. Valmis raamatukogud suudavad teha Multi-operatsioone vaid ühe nodi piires.
Asendage MGET N GET operatsioonide pipelinen.

SELECT DB
Vali andmebaas, millega töötame
Ei toeta mitmeid andmebaase.
Koguda kõik ühte andmebaasi. Lisada võtmete ette eesliite.

SCAN
Käia üle kõik võtmed andmebaasis.
Kuna meil on ainult üks andmebaas, on kogu klusteris võtmete üle käimine liiga kulukas.
Säilitada invariant ühe võtme piires ja teha HSCAN selle võtme kohta. Või loobuda täielikult.

GEO
Geovõtme operatsioonid
Geovõti ei jagune.

KEY BY PATTERN
Otsige võtmeid mustri alusel.
Kuna meil on ainult üks andmebaas, otsime klusteri kõigi võtmete seast. Liiga kulukas.
Loobuge või säilitage invariant, nagu SCAN puhul.

Redis vs Redis-kluster

Mida kaotame ja mida saame klusterisse üleminekul?

• Puudused: kaotame mitme andmebaasi funktsionaalsuse.
  • Kui soovime hoida ühes klusteris loogiliselt mitteseotud andmeid, peame looma eesliiteid.
  • Kaotame kõik 'andmebaasi' operatsioonid, nagu SCAN, DBSIZE, CLEAR DB jms.
  • Multi-operatsioonid on saanud oluliselt keerulisemaks, kuna võib osutuda vajalikuks pöörduda mitmete nodide poole.
• Eelised:
  • Veadeta mastreid avariivõimekusena.
  • Redis'i poolelt jagamine.
  • Andmete üleviimine nodide vahel atomaarse ja katkestusteta.
  • Võimsuste ja koormuste lisamine ja ümberjaotamine katkestusteta.

Ma arvan, et kui teil ei ole vaja tagada kõrget töökindlust, siis ei tasu klastrisse kolida, kuna see võib osutuda keerukaks ülesandeks. Kuid kui valida eraldi versiooni ja klastriversiooni vahel, siis tasub valida klaster, kuna see ei ole halvem ning lisaks vabastab teid osaliselt peavaludest.

Valmistumine kolimiseks

Alustame kolimise nõuetest:

• See peab olema sujuv. Teenuse täielik peatamine 5 minutiks ei sobi meile.
• See peab olema maksimaalselt ohutu ja järkjärguline. Soovime teatud kontrolli olukorra üle. Me ei soovi kõike korraga kokku kuhjata ja palvetada, et tagasipöördumise nupp töötaks.
• Minimaalsed andmekadud kolimise ajal. Me mõistame, et atomaarne kolimine on väga keeruline, seetõttu lubame mõningat desünkroniseerimist tavapäraste ja klastriliste Redis andmete vahel.

Klastri hooldus

Pärast kolimist tuleks mõelda, kas saame klastrit toetada:

• Graafikud. Kasutame Prometheust ja Grafanat protsessorite koormuse, kasutatava mälu, klientide arvu, GET, SET, AUTH jms operatsioonide graafikute loomiseks.
• Ekspertiseerimine. Kujutage ette, et homsest vastutate te tohutu klastrite eest. Kui see katki läheb, ei saa keegi peale teie selle parandada. Kui see hakkab aeglaselt töötama – siis tulevad kõik teie poole. Kui tuleb lisaressursse lisada või koormust ümber jaotada – jälle teie juurde. Et mitte 25-aastaseks halliks minna, tuleks selliseid olukordi ette näha ja eelnevalt kontrollida, kuidas tehnoloogia teatud tegevustes käitub. Räägime sellest lähemalt 'Ekspertiseerimise' osas.
• Monitooringud ja teavitamine. Kui klaster katki läheb, tahaks sellest esimesena teada. Siin oleme piirdunud teavitamisega, et kõik sõlmed naasevad sama teabe juurde klastrisse. (Jah, see juhtub ka teistmoodi). Teisi probleeme on kiiremini näha Redis klientide teenuste teavituste kaudu.

Kolimine

Kuidas me kolime:

• Esiteks peate ette valmistama teegi töötamiseks klastri jaoks. Gо versiooni aluseks võtsime go-redis'i ja tegime mõned muudatused. Rakendasime Multi-meetodid läbi pipeline'ide ning parandasime veidi päringute kordamise reegleid. PHP versiooniga tekkis rohkem probleeme, kuid lõpuks otsustasime php-redis'i kasuks. Hiljuti lisasid nad klastri toe ja meie arvates näeb see hea välja.
• Seejärel tuleb klastri välja arendada. See toimub sõna otseses mõttes kahe käsuga, tuginedes konfiguratsioonifailile. Räägime seadetest allpool lähemalt.
• Ahnemalt üleminekuks kasutame dry-mode'i. Kuna meil on kaks versiooni teegist, millel on sama liides (üks tavalise versiooni jaoks, teine klastri jaoks), pole midagi keerulist teha paketti, mis töötaks ühes versioonis ja samal ajal dubleeriks kõik päringud klastrisse, võrreldes vastuseid ja kirjutades lahknevused logidesse (meie puhul NewRelicisse). Nii, isegi kui klastriversioon laguneb, ei mõjuta see meie tootmist.
• Klastri dry-režiimis välja viies saame rahulikult vaadata vastuste lahknevuse graafikut. Kui veade osakaal liigub aeglaselt, aga kindlalt mingisse väikesele konstandile, siis on kõik hästi. Miks lahknevusi endiselt esineb? Sest kirjutamine eraldi versioonis toimub veidi varem kui klastris ning mikroviivitus tõttu võivad andmed lahkneda. Jäänud on vaid vaadata lahknevuste logisid ja kui kõik seletamatud need on kirjutamise mitteaatomsuse tõttu, siis saame edasi liikuda.
• Nüüd saab dry-mode'i tagasi keerata. Kirjutame ja loeme klastrist, dubleerides eraldi versiooni. Miks? Järgmise nädala jooksul soovime klastrit jälgida. Kui ilmneb, et laadimispikkuse käigus on probleeme või oleme midagi arvesse võtnud, on meil alati võimalus tagasipöörduda vana koodi ja tänu dry-mode'ile, kehtivate andmete juurde.
• Jäänud on dry-mode'i väljalülitamine ja eraldi versiooni eemaldamine.

Ekspertarvamus

Esiteks, lühidalt klastri seadistusest.

Esiteks, Redis on key-value andmebaas. Võtmena kasutatakse kõiki sorte stringe. Väärtustena võivad olla numbrid, stringid ja täisarhitektuurid. Viimaste hulk on suur, kuid üldise arusaama jaoks pole see oluline.
Järgnev abstraktsiooni tase on slotid (SLOTS). Iga võtme kuulub ühte 16 383 slotti. Igas slotis võib olla lõpmatu arv võtmeid. Nii et kõik võtmed jagunevad 16 383 mitteühtesse kogusse.

Klastris peab olema N peanood. Iga noot saab vaadelda eraldi Redis'i instantsina, mis teab kõigest teistest nootidest klassis. Igal peanoodil on teatud arv slote. Iga slot kuulub ainult ühele peanoodile. Kõik slotid tuleb jaotada nootide vahel. Kui mingid slotid ei ole jaotatud, ei ole neis hoitavad võtmed kättesaadavad. Iga peanoodi on mõistlik käivitada eraldi loogilisel või füüsilisel masinal. Samuti tasub meeles pidada, et iga noot töötab ainult ühel tuumal ja kui soovite käivitada mitut Redis'i instantsi ühel loogilisel masinal, siis veenduge, et nad töötaksid erinevatel tuumadel (me ei ole seda proovinud, kuid teoorias kõik peaks töötama). Põhimõtteliselt tagavad peanoodid tavapärase sharding'i ja suurem arvu peanoodide korral saab suurendada kirjutamise ja lugemise päringute mahtu.

Pärast seda, kui kõik võtmed on slotides ja slotid on jaotatud peanoodide vahel, saab igale peanoodile lisada suvalise arvu slave-noode. Igas sellises "master-slave" paaris töötab tavaline replikatsioon. Slaved on vajalikud lugemisepäringute suurendamiseks ja rikke korral peanoodi vahetamiseks.

Nüüd räägime toimingutest, mida oleks hea osata teha.

Me pöördume süsteemi Redis-CLI kaudu. Kuna Redis'il ei ole ühtset sissepääsupunkti, saab järgmisi toiminguid teostada igas noodis. Igal punktis rõhutan eraldi võimalust teostada operatsiooni koormuse all.

• Esimene ja kõige olulisem, mida me vajame: operatsioon cluster nodes. See tagastab klastri oleku, näitab nootide loetelu, nende rolle, slotide jaotust jne. Täiendavat teavet saab saada cluster info ja cluster slots abil.
• Hea oleks hea osata lisada ja eemaldada sõlmi. Selleks on olemas toimingud cluster meet ja cluster forget. Pange tähele, et cluster forget tuleb rakendada KÕIKIDELE sõlmede, nii meistritele kui ka replikaatele. Cluster meet tuleks aga kutsuda välja vaid ühel sõlmel. Selline erinevus võib olla segadusttekitav, seega on parem sellest teada, enne kui oma klastrit tootmisse käivitate. Sõlme lisamine toimub turvaliselt ning ei mõjuta klastrite tööd (mis on mõistetav). Kui aga kavatsete sõlme klastrist eemaldada, tuleb veenduda, et sellel pole enam slotte (vastasel juhul riskite juurdepääsu kaotamisega kõigile selle sõlme võtmetele). Samuti ärge eemaldage meistrit, kellel on slave-d, vastasel juhul toimub uue meistri valimise jaoks tarbetu hääletamine. Kui sõlmedel pole enam slotte, on see väike probleem, kuid miks peaksime piirduma valikute vähendamisega, kui saaksime esmalt slave-d eemaldada.
• Kui on vaja sundida meistrit ja slave-d vahetama, sobib käsk cluster failover. Selle käivitamisel lahingus tuleb mõista, et operatsiooni käigus ei ole meister saadaval. Tavaliselt toimub vahetus vähem kui sekundiga, kuid mitte aatomiliselt. Võite arvestada, et osa päringutest meistrile lõpetatakse sel ajal veaga.
• Enne sõlme klastrist eemaldamist ei tohi nendel jääda slotte. Parim on neid ümber jaotada käsu cluster reshard abil. Slotte kantakse ühelt meistrilt teisele. Kogu operatsioon võib võtta mitu minutit, sõltuvalt edastatavate andmete mahust, kuid andmete edastamine on ohutu ega mõjuta klastrite tööd. Seega on kõik andmed võimalik üle kanda ühest sõlmest teise ka koormuse all, ilma et tuleks muretseda nende kättesaadavuse pärast. Siiski on siin mõned nipid. Esiteks, andmete edastamine toob kaasa teatava koormuse nii vastuvõtvale kui ka saatvale sõlmele. Kui vastuvõttev sõlm on juba protsessorilt tugevalt koormatud, siis ei tohiks seda koormata ka uute andmete vastuvõtmisega. Teiseks, niipea kui saatva meistri juures ei jää slotte, lähevad kõik tema orjad kohe meistrile, kuhu need slotid on kantud. Ja probleem on see, et kõik need orjad tahavad korraga andmeid sünkroniseerida. Teil on veel õnne, kui see on osaline, mitte täielik sünkroniseerimine. Pea seda meeles ja kombineeri slotite ülekandmise ja orjade väljalülitamise/ülekandmise operatsioone. Või looda, et teil on piisavalt vastupidavust.
• Mida teha, kui saate andmete ülekande ajal teada, et olete kuskile slotid kaotanud? Loodan, et see probleem teid ei puuduta, kuid kui siiski, on olemas operatsioon cluster fix. See jagab slotid sõlmede vahel enam-vähem juhuslikult. Soovitan kontrollida selle töö toimivust, eemaldades eelnevalt klastrist sõlme, kus slotid on jaotatud. Kuna andmed jaotamata slotidel ei ole nagunii kätte saadavad, on liiga hilja muretseda nende slotide kättesaadavuse probleemide pärast. Omakorda ei mõjuta operatsioon jagatud slotte.
• Teine kasulik operatsioon on monitor. See võimaldab reaalajas näha kogu päringute nimekirja, mis lähevad sõlmele. Lisaks on võimalik selle põhjal teha grep ja välja selgitada, kas vajalik liiklus on olemas.

Samuti tasub mainida meistrinõude varuakna vahetuse protseduuri. Lühidalt öeldes, see on olemas ja minu arvates töötab see suurepäraselt. Kuid ärge arvake, et kui tõmbate toitekaabli välja masina meistrinõudest, siis Redis vahetub koheselt ja kliendid ei tunne katkestust. Minu kogemuse järgi toimub vahetus mõne sekundi jooksul. Selle aja jooksul on osa andmeid kergesti kättesaamatud: tuvastatakse meistrinõude katkemine, sõlmed hääletavad uue eest, orjad vahetavad ja andmed sünkroonitakse. Parim viis veenduda, et skeem töötab, on läbi viia kohalikud harjutused. Kinnita klaster oma sülearvutisse, anna minimaalne koormus, simuleeri kokkuvarisemist (näiteks blokeerides pordid), hinda vahetuse kiirus. Minu arvates ainult mängides sellega päev või kaks, saab olla kindel tehnoloogia töös. Või loota, et tarkvara, mida kasutab pool internetist, kindlasti töötab.

Konfiguratsioon

Sageli on konfiguratsioon esimene asi, mis on vajalik töö alustamiseks tööriistaga. Ja kui kõik töötab, ei taha konfiguratsiooniga tegeleda. Tõenäoliselt on vaja teatud pingutust, et sundida end tagasi seadete juurde ja hoolikalt neid läbi vaadata. Minu mäletamist mööda on meil olnud vähemalt kaks tõsist ebaõnnestumist konfiguratsioonist tähelepanematuse tõttu. Pöörake erilist tähelepanu järgmistele punktidele:

• timeout 0
  Aeg, mille pärast suletakse mitteaktiivsed ühendused (sekundites). 0 — ei sulgeda.
  Meie raamatukogud ei osanud igaüht õigesti sulgeda. Selle seadistuse väljalülitamine paneb meid silmitsi kliendide arvu piirangu probleemiga. Teisest küljest, kui selline probleem olemas on, siis automaatne kadunud ühenduste katkestamine varjab selle, ja me võime seda märkamata jääda. Samuti ei tohi seda seadistust sisselülitamisega kasutada järjepidevate ühenduste puhul.
• Save x y & appendonly yes
  RDB-snapshooti salvestamine.
  RDB/AOF probleemid, mida arutame allpool.
• stop-writes-on-bgsave-error no & slave-serve-stale-data yes
  Kui see on lubatud, siis RDB-snapshooti rikke korral lõpetab meister muudatuse päringute vastuvõtmise. Kui ühendus meistriga katke, siis orjad võivad jätkata päringutele vastamist (jah). Või lõpetab (ei).
  Me ei ole rahul olukorraga, kus Redis muutub kõrvitsaks.
• repl-ping-slave-period 5
  Selle ajavahemiku jooksul hakkame muretsema selle üle, et meistriga on midagi valesti ja on aeg failover'i protseduur läbi viia.
  Peame käsitsi leidma tasakaalu valehäirete ja failover'i käivitamise vahel. Meie praktika kohaselt on see 5 sekundit.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  Just nii palju andmeid saame me salvestada katkenud koopiate puhvris. Kui puhvripaik lõpetab töötamise, tuleb täielikult sünkroonida.
  Praktika näitab, et on parem seada suurem väärtus. Põhjusi, miks koopia võib maha jääda, on palju. Kui see jääb maha, siis tõenäoliselt suudab teie meister juba raskustega toime tulla ja täielik sünkroonimine muutub viimaseks taastumisvõimaluseks.
• maxclients 10000
  Maksimaalne samal ajal ühendatud klientide arv.
  Meie kogemuse kohaselt on parem seada kõrgem väärtus. Redis suudab suurepäraselt hallata 10 tuhat ühendust. Ainult veenduge, et süsteemis oleks piisavalt sokette.
• maxmemory-policy volatile-ttl
  Reegel, mille järgi eemaldatakse võtmed, kui saavutatakse vaba mälu piir.
  Siin on tähtis mitte niivõrd reegel, vaid arusaam, kuidas see protsess toimub. Redisit saab kiita selle eest, et ta suudab hästi töötada mälu piiri saavutamisel.

RDB ja AOF probleemid

Kuigi Redis ise salvestab kogu teabe mälus, on ka mehhanism andmete salvestamiseks ketta peale. Täpsemalt öeldes on kolm mehhanismi:

• RDB-snapshoot — kõikide andmete täielik koopiatega. Seadetakse konfigureerimise SAVE X Y abil ja loetakse nagu "Salvesta kõikide andmete täielik koopi iga X sekundi järel, kui on vähemalt Y võtme muudatus."
• Append-only file — tehingute loend nende täitmise järjekorras. Uued saabunud tehingud kirjutatakse faili iga X sekundi või Y tehingu järel.
• RDB ja AOF — kahe eelmise kombinatsioon.

Katalooge kõigil meetoditel on oma eelised ja puudused, ma ei hakka neid kõiki loetlema, vaid toome välja mõned minu arvates mitte ilmseid punkte.

Esiteks, RDB-snepšoti salvestamiseks tuleb kutsuda FORK. Kui andmeid on palju, võib see peatada kogu Redis'i ajaks paarist millisekundist kuni sekundini. Lisaks peab süsteem eraldama mälu sellise koopia jaoks, mis tähendab, et loogilisel masinal peab olema topeltmälu varu: kui Redis'ile on eraldatud 8 GB, siis virtuaalmasinal peab olema saada 16.

Teiseks, on osalise sünkroonimisega probleeme. AOF-režiimis võib slave'i uuesti ühendamisel toimuda täielik sünkroonimine, mitte osaline. Miks see nii on, ei suutnud ma aru saada. Kuid sellest on hea meeles pidada.

Need kaks punkti panevad juba mõtlema, kas on tõesti vajalik, et need andmed oleksid kettal, kui slave'id juba kõike dubleerivad. Andmed võib kaotada ainult juhul, kui kõik slave'id ebaõnnestuvad, ja see on probleem, mis sarnaneb 'tulekahjule andmekeskuses'. Kompromissina võib pakkuda, et andmeid hoitakse ainult slave'ides, kuid sel juhul tuleb veenduda, et need slave'id ei muutuks kunagi hädaolukorra taastamisel masteriks (selle jaoks on olemas slaavi prioriteedi seadistus nende konfiguratsioonis). Iga konkreetse juhtumi puhul mõtleme, kas on vajalik andmed kettale salvestada, ja enamasti vastame "ei".

Kokkuvõte

Kokkuvõtteks loodan, et suutsin anda üldise teadlikkuse redis-cluster-i toimimisest neile, kes ei ole sellest kunagi kuulnud, ning pöörata tähelepanu mitmetele mitte-ilmselgedele aspektidele neile, kes on juba pikka aega seda kasutanud.
Aitäh, et leidsite aega ja nagu tavaliselt, on teemakohased kommentaarid teretulnud.

Allikas: habr.com