O'n yildan ko'proq vaqt davomida ishlab chiqilgan mahsulotga kelsak, unda eskirgan texnologiyalarni topish ajablanarli emas. Ammo olti oy ichida siz yukni 10 baravar yuqori ushlab turishingiz kerak bo'lsa-chi, va tushish narxi yuzlab marta oshadi? Bunday holda, sizga ajoyib yuqori yuk muhandisi kerak. Lekin xizmatkor yo'qligi sababli muammoni hal qilishni menga ishonib topshirishdi. Maqolaning birinchi qismida Redisdan Redis-klasterga qanday o‘tganimizni aytib bersam, ikkinchi qismida esa klasterdan qanday foydalanishni boshlash va undan foydalanishda nimalarga e’tibor berish kerakligi haqida maslahatlar beraman.

Texnologiyani tanlash

Shunchalik yomonmi? alohida Redis (mustaqil redis) 1 ta master va N qul konfiguratsiyasida? Nega men uni eskirgan texnologiya deb atayman?

Yo‘q, Redis unchalik yomon emas... Biroq, e’tibordan chetda qoldirib bo‘lmaydigan kamchiliklar ham bor.

• Birinchidan, Redis asosiy muvaffaqiyatsizlikdan keyin falokatni tiklash mexanizmlarini qo'llab-quvvatlamaydi. Ushbu muammoni hal qilish uchun biz VIP-larni avtomatik ravishda yangi ustaga o'tkazish, qullardan birining rolini o'zgartirish va qolganlarini almashtirish bilan konfiguratsiyadan foydalandik. Bu mexanizm ishladi, lekin uni ishonchli yechim deb atash mumkin emas edi. Birinchidan, noto'g'ri signallar paydo bo'ldi, ikkinchidan, u bir martalik edi va operatsiyadan keyin bahorni zaryad qilish uchun qo'lda harakatlar talab qilindi.

• Ikkinchidan, faqat bitta ustaga ega bo'lish sharding muammosiga olib keldi. Biz bir nechta mustaqil "1 master va N qul" klasterlarini yaratishimiz kerak edi, keyin ma'lumotlar bazalarini ushbu mashinalar o'rtasida qo'lda taqsimlashimiz kerak edi va ertaga ma'lumotlar bazalaridan biri shunchalik shishib ketmasligi uchun uni alohida nusxaga ko'chirishga to'g'ri keladi deb umid qilamiz.

Qanday variantlar mavjud?

• Eng qimmat va eng boy yechim - Redis-Enterprise. Bu to'liq texnik yordamga ega bo'lgan qutidagi yechim. Texnik nuqtai nazardan ideal ko'rinishiga qaramay, mafkuraviy sabablarga ko'ra bizga mos kelmadi.
• Redis-klaster. Qutidan tashqarida asosiy o'zgartirish va parchalanish uchun yordam mavjud. Interfeys oddiy versiyadan deyarli farq qilmaydi. Bu istiqbolli ko'rinadi, tuzoqlar haqida keyinroq gaplashamiz.
• Tarantool, Memcache, Aerospike va boshqalar. Ushbu vositalarning barchasi deyarli bir xil ishlaydi. Ammo har birining o'ziga xos kamchiliklari bor. Biz barcha tuxumlarimizni bitta savatga solmaslikka qaror qildik. Biz Memcache va Tarantool-dan boshqa vazifalar uchun foydalanamiz va oldinga qarab shuni aytamanki, bizning amaliyotimizda ular bilan ko'proq muammolar mavjud edi.

Foydalanish xususiyatlari

Keling, Redis bilan tarixan qanday muammolarni hal qilganimizni va qanday funksiyalardan foydalanganimizni ko'rib chiqaylik:

• 2GIS | kabi masofaviy xizmatlarga so'rovlardan oldin kesh Golang
  

  SET MGET MSETni OLISH "JBni tanlash"

• MYSQL | oldidan kesh PHP
  

  SOZLASH MGET MSET SCAN "KALYUT BO'YICHA" "JBni tanlash"

• Seanslar va haydovchi koordinatalari bilan ishlash xizmati uchun asosiy xotira | Golang
  

  SOZLASH MGET MSET "JB TANILADI" "GEO KALIT QO'SHISH" "GEO KALITNI OLISH" Skanerlash

Ko'rib turganingizdek, oliy matematika yo'q. Unda qiyinchilik nimada? Keling, har bir usulni alohida ko'rib chiqaylik.

usul
tavsifi
Redis-klasterning xususiyatlari
qaror

O'RNATISH
Yozish/o'qish kaliti

MGET MSET
Bir nechta tugmachalarni yozish/o'qish
Kalitlar turli tugunlarda bo'ladi. Tayyor kutubxonalar faqat bitta tugun ichida ko'p amallarni bajarishi mumkin
MGETni N GET operatsiyalari quvur liniyasi bilan almashtiring

JB TANGLASH
Biz ishlaydigan bazani tanlang
Bir nechta ma'lumotlar bazalarini qo'llab-quvvatlamaydi
Hamma narsani bitta ma'lumotlar bazasiga joylashtiring. Tugmalarga prefiks qo'shing

SCAN
Ma'lumotlar bazasidagi barcha kalitlardan o'ting
Bizda bitta ma'lumotlar bazasi bo'lganligi sababli, klasterdagi barcha kalitlardan o'tish juda qimmat
Bitta kalit ichida invariantni saqlang va bu kalitda HSCAN ni bajaring. Yoki butunlay rad eting

GEO
Geokey bilan operatsiyalar
Geokey ajratilmagan

KALYONA BO'YICHA
Kalit naqsh bo'yicha qidirilmoqda
Bizda bitta ma'lumotlar bazasi bo'lgani uchun biz klasterdagi barcha kalitlarni qidiramiz. Juda qimmat
SCAN misolida bo'lgani kabi invariantni rad eting yoki saqlang

Redis va Redis-klaster

Klasterga o'tishda nimani yo'qotamiz va nimani yutamiz?

• Kamchiliklari: biz bir nechta ma'lumotlar bazalarining funksionalligini yo'qotamiz.
  • Agar biz mantiqiy jihatdan bog'liq bo'lmagan ma'lumotlarni bitta klasterda saqlamoqchi bo'lsak, biz prefikslar shaklida tayoqchalar yasashimiz kerak bo'ladi.
  • Biz SCAN, DBSIZE, CLEAR DB va boshqalar kabi barcha "asosiy" operatsiyalarni yo'qotamiz.
  • Ko'p operatsiyalarni amalga oshirish ancha qiyinlashdi, chunki u bir nechta tugunlarga kirishni talab qilishi mumkin.
• afzalliklari:
  • Magistrning uzilishi ko'rinishidagi xatolarga chidamlilik.
  • Redis tomonida parchalanish.
  • Ma'lumotni tugunlar o'rtasida atomik va uzilishlarsiz uzatish.
  • Imkoniyatlar va yuklarni to'xtamasdan qo'shing va qayta taqsimlang.

Xulosa qilgan bo'lardimki, agar siz yuqori darajadagi nosozliklarga chidamliligini ta'minlashingiz shart bo'lmasa, unda klasterga o'tish bunga loyiq emas, chunki bu ahamiyatsiz ish bo'lishi mumkin. Ammo agar siz dastlab alohida versiya va klaster versiyasini tanlasangiz, unda siz klasterni tanlashingiz kerak, chunki bu yomon emas va qo'shimcha ravishda sizni bosh og'rig'idan xalos qiladi.

Ko'chirishga tayyorlanmoqda

Keling, ko'chirish uchun talablardan boshlaylik:

• Bu muammosiz bo'lishi kerak. Xizmatni 5 daqiqaga to'liq to'xtatish bizga mos kelmaydi.
• Bu imkon qadar xavfsiz va asta-sekin bo'lishi kerak. Men vaziyatni biroz nazorat qilishni xohlayman. Biz hamma narsani birdaniga tashlab, orqaga qaytarish tugmasi ustida ibodat qilishni xohlamaymiz.
• Ko'chirishda minimal ma'lumotlar yo'qolishi. Biz atomik tarzda harakat qilish juda qiyin bo'lishini tushunamiz, shuning uchun biz oddiy va klasterli Redis-dagi ma'lumotlar o'rtasida ba'zi bir desinxronizatsiyaga ruxsat beramiz.

Klasterga texnik xizmat ko'rsatish

Ko'chirishdan oldin, biz klasterni qo'llab-quvvatlashimiz mumkinmi, deb o'ylashimiz kerak:

• Grafikalar. Biz Prometey va Grafana-dan protsessor yukini, xotiradan foydalanishni, mijozlar sonini, GET, SET, AUTH operatsiyalari sonini va hokazolarni grafik qilish uchun foydalanamiz.
• Ekspertiza. Tasavvur qiling-a, ertaga sizning mas'uliyatingiz ostida ulkan klaster bo'ladi. Agar u buzilib qolsa, uni sizdan boshqa hech kim tuzata olmaydi. Agar u sekinlasha boshlasa, hamma sizga qarab yuguradi. Agar siz resurslarni qo'shishingiz yoki yukni qayta taqsimlashingiz kerak bo'lsa, sizga qaytib keling. 25 yoshda kul rangga aylanmaslik uchun ushbu holatlarni ta'minlash va texnologiya muayyan harakatlar ostida qanday harakat qilishini oldindan tekshirish tavsiya etiladi. Keling, bu haqda "Ekspertiza" bo'limida batafsilroq gaplashamiz.
• Monitoring va ogohlantirishlar. Klaster buzilganda, siz bu haqda birinchi bo'lib bilishni xohlaysiz. Bu erda biz barcha tugunlar klaster holati to'g'risida bir xil ma'lumotni qaytarishi haqida bildirishnoma bilan cheklandik (ha, bu boshqacha sodir bo'ladi). Va boshqa muammolarni Redis mijozlar xizmatlarining ogohlantirishlari orqali tezroq sezish mumkin.

Ko'chib o'tish

Biz qanday harakat qilamiz:

• Klaster bilan ishlash uchun birinchi navbatda kutubxonani tayyorlash kerak. Go versiyasi uchun biz go-redisni asos qilib oldik va uni o'zimizga moslash uchun biroz o'zgartirdik. Biz quvurlar orqali ko'p usullarni amalga oshirdik, shuningdek, so'rovlarni takrorlash qoidalarini biroz tuzatdik. PHP versiyasida ko'proq muammolar bor edi, lekin biz oxir-oqibat php-redisga qaror qildik. Ular yaqinda klasterni qo'llab-quvvatlashni joriy qilishdi va bu bizning fikrimizcha yaxshi ko'rinadi.
• Keyin klasterni o'zi joylashtirishingiz kerak. Bu konfiguratsiya fayliga asoslangan ikkita buyruqda tom ma'noda amalga oshiriladi. Sozlamani quyida batafsilroq muhokama qilamiz.
• Sekin-asta harakat qilish uchun biz quruq rejimdan foydalanamiz. Bizda kutubxonaning bir xil interfeysga ega ikkita versiyasi (biri oddiy versiya uchun, ikkinchisi klaster uchun) mavjud bo'lganligi sababli, alohida versiya bilan ishlaydigan va parallel ravishda klasterga barcha so'rovlarni takrorlaydigan o'ramni yaratish hech qanday xarajat qilmaydi, javoblarni solishtiring va jurnallarga nomuvofiqliklarni yozing (bizning holimizda NewRelic-da). Shunday qilib, ishlab chiqarish jarayonida klaster versiyasi buzilgan taqdirda ham, bizning ishlab chiqarishimizga ta'sir qilmaydi.
• Klasterni quruq rejimda chiqarganimizdan so'ng, biz javob kelishmovchiliklari grafigiga xotirjamlik bilan qarashimiz mumkin. Agar xato darajasi asta-sekin, lekin aniq bir kichik konstantaga qarab harakat qilsa, unda hamma narsa yaxshi. Nima uchun hali ham kelishmovchiliklar mavjud? Alohida versiyada yozish klasterga qaraganda biroz oldinroq sodir bo'lganligi sababli va mikrolag tufayli ma'lumotlar farq qilishi mumkin. Faqatgina nomuvofiqlik jurnallarini ko'rib chiqish qoladi va agar ularning barchasi yozuvning atomsizligi bilan izohlansa, biz davom etishimiz mumkin.
• Endi siz quruq rejimni teskari yo'nalishda almashtirishingiz mumkin. Biz klasterdan yozamiz va o'qiymiz va uni alohida versiyaga ko'paytiramiz. Nima uchun? Keyingi haftada men klaster ishini kuzatmoqchiman. Agar to'satdan eng yuqori yuklanishda muammolar borligi aniqlansa yoki biz biror narsani hisobga olmagan bo'lsak, quruq rejim tufayli biz doimo eski kodga va joriy ma'lumotlarga favqulodda qaytishga ega bo'lamiz.
• Faqat quruq rejimni o'chirish va alohida versiyani demontaj qilish qoladi.

Mutaxassislik

Birinchidan, klaster dizayni haqida qisqacha.

Birinchidan, Redis - bu asosiy qiymat do'koni. Kalit sifatida ixtiyoriy satrlar ishlatiladi. Qiymat sifatida raqamlar, satrlar va butun tuzilmalardan foydalanish mumkin. Ikkinchisi juda ko'p, ammo umumiy tuzilmani tushunish uchun bu biz uchun muhim emas.
Tugmachalardan keyingi abstraksiya darajasi uyalardir (SLOTS). Har bir kalit 16 383 slotdan biriga tegishli. Har bir uyaning ichida istalgan miqdordagi kalitlar bo'lishi mumkin. Shunday qilib, barcha kalitlar 16 383 ta ajratilgan to'plamga bo'lingan.

Keyinchalik, klasterda N ta asosiy tugun bo'lishi kerak. Har bir tugunni klaster ichidagi boshqa tugunlar haqida hamma narsani biladigan alohida Redis misoli sifatida ko'rish mumkin. Har bir asosiy tugunda bir nechta uyalar mavjud. Har bir slot faqat bitta asosiy tugunga tegishli. Barcha uyalar tugunlar o'rtasida taqsimlanishi kerak. Agar ba'zi uyalar ajratilmagan bo'lsa, unda saqlangan kalitlarga kirish imkoni bo'lmaydi. Har bir asosiy tugunni alohida mantiqiy yoki jismoniy mashinada ishga tushirish mantiqiy. Shuni ham yodda tutish kerakki, har bir tugun faqat bitta yadroda ishlaydi va agar siz bir xil mantiqiy mashinada bir nechta Redis nusxalarini ishga tushirishni istasangiz, ular turli yadrolarda ishlashiga ishonch hosil qiling (biz buni sinab ko'rmadik, lekin nazariy jihatdan u ishlashi kerak) . Asosan, asosiy tugunlar muntazam parchalanishni ta'minlaydi va ko'proq asosiy tugunlar yozish va o'qish so'rovlarini masshtablash imkonini beradi.

Barcha kalitlar uyalar orasida taqsimlangandan so'ng va uyalar asosiy tugunlar orasida tarqalib ketgandan so'ng, har bir asosiy tugunga o'zboshimchalik bilan bog'liq tugunlar qo'shilishi mumkin. Har bir shunday master-slave havolasida oddiy replikatsiya ishlaydi. O'qish so'rovlarini masshtablash va master ishlamay qolgan taqdirda uzilish uchun tobelar kerak.

Endi bajara olish yaxshiroq bo'lgan operatsiyalar haqida gapiraylik.

Biz tizimga Redis-CLI orqali kiramiz. Redisda bitta kirish nuqtasi bo'lmagani uchun siz istalgan tugun ustida quyidagi amallarni bajarishingiz mumkin. Har bir nuqtada men yuk ostida operatsiyani bajarish imkoniyatiga alohida e'tibor qarataman.

• Bizga kerak bo'lgan birinchi va eng muhim narsa - bu klaster tugunlarining ishlashi. U klaster holatini qaytaradi, tugunlar ro'yxatini, ularning rollarini, slot taqsimotini va hokazolarni ko'rsatadi. Qo'shimcha ma'lumotni klaster ma'lumotlari va klaster uyalari yordamida olish mumkin.
• Tugunlarni qo'shish va olib tashlash mumkin bo'lsa yaxshi bo'lardi. Shu maqsadda klaster bilan uchrashish va klasterni unutish operatsiyalari mavjud. E'tibor bering, klasterni unutish HAR bir tugunga, ham master, ham replika uchun qo'llanilishi kerak. Va klaster uchrashuvini faqat bitta tugunda chaqirish kerak. Bu farq sizni bezovta qilishi mumkin, shuning uchun klasteringiz bilan jonli efirga chiqishdan oldin bu haqda bilib olganingiz ma'qul. Tugunni qo'shish jangda xavfsiz tarzda amalga oshiriladi va klasterning ishlashiga hech qanday ta'sir qilmaydi (bu mantiqiy). Agar siz klasterdan tugunni olib tashlamoqchi bo'lsangiz, unda hech qanday uyalar qolmaganligiga ishonch hosil qilishingiz kerak (aks holda siz ushbu tugundagi barcha kalitlarga kirish huquqini yo'qotish xavfi mavjud). Bundan tashqari, qullari bo'lgan xo'jayinni o'chirmang, aks holda yangi xo'jayin uchun keraksiz ovoz berish amalga oshiriladi. Agar tugunlarda endi uyalar bo'lmasa, bu kichik muammo, lekin birinchi navbatda qullarni o'chirib tashlasak, nima uchun bizga qo'shimcha tanlov kerak.
• Agar siz asosiy va yordamchi pozitsiyalarni majburan almashtirishingiz kerak bo'lsa, klasterni o'zgartirish buyrug'i bajariladi. Uni jangda chaqirganda, operatsiya vaqtida usta mavjud bo'lmasligini tushunishingiz kerak. Odatda kalit bir soniyadan kamroq vaqt ichida sodir bo'ladi, lekin atomik emas. Bu vaqt ichida ustaga ba'zi so'rovlar muvaffaqiyatsiz bo'lishini kutishingiz mumkin.
• Klasterdan tugunni olib tashlashdan oldin, unda bo'shliqlar qolmasligi kerak. Klaster reshard buyrug'i yordamida ularni qayta taqsimlash yaxshiroqdir. Slotlar bir masterdan ikkinchisiga o'tkaziladi. Butun operatsiya bir necha daqiqa davom etishi mumkin, bu uzatilayotgan ma'lumotlar hajmiga bog'liq, ammo uzatish jarayoni xavfsiz va klasterning ishlashiga hech qanday ta'sir qilmaydi. Shunday qilib, barcha ma'lumotlar bir tugundan boshqasiga to'g'ridan-to'g'ri yuk ostida va uning mavjudligi haqida tashvishlanmasdan o'tkazilishi mumkin. Biroq, nozikliklar ham mavjud. Birinchidan, ma'lumotlarni uzatish qabul qiluvchi va jo'natuvchi tugunlarida ma'lum bir yuk bilan bog'liq. Agar qabul qiluvchi tugun protsessorga allaqachon yuklangan bo'lsa, unda siz uni yangi ma'lumotlarni olish bilan yuklamasligingiz kerak. Ikkinchidan, jo'natuvchi ustada bitta bo'sh joy qolmasa, uning barcha qullari darhol ushbu slotlar o'tkazilgan xo'jayinga boradi. Va muammo shundaki, bu barcha qullar bir vaqtning o'zida ma'lumotlarni sinxronlashtirishni xohlashadi. Va to'liq sinxronizatsiya emas, balki qisman bo'lsa, sizga omad kulib boqadi. Buni hisobga oling va uyalarni o'tkazish va qullarni o'chirish/o'tkazish operatsiyalarini birlashtiring. Yoki sizda etarli xavfsizlik chegarasi borligiga umid qiling.
• Agar o'tkazma paytida biror joyda o'z slotlaringizni yo'qotib qo'yganingizni aniqlasangiz nima qilish kerak? Umid qilamanki, bu muammo sizga ta'sir qilmaydi, lekin agar shunday bo'lsa, klasterni tuzatish operatsiyasi mavjud. Hech bo'lmaganda, u tasodifiy tartibda tugunlar bo'ylab uyalarni tarqatadi. Avval klasterdan taqsimlangan uyalar bilan tugunni olib tashlash orqali uning ishlashini tekshirishni tavsiya etaman. Ajratilmagan slotlardagi ma'lumotlar allaqachon mavjud emasligi sababli, bu slotlarning mavjudligi bilan bog'liq muammolar haqida tashvishlanish juda kech. O'z navbatida, operatsiya taqsimlangan slotlarga ta'sir qilmaydi.
• Yana bir foydali operatsiya - monitor. Bu sizga real vaqt rejimida tugunga kiradigan so'rovlarning to'liq ro'yxatini ko'rish imkonini beradi. Bundan tashqari, siz uni o'rganishingiz va kerakli trafik mavjudligini bilib olishingiz mumkin.

Shuningdek, asosiy o'chirish tartibini eslatib o'tish kerak. Muxtasar qilib aytganda, u mavjud va mening fikrimcha, u ajoyib ishlaydi. Biroq, agar siz asosiy tugunga ega bo'lgan mashinada quvvat simini ajratib qo'ysangiz, Redis darhol o'zgaradi va mijozlar yo'qotishni sezmaydilar deb o'ylamang. Mening amaliyotimda o'tish bir necha soniya ichida sodir bo'ladi. Bu vaqt ichida ba'zi ma'lumotlar mavjud bo'lmaydi: masterning mavjud emasligi aniqlandi, tugunlar yangisiga ovoz beradi, qullar almashtiriladi, ma'lumotlar sinxronlashtiriladi. O'zingiz uchun sxema ishlayotganiga ishonch hosil qilishning eng yaxshi usuli - bu mahalliy mashqlarni o'tkazish. Noutbukdagi klasterni ko'taring, unga minimal yuk bering, avariyani simulyatsiya qiling (masalan, portlarni blokirovka qilish orqali) va o'tish tezligini baholang. Menimcha, bir-ikki kun shu tarzda o'ynaganingizdan keyingina texnologiyaning ishlashiga ishonchingiz komil bo'lishi mumkin. Xo'sh, yoki umid qilamanki, Internetning yarmi foydalanadigan dasturiy ta'minot ishlaydi.

Konfiguratsiya

Ko'pincha, asbob bilan ishlashni boshlashingiz kerak bo'lgan birinchi narsa konfiguratsiyadir va hamma narsa ishlaganda, siz konfiguratsiyaga tegishni ham xohlamaysiz. O'zingizni sozlamalarga qaytishga va ularni diqqat bilan ko'rib chiqishga majburlash uchun biroz harakat talab etiladi. Mening xotiramda, konfiguratsiyaga e'tibor bermaslik tufayli bizda kamida ikkita jiddiy nosozlik bor edi. Quyidagi fikrlarga alohida e'tibor bering:

• tanaffus 0
  Faol bo'lmagan ulanishlar yopilgan vaqt (sekundlarda). 0 - yopmang
  Bizning har bir kutubxonamiz aloqalarni to'g'ri yopa olmadi. Ushbu sozlamani o'chirib qo'yish orqali biz mijozlar soni bo'yicha cheklovga erishish xavfini tug'diramiz. Boshqa tomondan, agar bunday muammo mavjud bo'lsa, yo'qolgan ulanishlarni avtomatik ravishda tugatish uni niqoblaydi va biz buni sezmasligimiz mumkin. Bundan tashqari, doimiy ulanishlardan foydalanganda ushbu sozlamani yoqmasligingiz kerak.
• Xy-ni saqlang va faqat ha
  RDB suratini saqlash.
  Biz quyida RDB/AOF masalalarini batafsil muhokama qilamiz.
• bgsave-da yozishni to'xtatish-xato yo'q va slave-serve-stale-ma'lumotlar ha
  Agar yoqilgan bo'lsa, RDB oniy tasviri buzilgan bo'lsa, master o'zgartirish so'rovlarini qabul qilishni to'xtatadi. Agar usta bilan aloqa uzilgan bo'lsa, qul so'rovlarga javob berishda davom etishi mumkin (ha). Yoki javob berishni to'xtatadi (yo'q)
  Biz Redisning qovoqqa aylangan holatidan mamnun emasmiz.
• repl-ping-qullik davri 5
  Ushbu vaqtdan so'ng, biz usta buzilib ketganidan xavotirlana boshlaymiz va uzilish jarayonini amalga oshirish vaqti keldi.
  Siz noto'g'ri pozitivlar va muvaffaqiyatsizlikni ishga tushirish o'rtasidagi muvozanatni qo'lda topishingiz kerak bo'ladi. Bizning amaliyotimizda bu 5 soniya.
• repl-backlog-hajmi 1024mb va epl-backlog-ttl 0
  Muvaffaqiyatsiz replika uchun buferda aynan shuncha ma'lumotlarni saqlashimiz mumkin. Agar bufer tugasa, siz to'liq sinxronizatsiya qilishingiz kerak bo'ladi.
  Amaliyot shuni ko'rsatadiki, yuqoriroq qiymatni belgilash yaxshiroqdir. Replika ortda qolishi uchun ko'p sabablar mavjud. Agar u kechiksa, ehtimol sizning xo'jayiningiz allaqachon engish uchun kurashmoqda va to'liq sinxronizatsiya so'nggi tomchi bo'ladi.
• maxclients 10000
  Bir martalik mijozlarning maksimal soni.
  Bizning tajribamizga ko'ra, yuqoriroq qiymatni belgilash yaxshiroqdir. Redis 10 ming ulanishni yaxshi boshqaradi. Tizimda yetarlicha rozetkalar mavjudligiga ishonch hosil qiling.
• maxmemory-policy volatile-ttl
  Mavjud xotira chegarasiga erishilganda kalitlar o'chiriladigan qoida.
  Bu erda muhim narsa qoidaning o'zi emas, balki bu qanday sodir bo'lishini tushunishdir. Redisni xotira chegarasiga yetganda normal ishlash qobiliyati uchun maqtash mumkin.

RDB va AOF muammolari

Redisning o'zi barcha ma'lumotlarni operativ xotirada saqlasa ham, diskda ma'lumotlarni saqlash mexanizmi ham mavjud. Aniqroq aytganda, uchta mexanizm:

• RDB-snapshot - barcha ma'lumotlarning to'liq surati. SAVE XY konfiguratsiyasi yordamida sozlang va “Agar hech boʻlmaganda Y tugmalari oʻzgargan boʻlsa, har X soniyada barcha maʼlumotlarning toʻliq suratini saqlang” deb oʻqiladi.
• Faqat qo'shimcha fayl - bajarilish tartibidagi operatsiyalar ro'yxati. Faylga har X soniyada yoki har Y amalda yangi kiruvchi amallarni qo'shadi.
• RDB va AOF oldingi ikkitasining kombinatsiyasi.

Barcha usullarning afzalliklari va kamchiliklari bor, men ularning barchasini sanab o'tmayman, men faqat, mening fikrimcha, aniq bo'lmagan fikrlarga e'tibor qarataman.

Birinchidan, RDB snapshotini saqlash FORK-ga qo'ng'iroq qilishni talab qiladi. Agar ma'lumotlar juda ko'p bo'lsa, bu barcha Redis-ni bir necha millisekunddan bir soniyagacha ushlab turishi mumkin. Bundan tashqari, tizim bunday suratga olish uchun xotirani ajratishi kerak, bu mantiqiy mashinada operativ xotiraning ikki baravar zaxirasini saqlash zarurligiga olib keladi: agar Redis uchun 8 Gb ajratilgan bo'lsa, u holda virtual mashinada 16 Gb bo'lishi kerak. bu.

Ikkinchidan, qisman sinxronizatsiya bilan bog'liq muammolar mavjud. AOF rejimida, qul qayta ulanganda, qisman sinxronizatsiya o'rniga, to'liq sinxronizatsiya amalga oshirilishi mumkin. Nega bu sodir bo'ldi, men tushunolmadim. Ammo buni eslab qolishga arziydi.

Bu ikki nuqta, agar hamma narsa allaqachon qullar tomonidan takrorlangan bo'lsa, diskdagi ushbu ma'lumotlarga haqiqatan ham kerakmi yoki yo'qmi haqida o'ylashga majbur qiladi. Ma'lumotlar faqat barcha qullar ishlamay qolganda yo'qolishi mumkin va bu "DCda yong'in" darajasidagi muammo. Murosaga kelsak, siz ma'lumotlarni faqat qullarda saqlashni taklif qilishingiz mumkin, ammo bu holda siz ushbu qullar ofatni tiklash paytida hech qachon usta bo'lib qolmasligiga ishonch hosil qilishingiz kerak (buning uchun ularning konfiguratsiyasida qul ustuvorligi sozlamalari mavjud). O'zimiz uchun, har bir alohida holatda biz ma'lumotlarni diskka saqlash kerakmi yoki yo'qmi, deb o'ylaymiz va ko'pincha javob "yo'q".

xulosa

Xulosa qilib aytganda, men bu haqda umuman eshitmaganlar uchun redis-klaster qanday ishlashi haqida umumiy fikr bera oldim, deb umid qilaman, shuningdek, undan foydalanganlar uchun noaniq bo'lgan ba'zi fikrlarga e'tibor qaratdim. uzoq vaqt davomida; anchadan beri.
Vaqtingiz uchun rahmat va har doimgidek, mavzu bo'yicha sharhlar qabul qilinadi.

Manba: www.habr.com