Hatina ber hilberek ku ji deh salan zêdetir e ku pêş dikeve, ne ecêb e ku meriv tê de teknolojiyên kevnar bibîne. Lê heke di şeş mehan de pêdivî ye ku hûn barkirinê 10 qat zêdetir bihêlin, û lêçûna ketina wê bi sedan carî zêde bibe? Di vê rewşê de, hûn hewceyê Endezyarek Highload-ê xweş in. Lê ji ber ku xizmetkarek tunebû, çareserkirina pirsgirêkê spartin min. Di beşa yekem a gotarê de ez ê ji we re vebêjim ka em çawa ji Redis berbi Redis-cluster ve çûn, û di beşa duyemîn de ez ê şîretan bikim ka meriv çawa dest bi karanîna komê bike û dema ku meriv bikar tîne bala xwe bide çi.

Hilbijartina Teknolojiyê

Ma ew qas xirab e? Redis veqetînin (redisên serbixwe) di veavakirina 1 master û N xulam de? Çima ez jê re dibêjim teknolojiya kevinbûyî?

Na, Redis ne ew qas xerab e... Lêbelê hin kêmasî hene ku nayên paşguh kirin.

• Pêşîn, Redis piştî têkçûnek masterê mekanîzmayên başkirina karesatê piştgirî nake. Ji bo çareserkirina vê pirsgirêkê, me veavakirinek bi veguheztina otomatîkî ya VIP-an ji axayek nû re bikar anî, rola yek ji xulaman biguhezîne û yên mayî biguherîne. Ev mekanîzma xebitî, lê nikare jê re çareseriyek pêbawer were gotin. Ya yekem, alarmên derewîn çêbûn, û ya duyemîn jî, ew yekcar bû, û piştî operasyonê ji bo barkirina biharê ji bo barkirina biharê tevgerên destan hewce bûn.

• Ya duyemîn, hebûna tenê yek axayê bû sedema pirsgirêka şirînê. Diviya bû ku me çend komikên serbixwe "1 master û N xulam" biafirînin, dûv re bi destan databasan di nav van makîneyan de belav bikin û hêvî bikin ku sibê yek ji databasan ew qas mezin nebe ku pêdivî ye ku ew veguhezîne mînakek cûda.

Vebijarkên çi ne?

• Çareseriya herî biha û dewlemend Redis-Enterprise ye. Ev çareseriyek qutkirî bi piştgiriya teknîkî ya bêkêmasî ye. Digel ku ji hêla teknîkî ve îdeal xuya dike jî, ji ber sedemên îdeolojîk ne li gorî me ye.
• Redis-cluster. Ji derveyî qutiyê piştgirî ji bo têkçûn û parvekirina masterê heye. Navber hema hema ji guhertoya birêkûpêk cûda nabe. Ew sozdar xuya dike, em ê paşê li ser xeletiyan biaxivin.
• Tarantool, Memcache, Aerospike û yên din. Hemî van amûran hema hema heman tiştî dikin. Lê her yek kêmasiyên xwe hene. Me biryar da ku em hemû hêkên xwe nexin selikekê. Em Memcache û Tarantool ji bo karên din bikar tînin, û, li pêş çavan, ez ê bibêjim ku di pratîka me de bêtir pirsgirêk bi wan re hebûn.

Taybetmendiyên karanîna

Ka em binihêrin ka me çi pirsgirêk di dîrokê de bi Redis re çareser kirine û me çi fonksiyonel bikar aniye:

• Cache berî daxwazên karûbarên dûr ên mîna 2GIS | Golang
  

  GET SET MGET MSET "HILBIJARTIN DB"

• Cache berî MYSQL | PHP
  

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

• Depoya sereke ya ji bo karûbarê xebata bi danişîn û hevrêzên ajokerê | Golang
  

  BİXWÎNE BİXWÎNE MGET MSET "HILBIJARTIN DB" "ZÊDE BIKE GEO KEY" "GET GEO KEY" SCAN

Wekî ku hûn dibînin, matematîkên bilind tune. Wê demê zehmetî çi ye? Ka em li her rêbazê ji hev cuda binêrin.

Rêbaz
description
Taybetmendiyên Redis-cluster
biryar

GIRTIN
Mifteya nivîsandin / xwendin

MGET MSET
Bişkojkên pirjimar binivîsin / bixwînin
Bişkok dê li ser girêkên cûda bin. Pirtûkxaneyên amadekirî tenê di nav yek girêk de dikarin pir-operasyonan bikin
Li şûna MGET boriyeke ji operasyonên N GET

DB Hilbijêre
Bingeha ku em ê pê re bixebitin hilbijêrin
Gelek databases piştgirî nake
Her tiştî bixin nav yek databasê. Pêşgiran li mifteyan zêde bikin

SCAN
Hemî mifteyên di databasê de derbas bibin
Ji ber ku me yek databasek heye, derbaskirina hemî mifteyên di komê de pir biha ye
Di nav yek mifteyê de guhêrbarek bidomînin û li ser vê mifteyê HSCAN bikin. An jî bi tevahî red bikin

GEO
Operasyonên bi geokey
Erdnîgarî nayê şirandin

KEY BY PATTERN
Bi şêweyê mifteyê digere
Ji ber ku databasek me heye, em ê li hemî bişkokên komê bigerin. Pir biha
Wekî di doza SCAN de, guhêrbar red bikin an biparêzin

Redis vs Redis-cluster

Dema ku em diçin komekê em çi winda dikin û çi qezenc dikin?

• Kêmasî: em fonksiyona çend databasan winda dikin.
  • Ger em bixwazin daneyên mentiqî yên negirêdayî di yek komê de hilînin, em ê neçar bin ku di forma pêşgiran de kêşan çêkin.
  • Em hemî operasyonên "bingeh" winda dikin, wek SCAN, DBSIZE, CLEAR DB, hwd.
  • Pêkanîna pir-operasyon pir dijwartir bûye ji ber ku dibe ku pêdivî bi gihîştina çend nokan hebe.
• Pluses:
  • Tolerasyona xeletiyê di forma têkçûna masterê de.
  • Sharding li aliyê Redis.
  • Daneyên di navbera girêkan de bi atomî û bêyî demdirêj veguhezînin.
  • Kapasîteya û barkêşan bêyî demdirêj zêde bikin û ji nû ve belav bikin.

Ez ê encam bikim ku heke hûn ne hewce ne ku astek bilind a tolerasyona xeletiyê peyda bikin, wê hingê veguheztinek berbi komekê ne hêja ye, ji ber ku ew dikare karek ne-tayî be. Lê heke hûn di destpêkê de di navbera guhertoyek veqetandî û guhertoyek komê de hilbijêrin, wê hingê divê hûn komek hilbijêrin, ji ber ku ew ne xirabtir e û, ji bilî vê, dê we ji hin serêşan jî xilas bike.

Amadekirina tevgerê

Ka em bi hewcedariyên tevgerê dest pê bikin:

• Divê bêkêmasî be. Rawestandina tam a karûbarê 5 hûrdeman ne li gorî me ye.
• Divê ew bi qasî ku pêkan ewle û gav bi gav be. Ez dixwazim hinekî li ser rewşê kontrol bikim. Em naxwazin her tiştî bi yekcarî bavêjin û li ser bişkoja paşvegerê dua bikin.
• Wendabûna daneya hindiktirîn dema ku diçin. Em fam dikin ku ew ê pir dijwar be ku ew bi atomî bigerin, ji ber vê yekê em destûr didin hin desenkronîzekirinê di navbera daneyan de di Redisên birêkûpêk û komkirî de.

Parastina Cluster

Hema berî tevgerê, divê em bifikirin ka gelo em dikarin piştgirî bidin komê:

• Charts. Em Prometheus û Grafana bikar tînin da ku barkirina CPU, karanîna bîranînê, hejmara xerîdaran, hejmara operasyonên GET, SET, AUTH, hwd.
• Expertise. Bifikirin ku sibê hûn ê di bin berpirsiyariya we de komek mezin hebin. Ger ew bişkîne, ji bilî we kes nikare wê rast bike. Ger ew dest bi hêdîbûnê bike, dê her kes ber bi we ve birevin. Heke hûn hewce ne ku çavkaniyan zêde bikin an barkirinê ji nû ve belav bikin, vegerin we. Ji bo ku di 25 saliya xwe de gewr nebin, tê pêşniyar kirin ku hûn van rewşan peyda bikin û pêşî kontrol bikin ka teknolojî dê di binê hin çalakiyan de çawa tevbigere. Ka em li ser vê yekê di beşa "Pisporî" de bi hûrgulî biaxivin.
• Şopandin û alerts. Dema ku komek hilweşe, hûn dixwazin bibin yê yekem ku li ser wê zanibin. Li vir me xwe bi agahdariyek sînordar kir ku hemî girêk heman agahdariyê di derbarê rewşa komê de vedigerînin (erê, ew bi rengek cûda dibe). Û pirsgirêkên din ji hêla hişyariyên ji karûbarên xerîdar Redis ve zûtir têne dîtin.

Vejandin

Em ê çawa tevbigerin:

• Berî her tiştî, hûn hewce ne ku pirtûkxaneyek amade bikin ku bi komê re bixebitin. Me go-redis ji bo guhertoya Go-yê bingeh girt û ew piçek guhezand ku li gorî xwe be. Me Pir-rêbaz bi riya lûleyan bicîh kir, û di heman demê de qaîdeyên dubarekirina daxwazan jî hinekî rast kir. Guhertoya PHP-ê bêtir pirsgirêk hebûn, lê em di dawiyê de li ser php-redis rûniştin. Wan van demên dawî piştgirîya komê destnîşan kir û li gorî me baş xuya dike.
• Dûv re hûn hewce ne ku komê bixwe bicîh bikin. Ev bi rastî di du fermanan de li ser bingeha pelê veavakirinê pêk tê. Em ê li jêr bi berfirehî li ser mîhengê nîqaş bikin.
• Ji bo tevgera hêdî-hêdî em moda hişk bikar tînin. Ji ber ku me du guhertoyên pirtûkxaneyê bi heman navbeynê heye (yek ji bo guhertoya birêkûpêk, ya din ji bo komê), çêkirina pêçekek ku dê bi guhertoyek cihêreng bixebite û bi paralelî hemî daxwaznameyên komê dubare bike çu tişt nabe. bersivan bidin ber hev û di têketinan de nakokiyan binivîsin (di doza me de di NewRelic de). Ji ber vê yekê, her çend guhertoya komê di dema danasînê de têk biçe, hilberîna me dê bandor nebe.
• Piştî ku komê di moda hişk de derxist, em dikarin bi aramî li grafika nakokiyên bersivê binihêrin. Ger rêjeya xeletiyê hêdî lê bê guman berbi hin domdarek piçûk ve diçe, wê hingê her tişt baş e. Çima hê jî nakokî hene? Ji ber ku tomarkirin di guhertoyek veqetandî de hinekî zûtir ji komê pêk tê, û ji ber mîkrolagê, dibe ku dane ji hev cuda bibin. Tiştê ku dimîne ev e ku em li têketinên cudahiyê binihêrin, û ger ew hemî bi ne-atomiya tomarê ve werin rave kirin, wê hingê em dikarin pêş de biçin.
• Naha hûn dikarin di rêça berevajî de moda hişk biguherînin. Em ê ji komê binivîsin û bixwînin, û wê di guhertoyek cihê de dubare bikin. Bo çi? Di hefteya pêş de ez dixwazim xebata komê bişopînim. Ger ji nişkê ve derkeve holê ku di barkirina lûtkeyê de pirsgirêk hene, an jî me tiştek hesab nekiriye, bi saya moda zuwa her gav paşvegerek awarte li koda kevn û daneyên heyî heye.
• Tiştê ku dimîne ev e ku meriv moda hişk neçalak bike û guhertoya veqetandî hilweşîne.

Pisporbûn

Pêşîn, bi kurtî li ser sêwirana komê.

Berî her tiştî, Redis firotgehek nirxa sereke ye. Têlên keyfî wekî kilîtan têne bikar anîn. Hêjmar, rêzik, û tevahiya pêkhateyan dikarin wekî nirx werin bikar anîn. Gelek ji yên paşîn hene, lê ji bo têgihîştina avahiya giştî ev ji bo me ne girîng e.
Asta din a abstraction piştî bişkokan e slots (SLOTS). Her key ji yek ji 16 slots e. Dibe ku di hundurê her hêlînê de hejmarek bişkok hebin. Bi vî rengî, hemî bişkok li 383 komên veqetandî têne dabeş kirin.

Dûv re, divê di komê de N girêkên sereke hebin. Her girêk dikare wekî mînakek Redis-a veqetandî were hesibandin ku her tiştî di derheqê girêkên din ên di nav komê de dizane. Her node master dihewîne hejmarek ji slots. Her hêlînek tenê ji yek nodek masterê re ye. Pêdivî ye ku hemî slots di navbera girêkan de bêne belav kirin. Ger hin slots neyên veqetandin, wê hingê mifteyên ku di wan de hatine hilanîn dê negihîjin. Aqil e ku meriv her girêkek master li ser makîneyek mentiqî an fîzîkî ya cihêreng bixebite. Di heman demê de hêjayî bîranînê ye ku her girêk tenê li ser yek bingehîn dimeşîne, û heke hûn dixwazin li ser heman makîneya mantiqî gelek mînakên Redis bimeşînin, pê ewle bin ku ew li ser bingehên cihêreng dixebitin (me ev ceriband, lê di teoriyê de divê ew bixebite) . Di bingeh de, girêkên master parvekirina birêkûpêk peyda dikin, û bêtir girêkên master rê didin daxwazên nivîsandin û xwendinê ku pîvandinê bikin.

Piştî ku hemî bişkok di nav hêlînê de têne belav kirin, û hêlîn di nav girêkên serdest de belav dibin, dikare hejmareke keyfî ya girêkên xulam li her girêkek masterê were zêdekirin. Di nav her girêdanek weha master-xulam de, dubarekirina normal dê bixebite. Ji bo pîvandina daxwazên xwendinê û ji bo têkçûna di bûyera têkçûna master de kole hewce ne.

Niha em li ser operasyonên ku çêtir e ku meriv bikaribe biaxivin.

Em ê bi rêya Redis-CLI bigihîjin pergalê. Ji ber ku Redis ne xalek têketinê ya yekane ye, hûn dikarin li ser her yek ji girêkan operasyonên jêrîn pêk bînin. Di her xalê de ez ji hev cuda balê dikişînim ser îhtîmala pêkanîna operasyonê di bin bar de.

• Tişta yekem û ya herî girîng ku em hewce ne operasyona girêkên komê ye. Ew rewşa komê vedigerîne, navnîşek girêkan, rolên wan, belavkirina hêlînê, hwd nîşan dide. Zêdetir agahdarî bi karanîna agahdariya komê û hêlînên komê têne wergirtin.
• Dê xweş be ku meriv bikaribe girêkan lê zêde bike û jê rake. Ji bo vê armancê operasyonên kombûn û jibîrkirina komê hene. Ji kerema xwe bala xwe bidin ku jibîrkirina komê divê li HER girêk, hem serdest û hem jî kopiyek were sepandin. Û kombûna komê tenê pêdivî ye ku li ser yek girêkekê were gazî kirin. Ev cûdahî dikare xemgîn be, ji ber vê yekê çêtirîn e ku hûn li ser wê fêr bibin berî ku hûn bi koma xwe re bijîn. Zêdekirina nodek di şer de bi ewlehî tête kirin û bi ti awayî bandorê li operasyona komê nake (ku mentiqî ye). Ger hûn ê girêkek ji komê derxînin, divê hûn pê ewle bin ku li ser wê hêlînek nemaye (ku nebe hûn xetera windakirina gihîştina hemî bişkokên li ser vê girêkê dikin). Di heman demê de, axayek ku xulamên wî hene jêbirin, wekî din dê ji bo axayek nû dengek nehewce were kirin. Ger girêk êdî ne xwedî hêlîn in, wê hingê ev pirsgirêkek piçûk e, lê çima em hewceyê vebijarkên zêde ne heke em dikarin pêşî xulaman jêbikin.
• Heke hûn hewce ne ku bi zorê pozîsyonên master û xulam biguhezînin, wê hingê fermana têkçûna komê dê bike. Dema ku hûn di şer de gazî dikin, hûn hewce ne ku fêm bikin ku master dê di dema operasyonê de peyda nebe. Bi gelemperî guheztin di kêmtirî saniyeyekê de çêdibe, lê ne atomî ye. Hûn dikarin hêvî bikin ku hin daxwazên ji masterê re dê di vê demê de têk biçin.
• Berî ku girêkek ji komê were rakirin, divê li ser wê hêlînek nemîne. Çêtir e ku meriv wan bi karanîna fermana reshard komê ji nû ve belav bike. Slots dê ji yek master bo yekî din bêne veguheztin. Tevahiya operasyonê dibe ku çend hûrdem bidome, ew bi qebareya daneyên ku têne veguheztin ve girêdayî ye, lê pêvajoya veguheztinê ewle ye û bi tu awayî bandorê li xebata komê nake. Bi vî rengî, hemî dane dikarin rasterast di bin barkirinê de ji yek girêkek din ve werin veguheztin, û bêyî ku ji hebûna wê xeman bikin. Lêbelê, hûrgelî jî hene. Ya yekem, veguheztina daneyê bi barek diyarkirî li ser girêkên wergir û şander ve girêdayî ye. Ger girêka wergir jixwe bi giranî li ser pêvajoyê barkirî ye, wê hingê divê hûn wê bi wergirtina daneyên nû bar nekin. Ya duyemîn, gava ku yek hêlînek li ser axayê şandinê nemîne, dê hemî xulamên wê tavilê biçin cem axayê ku ev hêlîn jê re hatine veguheztin. Û pirsgirêk ev e ku hemî van xulam dê bixwazin ku daneyan yekcar hevdeng bikin. Û hûn ê bi şens bin ger ew qismî be ji hevdengkirina tam. Vê yekê bihesibînin û operasyonên veguheztina slots û neçalakkirin/veguheztina koleyan bi hev re bikin. An jî hêvî dikin ku hûn marjîneyek têr a ewlehiyê heye.
• Ger, di dema veguheztinê de, hûn bibînin ku we li cîhek wenda kiriye hûn çi bikin? Ez hêvî dikim ku ev pirsgirêk bandorê li we neke, lê heke wusa be, operasyonek rastkirina komê heye. Bi kêmanî, ew ê hêlînên li ser girêkan bi rêzek rasthatî belav bike. Ez pêşniyar dikim ku operasyona wê kontrol bikin û pêşî girêka bi hêlînên belavbûyî ji komê derxînin. Ji ber ku daneyên di hêlînên nehatine veqetandin de jixwe ne berdest in, pir dereng e ku meriv li ser pirsgirêkên hebûna van hêlînên xwe fikar bike. Di encamê de, operasyon dê bandorê li slots belavkirî neke.
• Operasyona din a kêrhatî çavdêrî ye. Ew dihêle hûn di demek rast de tevahiya navnîşa daxwazên ku diçin nodê bibînin. Digel vê yekê, hûn dikarin wê bigirin û fêr bibin ka seyrûsefera pêwîst heye.

Di heman demê de hêjayî gotinê ye ku prosedûra têkçûna masterê. Bi kurtasî, ew heye, û, bi dîtina min, ew pir baş dixebite. Lêbelê, nefikirin ku heke hûn pêla elektrîkê li ser makîneyek bi nodek master veqetînin, Redis dê tavilê biguhere û xerîdar dê windahiyê nebînin. Di pratîka min de, veguhertin di çend hûrdeman de pêk tê. Di vê demê de, hin dane dê neberdest bin: neberdestbûna axayê tê tespît kirin, girêk ji bo yekî nû deng didin, xulam têne guheztin, dane hevdem têne kirin. Awayê çêtirîn ku hûn bi xwe pê ewle bibin ku plan dixebite ev e ku meriv temrînên herêmî pêk bîne. Komê li ser laptopa xwe bilind bikin, barek hindiktirîn bidin wê, qezayek simule bikin (mînak, bi astengkirina portan), û leza guheztinê binirxînin. Bi dîtina min, tenê piştî ku hûn rojek an du rojan bi vî rengî lîstin hûn dikarin di xebata teknolojiyê de pê ewle bin. Welê, an hêvî dikin ku nermalava ku nîvê Înternetê bikar tîne dibe ku kar bike.

Guhertin

Pir caran, veavakirin yekem tişt e ku hûn hewce ne ku hûn bi amûrê re dest bi xebatê bikin. Û gava ku her tişt kar dike, hûn jî naxwazin dest bi vesazkirinê bikin. Hin hewldan hewce dike ku hûn neçar bikin ku vegerin mîhengan û bi baldarî wan derbas bikin. Di bîranîna min de, ji ber neguhdariya li ser veavakirinê bi kêmî ve du têkçûnên me yên cidî hebûn. Bi taybetî bala xwe bidin xalên jêrîn:

• demjimêr 0
  Dem piştî ku pêwendiyên neçalak têne girtin (di çirkeyan de). 0 - negirin
  Her pirtûkxaneya me nikarîbû têkiliyan rast bigire. Bi neçalakkirina vê mîhengê, em xeternak in ku sînorê hejmara xerîdaran bixin. Ji hêla din ve, heke pirsgirêkek wusa hebe, wê hingê bidawîbûna otomatîkî ya girêdanên winda wê mask bike, û dibe ku em ferq nekin. Wekî din, divê hûn vê mîhengê dema ku girêdanên domdar bikar tînin çalak nekin.
• Xy xilas bike & tenê erê
  Sazkirina wêneyek RDB.
  Em ê li jêr li ser mijarên RDB/AOF bi berfirehî nîqaş bikin.
• stop-writes-on-bgsave-error no & slave-serve-stale-data erê
  Ger çalak be, heke wêneya RDB bişkîne, dê master qebûl daxwazên guhartinê rawestîne. Ger pêwendiya bi axayê re winda bibe, xulam dikare bersiva daxwazan berdewam bike (erê). An jî dê dev ji bersivdayînê berde (na)
  Em ji rewşa ku Redis vediguhere kulmek ne kêfxweş in.
• repl-ping-slave-period 5
  Piştî vê heyamê, em ê dest bi fikar bikin ku master têk çûye û dem e ku meriv prosedûra têkçûnê bimeşîne.
  Pêdivî ye ku hûn bi destan hevsengiyek di navbera erênîyên derewîn û destpêkirina têkçûnek de bibînin. Di pratîka me de ev 5 saniye ye.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  Em dikarin tam evqas daneyê di tamponek ji bo kopiyek têkçûyî de hilînin. Ger tampon xilas bibe, hûn neçar in ku bi tevahî hevdeng bikin.
  Pratîk pêşniyar dike ku çêtir e ku meriv nirxek bilindtir saz bike. Gelek sedem hene ku dibe ku kopiyek dest bi dereng bike. Ger ew dereng bimîne, wê hingê bi îhtîmalek mezin serdestê we jixwe têdikoşe ku li ber xwe bide, û hevdengkirina bêkêmasî dê keviya paşîn be.
• herî zêde xerîdar 10000
  Hejmara herî zêde ya xerîdarên yek carî.
  Di ezmûna me de, çêtir e ku meriv nirxek bilindtir destnîşan bike. Redis 10k pêwendiyan baş çêdike. Tenê piştrast bikin ku li ser pergalê têra xwe soket hene.
• maxmemory-policy volatile-ttl
  Rêzika ku gava ku sînorê bîra berdest bigihîje bişkojan têne jêbirin.
  Ya ku li vir girîng e ne qaîdeyek bi xwe ye, lê têgihîştina ka dê çawa bibe. Redis dikare ji bo şiyana wê ya ku di normalê de xebitî gava ku sînorê bîranînê gihîştiye pesnê xwe bide.

Pirsgirêkên RDB û AOF

Her çend Redis bixwe hemî agahdariya di RAM-ê de hilîne, di heman demê de mekanîzmayek ji bo hilanîna daneyan li ser dîskê jî heye. Bi rastî, sê mekanîzmayên:

• RDB-snapshot - wêneyek bêkêmasî ya hemî daneyan. Bi karanîna veavakirina SAVE XY saz bike û dixwîne "Heke bi kêmanî bişkokên Y hatine guhertin her X çirkeyan wêneyek tevahî ya daneyan hilînin."
• Pelê tenê-pêvek - navnîşek operasyonan bi rêza ku têne kirin. Her X çirkeyan an her operasyonên Y-yê operasyonên hatina nû li pelê zêde dike.
• RDB û AOF tevliheviya her du berê ne.

Hemû rêbaz xwedî awantaj û dezawantajên xwe ne, ez ê wan hemûyan navnîş nekim, ez ê tenê balê bikişînim ser xalên ku, bi dîtina min, ne diyar in.

Pêşîn, tomarkirina wêneyek RDB hewce dike ku FORK bang bikin. Ger gelek dane hebin, ev dikare hemî Redis ji bo heyamek çend milî çirkeyan heya saniyeyekê daleqîne. Digel vê yekê, pêdivî ye ku pergal ji bo dîmenek wusa bîranîn veqetîne, ku ev yek dibe sedema hewcedariya girtina du caran RAM li ser makîneya mentiqî: heke 8 GB ji Redis re were veqetandin, wê hingê divê 16 GB li ser makîneya virtual bi ew.

Ya duyemîn jî, pirsgirêkên hevdemkirinê yên qismî hene. Di moda AOF de, dema ku xulam ji nû ve tê girêdan, li şûna hevdemkirina qismî, hevdengkirina tevahî dikare were kirin. Çima ev diqewime, min nikarî fêm bikim. Lê hêjayî bîranîna vê yekê ye.

Van her du xal berê me dihêle ku em bifikirin ka gelo em bi rastî hewceyê van daneyan li ser dîskê ne heke her tişt jixwe ji hêla koleyan ve hatî dubare kirin. Daneyên tenê dikarin winda bibin heke hemî xulam têk bibin, û ev pirsgirêkek asta "agir di DC" de ye. Wekî lihevkirinek, hûn dikarin pêşniyar bikin ku hûn daneyan tenê li ser koleyan hilînin, lê di vê rewşê de hûn hewce ne ku pê ewle bin ku ew ê di dema vegerandina karesatê de çu carî nebin serwer (ji bo vê yekê di mîhengê wan de mîhengek pêşîn a xulamê heye). Ji bo xwe, di her rewşek taybetî de em difikirin ka gelo pêdivî ye ku daneyan li ser dîskê hilînin, û pir caran bersiv "na" ye.

encamê

Di encamê de, ez hêvî dikim ku min karîbû ramanek giştî bidim ka redis-cluster ji bo kesên ku qet jê nebihîstine çawa dixebite, û her weha bal kişand ser hin xalên ne diyar ên ji bo kesên ku wê bikar tînin. ji bo demeke dirêj.
Spas ji bo dema we û, wekî her gav, şîroveyên li ser mijarê bi xêr hatin.

Source: www.habr.com