Pagdating sa isang produkto na umuunlad nang higit sa isang dekada, hindi nakakagulat na makahanap ng mga hindi napapanahong teknolohiya dito. Ngunit paano kung sa anim na buwan kailangan mong panatilihin ang pagkarga ng 10 beses na mas mataas, at ang halaga ng pagbagsak ay tataas ng daan-daang beses? Sa kasong ito, kailangan mo ng isang cool na Highload Engineer. Ngunit sa kawalan ng kasambahay, ipinagkatiwala nila sa akin ang paglutas ng problema. Sa unang bahagi ng artikulo ay sasabihin ko sa iyo kung paano kami lumipat mula sa Redis patungo sa Redis-cluster, at sa pangalawang bahagi ay magbibigay ako ng payo kung paano simulan ang paggamit ng cluster at kung ano ang dapat bigyang pansin kapag ginagamit ito.

Pagpili ng teknolohiya

Ganun na ba kalala? hiwalay na si Redis (standalone redis) sa isang configuration ng 1 master at N alipin? Bakit ko ito tinatawag na hindi na ginagamit na teknolohiya?

Hindi, hindi ganoon kalala ang Redis... Gayunpaman, may ilang mga pagkukulang na hindi maaaring balewalain.

• Una, hindi sinusuportahan ng Redis ang mga mekanismo sa pagbawi ng sakuna pagkatapos ng master failure. Upang malutas ang problemang ito, gumamit kami ng configuration na may awtomatikong paglilipat ng mga VIP sa isang bagong master, binabago ang tungkulin ng isa sa mga alipin at inilipat ang iba. Ang mekanismong ito ay gumana, ngunit hindi ito matatawag na isang maaasahang solusyon. Una, naganap ang mga maling alarma, at pangalawa, ito ay disposable, at pagkatapos ng operasyon, ang mga manu-manong aksyon ay kinakailangan upang singilin ang tagsibol.

• Pangalawa, ang pagkakaroon lamang ng isang master ay humantong sa problema ng sharding. Kinailangan naming lumikha ng ilang independiyenteng mga kumpol na "1 master at N alipin," pagkatapos ay manu-manong ipamahagi ang mga database sa mga makinang ito at umaasa na bukas ang isa sa mga database ay hindi lalago nang labis na kailangan itong ilipat sa isang hiwalay na pagkakataon.

Ano ang mga pagpipilian?

• Ang pinakamahal at pinakamayamang solusyon ay Redis-Enterprise. Ito ay isang boxed solution na may ganap na teknikal na suporta. Sa kabila ng katotohanan na ito ay mukhang perpekto mula sa isang teknikal na punto ng view, hindi ito nababagay sa amin para sa ideological na mga kadahilanan.
• Redis-cluster. Sa labas ng kahon ay mayroong suporta para sa master failover at sharding. Ang interface ay halos hindi naiiba mula sa regular na bersyon. Mukhang promising, pag-uusapan natin ang mga pitfalls mamaya.
• Tarantool, Memcache, Aerospike at iba pa. Ang lahat ng mga tool na ito ay halos pareho ang ginagawa. Ngunit bawat isa ay may sariling pagkukulang. Napagpasyahan naming huwag ilagay ang lahat ng aming mga itlog sa isang basket. Ginagamit namin ang Memcache at Tarantool para sa iba pang mga gawain, at, sa hinaharap, sasabihin ko na sa aming pagsasanay ay may mas maraming problema sa kanila.

Mga detalye ng paggamit

Tingnan natin kung anong mga problema ang dati naming nalutas sa Redis at kung anong functionality ang ginamit namin:

• I-cache bago ang mga kahilingan sa malalayong serbisyo tulad ng 2GIS | Golang
  

  GET SET MGET MSET "PUMILI DB"

• Cache bago ang MYSQL | PHP
  

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

• Ang pangunahing imbakan para sa serbisyo ng pagtatrabaho sa mga session at mga coordinate ng driver | Golang
  

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

Tulad ng nakikita mo, walang mas mataas na matematika. Ano kaya ang kahirapan? Tingnan natin ang bawat pamamaraan nang hiwalay.

pamamaraan
Описание
Mga tampok ng Redis-cluster
desisyon

GET
Sumulat/magbasa ng susi

MGET MSET
Sumulat/magbasa ng maramihang mga susi
Ang mga susi ay nasa iba't ibang mga node. Ang mga handa na aklatan ay maaaring magsagawa ng maraming operasyon sa loob lamang ng isang node
Palitan ang MGET ng pipeline ng mga operasyon ng N GET

PUMILI ng DB
Piliin ang base na aming gagawin
Hindi sumusuporta sa maramihang mga database
Ilagay ang lahat sa isang database. Magdagdag ng mga prefix sa mga key

Malasin
Pumunta sa lahat ng mga susi sa database
Dahil mayroon kaming isang database, ang pagdaan sa lahat ng mga susi sa cluster ay masyadong mahal
Panatilihin ang isang invariant sa loob ng isang key at gumawa ng HSCAN sa key na ito. O tumanggi nang tuluyan

Geo
Mga operasyon na may geokey
Ang geokey ay hindi sharded

SUSI AYON SA PATTERN
Naghahanap ng susi ayon sa pattern
Dahil mayroon kaming isang database, maghahanap kami sa lahat ng mga key sa cluster. Masyadong mahal
Tanggihan o panatilihin ang invariant, tulad ng sa kaso ng SCAN

Redis kumpara sa Redis-cluster

Ano ang mawawala sa atin at ano ang makukuha natin kapag lumipat sa isang kumpol?

• Mga disadvantage: nawawala ang functionality ng ilang database.
  • Kung gusto naming mag-imbak ng lohikal na hindi nauugnay na data sa isang cluster, kakailanganin naming gumawa ng mga saklay sa anyo ng mga prefix.
  • Nawawala namin ang lahat ng "base" na operasyon, gaya ng SCAN, DBSIZE, CLEAR DB, atbp.
  • Ang mga multi-operasyon ay naging mas mahirap ipatupad dahil maaaring mangailangan ito ng access sa ilang mga node.
• Plus:
  • Fault tolerance sa anyo ng master failover.
  • Sharding sa gilid ng Redis.
  • Maglipat ng data sa pagitan ng mga node nang atomically at walang downtime.
  • Magdagdag at muling ipamahagi ang kapasidad at pag-load nang walang downtime.

Gusto kong tapusin na kung hindi mo kailangang magbigay ng isang mataas na antas ng fault tolerance, kung gayon ang paglipat sa isang kumpol ay hindi katumbas ng halaga, dahil maaari itong maging isang di-maliit na gawain. Ngunit kung una kang pumili sa pagitan ng isang hiwalay na bersyon at isang cluster na bersyon, pagkatapos ay dapat kang pumili ng isang kumpol, dahil ito ay hindi mas masahol pa at, bilang karagdagan, ay magpapaginhawa sa iyo ng ilan sa mga sakit ng ulo

Naghahanda para lumipat

Magsimula tayo sa mga kinakailangan para sa paglipat:

• Dapat itong walang putol. Ang kumpletong paghinto ng serbisyo sa loob ng 5 minuto ay hindi angkop sa amin.
• Dapat itong maging ligtas at unti-unti hangga't maaari. Gusto kong magkaroon ng kontrol sa sitwasyon. Hindi namin gustong itapon ang lahat nang sabay-sabay at ipagdasal ang rollback button.
• Minimal na pagkawala ng data kapag gumagalaw. Nauunawaan namin na magiging napakahirap na ilipat ang atomically, kaya pinapayagan namin ang ilang desynchronization sa pagitan ng data sa regular at clustered Redis.

Pagpapanatili ng cluster

Bago ang paglipat, dapat nating isipin kung maaari nating suportahan ang cluster:

• Mga tsart. Ginagamit namin ang Prometheus at Grafana para i-graph ang pag-load ng CPU, paggamit ng memory, bilang ng mga kliyente, bilang ng mga operasyon ng GET, SET, AUTH, atbp.
• Dalubhasa. Isipin na bukas magkakaroon ka ng isang malaking kumpol sa ilalim ng iyong responsibilidad. Kung masira, walang iba kundi ikaw ang makakaayos nito. Kung magsisimula siyang bumagal, lahat ay tatakbo patungo sa iyo. Kung kailangan mong magdagdag ng mga mapagkukunan o muling ipamahagi ang load, bumalik sa iyo. Upang hindi maging kulay abo sa 25, ipinapayong ibigay ang mga kasong ito at suriin nang maaga kung paano kikilos ang teknolohiya sa ilalim ng ilang mga aksyon. Pag-usapan natin ito nang mas detalyado sa seksyong "Dalubhasa".
• Pagsubaybay at mga alerto. Kapag nasira ang isang cluster, gusto mong ikaw ang unang makakaalam tungkol dito. Dito namin nilimitahan ang aming mga sarili sa isang abiso na ang lahat ng mga node ay nagbabalik ng parehong impormasyon tungkol sa estado ng cluster (oo, ito ay nangyayari nang iba). At ang iba pang mga problema ay maaaring mapansin nang mas mabilis sa pamamagitan ng mga alerto mula sa mga serbisyo ng kliyente ng Redis.

Relocation

Paano tayo lilipat:

• Una sa lahat, kailangan mong maghanda ng isang silid-aklatan upang magtrabaho kasama ang kumpol. Kinuha namin ang go-redis bilang batayan para sa bersyon ng Go at binago namin ito nang kaunti upang umangkop sa aming sarili. Nagpatupad kami ng Multi-methods sa pamamagitan ng pipelines, at bahagyang itinama din ang mga panuntunan para sa mga paulit-ulit na kahilingan. Ang bersyon ng PHP ay nagkaroon ng mas maraming problema, ngunit kalaunan ay naayos namin ang php-redis. Ipinakilala nila kamakailan ang suporta sa kumpol at mukhang maganda ito sa aming opinyon.
• Susunod na kailangan mong i-deploy ang cluster mismo. Ginagawa ito nang literal sa dalawang utos batay sa file ng pagsasaayos. Tatalakayin natin ang setting nang mas detalyado sa ibaba.
• Для постепенного переезда мы используем dry-mode. Так как у нас есть две версии библиотеки с одинаковым интерфейсом (одна для обычной версии, другая для кластера), ничего не стоит сделать обертку, которая будет работать с отдельной версией и параллельно дублировать все запросы в кластер, сравнивать ответы и писать расхождения в логи (в нашем случае в NewRelic). Таким образом, даже если при выкатке кластерная версия сломается, наш production это не затронет.
• Ang pagkakaroon ng roll out ang cluster sa dry mode, maaari naming mahinahon tingnan ang graph ng mga pagkakaiba sa tugon. Kung ang rate ng error ay dahan-dahan ngunit tiyak na lumilipat patungo sa isang maliit na pare-pareho, kung gayon ang lahat ay maayos. Bakit may mga pagkakaiba pa rin? Dahil ang pag-record sa isang hiwalay na bersyon ay nangyayari nang mas maaga kaysa sa cluster, at dahil sa microlag, ang data ay maaaring magkakaiba. Ang natitira na lang ay tingnan ang mga tala ng pagkakaiba, at kung ang lahat ng ito ay ipinaliwanag sa pamamagitan ng hindi atomicity ng rekord, maaari tayong magpatuloy.
• Ngayon ay maaari mong ilipat ang dry-mode sa tapat na direksyon. Magsusulat at magbabasa kami mula sa cluster, at ido-duplicate ito sa isang hiwalay na bersyon. Para saan? Sa susunod na linggo gusto kong obserbahan ang gawain ng cluster. Kung biglang lumabas na may mga problema sa peak load, o hindi namin isinasaalang-alang, palagi kaming may emergency rollback sa lumang code at kasalukuyang data salamat sa dry-mode.
• Ang natitira na lang ay i-disable ang dry-mode at i-dismantle ang hiwalay na bersyon.

Eksperto

Una, maikling tungkol sa disenyo ng kumpol.

Una sa lahat, ang Redis ay isang key-value store. Ang mga arbitrary na string ay ginagamit bilang mga susi. Ang mga numero, string, at buong istruktura ay maaaring gamitin bilang mga halaga. Marami sa huli, ngunit para sa pag-unawa sa pangkalahatang istraktura hindi ito mahalaga para sa amin.
Ang susunod na antas ng abstraction pagkatapos ng mga key ay slots (SLOTS). Ang bawat susi ay kabilang sa isa sa 16 na puwang. Maaaring mayroong anumang bilang ng mga susi sa loob ng bawat slot. Kaya, ang lahat ng mga susi ay nahahati sa 383 magkahiwalay na hanay.

Susunod, dapat mayroong N master node sa cluster. Ang bawat node ay maaaring isipin bilang isang hiwalay na halimbawa ng Redis na nakakaalam ng lahat tungkol sa iba pang mga node sa loob ng cluster. Ang bawat master node ay naglalaman ng isang bilang ng mga puwang. Ang bawat slot ay nabibilang lamang sa isang master node. Ang lahat ng mga puwang ay kailangang ipamahagi sa pagitan ng mga node. Kung ang ilang mga puwang ay hindi inilalaan, kung gayon ang mga susi na nakaimbak sa mga ito ay hindi maa-access. Makatuwirang patakbuhin ang bawat master node sa isang hiwalay na lohikal o pisikal na makina. Ito rin ay nagkakahalaga ng pag-alala na ang bawat node ay tumatakbo lamang sa isang core, at kung gusto mong magpatakbo ng maraming Redis instance sa parehong lohikal na makina, tiyaking tumatakbo ang mga ito sa iba't ibang mga core (hindi pa namin ito sinubukan, ngunit sa teorya dapat itong gumana) . Sa pangkalahatan, ang mga master node ay nagbibigay ng regular na sharding, at higit pang mga master node ang nagbibigay-daan sa pag-scale ng mga kahilingan sa pagsulat at pagbasa.

Matapos maipamahagi ang lahat ng mga susi sa mga puwang, at ang mga puwang ay nakakalat sa mga master node, maaaring magdagdag ng arbitrary na bilang ng mga slave node sa bawat master node. Sa loob ng bawat naturang master-slave link, gagana ang normal na pagtitiklop. Ang mga alipin ay kinakailangan upang sukatin ang mga kahilingan sa pagbasa at para sa failover kung sakaling mabigo ang master.

Ngayon ay pag-usapan natin ang tungkol sa mga operasyon na mas mainam na magawa.

Maa-access namin ang system sa pamamagitan ng Redis-CLI. Dahil walang iisang entry point ang Redis, maaari mong gawin ang mga sumusunod na operasyon sa alinman sa mga node. Sa bawat punto ay hiwalay kong binibigyang pansin ang posibilidad ng pagsasagawa ng operasyon sa ilalim ng pagkarga.

• Ang una at pinakamahalagang bagay na kailangan natin ay ang pagpapatakbo ng mga cluster node. Ibinabalik nito ang estado ng cluster, nagpapakita ng listahan ng mga node, ang kanilang mga tungkulin, pamamahagi ng slot, atbp. Higit pang impormasyon ang maaaring makuha gamit ang cluster info at cluster slots.
• Mas maganda kung makapagdagdag at makapag-alis ng mga node. Para sa layuning ito mayroong cluster meet at cluster forget operations. Pakitandaan na ang cluster forget ay dapat ilapat sa BAWAT node, parehong masters at replicas. At ang cluster meet ay kailangang tawagan lamang sa isang node. Ang pagkakaibang ito ay maaaring nakakalito, kaya pinakamahusay na alamin ang tungkol dito bago ka mag-live sa iyong cluster. Ang pagdaragdag ng node ay ligtas na ginagawa sa labanan at hindi nakakaapekto sa operasyon ng cluster sa anumang paraan (na lohikal). Kung aalisin mo ang isang node mula sa cluster, dapat mong tiyakin na walang natitirang mga puwang dito (kung hindi, nanganganib kang mawalan ng access sa lahat ng mga susi sa node na ito). Gayundin, huwag tanggalin ang isang master na may mga alipin, kung hindi, isang hindi kinakailangang boto para sa isang bagong master ay isasagawa. Kung ang mga node ay wala nang mga puwang, kung gayon ito ay isang maliit na problema, ngunit bakit kailangan natin ng mga karagdagang pagpipilian kung maaari nating tanggalin muna ang mga alipin.
• Kung kailangan mong pilitin na palitan ang mga posisyon ng master at slave, gagawin ang cluster failover command. Kapag tinawag ito sa labanan, kailangan mong maunawaan na ang master ay hindi magagamit sa panahon ng operasyon. Karaniwang nangyayari ang switch sa wala pang isang segundo, ngunit hindi atomic. Maaari mong asahan na ang ilang mga kahilingan sa master ay mabibigo sa panahong ito.
• Bago mag-alis ng node mula sa cluster, dapat na walang natitira na mga puwang dito. Mas mainam na ipamahagi muli ang mga ito gamit ang cluster reshard command. Ang mga puwang ay ililipat mula sa isang master patungo sa isa pa. Ang buong operasyon ay maaaring tumagal ng ilang minuto, depende ito sa dami ng data na inililipat, ngunit ang proseso ng paglipat ay ligtas at hindi nakakaapekto sa pagpapatakbo ng cluster sa anumang paraan. Kaya, ang lahat ng data ay maaaring ilipat mula sa isang node patungo sa isa pa nang direkta sa ilalim ng pagkarga, at nang hindi nababahala tungkol sa pagkakaroon nito. Gayunpaman, mayroon ding mga subtleties. Una, ang paglilipat ng data ay nauugnay sa isang tiyak na pagkarga sa mga node ng tatanggap at nagpadala. Kung ang recipient node ay na-load nang malaki sa processor, hindi mo ito dapat i-load sa pagtanggap ng bagong data. Pangalawa, sa sandaling wala nang isang slot na natitira sa nagpapadalang master, lahat ng mga alipin nito ay agad na mapupunta sa master kung saan inilipat ang mga slot na ito. At ang problema ay ang lahat ng mga aliping ito ay nais na i-synchronize ang data nang sabay-sabay. At masuwerte ka kung ito ay bahagyang sa halip na kumpletong pag-synchronize. Isaalang-alang ito at pagsamahin ang mga pagpapatakbo ng paglilipat ng mga slot at hindi pagpapagana/paglipat ng mga alipin. O umaasa na mayroon kang sapat na margin ng kaligtasan.
• Ano ang dapat mong gawin kung, sa panahon ng paglilipat, nalaman mong nawala mo ang iyong mga slot sa isang lugar? Umaasa ako na ang problemang ito ay hindi makakaapekto sa iyo, ngunit kung ito ay nangyari, mayroong isang cluster fix operation. Hindi bababa sa, ikakalat niya ang mga puwang sa mga node sa random na pagkakasunud-sunod. Inirerekomenda kong suriin ang operasyon nito sa pamamagitan ng pag-alis muna ng node na may mga distributed slots mula sa cluster. Dahil hindi na available ang data sa mga hindi inilalaang slot, huli na para mag-alala tungkol sa mga problema sa pagkakaroon ng mga slot na ito. Sa turn, ang operasyon ay hindi makakaapekto sa mga ipinamahagi na slot.
• Ang isa pang kapaki-pakinabang na operasyon ay monitor. Binibigyang-daan ka nitong makita sa real time ang buong listahan ng mga kahilingan na pupunta sa node. Bukod dito, maaari mong makuha ito at malaman kung mayroong kinakailangang trapiko.

Ito rin ay nagkakahalaga ng pagbanggit sa master failover procedure. Sa madaling salita, umiiral ito, at, sa palagay ko, mahusay itong gumagana. Gayunpaman, huwag isipin na kung tatanggalin mo ang power cord sa isang makina na may master node, agad na lilipat ang Redis at hindi mapapansin ng mga kliyente ang pagkawala. Sa aking pagsasanay, ang paglipat ay nangyayari sa loob ng ilang segundo. Sa panahong ito, ang ilan sa mga data ay hindi magagamit: ang kawalan ng kakayahan ng master ay nakita, ang mga node ay bumoto para sa isang bago, ang mga alipin ay inililipat, ang data ay naka-synchronize. Ang pinakamahusay na paraan upang matiyak sa iyong sarili na gumagana ang pamamaraan ay ang pagsasagawa ng mga lokal na pagsasanay. Itaas ang cluster sa iyong laptop, bigyan ito ng minimum na load, gayahin ang pag-crash (halimbawa, sa pamamagitan ng pagharang sa mga port), at suriin ang bilis ng paglipat. Sa palagay ko, pagkatapos lamang maglaro sa ganitong paraan sa loob ng isang araw o dalawa maaari kang maging tiwala sa pagpapatakbo ng teknolohiya. Well, o umaasa na ang software na ginagamit ng kalahati ng Internet ay malamang na gumagana.

Configuration

Kadalasan, ang configuration ang unang bagay na kailangan mo para magsimulang magtrabaho kasama ang tool. At kapag gumagana ang lahat, hindi mo na gustong hawakan ang config. Kailangan ng ilang pagsisikap upang pilitin ang iyong sarili na bumalik sa mga setting at maingat na suriin ang mga ito. Sa aking memorya, mayroon kaming hindi bababa sa dalawang malubhang pagkabigo dahil sa hindi pansin sa pagsasaayos. Bigyang-pansin ang mga sumusunod na puntos:

• timeout 0
  Oras pagkatapos kung saan ang mga hindi aktibong koneksyon ay sarado (sa mga segundo). 0 - huwag isara
  Hindi lahat ng library namin ay nakapagsara ng mga koneksyon nang tama. Sa pamamagitan ng hindi pagpapagana sa setting na ito, nanganganib kaming maabot ang limitasyon sa bilang ng mga kliyente. Sa kabilang banda, kung may ganoong problema, ang awtomatikong pagwawakas ng mga nawawalang koneksyon ay itatakip ito, at maaaring hindi natin mapansin. Bilang karagdagan, hindi mo dapat paganahin ang setting na ito kapag gumagamit ng mga persist na koneksyon.
• I-save ang xy at dagdag na oo
  Nagse-save ng snapshot ng RDB.
  Tatalakayin natin ang mga isyu sa RDB/AOF nang detalyado sa ibaba.
• stop-writes-on-bgsave-error no & slave-serve-stale-data yes
  Kung pinagana, kung masira ang snapshot ng RDB, hihinto ang master sa pagtanggap ng mga kahilingan sa pagbabago. Kung ang koneksyon sa master ay nawala, ang alipin ay maaaring magpatuloy na tumugon sa mga kahilingan (oo). O hihinto sa pagtugon (hindi)
  Hindi kami natutuwa sa sitwasyon kung saan naging kalabasa si Redis.
• repl-ping-slave-period 5
  Pagkatapos ng panahong ito, magsisimula kaming mag-alala na ang master ay nasira at oras na upang isagawa ang pamamaraan ng failover.
  Kakailanganin mong manual na maghanap ng balanse sa pagitan ng mga maling positibo at pagti-trigger ng failover. Sa aming pagsasanay ito ay 5 segundo.
• repl-backlog-size 1024mb at epl-backlog-ttl 0
  Maaari kaming mag-imbak ng eksaktong ganito karaming data sa isang buffer para sa isang nabigong replica. Kung maubusan ang buffer, kailangan mong ganap na mag-synchronize.
  Iminumungkahi ng pagsasanay na mas mahusay na magtakda ng mas mataas na halaga. Maraming dahilan kung bakit maaaring magsimulang ma-lag ang isang replika. Kung ito ay lags, malamang na ang iyong master ay nahihirapan na makayanan, at ang buong pag-synchronize ang magiging huling dayami.
• maxclients 10000
  Pinakamataas na bilang ng isang beses na kliyente.
  Sa aming karanasan, mas mainam na magtakda ng mas mataas na halaga. Ang Redis ay humahawak ng 10k koneksyon nang maayos. Siguraduhin lamang na mayroong sapat na mga socket sa system.
• maxmemory-policy volatile-ttl
  Ang panuntunan kung saan tinatanggal ang mga key kapag naabot na ang limitasyon ng magagamit na memorya.
  Ang mahalaga dito ay hindi ang panuntunan mismo, ngunit ang pag-unawa sa kung paano ito mangyayari. Maaaring purihin ang Redis para sa kakayahang gumana nang normal kapag naabot na ang limitasyon ng memorya.

Mga problema sa RDB at AOF

Kahit na ang Redis mismo ay nag-iimbak ng lahat ng impormasyon sa RAM, mayroon ding mekanismo para sa pag-save ng data sa disk. Mas tiyak, tatlong mekanismo:

• RDB-snapshot - isang kumpletong snapshot ng lahat ng data. Itakda gamit ang SAVE XY configuration at magbabasa ng "Mag-save ng buong snapshot ng lahat ng data bawat X segundo kung nagbago man lang ang mga Y key."
• Append-only na file - isang listahan ng mga operasyon ayon sa pagkakasunud-sunod ng mga ito. Nagdaragdag ng mga bagong papasok na operasyon sa file bawat X segundo o bawat Y na operasyon.
• Ang RDB at AOF ay kumbinasyon ng naunang dalawa.

Ang lahat ng mga pamamaraan ay may kanilang mga pakinabang at disadvantages, hindi ko ilista ang lahat, bibigyan ko lamang ng pansin ang mga punto na, sa aking palagay, ay hindi halata.

Una, ang pag-save ng snapshot ng RDB ay nangangailangan ng pagtawag sa FORK. Kung maraming data, maaari nitong i-hang ang lahat ng Redis sa loob ng ilang millisecond hanggang isang segundo. Bilang karagdagan, ang system ay kailangang maglaan ng memorya para sa naturang snapshot, na humahantong sa pangangailangan na panatilihin ang isang dobleng supply ng RAM sa lohikal na makina: kung ang 8 GB ay inilalaan para sa Redis, kung gayon ang 16 GB ay dapat na magagamit sa virtual machine na may ito.

Pangalawa, may mga problema sa bahagyang pag-synchronize. Sa AOF mode, kapag ang alipin ay muling nakakonekta, sa halip na bahagyang pag-synchronize, ganap na pag-synchronize ang maaaring isagawa. Bakit nangyayari ito, hindi ko maintindihan. Ngunit ito ay nagkakahalaga ng pag-alala.

Ang dalawang puntong ito ay nakapagpapaisip na sa atin kung talagang kailangan natin ang data na ito sa disk kung ang lahat ay nadoble na ng mga alipin. Ang data ay maaari lamang mawala kung ang lahat ng mga alipin ay nabigo, at ito ay isang problema sa antas ng "sunog sa DC". Bilang isang kompromiso, maaari kang magmungkahi na mag-save ng data lamang sa mga alipin, ngunit sa kasong ito kailangan mong tiyakin na ang mga alipin na ito ay hindi kailanman magiging isang master sa panahon ng pagbawi ng kalamidad (para dito mayroong isang setting ng priyoridad ng alipin sa kanilang config). Para sa ating sarili, sa bawat partikular na kaso iniisip natin kung kinakailangan bang i-save ang data sa disk, at kadalasan ang sagot ay "hindi".

Konklusyon

Sa konklusyon, umaasa ako na nakapagbigay ako ng pangkalahatang ideya kung paano gumagana ang redis-cluster para sa mga hindi pa nakakarinig tungkol dito, at nakakuha din ng pansin sa ilang hindi halatang mga punto para sa mga gumagamit nito. sa mahabang panahon.
Salamat sa iyong oras at, gaya ng nakasanayan, ang mga komento sa paksa ay malugod na tinatanggap.

Pinagmulan: www.habr.com