Teka produk sing wis dikembangake luwih saka sepuluh taun, ora nggumunake yen nemokake teknologi sing wis lawas. Nanging apa yen ing enem sasi sampeyan kudu tetep mbukak 10 kaping luwih, lan biaya tiba bakal nambah atusan kaping? Ing kasus iki, sampeyan butuh Highload Engineer sing keren. Nanging yen ora ana pembantu, dheweke dipasrahake marang aku kanggo ngrampungake masalah kasebut. Ing bagean pisanan saka artikel aku bakal pitutur marang kowe carane kita pindhah saka Redis kanggo Redis-cluster, lan ing sisih liya aku bakal menehi saran carane miwiti nggunakake kluster lan apa kanggo mbayar manungsa waé kanggo nalika nggunakake.

Pilihan teknologi

Apa iku ala? kapisah Redis (redis mandiri) ing konfigurasi 1 master lan N budak? Apa aku ngarani teknologi sing ora bisa digunakake?

Ora, Redis ora ala ... Nanging, ana sawetara kekurangan sing ora bisa digatekake.

• Kaping pisanan, Redis ora ndhukung mekanisme pemulihan bencana sawise gagal master. Kanggo ngatasi masalah iki, kita nggunakake konfigurasi kanthi transfer otomatis VIP menyang master anyar, ngganti peran siji saka abdi lan ngalih liyane. Mekanisme iki makarya, nanging ora bisa disebut solusi dipercaya. Kaping pisanan, weker palsu kedadeyan, lan kaping pindho, bisa digunakake, lan sawise operasi manual kudu ngisi spring.

• Kapindho, mung duwe siji master nyebabake masalah sharding. Kita kudu nggawe sawetara kluster independen "1 master lan N budak," banjur kanthi manual disebaraké database antarane mesin iki lan pangarep-arep sing besoke siji saka database ora swell dadi luwih sing kudu dipindhah menyang Kayata kapisah.

Apa pilihane?

• Solusi sing paling larang lan paling sugih yaiku Redis-Enterprise. Iki minangka solusi kothak kanthi dhukungan teknis lengkap. Senadyan kasunyatan katon becik saka sudut pandang teknis, iku ora cocog karo kita amarga alasan ideologis.
• Redis-kluster. Metu saka kothak ana dhukungan kanggo master failover lan sharding. Antarmuka meh ora beda karo versi biasa. Iku katon janjeni, kita bakal ngomong babagan pitfalls mengko.
• Tarantool, Memcache, Aerospike lan liya-liyane. Kabeh alat kasebut nindakake perkara sing padha. Nanging saben duwe kekurangan dhewe. Kita mutusake ora kanggo nyelehake kabeh endhog ing siji kranjang. Kita nggunakake Memcache lan Tarantool kanggo tugas liyane, lan, looking ahead, Aku bakal ngomong sing ing laku kita ana liyane masalah karo wong-wong mau.

Spesifik panggunaan

Ayo goleki masalah apa sing wis dirampungake kanthi historis karo Redis lan fungsi apa sing digunakake:

• Cache sadurunge njaluk menyang layanan remot kaya 2GIS | Golang
  

  GET SET MGET MSET "PILIH DB"

• Cache sadurunge MYSQL | PHP
  

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

• Panyimpenan utama kanggo layanan nggarap sesi lan koordinat driver | Golang
  

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

Kaya sing sampeyan ngerteni, ora ana matematika sing luwih dhuwur. Apa banjur kangelan? Ayo ndeleng saben cara kanthi kapisah.

Cara
Description
Fitur saka Redis-cluster
kaputusan

GOLEK
Nulis / maca tombol

MGET MSET
Nulis / maca sawetara tombol
Tombol bakal ana ing macem-macem simpul. Pustaka sing wis siap bisa nindakake multi-operasi mung ing siji simpul
Ganti MGET karo pipa operasi N GET

PILIH DB
Pilih basis sing bakal digunakake
Ora ndhukung macem-macem database
Sijine kabeh ing siji database. Tambah awalan menyang tombol

WANATA
Bukak kabeh tombol ing database
Awit kita duwe database siji, liwat kabeh tombol ing kluster larang banget
Njaga invarian ing siji tombol lan nindakake HSCAN ing tombol iki. Utawa nolak babar pisan

GEO
Operasi karo geokey
Geokey ora sharded

KUNCI BY POLA
Nggoleki kunci kanthi pola
Amarga kita duwe database siji, kita bakal nelusuri kabeh tombol ing kluster. larang banget
Nolak utawa njaga invarian, kaya ing kasus SCAN

Redis vs Redis-kluster

Apa sing ilang lan apa sing entuk nalika ngalih menyang kluster?

• Kekurangan: kita kelangan fungsi sawetara database.
  • Yen kita pengin nyimpen data logis sing ora ana hubungane ing siji kluster, kita kudu nggawe crutches ing wangun awalan.
  • Kita kelangan kabeh operasi "basis", kayata SCAN, DBSIZE, CLEAR DB, lsp.
  • Multi-operasi dadi luwih angel dileksanakake amarga mbutuhake akses menyang sawetara simpul.
• Liyane:
  • Toleransi fault ing wangun master failover.
  • Sharding ing sisih Redis.
  • Transfer data antarane simpul atom lan tanpa downtime.
  • Nambah lan nyebarake kapasitas lan beban tanpa downtime.

Aku nganakke yen sampeyan ora perlu kanggo nyedhiyani tingkat dhuwur saka toleransi fault, banjur pindhah menyang kluster ora worth iku, amarga bisa dadi tugas non-trivial. Nanging yen sampeyan pisanan milih ing antarane versi sing kapisah lan versi kluster, mula sampeyan kudu milih kluster, amarga ora luwih elek lan, saliyane, bakal ngilangi sawetara ngelu.

Nyiyapake kanggo pindhah

Ayo dadi miwiti karo syarat kanggo obah:

• Iku kudu mulus. A mandeg lengkap layanan kanggo 5 menit ora cocog karo kita.
• Sampeyan kudu aman lan bertahap sabisa. Aku pengin duwe sawetara kontrol liwat kahanan. Kita ora pengin mbucal kabeh bebarengan lan ndedonga liwat tombol rollback.
• Mundhut data minimal nalika obah. Kita ngerti manawa bakal angel banget kanggo mindhah kanthi atom, mula kita ngidini sawetara desynchronization antarane data ing Redis biasa lan clustered.

Pangopènan klaster

Sadurunge pamindhahan, kita kudu mikir apa bisa ndhukung kluster:

• Bagan. Kita nggunakake Prometheus lan Grafana kanggo nggambar beban CPU, panggunaan memori, jumlah klien, jumlah operasi GET, SET, AUTH, lsp.
• Keahlian. Mbayangno yen sesuk sampeyan bakal duwe klompok gedhe ing tanggung jawab sampeyan. Yen rusak, ora ana sing bisa ndandani. Yen dheweke wiwit alon-alon, kabeh wong bakal mlayu nyedhaki sampeyan. Yen sampeyan kudu nambah sumber daya utawa mbagekke maneh beban, bali menyang sampeyan. Supaya ora dadi abu-abu ing 25, disaranake kanggo nyedhiyakake kasus kasebut lan mriksa luwih dhisik kepiye teknologi bakal tumindak ing tumindak tartamtu. Ayo ngobrol babagan iki kanthi luwih rinci ing bagean "Keahlian".
• Ngawasi lan tandha. Nalika kluster rusak, sampeyan pengin dadi sing pertama ngerti babagan iki. Ing kene kita diwatesi kanggo kabar yen kabeh kelenjar ngasilake informasi sing padha babagan kahanan kluster (ya, kedadeyan kasebut beda). Lan masalah liyane bisa dingerteni kanthi cepet kanthi tandha saka layanan klien Redis.

Ngalih

Carane kita bakal pindhah:

• Kaping pisanan, sampeyan kudu nyiapake perpustakaan kanggo nggarap kluster. We njupuk go-redis minangka basis kanggo versi Go lan diganti sethitik sing cocog karo awake dhewe. We dipun ginakaken Multi-cara liwat pipelines, lan uga rada didandani aturan kanggo mbaleni panjalukan. Versi PHP duwe masalah luwih akeh, nanging pungkasane kita mapan ing php-redis. Dheweke bubar ngenalake dhukungan kluster lan katon apik ing pendapat kita.
• Sabanjure sampeyan kudu masang kluster dhewe. Iki rampung kanthi harfiah ing rong printah adhedhasar file konfigurasi. Kita bakal ngrembug setelan kasebut kanthi luwih rinci ing ngisor iki.
• Kanggo obah bertahap kita nggunakake mode garing. Awit kita duwe rong versi perpustakaan kanthi antarmuka sing padha (siji kanggo versi biasa, liyane kanggo kluster), ora ana biaya kanggo nggawe pambungkus sing bakal bisa digunakake kanthi versi sing kapisah lan kanthi podo duplikat kabeh panjaluk menyang kluster. mbandhingake respon lan nulis bedo ing log (ing kasus kita ing NewRelic). Dadi, sanajan versi kluster rusak nalika diluncurake, produksi kita ora bakal kena pengaruh.
• Sawise mbalek kluster ing mode garing, kita bisa kanthi tenang ndeleng grafik saka bedo respon. Yen tingkat kesalahan alon-alon nanging mesthi pindhah menyang sawetara konstanta cilik, mula kabeh bakal apik. Yagene isih ana bedho? Amarga ngrekam ing versi kapisah ana sethitik sadurungé saka kluster, lan amarga microlag, data bisa diverge. Kabeh sing isih katon ing log bedo, lan yen kabeh diterangake dening non-atomicity saka rekaman, banjur kita bisa nerusake.
• Saiki sampeyan bisa ngalih mode garing ing arah ngelawan. Kita bakal nulis lan maca saka kluster, lan duplikat menyang versi sing kapisah. Kanggo apa? Ing minggu ngarep aku pengin mirsani karya kluster. Yen dumadakan dadi metu sing ana masalah ing mbukak puncak, utawa kita ora njupuk soko menyang akun, kita tansah duwe rollback darurat kanggo kode lawas lan data saiki thanks kanggo garing-mode.
• Kabeh sing isih ana yaiku mateni mode garing lan mbongkar versi sing kapisah.

Keahlian

Pisanan, ringkes babagan desain kluster.

Kaping pisanan, Redis minangka toko kunci-nilai. String kasepakatan digunakake minangka kunci. Nomer, string, lan kabeh struktur bisa digunakake minangka nilai. Ana akeh sing terakhir, nanging kanggo mangerteni struktur umum iki ora penting kanggo kita.
Tingkat abstraksi sabanjure sawise tombol yaiku slot (SLOT). Saben tombol belongs kanggo salah siji saka 16 slot . Ana bisa sembarang nomer tombol nang saben slot . Mangkono, kabeh tombol dipérang dadi 383 set disjoint.

Sabanjure, kudu ana N master node ing kluster. Saben simpul bisa dianggep minangka conto Redis sing kapisah sing ngerti kabeh babagan kelenjar liyane ing kluster kasebut. Saben simpul master ngandhut sawetara slot . Saben slot belongs kanggo mung siji simpul master. Kabeh slot kudu disebarake antarane kelenjar. Yen sawetara slot ora diparengake, banjur tombol sing disimpen ing bakal ora bisa diakses. Iku ndadekake pangertèn kanggo mbukak saben simpul master ing mesin logis utawa fisik kapisah. Iku uga worth ngelengke sing saben simpul mung mlaku ing siji inti, lan yen sampeyan pengin mbukak sawetara kedadean Redis ing mesin logis padha, priksa manawa padha mbukak ing intine beda (kita wis ora nyoba iki, nanging ing teori iku kudu bisa) . Ateges, simpul master nyedhiyakake sharding biasa, lan luwih akeh simpul master ngidini panjaluk nulis lan maca kanthi skala.

Sawise kabeh tombol mbagekke antarane slot , lan slot kasebar ing antarane kelenjar master, nomer kasepakatan saka kelenjar budak bisa ditambahake kanggo saben simpul master. Ing saben link master-slave kasebut, replikasi normal bakal bisa digunakake. Budak perlu kanggo skala panjalukan maca lan kanggo failover ing cilik saka Gagal master.

Saiki ayo ngomong babagan operasi sing luwih apik yen bisa ditindakake.

Kita bakal ngakses sistem liwat Redis-CLI. Wiwit Redis ora duwe titik entri siji, sampeyan bisa nindakake operasi ing ngisor iki ing samubarang simpul. Ing saben titik aku kapisah narik kawigaten ing kamungkinan kanggo nindakake operasi ing mbukak.

• Babagan pisanan lan paling penting sing kita butuhake yaiku operasi simpul kluster. Ngasilake negara kluster, nuduhake dhaftar kelenjar, peran, distribusi slot, etc. Informasi liyane bisa dipikolehi nggunakake info kluster lan slot kluster.
• Luwih becik bisa nambah lan mbusak simpul. Kanggo maksud iki ana cluster ketemu lan klaster lali operasi. Wigati dimangerteni manawa klaster lali kudu ditrapake ing EVERY node, master lan replika. Lan kumpul kluster mung kudu diarani siji simpul. Bentenane iki bisa dadi mbingungake, mula luwih becik sinau babagan iki sadurunge mbukak klompok sampeyan. Nambahake simpul rampung kanthi aman ing perang lan ora mengaruhi operasi kluster kanthi cara apa wae (sing logis). Yen sampeyan arep kanggo mbusak simpul saka kluster, sampeyan kudu nggawe manawa ora ana slot kiwa ing (yen sampeyan resiko rusak akses kanggo kabeh tombol ing simpul iki). Uga, aja mbusak master sing duwe budak, yen ora, voting sing ora perlu kanggo master anyar bakal ditindakake. Yen kelenjar ora ana maneh slot , banjur iki masalah cilik, nanging kok kita kudu pilihan ekstra yen kita bisa mbusak babu dhisik.
• Yen sampeyan kudu ngganti posisi master lan budak kanthi paksa, banjur perintah failover cluster bakal ditindakake. Nalika nelpon ing perang, sampeyan kudu ngerti manawa master ora bakal kasedhiya sajrone operasi kasebut. Biasane saklar kedadeyan kurang saka detik, nanging ora atom. Sampeyan bisa nyana sawetara panjalukan kanggo master bakal gagal sajrone wektu iki.
• Sadurunge mbusak simpul saka kluster, kudu ora ana slot sing isih ana. Iku luwih apik kanggo mbagekke maneh nggunakake printah reshard cluster. Slot bakal ditransfer saka siji master liyane. Kabeh operasi bisa njupuk sawetara menit, gumantung saka volume data sing ditransfer, nanging proses transfer aman lan ora mengaruhi operasi kluster ing sembarang cara. Mangkono, kabeh data bisa ditransfer saka siji simpul menyang liyane langsung ing mbukak, lan tanpa kuwatir bab kasedhiyan. Nanging, ana uga subtleties. Kaping pisanan, transfer data digandhengake karo beban tartamtu ing simpul panampa lan pangirim. Yen simpul panampa wis akeh dimuat ing prosesor, sampeyan ora kudu mbukak karo nampa data anyar. Kapindho, sanalika ora ana siji slot sing isih ana ing master sing ngirim, kabeh budak bakal langsung menyang master sing slot kasebut ditransfer. Lan masalahe kabeh budak iki pengin nyinkronake data bebarengan. Lan sampeyan bakal begja yen sebagean tinimbang sinkronisasi lengkap. Njupuk iki menyang akun lan gabungke operasi transfer slot lan mateni / transfer babu. Utawa ngarep-arep sampeyan duwe wates safety sing cukup.
• Apa sing kudu dilakoni yen, sak transfer, sampeyan nemokake sing wis ilang slot nang endi wae? Mugi masalah iki ora mengaruhi sampeyan, nanging yen mengkono, ana operasi fix kluster. Paling ora, dheweke bakal nyebarake slot ing simpul kanthi urutan acak. Aku nyaranake mriksa sawijining operasi dening njabut simpul pisanan karo slot mbagekke saka kluster. Wiwit data ing unallocated slot wis kasedhiya, iku kasep sumelang ing masalah karo kasedhiyan slot iki. Ing siji, operasi ora bakal mengaruhi slot mbagekke.
• Operasi liyane sing migunani yaiku monitor. Iki ngidini sampeyan ndeleng kanthi nyata kabeh dhaptar panjaluk menyang simpul kasebut. Kajaba iku, sampeyan bisa grep lan ngerteni manawa ana lalu lintas sing dibutuhake.

Sampeyan uga kudu nyebutake prosedur master failover. Ing cendhak, iku ana, lan, ing mratelakake panemume, iku dianggo gedhe. Nanging, aja mikir yen sampeyan copot kabel listrik ing mesin karo simpul master, Redis bakal langsung ngalih lan klien ora bakal sok dong mirsani mundhut. Ing praktikku, owah-owahan kedadeyan ing sawetara detik. Sajrone wektu iki, sawetara data ora kasedhiya: ora kasedhiya master dideteksi, node milih sing anyar, budak diuripake, data disinkronake. Cara paling apik kanggo mesthekake yen skema kasebut bisa digunakake yaiku nindakake latihan lokal. Ngunggahake kluster ing laptop, menehi beban minimal, simulasi kacilakan (contone, kanthi ngalangi port), lan evaluasi kacepetan ngalih. Ing mratelakake panemume, mung sawise muter ing cara iki kanggo dina utawa loro sampeyan bisa manteb ing ati ing operasi saka teknologi. Ya, utawa ngarep-arep manawa piranti lunak sing setengah saka Internet nggunakake bisa uga bisa digunakake.

Konfigurasi

Asring, konfigurasi minangka bab pisanan sampeyan kudu miwiti nggarap alat kasebut. Lan nalika kabeh bisa digunakake, sampeyan ora pengin ndemek konfigurasi kasebut. Butuh sawetara gaweyan kanggo meksa sampeyan bali menyang setelan kasebut kanthi teliti. Ing memoriku, paling ora ana rong kegagalan serius amarga ora nggatekake konfigurasi kasebut. Pay manungsa waé khusus kanggo titik ing ngisor iki:

• wektu entek 0
  Wektu sawise sambungan ora aktif ditutup (ing detik). 0 - aja nutup
  Ora saben perpustakaan kita bisa nutup sambungan kanthi bener. Kanthi mateni setelan iki, kita duwe risiko nggayuh watesan ing jumlah klien. Ing tangan liyane, yen ana masalah, banjur mandap otomatis saka sambungan ilang bakal mask, lan kita bisa uga ora sok dong mirsani. Kajaba iku, sampeyan ora kudu ngaktifake setelan iki nalika nggunakake sambungan tetep.
• Simpen xy & appendonly ya
  Nyimpen snapshot RDB.
  Kita bakal ngrembug masalah RDB/AOF kanthi rinci ing ngisor iki.
• stop-writes-on-bgsave-error no & slave-serve-stale-data ya
  Yen diaktifake, yen snapshot RDB rusak, master bakal mandheg nampa panjalukan pangowahan. Yen sambungan menyang master ilang, abdi bisa terus nanggapi panjalukan (ya). Utawa bakal mandheg nanggapi (ora)
  Kita ora seneng karo kahanan sing Redis dadi waluh.
• repl-ping-slave-periode 5
  Sawise wektu iki, kita bakal mulai kuwatir yen master wis rusak lan wektune kanggo nindakake prosedur failover.
  Sampeyan kudu kanthi manual golek imbangan antarane positif palsu lan micu failover. Ing laku kita iki 5 detik.
• repl-backlog-ukuran 1024mb & epl-backlog-ttl 0
  Kita bisa nyimpen persis data iki ing buffer kanggo replika gagal. Yen buffer entek, sampeyan kudu nyinkronake kanthi lengkap.
  Praktek nuduhake yen luwih becik nyetel nilai sing luwih dhuwur. Ana akeh alasan kenapa replika bisa wiwit ketinggalan. Yen lags, banjur paling kamungkinan master sampeyan wis berjuang kanggo ngrampungake, lan sinkronisasi lengkap bakal kang dipercoyo pungkasan.
• maksimal 10000
  Jumlah maksimum klien siji-wektu.
  Ing pengalaman kita, luwih becik nyetel nilai sing luwih dhuwur. Redis nangani 10k sambungan apik. Priksa manawa ana cukup soket ing sistem.
• maxmemory-policy volatile-ttl
  Aturan kang tombol dibusak nalika watesan memori kasedhiya wis tekan.
  Sing penting ing kene dudu aturan kasebut dhewe, nanging pangerten babagan kepiye kedadeyan kasebut. Redis bisa dipuji amarga bisa digunakake kanthi normal nalika watesan memori wis tekan.

Masalah RDB lan AOF

Sanajan Redis dhewe nyimpen kabeh informasi ing RAM, ana uga mekanisme kanggo nyimpen data menyang disk. Luwih tepat, telung mekanisme:

• RDB-snapshot - gambar asli seko lengkap kabeh data. Setel nggunakake konfigurasi SAVE XY lan maca "Simpen gambar asli kabeh data saben X detik yen paling tombol Y wis diganti."
• File mung append - dhaptar operasi miturut urutan sing ditindakake. Nambah operasi mlebu anyar menyang file saben X detik utawa saben operasi Y.
• RDB lan AOF minangka kombinasi saka loro sadurunge.

Kabeh cara duwe kaluwihan lan cacat, aku ora bakal nyathet kabeh, aku mung bakal narik kawigaten babagan poin sing, miturut pendapatku, ora jelas.

Pisanan, nyimpen snapshot RDB mbutuhake nelpon FORK. Yen ana akeh data, iki bisa nyumerepi kabeh Redis sajrone sawetara milidetik nganti detik. Kajaba iku, sistem kudu nyedhiakke memori kanggo gambar asli seko kuwi, kang ndadékaké kanggo perlu kanggo nyimpen sumber pindho RAM ing mesin logis: yen 8 GB diparengake kanggo Redis, banjur 16 GB kudu kasedhiya ing mesin virtual karo iku.

Kapindho, ana masalah karo sinkronisasi parsial. Ing mode AOF, nalika budak disambungake maneh, tinimbang sinkronisasi parsial, sinkronisasi lengkap bisa ditindakake. Napa iki kedadeyan, aku ora ngerti. Nanging iku worth ngelingi iki.

Iki loro poin wis nggawe kita mikir apa kita pancene butuh data iki ing disk yen kabeh wis diduplikasi dening budak. Data mung bisa ilang yen kabeh babu gagal, lan iki masalah tingkat "geni ing DC". Minangka kompromi, sampeyan bisa ngusulake kanggo nyimpen data mung ing babu, nanging ing kasus iki sampeyan kudu nggawe manawa babu iki ora bakal dadi master sak Recovery bilai (kanggo iki ana setelan prioritas babu ing config). Kanggo awake dhewe, ing saben kasus tartamtu, kita mikir apa perlu kanggo nyimpen data menyang disk, lan paling asring jawabane "ora".

kesimpulan

Pungkasan, muga-muga bisa menehi gambaran umum babagan cara redis-cluster bisa digunakake kanggo wong-wong sing durung tau krungu, lan uga narik kawigaten sawetara poin sing ora jelas kanggo wong-wong sing wis nggunakake. kanggo dangu.
Matur nuwun kanggo wektu sampeyan lan, kaya biasane, komentar babagan topik kasebut ditampa.

Source: www.habr.com