Keď prídeme k produktu, ktorý sa vyvíja viac ako desaťročie, nie je vôbec prekvapujúce, že v ňom nájdeme zastarané technológie. Ale čo ak za šesť mesiacov budete musieť udržať zaťaženie 10-krát vyššie a náklady na pády sa zvýšia stokrát? V tomto prípade potrebujete skvelého Highload Engineera. Ale v neprítomnosti chyžnej ma poverili riešením problému. V prvej časti článku vám poviem, ako sme prešli z Redis na Redis-cluster a v druhej časti poradím, ako začať používať klaster a na čo si dať pri jeho používaní pozor.

Výber technológie

Je to také zlé? samostatný Redis (samostatný redis) v konfigurácii 1 master a N slave? Prečo to nazývam zastaraná technológia?

Nie, Redis nie je až taký zlý... Existujú však nedostatky, ktoré nemožno ignorovať.

• Po prvé, Redis nepodporuje mechanizmy obnovy po havárii po hlavnom zlyhaní. Na vyriešenie tohto problému sme použili konfiguráciu s automatickým presunom VIP na nového pána, zmenou roly jedného z otrokov a prepnutím zvyšku. Tento mechanizmus fungoval, ale nedal sa nazvať spoľahlivým riešením. Po prvé, vyskytli sa falošné poplachy a po druhé, bol jednorazový a po prevádzke boli potrebné manuálne zásahy na nabitie pružiny.

• Po druhé, mať iba jedného majstra viedlo k problému úlomkov. Museli sme vytvoriť niekoľko nezávislých klastrov „1 master a N slaves“, potom manuálne distribuovať databázy medzi tieto stroje a dúfať, že zajtra sa jedna z databáz nezväčší natoľko, že bude musieť byť presunutá do samostatnej inštancie.

Aké sú možnosti?

• Najdrahším a najbohatším riešením je Redis-Enterprise. Ide o krabicové riešenie s plnou technickou podporou. Napriek tomu, že z technického hľadiska vyzerá ideálne, z ideologických dôvodov nám nevyhovoval.
• Redis-klaster. Po vybalení je k dispozícii podpora pre master failover a sharding. Rozhranie sa takmer nelíši od bežnej verzie. Vyzerá to sľubne, o nástrahách si povieme neskôr.
• Tarantool, Memcache, Aerospike a iné. Všetky tieto nástroje robia takmer to isté. Ale každý má svoje vlastné nedostatky. Rozhodli sme sa nedávať všetky vajíčka do jedného košíka. Na iné úlohy používame Memcache a Tarantool a pri pohľade do budúcnosti poviem, že v našej praxi s nimi bolo viac problémov.

Špecifiká použitia

Pozrime sa, aké problémy sme historicky riešili s Redis a akú funkcionalitu sme použili:

• Cache pred požiadavkami na vzdialené služby ako 2GIS | Golang
  

  GET SET MGET MSET "SELECT DB"

• Cache pred MYSQL | PHP
  

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

• Hlavné úložisko pre službu práce s reláciami a súradnicami vodiča | Golang
  

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

Ako vidíte, žiadna vyššia matematika. Aká je potom náročnosť? Pozrime sa na každú metódu samostatne.

metóda
Popis
Vlastnosti Redis-cluster
rozhodnutie

PRIPRAVIŤ SA
Kľúč na zápis/čítanie

MGET MSET
Zápis/čítanie viacerých kľúčov
Kľúče budú na rôznych uzloch. Hotové knižnice môžu vykonávať viacero operácií iba v rámci jedného uzla
Nahraďte MGET reťazcom operácií N GET

VYBERTE DB
Vyberte základ, s ktorým budeme pracovať
Nepodporuje viacero databáz
Vložte všetko do jednej databázy. Pridajte predpony ku kľúčom

SCAN
Prejdite všetky kľúče v databáze
Keďže máme jednu databázu, prejsť všetky kľúče v klastri je príliš drahé
Udržujte invariant v rámci jedného kľúča a vykonajte HSCAN na tomto kľúči. Alebo úplne odmietnuť

GEO
Operácie s geokľúčom
Geokľúč nie je poškodený

KĽÚČ PODĽA VZORU
Hľadanie kľúča podľa vzoru
Keďže máme jednu databázu, budeme hľadať vo všetkých kľúčoch v klastri. Príliš drahé
Odmietnuť alebo zachovať invariant, ako v prípade SCAN

Redis vs Redis-klaster

Čo stratíme a čo získame prechodom na klaster?

• Nevýhody: strácame funkčnosť viacerých databáz.
  • Ak chceme uložiť logicky nesúvisiace dáta do jedného zhluku, budeme si musieť urobiť barličky vo forme prefixov.
  • Stratíme všetky „základné“ operácie, ako je SCAN, DBSIZE, CLEAR DB atď.
  • Implementácia viacerých operácií sa stala oveľa zložitejšou, pretože môže vyžadovať prístup k niekoľkým uzlom.
• výhody:
  • Odolnosť voči chybám vo forme master failover.
  • Zdieľanie na strane Redis.
  • Prenášajte dáta medzi uzlami atómovo a bez prestojov.
  • Pridajte a prerozdeľte kapacitu a zaťaženie bez prestojov.

Dospel by som k záveru, že ak nepotrebujete poskytovať vysokú úroveň odolnosti voči chybám, potom prechod do klastra nestojí za to, pretože to môže byť netriviálna úloha. Ak sa však spočiatku rozhodujete medzi samostatnou verziou a klastrovou verziou, mali by ste zvoliť klaster, pretože nie je o nič horší a navyše vás zbaví bolesti hlavy

Príprava na presun

Začnime požiadavkami na sťahovanie:

• Malo by to byť bezproblémové. Úplné zastavenie prevádzky na 5 minút nám nevyhovuje.
• Malo by to byť čo najbezpečnejšie a postupné. Chcem mať situáciu pod kontrolou. Nechceme všetko naraz vyhodiť a modliť sa za tlačidlo návratu.
• Minimálna strata dát pri presune. Chápeme, že atómový presun bude veľmi náročný, preto umožňujeme určitú desynchronizáciu medzi dátami v bežných a klastrových Redis.

Údržba klastra

Tesne pred presunom by sme sa mali zamyslieť nad tým, či môžeme klaster podporiť:

• Grafy. Používame Prometheus a Grafana na zobrazenie grafu zaťaženia procesora, využitia pamäte, počtu klientov, počtu operácií GET, SET, AUTH atď.
• Odbornosť. Predstavte si, že zajtra budete mať pod zodpovednosťou obrovský klaster. Ak sa pokazí, nikto okrem vás to nedokáže opraviť. Ak začne spomaľovať, všetci sa rozbehnú oproti vám. Ak potrebujete pridať zdroje alebo prerozdeliť záťaž, vráťte sa k vám. Aby pri 25 nezošediveli, je vhodné zabezpečiť tieto prípady a vopred skontrolovať, ako sa bude technológia správať pri určitých akciách. Hovorme o tom podrobnejšie v časti „Odbornosť“.
• Monitorovanie a upozornenia. Keď sa zhluk rozpadne, chcete byť prvý, kto sa o tom dozvie. Tu sme sa obmedzili na upozornenie, že všetky uzly vracajú rovnakú informáciu o stave klastra (áno, stáva sa to inak). A ďalšie problémy možno rýchlejšie zaznamenať upozorneniami z klientskych služieb Redis.

Pohyb

Ako sa budeme pohybovať:

• V prvom rade je potrebné pripraviť knižnicu na prácu s klastrom. Ako základ pre verziu Go sme zobrali go-redis a trochu sme ho pozmenili, aby nám vyhovoval. Implementovali sme Multi-methods cez pipeline a tiež sme mierne upravili pravidlá pre opakované požiadavky. Verzia PHP mala viac problémov, ale nakoniec sme sa rozhodli pre php-redis. Nedávno zaviedli podporu klastrov a podľa nás to vyzerá dobre.
• Ďalej je potrebné nasadiť samotný klaster. To sa deje doslova v dvoch príkazoch na základe konfiguračného súboru. O nastavení sa budeme podrobnejšie rozprávať nižšie.
• Pre postupné presúvanie používame suchý režim. Keďže máme dve verzie knižnice s rovnakým rozhraním (jedna pre bežnú verziu, druhá pre klaster), vytvorenie obalu, ktorý bude pracovať so samostatnou verziou a paralelne duplikuje všetky požiadavky do klastra, nestojí nič, porovnajte odpovede a zapíšte nezrovnalosti do denníkov (v našom prípade v NewRelic). Takže aj keď sa klastrová verzia počas zavádzania pokazí, naša výroba nebude ovplyvnená.
• Po spustení klastra v suchom režime sa môžeme pokojne pozrieť na graf nezrovnalostí v odozvách. Ak sa chybovosť pomaly, ale isto posúva k nejakej malej konštante, tak je všetko v poriadku. Prečo sú stále nezrovnalosti? Pretože zaznamenávanie v samostatnej verzii prebieha o niečo skôr ako v klastri a kvôli mikrolagom sa údaje môžu rozchádzať. Zostáva len pozrieť si záznamy o nezrovnalostiach a ak sú všetky vysvetlené neatomickosťou záznamu, tak môžeme ísť ďalej.
• Teraz môžete prepnúť suchý režim v opačnom smere. Budeme zapisovať a čítať z klastra a duplikovať ho do samostatnej verzie. Prečo? V priebehu budúceho týždňa by som chcel sledovať prácu klastra. Ak sa zrazu ukáže, že pri špičkovom zaťažení sú problémy alebo sme niečo nebrali do úvahy, vždy máme núdzový návrat k starému kódu a aktuálnym údajom vďaka suchému režimu.
• Zostáva len vypnúť suchý režim a demontovať samostatnú verziu.

skúška

Najprv stručne o dizajne klastra.

Po prvé, Redis je obchod s hodnotami kľúča. Ako kľúče sa používajú ľubovoľné reťazce. Ako hodnoty možno použiť čísla, reťazce a celé štruktúry. Je ich veľmi veľa, ale pre pochopenie všeobecnej štruktúry to nie je pre nás dôležité.
Ďalšou úrovňou abstrakcie po kľúčoch sú sloty (SLOTS). Každý kľúč patrí do jedného zo 16 383 slotov. V každom slote môže byť ľubovoľný počet kľúčov. Všetky kľúče sú teda rozdelené do 16 383 disjunktných sád.

Ďalej musí byť v klastri N hlavných uzlov. Každý uzol si možno predstaviť ako samostatnú inštanciu Redis, ktorá vie všetko o ostatných uzloch v rámci klastra. Každý hlavný uzol obsahuje určitý počet slotov. Každý slot patrí iba jednému hlavnému uzlu. Všetky sloty musia byť rozdelené medzi uzly. Ak niektoré sloty nie sú pridelené, kľúče v nich uložené budú nedostupné. Má zmysel spúšťať každý hlavný uzol na samostatnom logickom alebo fyzickom počítači. Je tiež potrebné pripomenúť, že každý uzol beží iba na jednom jadre a ak chcete spustiť viacero inštancií Redis na rovnakom logickom stroji, uistite sa, že bežia na rôznych jadrách (neskúšali sme to, ale teoreticky by to malo fungovať) . Hlavné uzly v podstate poskytujú pravidelné sharding a ďalšie hlavné uzly umožňujú škálovať požiadavky na zápis a čítanie.

Potom, čo sú všetky kľúče rozdelené medzi sloty a sloty sú rozptýlené medzi hlavné uzly, je možné ku každému hlavnému uzlu pridať ľubovoľný počet podriadených uzlov. V rámci každého takéhoto spojenia master-slave bude fungovať normálna replikácia. Slave sú potrebné na škálovanie požiadaviek na čítanie a na núdzové prepnutie v prípade zlyhania hlavného servera.

Teraz si povedzme o operáciách, ktoré by bolo lepšie robiť.

Do systému budeme pristupovať cez Redis-CLI. Keďže Redis nemá jediný vstupný bod, nasledujúce operácie môžete vykonávať na ktoromkoľvek z uzlov. V každom bode osobitne upozorňujem na možnosť vykonania operácie pod záťažou.

• Prvá a najdôležitejšia vec, ktorú potrebujeme, je operácia uzlov klastra. Vracia stav klastra, zobrazuje zoznam uzlov, ich roly, distribúciu slotov atď. Viac informácií možno získať pomocou informácií o klastri a slotov klastra.
• Bolo by pekné mať možnosť pridávať a odstraňovať uzly. Na tento účel existujú operácie klastrového stretnutia a zabudnutia klastra. Upozorňujeme, že zabudnutie klastra sa musí použiť na KAŽDÝ uzol, a to ako predlohy, tak aj repliky. A cluster meet stačí zavolať na jeden uzol. Tento rozdiel môže byť znepokojujúci, takže je najlepšie sa o ňom dozvedieť skôr, ako začnete s klastrom pracovať. Pridanie uzla sa v boji deje bezpečne a nijako neovplyvňuje fungovanie klastra (čo je logické). Ak sa chystáte odstrániť uzol z klastra, mali by ste sa uistiť, že na ňom nezostali žiadne sloty (inak riskujete stratu prístupu ku všetkým kľúčom na tomto uzle). Taktiež nevymažte master, ktorý má otrokov, inak sa vykoná zbytočné hlasovanie za nového mastera. Ak uzly už nemajú sloty, potom je to malý problém, ale prečo potrebujeme ďalšie možnosti, ak môžeme najskôr odstrániť otrokov.
• Ak potrebujete násilne zameniť pozície master a slave, vykoná sa príkaz na prepnutie klastra. Keď to voláte v boji, musíte pochopiť, že majster nebude počas operácie k dispozícii. K prepnutiu zvyčajne dôjde za menej ako sekundu, ale nie je atómový. Môžete očakávať, že niektoré požiadavky na master počas tejto doby zlyhajú.
• Pred odstránením uzla z klastra by na ňom nemali zostať žiadne sloty. Je lepšie ich prerozdeliť pomocou príkazu cluster reshard. Sloty budú prenesené z jedného mastera do druhého. Celá operácia môže trvať niekoľko minút, závisí od objemu prenášaných dát, ale proces prenosu je bezpečný a nijako neovplyvňuje chod klastra. Všetky dáta je teda možné prenášať z jedného uzla do druhého priamo pod záťažou a bez obáv o ich dostupnosť. Existujú však aj jemnosti. Po prvé, prenos dát je spojený s určitým zaťažením uzlov príjemcu a odosielateľa. Ak je uzol príjemcu už značne zaťažený procesorom, nemali by ste ho zaťažovať prijímaním nových údajov. Po druhé, akonáhle na odosielajúcom nadradenom zariadení nezostane ani jeden slot, všetky jeho podriadené jednotky okamžite prejdú k nadradenému zariadeniu, na ktoré boli tieto sloty prenesené. A problém je, že všetci títo otroci budú chcieť synchronizovať dáta naraz. A budete mať šťastie, ak pôjde skôr o čiastočnú než úplnú synchronizáciu. Berte to do úvahy a kombinujte operácie prenosu slotov a deaktivácie/prenosu podriadených zariadení. Alebo dúfajte, že máte dostatočnú mieru bezpečnosti.
• Čo robiť, ak počas presunu zistíte, že ste niekde stratili sloty? Dúfam, že sa vás tento problém netýka, ale ak áno, existuje operácia opravy klastra. Prinajmenšom rozhádže sloty po uzloch v náhodnom poradí. Odporúčam skontrolovať jeho fungovanie tak, že najskôr odstránite uzol s distribuovanými slotmi z klastra. Keďže údaje v nepridelených slotoch sú už nedostupné, je príliš neskoro na obavy z problémov s dostupnosťou týchto slotov. Operácia zase neovplyvní distribuované sloty.
• Ďalšou užitočnou operáciou je monitor. Umožňuje vám vidieť v reálnom čase celý zoznam požiadaviek smerujúcich do uzla. Navyše ho môžete grepovať a zistiť, či je tam potrebná premávka.

Za zmienku stojí aj master failover postup. Skrátka existuje a podľa mňa funguje výborne. Nemyslite si však, že ak odpojíte napájací kábel na stroji s hlavným uzlom, Redis sa okamžite prepne a klienti si stratu nevšimnú. V mojej praxi dôjde k prepnutiu v priebehu niekoľkých sekúnd. Počas tejto doby budú niektoré údaje nedostupné: zistí sa nedostupnosť nadriadeného, ​​uzly hlasujú za nový, podriadené jednotky sa prepnú, údaje sa zosynchronizujú. Najlepší spôsob, ako sa uistiť, že schéma funguje, je vykonať miestne cvičenia. Zdvihnite cluster na svojom notebooku, dajte mu minimálnu záťaž, simulujte pád (napríklad zablokovaním portov) a vyhodnoťte rýchlosť prepínania. Podľa mňa až po dni alebo dvoch hraní týmto spôsobom si môžete byť istí fungovaním technológie. No alebo dúfať, že softvér, ktorý používa polovica internetu, pravdepodobne funguje.

konfigurácia

Konfigurácia je často prvá vec, ktorú potrebujete, aby ste mohli začať pracovať s nástrojom. A keď všetko funguje, konfigurácie sa ani nechcete dotknúť. Prinútiť sa vrátiť sa k nastaveniam a dôkladne ich prejsť si vyžaduje určité úsilie. V mojej pamäti sme mali minimálne dve vážne poruchy kvôli nepozornosti pri konfigurácii. Venujte zvláštnu pozornosť nasledujúcim bodom:

• časový limit 0
  Čas, po ktorom sa neaktívne spojenia zatvoria (v sekundách). 0 - nezatvárať
  Nie každá naša knižnica dokázala správne uzavrieť spojenia. Vypnutím tohto nastavenia riskujeme, že narazíme na limit počtu klientov. Na druhej strane, ak sa vyskytne takýto problém, automatické ukončenie stratených spojení ho zamaskuje a my si to nemusíme všimnúť. Okrem toho by ste toto nastavenie nemali povoliť pri používaní trvalých pripojení.
• Uložiť xy a pripojiť iba áno
  Uloženie snímky RDB.
  O problémoch RDB/AOF budeme podrobne diskutovať nižšie.
• stop-writes-on-bgsave-error nie & slave-serve-stare-data áno
  Ak je povolené, ak sa snímka RDB pokazí, master prestane prijímať požiadavky na zmenu. Ak dôjde k strate spojenia s masterom, slave môže naďalej odpovedať na požiadavky (áno). Alebo prestane reagovať (nie)
  Nie sme spokojní so situáciou, v ktorej sa Redis mení na tekvicu.
• repl-ping-slave-period 5
  Po uplynutí tejto doby sa začneme obávať, že sa master pokazil a je čas vykonať procedúru zlyhania.
  Budete musieť manuálne nájsť rovnováhu medzi falošnými pozitívami a spustením núdzového prepnutia. V našej praxi je to 5 sekúnd.
• repl-backlog-size 1024 MB & epl-backlog-ttl 0
  Presne toľko údajov môžeme uložiť do vyrovnávacej pamäte pre neúspešnú repliku. Ak sa minie vyrovnávacia pamäť, budete musieť vykonať úplnú synchronizáciu.
  Prax naznačuje, že je lepšie nastaviť vyššiu hodnotu. Existuje veľa dôvodov, prečo môže replika začať zaostávať. Ak zaostáva, váš pán sa s najväčšou pravdepodobnosťou už snaží vyrovnať a úplná synchronizácia bude poslednou kvapkou.
• maximálny počet klientov 10000 XNUMX
  Maximálny počet jednorazových klientov.
  Podľa našich skúseností je lepšie nastaviť vyššiu hodnotu. Redis v pohode zvláda 10k pripojení. Len sa uistite, že je v systéme dostatok zásuviek.
• maxmemory-policy volatile-ttl
  Pravidlo, podľa ktorého sa kľúče vymažú, keď sa dosiahne limit dostupnej pamäte.
  Dôležité tu nie je samotné pravidlo, ale pochopenie toho, ako sa to stane. Redis možno pochváliť za schopnosť normálne pracovať pri dosiahnutí limitu pamäte.

Problémy RDB a AOF

Aj keď samotný Redis ukladá všetky informácie do pamäte RAM, existuje aj mechanizmus na ukladanie dát na disk. Presnejšie povedané, tri mechanizmy:

• RDB-snapshot - kompletná snímka všetkých údajov. Nastavte pomocou konfigurácie ULOŽIŤ XY a znie: „Uložiť úplný snímok všetkých údajov každých X sekúnd, ak sa zmenilo aspoň Y kľúčov“.
• Append-only file – zoznam operácií v poradí, v akom sa vykonávajú. Pridáva nové prichádzajúce operácie do súboru každých X sekúnd alebo každých Y operácií.
• RDB a AOF sú kombináciou predchádzajúcich dvoch.

Všetky metódy majú svoje výhody a nevýhody, nebudem ich všetky uvádzať, len upozorním na body, ktoré podľa mňa nie sú zrejmé.

Po prvé, uloženie snímky RDB vyžaduje volanie FORK. Ak existuje veľa údajov, môže to zastaviť celý Redis na dobu niekoľkých milisekúnd až sekundy. Okrem toho musí systém alokovať pamäť pre takúto snímku, čo vedie k potrebe udržiavať dvojitú zásobu RAM na logickom stroji: ak je pre Redis alokovaných 8 GB, potom by malo byť 16 GB dostupných na virtuálnom stroji s to.

Po druhé, existujú problémy s čiastočnou synchronizáciou. V režime AOF, keď je slave znova pripojený, namiesto čiastočnej synchronizácie je možné vykonať úplnú synchronizáciu. Prečo sa to deje, nemohol som pochopiť. Ale stojí za to si to pripomenúť.

Už tieto dva body nás nútia zamyslieť sa nad tým, či tieto dáta na disku naozaj potrebujeme, ak je už všetko duplikované otrokmi. Údaje sa môžu stratiť iba vtedy, ak zlyhajú všetky podriadené jednotky, a to je problém na úrovni „požiaru v DC“. Ako kompromis môžete navrhnúť ukladanie údajov iba na podriadených zariadeniach, ale v tomto prípade sa musíte uistiť, že tieto podriadené jednotky sa počas obnovy po havárii nikdy nestanú hlavným zariadením (na to je v ich konfigurácii nastavená priorita podriadených). Sami pre seba v každom konkrétnom prípade premýšľame o tom, či je potrebné ukladať dáta na disk, a najčastejšie je odpoveď „nie“.

Záver

Na záver dúfam, že som mohol poskytnúť všeobecnú predstavu o tom, ako funguje redis-cluster pre tých, ktorí o ňom vôbec nepočuli, a tiež som upozornil na niektoré nezreteľné body pre tých, ktorí ho používajú. na dlhú dobu.
Ďakujem za váš čas a ako vždy sú vítané komentáre k téme.

Zdroj: hab.com