Kuja kwa bidhaa ambayo imekuwa ikitengenezwa kwa zaidi ya muongo mmoja, haishangazi kabisa kupata teknolojia za kizamani ndani yake. Lakini ni nini ikiwa katika miezi sita unapaswa kuweka mzigo mara 10 zaidi, na gharama ya kuanguka itaongeza mamia ya nyakati? Katika kesi hii, unahitaji Mhandisi mzuri wa Upakiaji. Lakini kwa kukosa mjakazi, walinikabidhi kutatua tatizo hilo. Katika sehemu ya kwanza ya kifungu nitakuambia jinsi tulivyohamia kutoka Redis hadi Redis-cluster, na katika sehemu ya pili nitatoa ushauri juu ya jinsi ya kuanza kutumia nguzo na nini cha kuzingatia wakati wa kutumia.

Uchaguzi wa teknolojia

Je, ni mbaya hivyo? tofauti Redis (standalone redis) katika usanidi wa 1 bwana na N watumwa? Kwa nini ninaiita teknolojia ya kizamani?

Hapana, Redis sio mbaya sana ... Hata hivyo, kuna baadhi ya mapungufu ambayo hayawezi kupuuzwa.

• Kwanza, Redis haiungi mkono njia za uokoaji wa maafa baada ya kushindwa kwa bwana. Ili kutatua tatizo hili, tulitumia usanidi na uhamisho wa moja kwa moja wa VIP kwa bwana mpya, kubadilisha jukumu la mmoja wa watumwa na kubadili wengine. Utaratibu huu ulifanya kazi, lakini hauwezi kuitwa suluhisho la kuaminika. Kwanza, kengele za uwongo zilitokea, na pili, ilikuwa inayoweza kutolewa, na baada ya vitendo vya mwongozo wa operesheni vilihitajika kutoza chemchemi.

• Pili, kuwa na bwana mmoja tu kulisababisha shida ya kugawanyika. Ilitubidi kuunda vikundi kadhaa vya kujitegemea "1 bwana na N watumwa," kisha kusambaza hifadhidata kati ya mashine hizi na kutumaini kwamba kesho moja ya hifadhidata haitavimba sana hivi kwamba italazimika kuhamishwa kwa mfano tofauti.

Je, ni chaguzi gani?

• Suluhisho la gharama kubwa na tajiri zaidi ni Redis-Enterprise. Hili ni suluhisho la sanduku na usaidizi kamili wa kiufundi. Licha ya ukweli kwamba inaonekana kuwa bora kutoka kwa mtazamo wa kiufundi, haukufaa sisi kwa sababu za kiitikadi.
• Redis-nguzo. Nje ya sanduku kuna usaidizi wa kushindwa kwa bwana na sharding. Interface ni karibu hakuna tofauti na toleo la kawaida. Inaonekana kuahidi, tutazungumza juu ya mitego baadaye.
• Tarantool, Memcache, Aerospike na wengine. Zana hizi zote hufanya kitu sawa. Lakini kila mmoja ana mapungufu yake. Tuliamua kutoweka mayai yetu yote kwenye kikapu kimoja. Tunatumia Memcache na Tarantool kwa kazi nyingine, na, kuangalia mbele, nitasema kwamba katika mazoezi yetu kulikuwa na matatizo zaidi nao.

Maalum ya matumizi

Wacha tuangalie ni shida gani tumesuluhisha kihistoria na Redis na ni utendaji gani tuliotumia:

• Akiba kabla ya maombi ya huduma za mbali kama 2GIS | Golang
  

  PATA WEKA MGET MSET "CHAGUA DB"

• Akiba kabla ya MYSQL | PHP
  

  PATA WEKA MGET MSET SCAN "KEY BY PATTERN" "CHAGUA DB"

• Hifadhi kuu ya huduma ya kufanya kazi na vikao na kuratibu za dereva | Golang
  

  PATA WEKA MGET MSET "CHAGUA DB" "ONGEZA GEO KEY" "GET GEO KEY" SCAN

Kama unaweza kuona, hakuna hisabati ya juu. Ugumu ni nini basi? Wacha tuangalie kila njia tofauti.

Mbinu
Description
Vipengele vya kikundi cha Redis
uamuzi

PATA SET
Ufunguo wa kuandika / kusoma

MGET MSET
Andika/soma funguo nyingi
Vifunguo vitakuwa kwenye nodi tofauti. Maktaba zilizotengenezwa tayari zinaweza kufanya shughuli nyingi tu ndani ya nodi moja
Badilisha MGET na bomba la uendeshaji wa N GET

CHAGUA DB
Chagua msingi ambao tutafanya kazi nao
Haitumii hifadhidata nyingi
Weka kila kitu kwenye hifadhidata moja. Ongeza viambishi awali kwenye vitufe

SCAN
Pitia funguo zote kwenye hifadhidata
Kwa kuwa tuna hifadhidata moja, kupitia funguo zote kwenye nguzo ni ghali sana
Dumisha tofauti ndani ya ufunguo mmoja na ufanye HSCAN kwenye ufunguo huu. Au kukataa kabisa

GEO
Uendeshaji na geokey
Geokey haijagawanywa

MUHIMU KWA MFANO
Inatafuta ufunguo kulingana na muundo
Kwa kuwa tuna hifadhidata moja, tutatafuta funguo zote kwenye nguzo. Ghali mno
Kataa au udumishe tofauti, kama ilivyo kwa SCAN

Redis dhidi ya kikundi cha Redis

Tunapoteza nini na tunapata nini tunapobadili nguzo?

• Hasara: tunapoteza utendaji wa hifadhidata kadhaa.
  • Ikiwa tunataka kuhifadhi data isiyohusiana kimantiki katika kundi moja, itatubidi tutengeneze magongo kwa njia ya viambishi awali.
  • Tunapoteza shughuli zote za "msingi", kama vile SCAN, DBSIZE, CLEAR DB, nk.
  • Shughuli nyingi zimekuwa ngumu zaidi kutekeleza kwa sababu inaweza kuhitaji ufikiaji wa nodi kadhaa.
• Mabwawa:
  • Uvumilivu wa makosa kwa namna ya kushindwa kwa bwana.
  • Kugawanyika kwa upande wa Redis.
  • Kuhamisha data kati ya nodi atomi na bila downtime.
  • Ongeza na ugawanye tena uwezo na mizigo bila muda wa kupungua.

Ningehitimisha kwamba ikiwa huna haja ya kutoa kiwango cha juu cha uvumilivu wa makosa, basi kuhamia kwenye kikundi sio thamani, kwa sababu inaweza kuwa kazi isiyo ya kawaida. Lakini ikiwa hapo awali unachagua kati ya toleo tofauti na toleo la nguzo, basi unapaswa kuchagua nguzo, kwa kuwa sio mbaya zaidi na, kwa kuongeza, itakuondoa baadhi ya maumivu ya kichwa.

Kujiandaa kuhama

Wacha tuanze na mahitaji ya kusonga:

• Inapaswa kuwa imefumwa. Kusimamishwa kamili kwa huduma kwa dakika 5 haifai sisi.
• Inapaswa kuwa salama na polepole iwezekanavyo. Ninataka kuwa na udhibiti fulani juu ya hali hiyo. Hatutaki kutupa kila kitu mara moja na kuomba juu ya kitufe cha kurejesha.
• Upotezaji mdogo wa data wakati wa kusonga. Tunaelewa kuwa itakuwa vigumu sana kusogeza kiatomi, kwa hivyo tunaruhusu upatanisho fulani kati ya data katika Redis za kawaida na zilizounganishwa.

Matengenezo ya nguzo

Kabla tu ya kuhama, tunapaswa kufikiria ikiwa tunaweza kusaidia nguzo:

• Chati. Tunatumia Prometheus na Grafana kuchora upakiaji wa CPU, matumizi ya kumbukumbu, idadi ya wateja, idadi ya shughuli za GET, SET, AUTH, n.k.
• Utaalamu. Fikiria kuwa kesho utakuwa na nguzo kubwa chini ya jukumu lako. Ikiwa itavunjika, hakuna mtu lakini unaweza kuirekebisha. Ikiwa ataanza kupungua, kila mtu atakukimbilia. Iwapo unahitaji kuongeza rasilimali au kusambaza upya mzigo, rudi kwako. Ili sio kugeuka kijivu saa 25, ni vyema kutoa kwa kesi hizi na kuangalia mapema jinsi teknolojia itafanya chini ya vitendo fulani. Wacha tuzungumze juu ya hili kwa undani zaidi katika sehemu ya "Utaalam".
• Ufuatiliaji na arifa. Wakati nguzo inavunjika, unataka kuwa wa kwanza kujua kuihusu. Hapa tulijiwekea kikomo kwa arifa kwamba nodi zote zinarudisha habari sawa kuhusu hali ya nguzo (ndio, hufanyika tofauti). Na matatizo mengine yanaweza kutambuliwa kwa haraka zaidi na arifa kutoka kwa huduma za mteja wa Redis.

Kuhama

Jinsi tutakavyosonga:

• Kwanza kabisa, unahitaji kuandaa maktaba ya kufanya kazi na nguzo. Tulichukua go-redis kama msingi wa toleo la Go na kulibadilisha kidogo ili litufae. Tulitekeleza Mbinu nyingi kupitia mabomba, na pia tukasahihisha kidogo sheria za kurudia maombi. Toleo la PHP lilikuwa na shida zaidi, lakini hatimaye tulitulia kwenye php-redis. Hivi majuzi walianzisha usaidizi wa nguzo na inaonekana nzuri kwa maoni yetu.
• Ifuatayo unahitaji kupeleka nguzo yenyewe. Hii inafanywa halisi katika amri mbili kulingana na faili ya usanidi. Tutajadili mpangilio kwa undani zaidi hapa chini.
• Kwa kusonga polepole tunatumia hali ya kavu. Kwa kuwa tuna matoleo mawili ya maktaba yenye kiolesura sawa (moja kwa toleo la kawaida, lingine kwa nguzo), haigharimu chochote kuunda kifurushi ambacho kitafanya kazi na toleo tofauti na kwa sambamba kuiga maombi yote kwa nguzo, linganisha majibu na uandike tofauti kwenye kumbukumbu ( kwa upande wetu katika NewRelic). Kwa hivyo, hata toleo la nguzo likivunjika wakati wa uchapishaji, utayarishaji wetu hautaathiriwa.
• Baada ya kusambaza nguzo katika hali kavu, tunaweza kutazama kwa utulivu grafu ya tofauti za majibu. Ikiwa kiwango cha makosa polepole lakini hakika kinasonga kuelekea kiwango kidogo cha kila wakati, basi kila kitu kiko sawa. Kwa nini bado kuna tofauti? Kwa sababu kurekodi katika toleo tofauti hutokea mapema kidogo kuliko kwenye nguzo, na kutokana na microlag, data inaweza kutofautiana. Yote iliyobaki ni kuangalia magogo ya kutofautiana, na ikiwa yote yanaelezwa na kutokuwa na atomicity ya rekodi, basi tunaweza kuendelea.
• Sasa unaweza kubadilisha hali-kavu katika mwelekeo tofauti. Tutaandika na kusoma kutoka kwa nguzo, na kuiga nakala katika toleo tofauti. Kwa ajili ya nini? Wiki ijayo ningependa kutazama kazi ya nguzo. Ikiwa ghafla inageuka kuwa kuna matatizo katika mzigo wa kilele, au hatukuzingatia kitu, sisi daima tuna urejesho wa dharura kwa msimbo wa zamani na shukrani ya data ya sasa kwa hali ya kavu.
• Kinachobaki ni kuzima hali-kavu na kufuta toleo tofauti.

Utaalamu

Kwanza, kwa ufupi juu ya muundo wa nguzo.

Kwanza kabisa, Redis ni duka la thamani kuu. Kamba za kiholela hutumiwa kama funguo. Nambari, kamba, na miundo yote inaweza kutumika kama maadili. Kuna mengi ya mwisho, lakini kwa kuelewa muundo wa jumla hii sio muhimu kwetu.
Kiwango kinachofuata cha uondoaji baada ya funguo ni nafasi (SLOTS). Kila ufunguo ni wa moja ya nafasi 16. Kunaweza kuwa na idadi yoyote ya funguo ndani ya kila slot. Kwa hivyo, funguo zote zimegawanywa katika seti 383 zisizounganishwa.

Ifuatayo, lazima kuwe na nodi kuu za N kwenye nguzo. Kila nodi inaweza kuzingatiwa kama mfano tofauti wa Redis ambao unajua kila kitu kuhusu nodi zingine ndani ya nguzo. Kila nodi kuu ina idadi ya inafaa. Kila yanayopangwa ni ya nodi moja tu kuu. Nafasi zote zinahitajika kusambazwa kati ya nodi. Ikiwa nafasi zingine hazijatengwa, basi funguo zilizohifadhiwa ndani yao hazitapatikana. Inafahamika kuendesha kila nodi kuu kwenye mashine tofauti ya kimantiki au ya kimwili. Inafaa pia kukumbuka kuwa kila nodi inaendesha msingi mmoja tu, na ikiwa unataka kuendesha visa vingi vya Redis kwenye mashine moja ya kimantiki, hakikisha zinaendesha kwa msingi tofauti (hatujajaribu hii, lakini kwa nadharia inapaswa kufanya kazi) . Kimsingi, nodi kuu hutoa sharding mara kwa mara, na nodi bwana zaidi huruhusu kuandika na kusoma maombi ili kuongeza kiwango.

Baada ya funguo zote kusambazwa kati ya inafaa, na inafaa hutawanyika kati ya nodi za bwana, idadi ya kiholela ya nodi za watumwa inaweza kuongezwa kwa kila nodi kuu. Ndani ya kila kiungo cha bwana-mtumwa, uigaji wa kawaida utafanya kazi. Watumwa wanahitajika ili kuongeza maombi ya kusoma na kwa kushindwa katika kesi ya kushindwa kwa bwana.

Sasa hebu tuzungumze kuhusu shughuli ambazo itakuwa bora kuwa na uwezo wa kufanya.

Tutafikia mfumo kupitia Redis-CLI. Kwa kuwa Redis haina sehemu moja ya kuingia, unaweza kufanya shughuli zifuatazo kwenye nodi yoyote. Katika kila hatua mimi huzingatia kando uwezekano wa kufanya operesheni chini ya mzigo.

• Jambo la kwanza na muhimu zaidi tunalohitaji ni operesheni ya nodi za nguzo. Inarudisha hali ya nguzo, inaonyesha orodha ya nodi, majukumu yao, usambazaji wa yanayopangwa, nk. Maelezo zaidi yanaweza kupatikana kwa kutumia maelezo ya nguzo na nafasi za nguzo.
• Itakuwa nzuri kuweza kuongeza na kuondoa nodi. Kwa kusudi hili kuna shughuli za mkutano wa nguzo na usahau wa nguzo. Tafadhali kumbuka kuwa kusahau kwa nguzo lazima kutumike kwa KILA nodi, zote kuu na nakala. Na mkutano wa nguzo unahitaji tu kuitwa kwenye nodi moja. Tofauti hii inaweza kuwa ya kutatanisha, kwa hivyo ni bora kujifunza kuihusu kabla ya kwenda moja kwa moja na kikundi chako. Kuongeza nodi hufanyika kwa usalama katika vita na haiathiri uendeshaji wa nguzo kwa njia yoyote (ambayo ni mantiki). Ikiwa utaondoa nodi kutoka kwa nguzo, unapaswa kuhakikisha kuwa hakuna nafasi zilizobaki juu yake (vinginevyo una hatari ya kupoteza ufikiaji wa funguo zote kwenye nodi hii). Pia, usifute bwana ambaye ana watumwa, vinginevyo kura isiyo ya lazima kwa bwana mpya itafanywa. Ikiwa nodi hazina nafasi tena, basi hii ni shida ndogo, lakini kwa nini tunahitaji chaguzi za ziada ikiwa tunaweza kufuta watumwa kwanza.
• Ikiwa unahitaji kubadilisha kwa nguvu nafasi za bwana na mtumwa, basi amri ya kushindwa kwa nguzo itafanya. Wakati wa kuiita katika vita, unahitaji kuelewa kwamba bwana hatapatikana wakati wa operesheni. Kwa kawaida kubadili hutokea chini ya sekunde, lakini sio atomiki. Unaweza kutarajia kwamba baadhi ya maombi kwa bwana yatashindwa wakati huu.
• Kabla ya kuondoa nodi kutoka kwa nguzo, haipaswi kuwa na nafasi zilizoachwa juu yake. Ni bora kuzisambaza tena kwa kutumia amri ya cluster reshard. Slots zitahamishwa kutoka kwa bwana mmoja hadi mwingine. Operesheni nzima inaweza kuchukua dakika kadhaa, inategemea kiasi cha data inayohamishwa, lakini mchakato wa uhamisho ni salama na hauathiri uendeshaji wa nguzo kwa njia yoyote. Kwa hivyo, data zote zinaweza kuhamishwa kutoka kwa nodi moja hadi nyingine moja kwa moja chini ya mzigo, na bila kuwa na wasiwasi juu ya upatikanaji wake. Walakini, pia kuna hila. Kwanza, uhamishaji wa data unahusishwa na mzigo fulani kwenye nodi za mpokeaji na mtumaji. Ikiwa nodi ya mpokeaji tayari imejaa sana kwenye processor, basi usipaswi kuipakia kwa kupokea data mpya. Pili, mara tu hakuna nafasi moja iliyobaki kwa bwana anayetuma, watumwa wake wote wataenda mara moja kwa bwana ambaye nafasi hizi zilihamishiwa. Na shida ni kwamba watumwa hawa wote watataka kusawazisha data mara moja. Na utakuwa na bahati ikiwa ni sehemu badala ya usawazishaji kamili. Zingatia hili na uchanganye shughuli za kuhamisha nafasi na kulemaza/kuhamisha watumwa. Au tumaini kwamba una kiasi cha kutosha cha usalama.
• Unapaswa kufanya nini ikiwa, wakati wa uhamisho, utapata kwamba umepoteza nafasi zako mahali fulani? Natumai shida hii haikuathiri, lakini ikiwa itatokea, kuna operesheni ya kurekebisha nguzo. Angalau, atatawanya nafasi kwenye nodi kwa mpangilio wa nasibu. Ninapendekeza uangalie utendakazi wake kwa kuondoa kwanza nodi iliyo na sehemu zilizosambazwa kutoka kwa nguzo. Kwa kuwa data katika nafasi ambazo hazijatengwa tayari hazipatikani, tumechelewa sana kuwa na wasiwasi kuhusu matatizo na upatikanaji wa nafasi hizi. Kwa upande wake, operesheni haitaathiri nafasi zilizosambazwa.
• Operesheni nyingine muhimu ni kufuatilia. Inakuruhusu kuona kwa wakati halisi orodha nzima ya maombi kwenda kwenye nodi. Kwa kuongeza, unaweza kuiboresha na kujua ikiwa kuna trafiki inayofaa.

Inafaa pia kutaja utaratibu wa kushindwa kwa bwana. Kwa kifupi, ipo, na, kwa maoni yangu, inafanya kazi nzuri. Hata hivyo, usifikiri kwamba ukiondoa kamba ya nguvu kwenye mashine yenye node kuu, Redis itabadilisha mara moja na wateja hawatambui hasara. Katika mazoezi yangu, kubadili hutokea kwa sekunde chache. Wakati huu, baadhi ya data haitapatikana: kutokuwepo kwa bwana hugunduliwa, nodes hupiga kura kwa mpya, watumwa hubadilishwa, data inasawazishwa. Njia bora ya kujihakikishia kuwa mpango unafanya kazi ni kufanya mazoezi ya ndani. Inua nguzo kwenye kompyuta yako ya mkononi, uipe kiwango cha chini cha mzigo, uiga mvurugo (kwa mfano, kwa kuzuia bandari), na utathmini kasi ya kubadili. Kwa maoni yangu, tu baada ya kucheza kwa njia hii kwa siku moja au mbili unaweza kuwa na ujasiri katika uendeshaji wa teknolojia. Kweli, au tunatumai kuwa programu ambayo nusu ya Mtandao hutumia labda inafanya kazi.

Usanidi

Mara nyingi, usanidi ni jambo la kwanza unahitaji kuanza kufanya kazi na chombo.Na wakati kila kitu kitafanya kazi, hutaki hata kugusa usanidi. Inachukua juhudi fulani kujilazimisha kurudi kwenye mipangilio na kuipitia kwa uangalifu. Katika kumbukumbu yangu, tulikuwa na angalau makosa mawili makubwa kwa sababu ya kutozingatia usanidi. Makini hasa kwa pointi zifuatazo:

• muda wa kumaliza 0
  Muda baada ya hapo miunganisho isiyotumika hufungwa (kwa sekunde). 0 - usifunge
  Sio kila maktaba yetu iliweza kufunga miunganisho kwa usahihi. Kwa kuzima mpangilio huu, tunahatarisha kufikia kikomo cha idadi ya wateja. Kwa upande mwingine, ikiwa kuna shida kama hiyo, basi kukomesha kiotomatiki kwa viunganisho vilivyopotea kutafunika, na hatuwezi kugundua. Kwa kuongeza, hupaswi kuwezesha mpangilio huu unapotumia miunganisho ya kudumu.
• Hifadhi xy & appendonly ndiyo
  Inahifadhi picha ya RDB.
  Tutajadili masuala ya RDB/AOF kwa undani hapa chini.
• stop-writes-on-bgsave-error hapana & slave-serve-stale-data ndiyo
  Ikiwashwa, ikiwa muhtasari wa RDB utavunjika, bwana ataacha kukubali maombi ya mabadiliko. Ikiwa uunganisho kwa bwana umepotea, mtumwa anaweza kuendelea kujibu maombi (ndiyo). Au ataacha kujibu (hapana)
  Hatufurahii na hali ambayo Redis inageuka kuwa malenge.
• repl-ping-slave kipindi 5
  Baada ya kipindi hiki cha muda, tutaanza kuwa na wasiwasi kwamba bwana amevunja na ni wakati wa kutekeleza utaratibu wa kushindwa.
  Utalazimika kupata usawa kati ya chanya za uwongo na kusababisha kushindwa. Katika mazoezi yetu hii ni sekunde 5.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  Tunaweza kuhifadhi data hii haswa katika bafa kwa nakala iliyoshindwa. Ikiwa bafa itaisha, itabidi ulandanishe kabisa.
  Mazoezi yanapendekeza kuwa ni bora kuweka thamani ya juu. Kuna sababu nyingi kwa nini nakala inaweza kuanza kuchelewa. Ikiwa inachelewa, basi uwezekano mkubwa bwana wako tayari anajitahidi kukabiliana, na maingiliano kamili yatakuwa majani ya mwisho.
• wateja 10000
  Idadi ya juu zaidi ya wateja wa mara moja.
  Katika uzoefu wetu, ni bora kuweka thamani ya juu. Redis hushughulikia miunganisho 10k vizuri. Hakikisha tu kuna soketi za kutosha kwenye mfumo.
• maxmemory-sera tete-ttl
  Sheria ambayo funguo hufutwa wakati kikomo cha kumbukumbu kinachopatikana kinafikiwa.
  Kilicho muhimu hapa sio sheria yenyewe, lakini uelewa wa jinsi hii itatokea. Redis inaweza kusifiwa kwa uwezo wake wa kufanya kazi kawaida wakati kikomo cha kumbukumbu kinafikiwa.

Matatizo ya RDB na AOF

Ingawa Redis yenyewe huhifadhi habari zote kwenye RAM, pia kuna utaratibu wa kuhifadhi data kwenye diski. Kwa usahihi zaidi, taratibu tatu:

• RDB-snapshot - snapshot kamili ya data zote. Weka kwa kutumia usanidi wa SAVE XY na usome "Hifadhi muhtasari kamili wa data yote kila sekunde X ikiwa angalau vitufe vya Y vimebadilika."
• Faili ya nyongeza tu - orodha ya shughuli kwa mpangilio unaofanywa. Huongeza shughuli mpya zinazoingia kwenye faili kila sekunde X au kila operesheni ya Y.
• RDB na AOF ni mchanganyiko wa hizo mbili zilizopita.

Njia zote zina faida na hasara zao, sitaziorodhesha zote, nitazingatia tu pointi ambazo, kwa maoni yangu, si dhahiri.

Kwanza, kuhifadhi muhtasari wa RDB kunahitaji kupiga simu FORK. Ikiwa kuna data nyingi, hii inaweza kunyongwa Redis zote kwa kipindi cha milisekunde chache hadi sekunde. Kwa kuongezea, mfumo unahitaji kutenga kumbukumbu kwa snapshot kama hiyo, ambayo husababisha hitaji la kuweka usambazaji mara mbili wa RAM kwenye mashine ya kimantiki: ikiwa 8 GB imetengwa kwa Redis, basi 16 GB inapaswa kupatikana kwenye mashine ya kawaida na. ni.

Pili, kuna shida na usawazishaji wa sehemu. Katika hali ya AOF, wakati mtumwa ameunganishwa tena, badala ya usawazishaji wa sehemu, maingiliano kamili yanaweza kufanywa. Kwa nini hii inatokea, sikuweza kuelewa. Lakini inafaa kukumbuka hii.

Pointi hizi mbili tayari zinatufanya tufikirie ikiwa tunahitaji data hii kwenye diski ikiwa kila kitu tayari kimenakiliwa na watumwa. Data inaweza tu kupotea ikiwa watumwa wote wanashindwa, na hii ni tatizo la kiwango cha "moto katika DC". Kama maelewano, unaweza kupendekeza kuhifadhi data kwa watumwa tu, lakini katika kesi hii unahitaji kuhakikisha kuwa watumwa hawa hawatawahi kuwa bwana wakati wa uokoaji wa maafa (kwa hili kuna mpangilio wa kipaumbele cha mtumwa katika usanidi wao). Kwa sisi wenyewe, katika kila kesi maalum tunafikiria ikiwa ni muhimu kuhifadhi data kwenye diski, na mara nyingi jibu ni "hapana".

Hitimisho

Kwa kumalizia, natumai kuwa niliweza kutoa wazo la jumla la jinsi nguzo ya redis inavyofanya kazi kwa wale ambao hawajaisikia kabisa, na pia nikazingatia vidokezo visivyo wazi kwa wale ambao wamekuwa wakiitumia. kwa muda mrefu.
Asante kwa wakati wako na, kama kawaida, maoni juu ya mada yanakaribishwa.

Chanzo: mapenzi.com