Egy több mint egy évtizede fejlődő termékhez közeledve egyáltalán nem meglepő, hogy elavult technológiákat találunk benne. De mi van akkor, ha hat hónap alatt tízszer nagyobb terhelést kell tartania, és az esések költsége több százszorosára nő? Ebben az esetben egy menő Highload Engineerre van szüksége. De szobalány híján engem bíztak meg a probléma megoldásával. A cikk első részében elmondom, hogyan kerültünk át a Redisről a Redis-clusterre, a második részben pedig tanácsokat adok a fürt használatának megkezdéséhez, illetve mire kell figyelni a használat során.

Technológia kiválasztása

Ez olyan rossz? külön Redis (önálló redis) 1 master és N slave konfigurációban? Miért nevezem elavult technológiának?

Nem, a Redis nem olyan rossz... Vannak azonban olyan hiányosságok, amelyeket nem lehet figyelmen kívül hagyni.

• Először is, a Redis nem támogatja a katasztrófa utáni helyreállítási mechanizmusokat a fő hiba után. A probléma megoldására olyan konfigurációt használtunk, amelyben a VIP-k automatikus átvitele egy új mesterre történt, megváltoztatva az egyik slave szerepét, és átkapcsolva a többit. Ez a mechanizmus működött, de nem nevezhető megbízható megoldásnak. Egyrészt téves riasztások történtek, másrészt eldobható volt, és az üzemeltetés után kézi beavatkozásra volt szükség a rugó feltöltéséhez.

• Másodszor, ha csak egy mester volt, az a szilánkosodás problémájához vezetett. Létre kellett hoznunk több független „1 mester és N slave” klasztert, majd manuálisan osztjuk szét az adatbázisokat ezek között a gépek között, és reméljük, hogy holnap nem duzzad fel annyira az egyik adatbázis, hogy egy külön példányba kelljen áthelyezni.

Mik a lehetőségek?

• A legdrágább és leggazdagabb megoldás a Redis-Enterprise. Ez egy dobozos megoldás teljes műszaki támogatással. Annak ellenére, hogy technikailag ideálisnak tűnik, ideológiai okokból nem jött be nekünk.
• Redis-klaszter. A dobozból kiindulva támogatja a fő feladatátvételt és a felosztást. A felület szinte semmiben sem különbözik a normál verziótól. Ígéretesnek tűnik, a buktatókról később fogunk beszélni.
• Tarantool, Memcache, Aerospike és mások. Ezek az eszközök nagyjából ugyanazt végzik. De mindegyiknek megvannak a maga hiányosságai. Úgy döntöttünk, hogy nem teszünk minden tojást egy kosárba. Más feladatokra a Memcache-t és a Tarantool-t használjuk, és előretekintve elmondom, hogy gyakorlatunkban ezekkel több probléma volt.

A felhasználás sajátosságai

Nézzük meg, milyen problémákat oldottunk meg a múltban a Redissel, és milyen funkciókat használtunk:

• Gyorsítótár a távoli szolgáltatásokhoz, például a 2GIS | Golang
  

  GET SET MGET MSET "SELECT DB"

• Gyorsítótár a MYSQL előtt | PHP
  

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

• A fő tárhely a munkamenetekkel és illesztőprogram-koordinátákkal végzett munka szolgáltatásához | Golang
  

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

Amint látja, nincs magasabb matematika. Akkor mi a nehézség? Nézzük meg mindegyik módszert külön-külön.

módszer
Leírás
A Redis-cluster jellemzői
döntés

FELKÉSZÜLNI
Írás/olvasás gomb

MGET MSET
Több kulcs írása/olvasása
A kulcsok különböző csomópontokon lesznek. A kész könyvtárak csak egy csomóponton belül tudnak több műveletet végrehajtani
Cserélje le az MGET-et egy N GET-műveletből álló folyamatra

DB KIVÁLASZTÁSA
Válassza ki az alapot, amellyel dolgozni fogunk
Nem támogat több adatbázist
Tegyen mindent egy adatbázisba. Adjon hozzá előtagokat a kulcsokhoz

LETAPOGATÁS
Menjen végig az adatbázisban található összes kulcson
Mivel egyetlen adatbázisunk van, a fürt összes kulcsának áttekintése túl drága
Tartson fenn egy invariánst egy kulcson belül, és végezzen HSCAN-t ezen a kulcson. Vagy teljesen elutasítja

GEO
Műveletek geokulccsal
A geokulcs nincs széttörve

KULCS MINTA SZERINT
Kulcs keresése minta szerint
Mivel egyetlen adatbázisunk van, a fürt összes kulcsában fogunk keresni. Túl drága
Az invariáns elutasítása vagy fenntartása, mint a SCAN esetében

Redis vs Redis-fürt

Mit veszítünk és mit nyerünk, ha klaszterre váltunk?

• Hátrányok: több adatbázis funkcionalitását elveszítjük.
  • Ha logikailag nem kapcsolódó adatokat szeretnénk egy klaszterben tárolni, akkor előtagok formájában kell mankókat készítenünk.
  • Elveszítjük az összes „alap” műveletet, mint például a SCAN, DBSIZE, CLEAR DB stb.
  • A több művelet végrehajtása sokkal nehezebbé vált, mivel több csomóponthoz való hozzáférést igényelhet.
• Előnyök:
  • Hibatűrés fő feladatátvétel formájában.
  • Felosztás a Redis oldalon.
  • Adatátvitel a csomópontok között atomszerűen és leállás nélkül.
  • Kapacitás és terhelés hozzáadása és újraosztása állásidő nélkül.

Arra a következtetésre jutok, hogy ha nem kell magas szintű hibatűrést biztosítani, akkor nem éri meg a klaszterbe költözni, mert ez nem triviális feladat lehet. De ha kezdetben a külön verzió és a fürt verzió között választ, akkor válasszon egy klasztert, mivel az nem rosszabb, és emellett megszabadít néhány fejfájástól.

Felkészülés a mozgásra

Kezdjük a költözés követelményeivel:

• Zökkenőmentesnek kell lennie. A szolgáltatás 5 perces teljes leállítása nem felel meg nekünk.
• A lehető legbiztonságosabbnak és fokozatosnak kell lennie. Szeretnék egy kicsit kontrollálni a helyzetet. Nem akarunk mindent egyszerre kidobni, és imádkozni a visszaállítás gombért.
• Minimális adatvesztés költözéskor. Tisztában vagyunk vele, hogy nagyon nehéz lesz atomosan mozgatni, ezért lehetővé tesszük a normál és a fürtözött Redis adatok közötti némi deszinkronizálást.

Klaszter karbantartás

Közvetlenül a költözés előtt érdemes átgondolnunk, hogy támogathatjuk-e a klasztert:

• Diagramok. A Prometheus és a Grafana segítségével ábrázoljuk a processzorterhelést, a memóriahasználatot, a kliensek számát, a GET, SET, AUTH műveletek számát stb.
• Szakvélemény. Képzeld el, hogy holnap egy hatalmas klaszter lesz a felelősséged alatt. Ha elromlik, rajtad kívül senki nem tudja megjavítani. Ha lassítani kezd, mindenki feléd fog futni. Ha erőforrásokat kell hozzáadnia vagy újra kell osztania a terhelést, térjen vissza. Annak érdekében, hogy ne szürküljön meg 25 évesen, tanácsos gondoskodni ezekről az esetekről, és előre ellenőrizni, hogyan fog viselkedni a technológia bizonyos műveletek során. Beszéljünk erről részletesebben a „Szakértelem” részben.
• Monitoring és riasztások. Ha egy klaszter meghibásodik, elsőként szeretne értesülni róla. Itt egy értesítésre szorítkoztunk, hogy minden csomópont ugyanazt az információt adja vissza a fürt állapotáról (igen, ez másképp történik). Más problémákat pedig gyorsabban észlelhetnek a Redis ügyfélszolgálataitól érkező figyelmeztetések.

Mozgás

Hogyan fogunk mozogni:

• Először is fel kell készítenie egy könyvtárat a fürttel való együttműködéshez. A Go-verzió alapjául a go-redis-t vettük, és egy kicsit megváltoztattuk, hogy megfeleljen magunknak. Csővezetékeken keresztül vezettük be a Multi-methodokat, és némileg korrigáltuk az ismétlődő kérések szabályait. A PHP verzióval több probléma volt, de végül a php-redis mellett döntöttünk. Nemrég vezették be a klasztertámogatást, és véleményünk szerint jól néz ki.
• Ezután magát a fürtöt kell üzembe helyeznie. Ez szó szerint két paranccsal történik a konfigurációs fájl alapján. Az alábbiakban részletesebben tárgyaljuk a beállítást.
• A fokozatos mozgatáshoz száraz üzemmódot használunk. Mivel a könyvtárnak két verziója van ugyanazzal a felülettel (az egyik a normál verzióhoz, a másik a fürthöz), nem kerül semmibe egy olyan burkoló létrehozása, amely külön verzióval működik, és ezzel párhuzamosan minden kérést megkettőz a fürt felé. hasonlítsa össze a válaszokat, és írja be az eltéréseket a naplókba (a mi esetünkben a NewRelic-ben). Így még ha a fürtverzió elromlik is a bevezetés során, a termelésünket ez nem érinti.
• Miután a klasztert száraz módban gördítettük ki, nyugodtan nézhetjük a válaszeltérések grafikonját. Ha a hibaarány lassan, de biztosan valami kis állandó felé halad, akkor minden rendben van. Miért vannak még mindig eltérések? Mivel a külön verzióban történő rögzítés valamivel korábban történik, mint a klaszterben, és a mikrolag miatt az adatok eltérhetnek. Nem marad más hátra, mint megnézni az eltérési naplókat, és ha mindet a rekord atommentességével magyarázzák, akkor mehetünk tovább.
• Most átkapcsolhatja a száraz üzemmódot az ellenkező irányba. Írni és olvasni fogunk a fürtből, és egy külön verzióba másoljuk. Miért? A következő héten szeretném megfigyelni a klaszter munkáját. Ha hirtelen kiderül, hogy csúcsterhelésnél problémák vannak, vagy valamit nem vettünk figyelembe, mindig van vészhelyzeti visszaállításunk a régi kódra és az aktuális adatokra a száraz üzemmódnak köszönhetően.
• Nincs más hátra, mint a száraz mód letiltása és a különálló verzió szétszerelése.

Szakvélemény

Először is röviden a fürt kialakításáról.

Először is, a Redis egy kulcs-érték tároló. Kulcsként tetszőleges karakterláncokat használnak. Számok, karakterláncok és teljes struktúrák használhatók értékként. Ez utóbbiak közül nagyon sok van, de az általános szerkezet megértéséhez ez számunkra nem fontos.
Az absztrakció következő szintje a billentyűk után a nyílások (SLOTS). Minden kulcs a 16 383 slot egyikéhez tartozik. Minden nyíláson belül tetszőleges számú kulcs lehet. Így az összes kulcs 16 383 diszjunkt készletre van felosztva.

Ezután N fő csomópontnak kell lennie a fürtben. Mindegyik csomópont egy különálló Redis-példánynak tekinthető, amely mindent tud a fürtön belüli többi csomópontról. Minden főcsomópont számos slotot tartalmaz. Minden slot csak egy fő csomóponthoz tartozik. Az összes helyet el kell osztani a csomópontok között. Ha néhány rés nincs lefoglalva, akkor a bennük tárolt kulcsok elérhetetlenek lesznek. Érdemes minden főcsomópontot külön logikai vagy fizikai gépen futtatni. Azt is érdemes megjegyezni, hogy minden csomópont csak egy magon fut, és ha több Redis-példányt szeretne futtatni ugyanazon a logikai gépen, győződjön meg arról, hogy azok különböző magokon futnak (ezt még nem próbáltuk, de elméletileg működnie kell) . Lényegében a főcsomópontok rendszeres felosztást biztosítanak, és több főcsomópont teszi lehetővé az írási és olvasási kérelmek méretezését.

Miután az összes kulcsot elosztották a rések között, és a réseket szétszórták a mester csomópontok között, tetszőleges számú szolga csomópont adható hozzá minden mester csomóponthoz. Minden ilyen master-slave hivatkozáson belül a normál replikáció működik. Slave-re van szükség az olvasási kérelmek méretezéséhez és a feladatátvételhez mester hiba esetén.

Most beszéljünk azokról a műveletekről, amelyeket jobb lenne elvégezni.

A rendszerhez a Redis-CLI-n keresztül fogunk hozzáférni. Mivel a Redisnek nincs egyetlen belépési pontja, a következő műveleteket bármelyik csomóponton elvégezheti. Minden ponton külön felhívom a figyelmet a művelet terhelés alatti végrehajtásának lehetőségére.

• Az első és legfontosabb dolog, amire szükségünk van, az a fürt csomópontok működése. Visszaadja a fürt állapotát, megjeleníti a csomópontok listáját, szerepkörüket, slot-elosztást stb. További információk a fürtinformációk és a fürthelyek használatával szerezhetők be.
• Jó lenne csomópontokat hozzáadni és eltávolítani. Erre a célra vannak fürt találkozás és fürt felejtés műveletek. Kérjük, vegye figyelembe, hogy a fürt felejtést MINDEN csomópontra alkalmazni kell, mind a mesterekre, mind a replikákra. A fürttalálkozót pedig csak egy csomóponton kell meghívni. Ez a különbség zavarba ejtő lehet, ezért a legjobb, ha tájékozódunk róla, mielőtt élesben hozzuk a fürtöt. A csomópont hozzáadása biztonságosan történik a csatában, és semmilyen módon nem befolyásolja a fürt működését (ami logikus). Ha el kíván távolítani egy csomópontot a fürtből, győződjön meg arról, hogy nem maradt rajta rés (ellenkező esetben fennáll annak a veszélye, hogy elveszíti a hozzáférést a csomópont összes kulcsához). Továbbá ne töröljön olyan mestert, amelyiknek szolgái vannak, különben szükségtelen szavazás történik egy új mesterre. Ha a csomópontok már nem rendelkeznek slottal, akkor ez egy kis probléma, de miért van szükségünk extra választási lehetőségekre, ha előbb törölhetjük a slave-eket.
• Ha erőszakosan fel kell cserélnie a mester és a szolga pozíciókat, akkor a fürt feladatátvételi parancs megteszi. Ha csatában hívja, meg kell értenie, hogy a mester nem lesz elérhető a művelet során. A váltás általában kevesebb, mint egy másodperc alatt következik be, de nem atomi. Számíthat arra, hogy ezalatt a mesterhez intézett egyes kérések meghiúsulnak.
• Mielőtt eltávolítana egy csomópontot a fürtből, ne maradjon rajta rés. Jobb, ha a cluster reshard paranccsal újraterjeszti őket. A slotok egyik mesterről a másikra kerülnek át. A teljes művelet több percig is eltarthat, ez függ az átvitt adatok mennyiségétől, de az átviteli folyamat biztonságos, és semmilyen módon nem befolyásolja a fürt működését. Így az összes adat közvetlenül terhelés alatt átvihető egyik csomópontról a másikra, anélkül, hogy aggódna az elérhetőségük miatt. Vannak azonban finomságok is. Először is, az adatátvitel a fogadó és a küldő csomópontok bizonyos terheléséhez kapcsolódik. Ha a fogadó csomópont már erősen le van terhelve a processzoron, akkor ne töltse be új adatok fogadásával. Másodszor, amint egyetlen rés sem marad a küldő mesteren, az összes szolga azonnal ahhoz a masterhez megy, amelyre ezeket a réseket átvitték. És a probléma az, hogy ezek a rabszolgák egyszerre akarják majd szinkronizálni az adatokat. És akkor szerencsés lesz, ha részleges, nem pedig teljes szinkronizálásról van szó. Vegye ezt figyelembe, és kombinálja a slotok átvitelének és a slave-ek letiltásának/átvitelének műveleteit. Vagy remélem, hogy elegendő biztonsági tartalékkal rendelkezik.
• Mi a teendő, ha az átutalás során úgy találja, hogy valahol elvesztette a résidőket? Remélem, ez a probléma nem érinti Önt, de ha igen, akkor van egy fürtjavítási művelet. Legalább véletlenszerű sorrendben szétszórja a réseket a csomópontok között. Azt javaslom, hogy ellenőrizze a működését úgy, hogy először távolítsa el az elosztott résekkel rendelkező csomópontot a fürtből. Mivel a fel nem osztott résekben lévő adatok már nem állnak rendelkezésre, túl késő aggódni az ilyen helyek elérhetőségével kapcsolatos problémák miatt. A művelet viszont nem érinti az elosztott slotokat.
• Egy másik hasznos művelet a monitor. Lehetővé teszi, hogy valós időben tekintse meg a csomóponthoz érkezett kérések teljes listáját. Sőt, grep, és megtudja, van-e a szükséges forgalom.

Érdemes megemlíteni a fő feladatátvételi eljárást is. Röviden: létezik, és véleményem szerint remekül működik. Ne gondolja azonban, hogy ha kihúzza egy főcsomóponttal rendelkező gép tápkábelét, a Redis azonnal átkapcsol, és az ügyfelek nem veszik észre a veszteséget. Az én gyakorlatomban a váltás néhány másodperc alatt megtörténik. Ezalatt az adatok egy része elérhetetlen lesz: a rendszer észleli a master elérhetetlenségét, a csomópontok újat szavaznak, a slave-eket váltják, az adatokat szinkronizálja. A legjobb módja annak, hogy megbizonyosodjon a rendszer működéséről, ha helyi gyakorlatokat hajt végre. Emelje fel a fürtöt a laptopon, biztosítson minimális terhelést, szimuláljon összeomlást (például a portok blokkolásával), és értékelje a kapcsolási sebességet. Véleményem szerint csak egy-két napos játék után lehet magabiztos a technológia működésében. Nos, vagy reméljük, hogy az a szoftver, amelyet az internet fele használ, valószínűleg működik.

Configuration

Gyakran a konfiguráció az első dolog, amire szüksége van az eszközzel való munka megkezdéséhez. És ha minden működik, akkor nem is akarja megérinteni a konfigurációt. Némi erőfeszítést igényel, hogy rákényszerítse magát, hogy visszatérjen a beállításokhoz, és gondosan végignézze azokat. Emlékeim szerint legalább két komoly meghibásodásunk volt a konfigurációval kapcsolatos figyelmetlenség miatt. Különös figyelmet kell fordítani a következő pontokra:

• időtúllépés 0
  Az az idő, amely után az inaktív kapcsolatok bezáródnak (másodpercben). 0 - ne zárja be
  Nem minden könyvtárunk tudta megfelelően lezárni a kapcsolatokat. A beállítás letiltásával azt kockáztatjuk, hogy elérjük az ügyfelek számának korlátját. Másrészt, ha van ilyen probléma, akkor a megszakadt kapcsolatok automatikus megszakítása elfedi, és nem biztos, hogy észrevesszük. Ezenkívül ne engedélyezze ezt a beállítást, ha fennálló kapcsolatokat használ.
• Mentse el az xy-t és csak hozzáfűzze, igen
  RDB pillanatkép mentése.
  Az RDB/AOF-problémákat az alábbiakban részletesen tárgyaljuk.
• stop-writes-on-bgsave-error no & slave-serve-stale-data igen
  Ha engedélyezve van, és az RDB pillanatkép megszakad, a mester nem fogadja el a változtatási kérelmeket. Ha megszakad a kapcsolat a masterrel, a slave továbbra is válaszolhat a kérésekre (igen). Vagy nem válaszol (nem)
  Nem vagyunk elégedettek a helyzettel, amikor Redis tökké változik.
• repl-ping-slave-period 5
  Ezen idő elteltével aggódni kezdünk, hogy a mester meghibásodott, és itt az ideje végrehajtani a feladatátvételi eljárást.
  Manuálisan kell megtalálnia az egyensúlyt a hamis pozitívumok és a feladatátvétel kiváltása között. Gyakorlatunkban ez 5 másodperc.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  Pontosan ennyi adatot tudunk tárolni egy pufferben egy meghibásodott replika esetén. Ha a puffer kifogy, teljesen szinkronizálnia kell.
  A gyakorlat azt sugallja, hogy jobb magasabb értéket beállítani. Számos oka lehet annak, hogy a replika késni kezd. Ha késik, akkor nagy valószínűséggel a gazdája már nehezen boldogul, és a teljes szinkronizálás lesz az utolsó csepp a pohárban.
• Maximum ügyfelek 10000
  Az egyszeri ügyfelek maximális száma.
  Tapasztalataink szerint jobb, ha magasabb értéket állítunk be. A Redis remekül kezeli a 10 XNUMX kapcsolatot. Csak győződjön meg arról, hogy elegendő aljzat van a rendszerben.
• maxmemory-policy volatile-ttl
  Az a szabály, amely alapján a kulcsok törlődnek a rendelkezésre álló memóriakorlát elérésekor.
  Itt nem maga a szabály a fontos, hanem annak megértése, hogy ez hogyan fog történni. A Redis azért dicsérhető, mert a memóriakorlát elérésekor képes normálisan működni.

RDB és AOF problémák

Bár maga a Redis minden információt a RAM-ban tárol, van egy mechanizmus az adatok lemezre mentésére is. Pontosabban három mechanizmus:

• RDB-pillanatkép – az összes adat teljes pillanatképe. Állítsa be az XY MENTÉSE konfigurációval, és ezt olvassa el: „Minden adat teljes pillanatfelvételének mentése X másodpercenként, ha legalább Y kulcs megváltozott”.
• Csak hozzáfűzhető fájl – a műveletek listája végrehajtásuk sorrendjében. X másodpercenként vagy Y műveletenként új bejövő műveleteket ad a fájlhoz.
• Az RDB és az AOF az előző kettő kombinációja.

Minden módszernek megvannak a maga előnyei és hátrányai, nem sorolom fel mindet, csak olyan pontokra hívom fel a figyelmet, amelyek véleményem szerint nem egyértelműek.

Először is, egy RDB-pillanatkép mentéséhez meg kell hívni a FORK-ot. Ha sok adat van, ez néhány ezredmásodperctől egy másodpercig leállíthatja az összes Redis-t. Ezenkívül a rendszernek memóriát kell lefoglalnia egy ilyen pillanatképhez, ami ahhoz vezet, hogy dupla RAM-ellátást kell tartani a logikai gépen: ha 8 GB van lefoglalva a Redis számára, akkor 16 GB-nak kell rendelkezésre állnia a virtuális gépen. azt.

Másodszor, problémák vannak a részleges szinkronizálással. AOF módban, amikor a slave újracsatlakozik, részleges szinkronizálás helyett teljes szinkronizálás végezhető. Miért történik ez, nem tudtam megérteni. De ezt érdemes megjegyezni.

Ez a két pont már arra késztet bennünket, hogy elgondolkodjunk, vajon valóban szükségünk van-e ezekre az adatokra a lemezen, ha már mindent lemásolnak a slave-ek. Az adatok csak akkor veszhetnek el, ha az összes slave meghibásodik, és ez „tűz a DC-ben” szintű probléma. Kompromisszumként javasolhatja, hogy csak a slave-eken mentsük az adatokat, de ebben az esetben meg kell győződni arról, hogy ezek a szolgák soha ne váljanak mesterré a katasztrófa-helyreállítás során (ehhez van egy slave prioritás beállítás a konfigurációjukban). Saját magunk számára minden konkrét esetben átgondoljuk, hogy szükséges-e az adatokat lemezre menteni, és a válasz leggyakrabban „nem”.

Következtetés

Végezetül remélem, hogy sikerült általános képet adni a redis-cluster működéséről azok számára, akik még nem hallottak róla, és felhívtam a figyelmet néhány nem nyilvánvaló pontra azok számára, akik már használják. hosszú ideje.
Köszönjük az idejét, és mint mindig, szívesen fogadjuk a témával kapcsolatos észrevételeket.

Forrás: will.com