Þegar kemur að vöru sem hefur verið í þróun í meira en áratug kemur það alls ekki á óvart að finna gamaldags tækni í henni. En hvað ef eftir sex mánuði þarftu að halda álaginu 10 sinnum hærra og kostnaðurinn við fall mun aukast hundruð sinnum? Í þessu tilfelli þarftu flottan Highload Engineer. En í fjarveru vinnukonu fólu þeir mér að leysa vandamálið. Í fyrri hluta greinarinnar mun ég segja þér hvernig við fórum frá Redis í Redis-þyrping og í seinni hlutanum mun ég gefa ráð um hvernig á að byrja að nota klasann og að hverju ber að huga þegar þú notar hann.

Tæknival

Er það svona slæmt? aðskilið Redis (standalone redis) í stillingu 1 herra og N þræla? Af hverju kalla ég það úrelta tækni?

Nei, Redis er ekki svo slæm... Hins vegar eru nokkrir annmarkar sem ekki er hægt að hunsa.

• Í fyrsta lagi styður Redis ekki hamfarabatakerfi eftir meistarabilun. Til að leysa þetta vandamál notuðum við stillingar með sjálfvirkum flutningi VIPs yfir á nýjan húsbónda, breyttum hlutverki eins þrælanna og skiptum um restina. Þetta fyrirkomulag virkaði, en það var ekki hægt að kalla það áreiðanlega lausn. Í fyrsta lagi komu falskar viðvaranir og í öðru lagi var það einnota og eftir notkun þurfti handvirkar aðgerðir til að hlaða gorminn.

• Í öðru lagi, að hafa aðeins einn húsbónda leiddi til vandans við að skera niður. Við þurftum að búa til nokkra sjálfstæða klasa „1 herra og N þræla“ og dreifa síðan gagnagrunnunum handvirkt á milli þessara véla og vonum að á morgun myndi einn gagnagrunnanna ekki bólgna svo mikið að það þyrfti að færa hann í sérstakt tilvik.

Hverjir eru kostirnir?

• Dýrasta og ríkasta lausnin er Redis-Enterprise. Þetta er kassalausn með fullri tækniaðstoð. Þrátt fyrir að það líti tilvalið út frá tæknilegu sjónarmiði, hentaði það okkur ekki af hugmyndafræðilegum ástæðum.
• Redis-þyrping. Upp úr kassanum er stuðningur við master failover og sharding. Viðmótið er nánast ekkert frábrugðið venjulegri útgáfu. Það lofar góðu, við tölum um gildrurnar síðar.
• Tarantool, Memcache, Aerospike og fleiri. Öll þessi verkfæri gera nokkurn veginn það sama. En hver hefur sína galla. Við ákváðum að setja ekki öll eggin okkar í eina körfu. Við notum Memcache og Tarantool fyrir önnur verkefni, og þegar horft er fram á veginn mun ég segja að á æfingum okkar hafi verið meiri vandamál með þau.

Sérstakur notkun

Við skulum skoða hvaða vandamál við höfum leyst í gegnum tíðina með Redis og hvaða virkni við notuðum:

• Skyndiminni fyrir beiðnir til fjarþjónustu eins og 2GIS | Golang
  

  GET SET MGET MSET "SELECT DB"

• Skyndiminni á undan MYSQL | PHP
  

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

• Helstu geymsla fyrir þjónustu við að vinna með lotur og hnit ökumanns | Golang
  

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

Eins og þú sérð, engin æðri stærðfræði. Hver er þá erfiðleikinn? Við skulum skoða hverja aðferð fyrir sig.

Aðferð
Lýsing
Eiginleikar Redis-þyrpingarinnar
ákvörðun

TILBÚIN
Skrifa/lesa lykill

MGET MSET
Skrifaðu / lestu marga lykla
Lyklarnir verða á mismunandi hnútum. Tilbúin bókasöfn geta aðeins framkvæmt margar aðgerðir innan eins hnúts
Skiptu út MGET fyrir leiðslu N GET aðgerða

VELDU DB
Veldu grunninn sem við munum vinna með
Styður ekki marga gagnagrunna
Settu allt í einn gagnagrunn. Bættu forskeytum við lykla

SCAN
Farðu í gegnum alla lykla í gagnagrunninum
Þar sem við erum með einn gagnagrunn er of dýrt að fara í gegnum alla lyklana í klasanum
Viðhaldið óbreytileika innan eins takka og gerðu HSCAN á þessum lykli. Eða neita algjörlega

GEO
Aðgerðir með geokey
Gearlykillinn er ekki rifinn

LYKILL EFTIR MYNSTUR
Leita að lykli eftir mynstri
Þar sem við erum með einn gagnagrunn munum við leita á öllum lyklum í klasanum. Of dýrt
Neita eða viðhalda óbreytileikanum, eins og í tilfelli SCAN

Redis vs Redis-þyrping

Hverju töpum við og hverju græðum við þegar skipt er yfir í klasa?

• Ókostir: við missum virkni nokkurra gagnagrunna.
  • Ef við viljum geyma rökfræðilega óskyld gögn í einum klasa verðum við að búa til hækjur í formi forskeyti.
  • Við týnum öllum „grunnaðgerðum“ eins og SCAN, DBSIZE, CLEAR DB, o.s.frv.
  • Fjölaðgerðir eru orðnar mun erfiðari í framkvæmd vegna þess að þær geta þurft aðgang að nokkrum hnútum.
• Plús:
  • Bilunarþol í formi master failover.
  • Sharding Redis megin.
  • Flytja gögn á milli hnúta í lotukerfinu og án niður í miðbæ.
  • Bættu við og endurdreifðu getu og álagi án niður í miðbæ.

Ég myndi draga þá ályktun að ef þú þarft ekki að veita mikið bilunarþol, þá er það ekki þess virði að flytja í klasa, vegna þess að það getur verið léttvægt verkefni. En ef þú velur í upphafi á milli sérstakrar útgáfu og klasaútgáfu, þá ættir þú að velja klasa, þar sem það er ekkert verra og að auki losar þú við höfuðverkinn.

Undirbúa flutning

Við skulum byrja á kröfunum til að flytja:

• Það ætti að vera óaðfinnanlegt. Algjört þjónustustopp í 5 mínútur hentar okkur ekki.
• Það ætti að vera eins öruggt og hægt og hægt er. Ég vil hafa einhverja stjórn á aðstæðum. Við viljum ekki henda öllu í einu og biðja um afturköllunarhnappinn.
• Lágmarks gagnatap við flutning. Við skiljum að það verður mjög erfitt að hreyfa sig í lotukerfinu, þannig að við leyfum nokkra afsamstillingu á milli gagna í venjulegum og þyrpuðum Redis.

Klasaviðhald

Rétt fyrir flutninginn ættum við að hugsa um hvort við getum stutt klasann:

• Töflur. Við notum Prometheus og Grafana til að grafa upp CPU hleðslu, minnisnotkun, fjölda viðskiptavina, fjölda GET, SET, AUTH aðgerða o.s.frv.
• Sérfræðiþekking. Ímyndaðu þér að á morgun muntu hafa risastóran þyrping á þína ábyrgð. Ef það bilar getur enginn nema þú lagað það. Ef hann fer að hægja á sér munu allir hlaupa á móti þér. Ef þú þarft að bæta við auðlindum eða dreifa álaginu aftur, komdu aftur til þín. Til þess að grána ekki við 25 ára aldur er ráðlegt að gera ráð fyrir þessum tilfellum og athuga fyrirfram hvernig tæknin mun haga sér við ákveðnar aðgerðir. Við skulum tala um þetta nánar í hlutanum „Sérfræði“.
• Vöktun og viðvaranir. Þegar þyrping brotnar niður viltu vera fyrstur til að vita af því. Hér takmörkuðum við okkur við tilkynningu um að allir hnútar skila sömu upplýsingum um ástand klasans (já, það gerist öðruvísi). Og hægt er að taka eftir öðrum vandamálum hraðar með tilkynningum frá Redis viðskiptavinaþjónustu.

Flytja

Hvernig við munum flytja:

• Fyrst af öllu þarftu að undirbúa bókasafn til að vinna með klasann. Við tókum go-redis sem grunn fyrir Go útgáfuna og breyttum henni aðeins til að henta okkur sjálfum. Við innleiddum fjölaðferðir í gegnum leiðslur og leiðréttum einnig reglurnar um endurteknar beiðnir lítillega. PHP útgáfan átti við fleiri vandamál en við komumst að lokum að php-redis. Þeir kynntu nýlega klasastuðning og það lítur vel út að okkar mati.
• Næst þarftu að dreifa þyrpingunni sjálfum. Þetta er gert bókstaflega í tveimur skipunum byggðar á stillingarskránni. Við munum ræða stillinguna nánar hér að neðan.
• Fyrir hægfara hreyfingu notum við þurrstillingu. Þar sem við erum með tvær útgáfur af bókasafninu með sama viðmóti (ein fyrir venjulega útgáfu, hin fyrir klasann), þá kostar ekkert að búa til umbúðir sem virkar með sérstakri útgáfu og samhliða afrita allar beiðnir til klasans, bera saman svör og skrifa misræmi í annálana (í okkar tilviki í NewRelic). Þannig að jafnvel þótt klasaútgáfan brotni við útsetningu mun framleiðsla okkar ekki verða fyrir áhrifum.
• Eftir að hafa rúllað út þyrpingunni í þurrham, getum við í rólegheitum horft á línuritið yfir svörunarmisræmi. Ef villuhlutfallið færist hægt en örugglega í átt að einhverjum litlum fasta, þá er allt í lagi. Hvers vegna eru enn misræmi? Vegna þess að upptaka í sérstakri útgáfu á sér stað aðeins fyrr en í þyrpingunni og vegna örþrengslna geta gögnin verið mismunandi. Það eina sem er eftir er að skoða misræmisskrárnar og ef þeir eru allir útskýrðir af því að skráin er ekki atóm, þá getum við haldið áfram.
• Nú geturðu skipt um þurrstillingu í gagnstæða átt. Við munum skrifa og lesa úr þyrpingunni og afrita það í sérstaka útgáfu. Til hvers? Í næstu viku langar mig að fylgjast með starfi klasans. Ef það kemur skyndilega í ljós að vandamál eru í hámarksálagi, eða við tókum ekki eitthvað með í reikninginn, erum við alltaf með neyðartilbaka í gamla kóðann og núverandi gögn þökk sé þurrstillingu.
• Allt sem er eftir er að slökkva á þurrstillingu og taka í sundur aðskildu útgáfuna.

Sérfræðiþekking

Í fyrsta lagi stuttlega um klasahönnunina.

Í fyrsta lagi er Redis verslun með lykilgildi. Handahófskenndir strengir eru notaðir sem lyklar. Hægt er að nota tölur, strengi og heilar mannvirki sem gildi. Það eru mjög margir af þeim síðarnefndu, en til að skilja almenna uppbyggingu er þetta ekki mikilvægt fyrir okkur.
Næsta útdráttarstig á eftir lyklum er rifa (RAUF). Hver lykill tilheyrir einum af 16 rifum. Það getur verið hvaða fjöldi lykla sem er í hverri rauf. Þannig er öllum lyklum skipt í 383 sundurlaus sett.

Næst verða N höfuðhnútar að vera í klasanum. Líta má á hvern hnút sem sérstakt Redis tilvik sem veit allt um aðra hnúta innan klasans. Hver aðalhnút inniheldur fjölda rifa. Hver rifa tilheyrir aðeins einum aðalhnút. Dreifa þarf öllum raufum á milli hnúta. Ef einhverjum afgreiðslutímum er ekki úthlutað, þá verða lyklarnir sem eru geymdir í þeim óaðgengilegir. Það er skynsamlegt að keyra hvern aðalhnút á sérstakri rökrænni eða líkamlegri vél. Það er líka þess virði að muna að hver hnút keyrir aðeins á einum kjarna og ef þú vilt keyra mörg Redis tilvik á sömu rökréttu vélinni skaltu ganga úr skugga um að þau keyri á mismunandi kjarna (við höfum ekki prófað þetta, en í orði ætti það að virka) . Í meginatriðum veita aðalhnútar reglulega sundrun og fleiri aðalhnútar gera skrif- og lesbeiðnir kleift að skala.

Eftir að öllum lyklunum hefur verið dreift á milli raufanna og raufunum er dreift á milli aðalhnúta er hægt að bæta handahófskenndum fjölda þrælhnúta við hvern aðalhnút. Innan hvers slíks master-slave hlekkur mun eðlileg afritun virka. Þrælar eru nauðsynlegir til að skala lestrarbeiðnir og fyrir bilun ef meistarabilun verður.

Nú skulum við tala um aðgerðir sem betra væri að geta gert.

Við munum fá aðgang að kerfinu í gegnum Redis-CLI. Þar sem Redis er ekki með einn aðgangsstað geturðu framkvæmt eftirfarandi aðgerðir á hvaða hnút sem er. Á hverjum stað vek ég sérstaklega athygli á möguleikanum á að framkvæma aðgerðina undir álagi.

• Það fyrsta og mikilvægasta sem við þurfum er rekstur klasahnúta. Það skilar stöðu klasans, sýnir lista yfir hnúta, hlutverk þeirra, dreifingu rifa osfrv. Frekari upplýsingar er hægt að fá með því að nota klasaupplýsingar og klasaafgreiðslur.
• Það væri gaman að geta bætt við og fjarlægt hnúta. Í þessu skyni eru klasamót og klasagleyma starfsemi. Vinsamlegast athugaðu að cluster forgeit verður að nota á ALLA hnút, bæði meistara og eftirmyndir. Og cluster meet þarf aðeins að kalla á einn hnút. Þessi munur getur verið óhugnanlegur, svo það er best að læra um hann áður en þú ferð með þyrpinguna þína. Að bæta við hnút er gert á öruggan hátt í bardaga og hefur ekki áhrif á rekstur klasans á nokkurn hátt (sem er rökrétt). Ef þú ætlar að fjarlægja hnút úr þyrpingunni ættirðu að ganga úr skugga um að engar raufar séu eftir á honum (annars er hætta á að þú missir aðgang að öllum lyklunum á þessum hnút). Ekki eyða líka húsbónda sem er með þræla, annars verður óþarfa atkvæði um nýjan húsbónda. Ef hnútarnir eru ekki lengur með rifa, þá er þetta lítið vandamál, en hvers vegna þurfum við aukavalkosti ef við getum eytt þrælunum fyrst.
• Ef þú þarft að skipta kröftuglega um skipstjóra og þrælastöðu, þá dugar skipun þyrpingarinnar. Þegar þú kallar það í bardaga þarftu að skilja að meistarinn verður ekki tiltækur meðan á aðgerðinni stendur. Venjulega gerist skiptingin á innan við einni sekúndu, en er ekki atóm. Þú getur búist við því að sumar beiðnir til skipstjóra muni mistakast á þessum tíma.
• Áður en hnútur er fjarlægður úr þyrpingunni ættu engar raufar að vera eftir á honum. Það er betra að dreifa þeim aftur með því að nota cluster reshard skipunina. Spilakassar verða fluttir frá einum meistara til annars. Öll aðgerðin getur tekið nokkrar mínútur, það fer eftir magni gagna sem flutt er, en flutningsferlið er öruggt og hefur ekki áhrif á rekstur klasans á nokkurn hátt. Þannig er hægt að flytja öll gögn frá einum hnút til annars beint undir álagi og án þess að hafa áhyggjur af framboði þeirra. Hins vegar eru líka næmi. Í fyrsta lagi er gagnaflutningur tengdur ákveðnu álagi á hnúta viðtakanda og sendanda. Ef viðtakandahnúturinn er nú þegar mikið hlaðinn á örgjörvann, þá ættirðu ekki að hlaða honum með móttöku nýrra gagna. Í öðru lagi, um leið og það er ekki ein einasta rifa eftir á sendiherranum, munu allir þrælar hans fara strax til húsbóndans sem þessar raufar voru fluttar til. Og vandamálið er að allir þessir þrælar vilja samstilla gögn í einu. Og þú munt vera heppinn ef það er að hluta frekar en algjör samstilling. Taktu tillit til þessa og sameinaðu aðgerðirnar við að flytja afgreiðslutíma og slökkva/flutninga þræla. Eða vona að þú hafir nægjanlegt öryggissvigrúm.
• Hvað ættir þú að gera ef þú kemst að því við flutninginn að þú hafir týnt spilakössum einhvers staðar? Ég vona að þetta vandamál hafi ekki áhrif á þig, en ef það gerir það, þá er til klasaleiðrétting. Að minnsta kosti mun hún dreifa raufunum yfir hnútana í handahófskenndri röð. Ég mæli með því að athuga virkni þess með því að fjarlægja fyrst hnútinn með dreifðum raufum úr þyrpingunni. Þar sem gögn í óúthlutuðum afgreiðslutímum eru nú þegar ekki tiltæk, er of seint að hafa áhyggjur af vandamálum með framboð á þessum raufum. Aftur á móti mun aðgerðin ekki hafa áhrif á dreifða spilakassa.
• Önnur gagnleg aðgerð er skjár. Það gerir þér kleift að sjá í rauntíma allan listann yfir beiðnir sem fara í hnútinn. Þar að auki geturðu gripið það og fundið út hvort það sé nauðsynleg umferð.

Það er líka þess virði að minnast á master failover aðferðina. Í stuttu máli, það er til, og að mínu mati, það virkar frábærlega. Hins vegar skaltu ekki halda að ef þú tekur rafmagnssnúruna úr sambandi á vél með aðalhnút mun Redis strax skipta yfir og viðskiptavinir munu ekki taka eftir tapinu. Í mínum æfingum gerist skiptingin á nokkrum sekúndum. Á þessum tíma verða sum gagna ekki tiltæk: ófáanleiki skipstjórans er greindur, hnútar kjósa nýjan, skipt er um þræla, gögn eru samstillt. Besta leiðin til að ganga úr skugga um að kerfið virki er að framkvæma staðbundnar æfingar. Lyftu þyrpingunni á fartölvunni þinni, láttu hana vera lágmarksálag, líktu eftir hruni (til dæmis með því að loka fyrir tengin) og metið skiptihraðann. Að mínu mati, aðeins eftir að hafa spilað á þennan hátt í einn eða tvo daga geturðu verið öruggur í rekstri tækninnar. Jæja, eða vona að hugbúnaðurinn sem helmingur internetsins notar virki líklega.

Stillingar

Oft er uppsetningin það fyrsta sem þú þarft til að byrja að vinna með tólið. Og þegar allt virkar, vilt þú ekki einu sinni snerta stillinguna. Það tekur smá áreynslu að þvinga sjálfan sig til að fara aftur í stillingarnar og fara vandlega í gegnum þær. Í minningunni lentum við í að minnsta kosti tveimur alvarlegum bilunum vegna athyglisleysis á uppsetningunni. Gefðu sérstaka athygli á eftirfarandi atriðum:

• tímamörk 0
  Tími eftir að óvirkum tengingum er lokað (í sekúndum). 0 - ekki loka
  Ekki hvert bókasafn okkar gat lokað tengingum á réttan hátt. Með því að slökkva á þessari stillingu eigum við á hættu að ná takmörkunum á fjölda viðskiptavina. Á hinn bóginn, ef það er slíkt vandamál, þá mun sjálfvirk lokun tapaðra tenginga dulka það og við gætum ekki tekið eftir því. Að auki ættirðu ekki að virkja þessa stillingu þegar þú notar viðvarandi tengingar.
• Vista xy og viðauka já
  Vistar RDB skyndimynd.
  Við munum ræða RDB/AOF málefni í smáatriðum hér að neðan.
• stop-writes-on-bgsave-error no & slave-serve-stale-data já
  Ef virkt, ef RDB skyndimyndin bilar, mun skipstjórinn hætta að samþykkja breytingarbeiðnir. Ef tengingin við húsbóndann rofnar getur þrællinn haldið áfram að svara beiðnum (já). Eða mun hætta að svara (nei)
  Við erum ekki ánægð með stöðuna þar sem Redis breytist í grasker.
• repl-ping-slave-tímabil 5
  Eftir þennan tíma munum við byrja að hafa áhyggjur af því að skipstjórinn hafi bilað og það sé kominn tími til að framkvæma bilunarferlið.
  Þú verður að finna jafnvægi handvirkt á milli rangra jákvæðra og kveikja á bilun. Í okkar æfingum er þetta 5 sekúndur.
• repl-backlog-stærð 1024mb & epl-backlog-ttl 0
  Við getum geymt nákvæmlega svona mikið af gögnum í biðminni fyrir misheppnaða eftirmynd. Ef biðminni klárast verður þú að samstilla algjörlega.
  Æfingin bendir til þess að betra sé að setja hærra gildi. Það eru margar ástæður fyrir því að eftirmynd gæti byrjað að seinka. Ef það sefur, þá er líklegast að húsbóndi þinn er nú þegar í erfiðleikum með að takast á við, og full samstilling verður síðasta hálmstráið.
• maxclients 10000
  Hámarksfjöldi einskiptis viðskiptavina.
  Í okkar reynslu er betra að setja hærra gildi. Redis sér bara vel um 10k tengingar. Gakktu bara úr skugga um að það séu nægar innstungur á kerfinu.
• maxmemory-stefna óstöðug-ttl
  Reglan þar sem lyklum er eytt þegar tiltæku minnistakmörkunum er náð.
  Það sem skiptir máli hér er ekki reglan sjálf, heldur skilningurinn á því hvernig þetta mun gerast. Hrósa má Redis fyrir getu sína til að vinna eðlilega þegar minnismörkum er náð.

RDB og AOF vandamál

Þó að Redis geymi sjálft allar upplýsingar í vinnsluminni, þá er líka til búnaður til að vista gögn á disk. Nánar tiltekið, þrjár leiðir:

• RDB-snapshot - heildarmynd af öllum gögnum. Stilltu með því að nota SAVE XY stillinguna og segir "Vista heildarmynd af öllum gögnum á X sekúndna fresti ef að minnsta kosti Y lyklar hafa breyst."
• Skrá sem eingöngu er hægt að bæta við - listi yfir aðgerðir í þeirri röð sem þær eru framkvæmdar. Bætir nýjum mótteknum aðgerðum við skrána á X sekúndna fresti eða á Y aðgerðum.
• RDB og AOF eru sambland af fyrri tveimur.

Allar aðferðir hafa sína kosti og galla, ég ætla ekki að telja þá alla upp, ég vek bara athygli á atriðum sem að mínu mati eru ekki augljós.

Í fyrsta lagi þarf að hringja í FORK til að vista RDB skyndimynd. Ef það er mikið af gögnum getur þetta hangið allt Redis í nokkrar millisekúndur í sekúndu. Að auki þarf kerfið að úthluta minni fyrir slíka skyndimynd, sem leiðir til þess að halda þarf tvöföldu framboði af vinnsluminni á rökréttu vélinni: ef 8 GB er úthlutað fyrir Redis, þá ætti 16 GB að vera tiltækt á sýndarvélinni með það.

Í öðru lagi eru vandamál með samstillingu að hluta. Í AOF ham, þegar þrællinn er tengdur aftur, í stað samstillingar að hluta, er hægt að framkvæma fulla samstillingu. Hvers vegna þetta gerist gat ég ekki skilið. En það er þess virði að muna þetta.

Þessir tveir punktar fá okkur nú þegar til að hugsa um hvort við þurfum virkilega þessi gögn á disknum ef allt er þegar afritað af þrælum. Gögn geta aðeins tapast ef allir þrælar mistakast, og þetta er „eldur í DC“ vandamáli. Sem málamiðlun geturðu lagt til að vista gögn aðeins um þræla, en í þessu tilfelli þarftu að ganga úr skugga um að þessir þrælar verði aldrei meistari meðan á hörmungarbati stendur (fyrir þetta er þrælaforgangsstilling í stillingum þeirra). Fyrir okkur sjálf, í hverju einstöku tilviki, hugsum við um hvort það sé nauðsynlegt að vista gögn á disk, og oftast er svarið „nei“.

Ályktun

Að lokum vona ég að ég hafi getað gefið almenna hugmynd um hvernig redis-cluster virkar fyrir þá sem hafa alls ekki heyrt um það, og einnig vakið athygli á nokkrum óaugljósum atriðum fyrir þá sem hafa notað það í langan tíma.
Þakka þér fyrir tíma þinn og eins og alltaf eru athugasemdir um efnið vel þegnar.

Heimild: www.habr.com