Pievēršoties produktam, kas tiek izstrādāts vairāk nekā desmit gadus, nav pārsteidzoši atrast tajā novecojušas tehnoloģijas. Bet ko darīt, ja sešos mēnešos jums ir jāsaglabā 10 reizes lielāka slodze, un kritienu izmaksas palielināsies simtiem reižu? Šajā gadījumā jums ir nepieciešams foršs Highload inženieris. Bet, ja nebija istabenes, viņi man uzticēja problēmas risināšanu. Raksta pirmajā daļā pastāstīšu, kā no Redis pārgājām uz Redis-klasteri, bet otrajā sniegšu padomus, kā sākt lietot klasteru un kam pievērst uzmanību to lietojot.

Tehnoloģiju izvēle

Vai tas ir tik slikti? atsevišķs Redis (savrupais redis) konfigurācijā, kurā ir 1 galvenais un N slaves? Kāpēc es to saucu par novecojušu tehnoloģiju?

Nē, Redis nav nemaz tik slikts... Tomēr ir daži trūkumi, kurus nevar ignorēt.

• Pirmkārt, Redis neatbalsta avārijas atkopšanas mehānismus pēc galvenās kļūmes. Lai atrisinātu šo problēmu, mēs izmantojām konfigurāciju ar automātisku VIP pārsūtīšanu uz jaunu galveno, mainot viena no vergu lomu un pārslēdzot pārējos. Šis mehānisms darbojās, taču to nevarēja saukt par uzticamu risinājumu. Pirmkārt, radās viltus trauksmes, un, otrkārt, tas bija vienreiz lietojams, un pēc darbības bija jāveic manuālas darbības, lai uzlādētu atsperi.

• Otrkārt, tas, ka bija tikai viens meistars, noveda pie šķelšanās problēmas. Nācās izveidot vairākus neatkarīgus klasterus “1 master and N slaves”, pēc tam manuāli sadalīt datubāzes starp šīm mašīnām un cerēt, ka rīt kāda no datu bāzēm tik ļoti neuzbriest, ka būtu jāpārvieto uz atsevišķu instanci.

Kādas ir iespējas?

• Visdārgākais un bagātākais risinājums ir Redis-Enterprise. Šis ir kastes risinājums ar pilnu tehnisko atbalstu. Neskatoties uz to, ka no tehniskā viedokļa izskatās ideāli, ideoloģisku apsvērumu dēļ tas mums nederēja.
• Redis-klasteris. Sākotnēji ir atbalsts galvenajai kļūmjpārlēcei un sadalīšanai. Interfeiss gandrīz neatšķiras no parastās versijas. Tas izskatās daudzsološi, par kļūdām runāsim vēlāk.
• Tarantool, Memcache, Aerospike un citi. Visi šie rīki darbojas gandrīz vienādi. Bet katram ir savi trūkumi. Nolēmām visas olas nelikt vienā grozā. Mēs izmantojam Memcache un Tarantool citiem uzdevumiem, un, skatoties uz priekšu, teikšu, ka mūsu praksē ar tiem bija vairāk problēmu.

Lietošanas specifika

Apskatīsim, kādas problēmas esam vēsturiski atrisinājuši ar Redis un kādu funkcionalitāti izmantojām:

• Kešatmiņa pirms pieprasījumiem attāliem pakalpojumiem, piemēram, 2GIS | Golang
  

  GET SET MGET MSET "SELECT DB"

• Kešatmiņa pirms MYSQL | PHP
  

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

• Galvenā krātuve pakalpojumam darbam ar sesijām un vadītāja koordinātām | Golang
  

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

Kā redzat, nav augstākās matemātikas. Kādas tad ir grūtības? Apskatīsim katru metodi atsevišķi.

Metode
Apraksts
Redis klastera iezīmes
Šķīdums

SAGATAVOJIES
Rakstīšanas/lasīšanas atslēga

MGET MSET
Rakstīt/lasīt vairākus taustiņus
Atslēgas atradīsies dažādos mezglos. Gatavās bibliotēkas var veikt vairākas darbības tikai vienā mezglā
Aizstājiet MGET ar N GET darbību konveijeru

IZVĒLĒTIES DB
Izvēlieties bāzi, ar kuru mēs strādāsim
Neatbalsta vairākas datu bāzes
Ievietojiet visu vienā datubāzē. Pievienojiet taustiņiem prefiksus

SCAN
Izejiet cauri visām datu bāzē esošajām atslēgām
Tā kā mums ir viena datu bāze, visu klastera taustiņu caurskatīšana ir pārāk dārga
Saglabājiet invariantu vienā atslēgā un veiciet HSCAN ar šo taustiņu. Vai arī pilnībā atteikties

GEO
Darbības ar ģeoatslēgu
Ģeoatslēga nav sašķelta

ATSLĒGA PĒC RAŽA
Atslēgas meklēšana pēc modeļa
Tā kā mums ir viena datu bāze, mēs meklēsim visās klastera atslēgās. Pārāk dārgi
Atteikties vai saglabāt invariantu, kā tas ir SCAN gadījumā

Redis vs Redis klasteris

Ko mēs zaudējam un ko iegūstam, pārejot uz klasteru?

• Trūkumi: mēs zaudējam vairāku datu bāzu funkcionalitāti.
  • Ja mēs vēlamies glabāt loģiski nesaistītus datus vienā klasterī, mums būs jāveido kruķi prefiksu veidā.
  • Mēs zaudējam visas “bāzes” darbības, piemēram, SCAN, DBSIZE, CLEAR DB utt.
  • Vairākas darbības ir kļuvušas daudz grūtāk īstenojamas, jo var būt nepieciešama piekļuve vairākiem mezgliem.
• priekšrocības:
  • Kļūdu tolerance galvenās kļūmjpārlēces veidā.
  • Dalīšana Redis pusē.
  • Pārsūtiet datus starp mezgliem atomiski un bez dīkstāves.
  • Pievienojiet un sadaliet jaudu un slodzes bez dīkstāves.

Es secinu, ka, ja jums nav nepieciešams nodrošināt augstu kļūdu toleranci, tad pāriet uz klasteri nav tā vērts, jo tas var būt nenozīmīgs uzdevums. Bet, ja sākotnēji izvēlaties starp atsevišķu versiju un klastera versiju, tad jums vajadzētu izvēlēties klasteru, jo tas nav sliktāks un turklāt atbrīvos jūs no dažām galvassāpēm

Gatavošanās kustībai

Sāksim ar pārvietošanas prasībām:

• Tam jābūt nevainojamam. Pilnīga dienesta apturēšana uz 5 minūtēm mums neder.
• Tam jābūt pēc iespējas drošākam un pakāpeniskākam. Es vēlos kaut nedaudz kontrolēt situāciju. Mēs nevēlamies izmest visu uzreiz un lūgt par atgriešanas pogu.
• Minimāls datu zudums pārvietojoties. Mēs saprotam, ka to būs ļoti grūti pārvietot atomiski, tāpēc mēs pieļaujam zināmu desinhronizāciju starp datiem parastajā un grupētajā Redis.

Klasteru uzturēšana

Tieši pirms pārcelšanās mums vajadzētu padomāt par to, vai varam atbalstīt kopu:

• Diagrammas. Mēs izmantojam Prometheus un Grafana, lai attēlotu CPU slodzi, atmiņas lietojumu, klientu skaitu, GET, SET, AUTH operāciju skaitu utt.
• Ekspertīze. Iedomājieties, ka rīt jūsu atbildība būs milzīga kopa. Ja tas saplīst, to nevar salabot neviens cits, izņemot jūs. Ja viņš sāks palēnināties, visi skries tev pretī. Ja jums ir jāpievieno resursi vai jāpārdala slodze, atgriezieties pie jums. Lai 25 gadu vecumā nekļūtu pelēks, vēlams paredzēt šos gadījumus un iepriekš pārbaudīt, kā tehnoloģija izturēsies pie noteiktām darbībām. Par to sīkāk parunāsim sadaļā “Ekspertīze”.
• Uzraudzība un brīdinājumi. Kad klasteris sabojājas, vēlaties būt pirmais, kas par to uzzina. Šeit mēs aprobežojāmies ar paziņojumu, ka visi mezgli atgriež vienu un to pašu informāciju par klastera stāvokli (jā, tas notiek atšķirīgi). Un citas problēmas var ātrāk pamanīt pēc brīdinājumiem no Redis klientu apkalpošanas dienesta.

Pārvietošana

Kā mēs pārvietosimies:

• Pirmkārt, jums ir jāsagatavo bibliotēka darbam ar kopu. Mēs ņēmām go-redis par pamatu Go versijai un nedaudz mainījām to, lai tas atbilstu sev. Mēs ieviesām vairākas metodes, izmantojot cauruļvadus, kā arī nedaudz labojām pieprasījumu atkārtošanas noteikumus. PHP versijai bija vairāk problēmu, taču galu galā mēs izvēlējāmies php-redis. Viņi nesen ieviesa klasteru atbalstu, un, mūsuprāt, tas izskatās labi.
• Tālāk jums ir jāizvieto pats klasteris. Tas tiek darīts burtiski divās komandās, kuru pamatā ir konfigurācijas fails. Tālāk mēs apspriedīsim iestatījumu sīkāk.
• Pakāpeniskai pārvietošanai izmantojam sauso režīmu. Tā kā mums ir divas bibliotēkas versijas ar vienu un to pašu interfeisu (viena parastajai versijai, otra klasterim), nav jāmaksā nekas, lai izveidotu iesaiņojumu, kas darbosies ar atsevišķu versiju un paralēli dublēs visus pieprasījumus klasterim, salīdziniet atbildes un ierakstiet neatbilstības žurnālos (mūsu gadījumā NewRelic). Tādējādi, pat ja klastera versija izlaišanas laikā sabojājas, mūsu produkcija netiks ietekmēta.
• Pēc klastera izvēršanas sausajā režīmā mēs varam mierīgi aplūkot atbilžu neatbilstību grafiku. Ja kļūdu līmenis lēnām, bet noteikti virzās uz kādu mazu konstanti, tad viss ir kārtībā. Kāpēc joprojām pastāv neatbilstības? Tā kā ierakstīšana atsevišķā versijā notiek nedaudz agrāk nekā klasterī, un mikroaizkavējuma dēļ dati var atšķirties. Atliek tikai apskatīt nesakritības žurnālus, un, ja tie visi ir izskaidrojami ar ieraksta neatomitāti, tad varam doties tālāk.
• Tagad jūs varat pārslēgt sauso režīmu pretējā virzienā. Mēs rakstīsim un lasīsim no klastera un dublēsim to atsevišķā versijā. Par ko? Nākamās nedēļas laikā vēlos vērot klastera darbu. Ja pēkšņi izrādās, ka maksimālās slodzes laikā ir problēmas vai mēs kaut ko neņēmām vērā, mums vienmēr ir ārkārtas atgriešana uz veco kodu un pašreizējiem datiem, pateicoties sausajam režīmam.
• Atliek tikai atspējot sauso režīmu un demontēt atsevišķo versiju.

Ekspertīze

Pirmkārt, īsi par klastera dizainu.

Pirmkārt, Redis ir atslēgu vērtību veikals. Kā atslēgas tiek izmantotas patvaļīgas virknes. Kā vērtības var izmantot skaitļus, virknes un veselas struktūras. Pēdējo ir ļoti daudz, bet, lai izprastu vispārējo struktūru, tas mums nav svarīgi.
Nākamais abstrakcijas līmenis pēc taustiņiem ir sloti (SLOTS). Katra atslēga pieder vienai no 16 383 slotiem. Katrā slotā var būt neierobežots skaits atslēgu. Tādējādi visas atslēgas ir sadalītas 16 383 nesavienotos komplektos.

Tālāk klasterī ir jābūt N galvenajiem mezgliem. Katru mezglu var uzskatīt par atsevišķu Redis instanci, kas zina visu par citiem mezgliem klasterī. Katrs galvenais mezgls satur vairākus slotus. Katrs slots pieder tikai vienam galvenajam mezglam. Visi sloti ir jāsadala starp mezgliem. Ja daži sloti nav piešķirti, tad tajās saglabātās atslēgas nebūs pieejamas. Ir lietderīgi palaist katru galveno mezglu atsevišķā loģiskā vai fiziskā mašīnā. Ir arī vērts atcerēties, ka katrs mezgls darbojas tikai vienā kodolā, un, ja vēlaties palaist vairākus Redis gadījumus vienā un tajā pašā loģiskajā mašīnā, pārliecinieties, vai tie darbojas dažādos kodolos (mēs to neesam mēģinājuši, bet teorētiski tam vajadzētu darboties). . Būtībā galvenie mezgli nodrošina regulāru sadalīšanu, un vairāk galveno mezglu ļauj mērogot rakstīšanas un lasīšanas pieprasījumus.

Pēc tam, kad visas atslēgas ir sadalītas starp slotiem un sloti ir izkaisīti starp galvenajiem mezgliem, katram galvenajam mezglam var pievienot patvaļīgu skaitu pakārtotu mezglu. Katrā šādā galvenā-pakalpojuma saitē darbosies normāla replikācija. Slave ir nepieciešami, lai mērogotu lasīšanas pieprasījumus un veiktu kļūmjpārlēci galvenās kļūmes gadījumā.

Tagad parunāsim par operācijām, kuras būtu labāk, ja varētu veikt.

Mēs piekļūsim sistēmai, izmantojot Redis-CLI. Tā kā Redis nav viena ieejas punkta, varat veikt šādas darbības ar jebkuru no mezgliem. Katrā punktā atsevišķi vēršu uzmanību uz iespēju veikt operāciju zem slodzes.

• Pirmā un vissvarīgākā lieta, kas mums nepieciešama, ir klasteru mezglu darbība. Tas atgriež klastera stāvokli, parāda mezglu sarakstu, to lomas, slotu sadalījumu utt. Plašāku informāciju var iegūt, izmantojot klastera informāciju un klasteru slotus.
• Būtu jauki, ja varētu pievienot un noņemt mezglus. Šim nolūkam ir klasteru satikšanās un klasteru aizmirst darbības. Lūdzu, ņemiet vērā, ka klastera aizmiršana ir jāpiemēro KATRAM mezglam — gan galvenajām, gan replikām. Un klasteru sanāksme ir jāizsauc tikai vienā mezglā. Šī atšķirība var būt mulsinoša, tāpēc labāk par to uzzināt pirms kopas tiešraides. Mezgla pievienošana tiek veikta droši kaujā un nekādā veidā neietekmē klastera darbību (kas ir loģiski). Ja jūs gatavojaties noņemt mezglu no klastera, jums jāpārliecinās, ka tajā nav palicis neviens slots (pretējā gadījumā jūs riskējat zaudēt piekļuvi visām šī mezgla atslēgām). Tāpat neizdzēsiet saimnieku, kuram ir vergi, pretējā gadījumā tiks veikta nevajadzīga balsojums par jaunu saimnieku. Ja mezgliem vairs nav slotu, tā ir neliela problēma, taču kāpēc mums ir vajadzīgas papildu izvēles, ja vispirms varam izdzēst vergus.
• Ja jums ir nepieciešams piespiedu kārtā apmainīt galvenās un pakārtotās pozīcijas, tiks piemērota klastera kļūmjpārlēces komanda. Izsaucot to kaujā, jāsaprot, ka kapteinis operācijas laikā nebūs pieejams. Parasti pārslēgšanās notiek mazāk nekā sekundē, taču tā nav atomāra. Varat sagaidīt, ka šajā laikā daži kapteinim adresētie pieprasījumi neizdosies.
• Pirms mezgla noņemšanas no klastera uz tā nedrīkst būt atstātas vietas. Labāk tos pārdalīt, izmantojot komandu cluster reshard. Sloti tiks pārsūtīti no viena meistara uz otru. Visa darbība var ilgt vairākas minūtes, tas ir atkarīgs no pārsūtāmo datu apjoma, taču pārsūtīšanas process ir drošs un nekādā veidā neietekmē klastera darbību. Tādējādi visus datus var pārsūtīt no viena mezgla uz otru tieši zem slodzes un neuztraucoties par to pieejamību. Tomēr ir arī smalkumi. Pirmkārt, datu pārsūtīšana ir saistīta ar noteiktu saņēmēja un sūtītāja mezglu slodzi. Ja saņēmēja mezgls jau ir ļoti noslogots procesorā, jums nevajadzētu to ielādēt, saņemot jaunus datus. Otrkārt, tiklīdz nosūtīšanas galvenajā ierīcē nav palicis neviens slots, visi tā vergi nekavējoties pāries uz galveno, kuram šie sloti tika pārsūtīti. Un problēma ir tā, ka visi šie vergi vēlēsies sinhronizēt datus uzreiz. Un jums veiksies, ja tā būs daļēja, nevis pilnīga sinhronizācija. Ņemiet to vērā un apvienojiet slotu pārsūtīšanas un vergu atspējošanas/pārsūtīšanas darbības. Vai arī ceriet, ka jums ir pietiekama drošības rezerve.
• Kā rīkoties, ja pārsūtīšanas laikā atklājat, ka kaut kur esat pazaudējis savus laika nišus? Es ceru, ka šī problēma jūs neskar, taču, ja tā skar, tiek veikta klastera labošanas darbība. Vismaz viņa nejaušā secībā izkliedēs slotus pa mezgliem. Es iesaku pārbaudīt tā darbību, vispirms no klastera noņemot mezglu ar sadalītiem slotiem. Tā kā dati nepiešķirtajos laika nišos jau nav pieejami, ir par vēlu uztraukties par problēmām ar šo laika nišu pieejamību. Savukārt darbība neietekmēs sadalītos slotus.
• Vēl viena noderīga darbība ir monitors. Tas ļauj reāllaikā redzēt visu uz mezglu nosūtīto pieprasījumu sarakstu. Turklāt jūs varat to grep un uzzināt, vai ir nepieciešamā satiksme.

Ir arī vērts pieminēt galveno kļūmjpārlēces procedūru. Īsāk sakot, tas pastāv, un, manuprāt, tas darbojas lieliski. Tomēr nedomājiet, ka, atvienojot strāvas vadu mašīnai ar galveno mezglu, Redis nekavējoties pārslēgsies un klienti nepamanīs zaudējumus. Manā praksē pārslēgšanās notiek dažu sekunžu laikā. Šajā laikā daži dati nebūs pieejami: tiek konstatēta galvenā nepieejamība, mezgli balso par jaunu, vergi tiek pārslēgti, dati tiek sinhronizēti. Labākais veids, kā pašam pārliecināties, ka shēma darbojas, ir veikt vietējos vingrinājumus. Paceliet klēpjdatora kopu, piešķiriet tam minimālu slodzi, simulējiet avāriju (piemēram, bloķējiet portus) un novērtējiet pārslēgšanās ātrumu. Manuprāt, tikai šādi spēlējot dienu vai divas, var būt pārliecināts par tehnikas darbību. Nu, vai ceru, ka programmatūra, ko izmanto puse interneta, iespējams, darbojas.

Konfigurācija

Bieži vien konfigurācija ir pirmā lieta, kas jums nepieciešams, lai sāktu strādāt ar rīku. Un, kad viss darbojas, jūs pat nevēlaties pieskarties konfigurācijai. Ir jāpieliek pūles, lai piespiestu sevi atgriezties pie iestatījumiem un rūpīgi tos pārbaudīt. Manā atmiņā mums bija vismaz divas nopietnas kļūmes neuzmanības konfigurācijas dēļ. Pievērsiet īpašu uzmanību šādiem punktiem:

• taimauts 0
  Laiks, pēc kura tiek slēgti neaktīvie savienojumi (sekundēs). 0 - neaizveriet
  Ne katra mūsu bibliotēka varēja pareizi aizvērt savienojumus. Atspējojot šo iestatījumu, mēs riskējam sasniegt klientu skaita ierobežojumu. No otras puses, ja ir šāda problēma, tad automātiska zaudēto savienojumu pārtraukšana to maskēs, un mēs varam to nepamanīt. Turklāt jums nevajadzētu iespējot šo iestatījumu, ja izmantojat pastāvīgus savienojumus.
• Saglabāt xy un pievienot tikai jā
  RDB momentuzņēmuma saglabāšana.
  Tālāk mēs detalizēti apspriedīsim RDB/AOF jautājumus.
• stop-writes-on-bgsave-error nē un slave-serve-stale-data jā
  Ja tas ir iespējots, ja RDB momentuzņēmums sabojājas, kapteinis pārtrauks izmaiņu pieprasījumu pieņemšanu. Ja savienojums ar galveno ierīci tiek zaudēts, palīgs var turpināt atbildēt uz pieprasījumiem (jā). Vai arī pārtrauks reaģēt (nē)
  Mēs neesam apmierināti ar situāciju, kurā Redis pārvēršas par ķirbi.
• repl-ping-slave-period 5
  Pēc šī laika perioda mēs sāksim uztraukties, ka kapteinis ir sabojājies un ir pienācis laiks veikt kļūmjpārlēces procedūru.
  Jums būs manuāli jāatrod līdzsvars starp viltus pozitīviem rezultātiem un kļūmjpārlēces aktivizēšanu. Mūsu praksē tas ir 5 sekundes.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  Mēs varam saglabāt tieši tik daudz datu neveiksmīgas replikas buferī. Ja buferis beidzas, jums būs pilnībā jāsinhronizē.
  Prakse liecina, ka labāk ir iestatīt lielāku vērtību. Ir daudz iemeslu, kāpēc kopija var sākt aizkavēties. Ja tas atpaliek, visticamāk, jūsu meistars jau cīnās, lai tiktu galā, un pilnīga sinhronizācija būs pēdējais piliens.
• Maksimālie klienti 10000
  Maksimālais vienreizējo klientu skaits.
  Mūsu pieredze liecina, ka labāk ir iestatīt lielāku vērtību. Redis lieliski apstrādā 10 XNUMX savienojumus. Vienkārši pārliecinieties, vai sistēmā ir pietiekami daudz kontaktligzdu.
• maxmemory-policy volatile-ttl
  Noteikums, saskaņā ar kuru atslēgas tiek dzēstas, kad tiek sasniegts pieejamās atmiņas ierobežojums.
  Šeit svarīgs nav pats noteikums, bet gan izpratne par to, kā tas notiks. Redis var uzslavēt par spēju normāli strādāt, kad ir sasniegts atmiņas limits.

RDB un AOF problēmas

Lai gan pats Redis visu informāciju glabā RAM, ir arī mehānisms datu saglabāšanai diskā. Precīzāk, trīs mehānismi:

• RDB momentuzņēmums - pilnīgs visu datu momentuzņēmums. Iestatiet, izmantojot SAGLABĀT XY konfigurāciju, un ir rakstīts "Saglabājiet visu datu pilnu momentuzņēmumu ik pēc X sekundēm, ja ir mainījušies vismaz Y taustiņi".
• Tikai pievienojams fails — darbību saraksts to izpildes secībā. Pievieno jaunas ienākošās darbības failam ik pēc X sekundēm vai ik pēc Y darbības.
• RDB un AOF ir iepriekšējo divu kombinācija.

Visām metodēm ir savas priekšrocības un trūkumi, es tās visas neuzskaitīšu, es tikai pievērsīšu uzmanību punktiem, kas, manuprāt, nav acīmredzami.

Pirmkārt, lai saglabātu RDB momentuzņēmumu, ir jāizsauc FORK. Ja datu ir daudz, tas var apturēt visu Redis uz laiku no dažām milisekundēm līdz sekundei. Turklāt sistēmai ir jāpiešķir atmiņa šādam momentuzņēmumam, kā rezultātā loģiskajā mašīnā ir jāsaglabā dubultā RAM: ja Redis ir atvēlēti 8 GB, tad virtuālajā mašīnā jābūt pieejamiem 16 GB ar to.

Otrkārt, ir problēmas ar daļēju sinhronizāciju. AOF režīmā, kad vergs ir atkārtoti savienots, daļējas sinhronizācijas vietā var veikt pilnu sinhronizāciju. Kāpēc tas notiek, es nevarēju saprast. Bet ir vērts to atcerēties.

Šie divi punkti jau liek mums aizdomāties par to, vai tiešām mums vajag šos datus diskā, ja visu jau dublē vergi. Datus var zaudēt tikai tad, ja neizdodas visi vergi, un tā ir “ugunsgrēka līdzstrāvas” līmeņa problēma. Kā kompromisu jūs varat ierosināt saglabāt datus tikai par vergiem, taču šajā gadījumā jums ir jāpārliecinās, ka šie vergi nekad nekļūs par kapteiņiem avārijas atkopšanas laikā (šim nolūkam viņu konfigurācijā ir vergu prioritātes iestatījums). Mēs paši katrā konkrētajā gadījumā domājam par to, vai ir nepieciešams saglabāt datus diskā, un visbiežāk atbilde ir “nē”.

Secinājums

Nobeigumā es ceru, ka varēju sniegt vispārēju priekšstatu par to, kā redis-klasters darbojas tiem, kas par to vispār nav dzirdējuši, kā arī pievērsu uzmanību dažiem nepārprotamiem punktiem tiem, kas to izmanto. ilgu laiku.
Paldies par jūsu laiku un, kā vienmēr, komentāri par tēmu ir laipni gaidīti.

Avots: www.habr.com