On ildən artıqdır ki, inkişaf edən bir məhsula gəldikdə, onda köhnəlmiş texnologiyalar tapmaq heç də təəccüblü deyil. Bəs altı ay ərzində yükü 10 dəfə çox saxlamalı olursan və yıxılmanın qiyməti yüzlərlə dəfə artarsa ​​nə etməli? Bu halda sizə sərin Yüksək Yükləmə Mühəndisi lazımdır. Amma qulluqçu olmadığından problemin həllini mənə həvalə etdilər. Məqalənin birinci hissəsində Redis-dən Redis-klasterə necə keçdiyimizi, ikinci hissədə isə klasterdən istifadəyə necə başlamaq və ondan istifadə edərkən nələrə diqqət etmək barədə məsləhətlər verəcəyəm.

Texnologiya seçimi

Bu qədər pisdir? ayrı Redis (bağımsız redis) 1 master və N qul konfiqurasiyasında? Niyə mən buna köhnəlmiş texnologiya deyirəm?

Xeyr, Redis o qədər də pis deyil... Bununla belə, bəzi nöqsanlar da var ki, onları nəzərdən qaçırmaq olmaz.

• Birincisi, Redis master uğursuzluqdan sonra fəlakətin bərpası mexanizmlərini dəstəkləmir. Bu problemi həll etmək üçün biz VIP-lərin yeni ustaya avtomatik ötürülməsi, kölələrdən birinin rolunu dəyişdirmək və qalanlarını dəyişdirmək ilə bir konfiqurasiyadan istifadə etdik. Bu mexanizm işləyirdi, lakin onu etibarlı həll adlandırmaq olmazdı. Birincisi, yanlış siqnallar meydana gəldi, ikincisi, birdəfəlik idi və əməliyyatdan sonra yayı doldurmaq üçün əl hərəkətləri tələb olundu.

• İkincisi, yalnız bir ustanın olması parçalanma probleminə səbəb oldu. Biz bir neçə müstəqil klaster yaratmalı olduq "1 master və N qul", sonra verilənlər bazalarını bu maşınlar arasında əl ilə paylamaq və ümid edirik ki, sabah verilənlər bazalarından biri o qədər şişməyəcək ki, ayrı bir nümunəyə köçürülməli olacaq.

Seçimlər hansılardır?

• Ən bahalı və ən zəngin həll Redis-Enterprise-dir. Bu, tam texniki dəstəyi olan qutulu bir həlldir. Texniki baxımdan ideal görünməsinə baxmayaraq, ideoloji səbəblərdən bizə uyğun gəlmədi.
• Redis-klaster. Qutudan kənarda master uğursuzluq və parçalanma üçün dəstək var. İnterfeys adi versiyadan demək olar ki, fərqlənmir. Perspektivli görünür, tələlər haqqında sonra danışacağıq.
• Tarantool, Memcache, Aerospike və s. Bütün bu alətlər demək olar ki, eyni şeyi edir. Ancaq hər birinin öz çatışmazlıqları var. Bütün yumurtalarımızı bir səbətə qoymamağa qərar verdik. Memcache və Tarantool-dan digər tapşırıqlar üçün istifadə edirik və irəliyə baxaraq deyim ki, təcrübəmizdə onlarla daha çox problemlər var idi.

İstifadənin spesifikliyi

Gəlin Redis ilə tarixən hansı problemləri həll etdiyimizə və hansı funksionallıqdan istifadə etdiyimizə nəzər salaq:

• 2GIS | kimi uzaq xidmətlərə sorğulardan əvvəl keş Qolanq
  

  GET SET MGET MSET "DB-ni seçin"

• MYSQL-dən əvvəl önbellek | PHP
  

  SET MGET MSET SCAN-ı ALIN "NÜXÜSƏ GÖRƏ DÜŞÜR" "VB SEÇİN"

• Sessiyalar və sürücü koordinatları ilə işləmək üçün əsas saxlama | Qolanq
  

  GET SET MGET MSET "Select DB" "ADD GEO AÇAR" "GET GEO AÇAR" SCAN

Gördüyünüz kimi, ali riyaziyyat yoxdur. Bəs onda çətinlik nədir? Hər bir üsula ayrıca baxaq.

üsul
Təsvir
Redis-klasterin xüsusiyyətləri
qərar

SET ALIN
Yaz/oxu açarı

MGET MSET
Çox düymələri yaz/oxu
Açarlar müxtəlif qovşaqlarda olacaq. Hazır kitabxanalar çoxlu əməliyyatları yalnız bir qovşaq daxilində yerinə yetirə bilər
MGET-i N GET əməliyyatlarının boru kəməri ilə əvəz edin

DB SEÇİN
İşləyəcəyimiz bazanı seçin
Çox verilənlər bazası dəstəkləmir
Hər şeyi bir verilənlər bazasına qoyun. Düymələrə prefikslər əlavə edin

SCAN
Verilənlər bazasındakı bütün açarları keçin
Bir verilənlər bazamız olduğundan, klasterdəki bütün açarlardan keçmək çox bahadır
Bir açar daxilində invariant saxlamaq və bu açarda HSCAN əməliyyatı aparmaq. Və ya tamamilə imtina edin

GEO
Geokey ilə əməliyyatlar
Geokey parçalanmayıb

NƏXİŞƏ GÖRƏ AÇAR
Nümunə ilə açar axtarılır
Bir verilənlər bazamız olduğundan, biz klasterdəki bütün açarları axtaracağıq. Çox baha
SCAN vəziyyətində olduğu kimi invariantdan imtina edin və ya qoruyun

Redis və Redis-klaster

Klasterə keçərkən nə itiririk və nə qazanırıq?

• Dezavantajlar: bir neçə verilənlər bazasının funksionallığını itiririk.
  • Məntiqi əlaqəsi olmayan məlumatları bir klasterdə saxlamaq istəsək, prefikslər şəklində qoltuq dəyənəkləri hazırlamalı olacağıq.
  • SCAN, DBSIZE, CLEAR DB və s. kimi bütün "əsas" əməliyyatları itiririk.
  • Çox əməliyyatları həyata keçirmək daha çətinləşdi, çünki bir neçə qovşağa giriş tələb oluna bilər.
• Artıq:
  • Usta uğursuzluq şəklində nasazlığa dözümlülük.
  • Redis tərəfində parçalanma.
  • Məlumatları qovşaqlar arasında atomik və fasiləsiz ötürün.
  • Tutum və yükləri fasiləsiz əlavə edin və yenidən bölüşdürün.

Mən belə bir nəticəyə gələrdim ki, yüksək səviyyəli nasazlıqlara qarşı dözümlülük təmin etmək lazım deyilsə, o zaman klasterə keçməyə dəyməz, çünki bu, əhəmiyyətsiz bir iş ola bilər. Ancaq əvvəlcə ayrı bir versiya ilə klaster versiyası arasında seçim etsəniz, bir klaster seçməlisiniz, çünki bu, daha pis deyil və əlavə olaraq sizi bəzi baş ağrılarından azad edəcəkdir.

Hərəkət etməyə hazırlaşır

Köçürülmə tələblərindən başlayaq:

• Sorunsuz olmalıdır. Xidmətin 5 dəqiqəlik tam dayandırılması bizə yaraşmır.
• Mümkün qədər təhlükəsiz və tədricən olmalıdır. Mən vəziyyətə bir qədər nəzarət etmək istəyirəm. Biz hər şeyi bir anda atıb geri qaytarma düyməsi üzərində dua etmək istəmirik.
• Hərəkət edərkən minimum məlumat itkisi. Biz başa düşürük ki, atomik şəkildə hərəkət etmək çox çətin olacaq, ona görə də biz müntəzəm və klasterli Redis-də məlumatlar arasında bəzi desinxronizasiyaya icazə veririk.

Klasterə qulluq

Hərəkət etməzdən əvvəl, klasteri dəstəkləyə biləcəyimiz barədə düşünməliyik:

• Qrafiklər. Biz Prometheus və Grafana proqramlarından CPU yükünün qrafikini, yaddaş istifadəsini, müştərilərin sayını, GET, SET, AUTH əməliyyatlarının sayını və s.
• Ekspertiza. Təsəvvür edin ki, sabah sizin məsuliyyətiniz altında böyük bir çoxluq olacaq. Qırarsa, onu sizdən başqa heç kim düzəldə bilməz. O, yavaşlamağa başlasa, hamı sizə tərəf qaçacaq. Resurs əlavə etmək və ya yükü yenidən bölüşdürmək lazımdırsa, sizə qayıdın. 25-də boz rəngə çevrilməmək üçün bu halları təmin etmək və texnologiyanın müəyyən hərəkətlər altında necə davranacağını əvvəlcədən yoxlamaq məsləhətdir. Bu barədə "Ekspertiza" bölməsində daha ətraflı danışaq.
• Monitorinq və xəbərdarlıqlar. Bir klaster pozulduqda, siz bu barədə ilk xəbərdar olmaq istəyirsiniz. Burada biz özümüzü bütün qovşaqların klasterin vəziyyəti haqqında eyni məlumatı qaytardığına dair bildirişlə məhdudlaşdırdıq (bəli, bu fərqli olur). Digər problemlər Redis müştəri xidmətlərindən gələn xəbərdarlıqlarla daha tez aşkar edilə bilər.

Köçmək

Necə hərəkət edəcəyik:

• Klasterlə işləmək üçün ilk növbədə kitabxana hazırlamaq lazımdır. Go-redis-i Go versiyası üçün əsas götürdük və özümüzə uyğunlaşdırmaq üçün onu bir az dəyişdirdik. Biz boru kəmərləri vasitəsilə Multi-metodları tətbiq etdik, həmçinin sorğuların təkrarlanması qaydalarını bir az düzəltdik. PHP versiyasında daha çox problemlər var idi, lakin biz sonda php-redis üzərində qərarlaşdıq. Onlar bu yaxınlarda klaster dəstəyini təqdim etdilər və fikrimizcə yaxşı görünür.
• Sonra klasterin özünü yerləşdirməlisiniz. Bu, konfiqurasiya faylına əsaslanan iki əmrdə sözün həqiqi mənasında edilir. Aşağıda parametr haqqında daha ətraflı danışacağıq.
• Tədricən hərəkət etmək üçün quru rejimdən istifadə edirik. Kitabxananın eyni interfeysə malik iki versiyası (biri adi versiya üçün, digəri klaster üçün) olduğundan, ayrıca versiya ilə işləyəcək və paralel olaraq klasterə bütün sorğuların dublikatını yaradacaq sarğı yaratmaq heç bir xərc tələb etmir, cavabları müqayisə edin və qeydlərə uyğunsuzluqlar yazın (bizim vəziyyətimizdə NewRelic-də). Beləliklə, klaster versiyası buraxılış zamanı pozulsa belə, istehsalımız təsirlənməyəcək.
• Klasteri quru rejimdə yaydıqdan sonra sakitcə cavab uyğunsuzluqlarının qrafikinə baxa bilərik. Səhv dərəcəsi yavaş-yavaş, lakin şübhəsiz ki, kiçik bir sabitə doğru irəliləyirsə, hər şey qaydasındadır. Niyə hələ də uyğunsuzluqlar var? Ayrı bir versiyada qeyd çoxluqdakından bir qədər əvvəl baş verdiyindən və mikrolag səbəbindən məlumatlar fərqli ola bilər. Yalnız uyğunsuzluq qeydlərinə baxmaq qalır və əgər onların hamısı qeydin atomsuzluğu ilə izah olunursa, biz davam edə bilərik.
• İndi quru rejimini əks istiqamətdə dəyişə bilərsiniz. Biz klasterdən yazıb oxuyacağıq və onu ayrıca versiyaya köçürəcəyik. Nə üçün? Növbəti həftə mən klasterin işini müşahidə etmək istərdim. Birdən pik yüklənmədə problemlərin olduğu ortaya çıxarsa və ya biz nəyisə nəzərə almamışıqsa, quru rejim sayəsində həmişə köhnə koda və cari məlumatlara təcili geri qayıdırıq.
• Yalnız quru rejimini söndürmək və ayrıca versiyanı sökmək qalır.

Ekspertiza

Birincisi, klaster dizaynı haqqında qısaca.

Əvvəla, Redis əsas dəyər mağazasıdır. Açar kimi ixtiyari sətirlər istifadə olunur. Rəqəmlər, sətirlər və bütün strukturlar dəyər kimi istifadə edilə bilər. Sonuncuların çoxu var, lakin ümumi quruluşu anlamaq üçün bu bizim üçün vacib deyil.
Düymələrdən sonra növbəti abstraksiya səviyyəsi slotlardır (SLOTS). Hər bir açar 16 slotdan birinə aiddir. Hər yuvanın içərisində istənilən sayda açar ola bilər. Beləliklə, bütün açarlar 383 ayrı-ayrı dəstlərə bölünür.

Sonra, klasterdə N əsas qovşaq olmalıdır. Hər bir qovşaq klasterdəki digər qovşaqlar haqqında hər şeyi bilən ayrıca Redis nümunəsi kimi düşünülə bilər. Hər bir master node bir sıra yuvaları ehtiva edir. Hər bir yuva yalnız bir master node-a aiddir. Bütün yuvalar qovşaqlar arasında paylanmalıdır. Bəzi yuvalar ayrılmayıbsa, onda saxlanılan açarlar əlçatmaz olacaq. Hər bir master nodu ayrıca məntiqi və ya fiziki maşında işə salmağın mənası var. Həm də yadda saxlamaq lazımdır ki, hər bir node yalnız bir nüvədə işləyir və eyni məntiqi maşında birdən çox Redis nümunəsini işə salmaq istəyirsinizsə, onların fərqli nüvələrdə işlədiyinə əmin olun (biz bunu sınamamışıq, amma nəzəri olaraq işləməlidir) . Əsasən, master qovşaqlar müntəzəm parçalanma təmin edir və daha çox master qovşaqları yazma və oxuma sorğularını ölçməyə imkan verir.

Bütün açarlar yuvalar arasında bölüşdürüldükdən və yuvalar əsas qovşaqlar arasında səpələndikdən sonra hər bir master node-a ixtiyari sayda kölə qovşaq əlavə edilə bilər. Hər bir master-slave keçidində normal replikasiya işləyəcək. Oxuma sorğularını miqyaslaşdırmaq və master uğursuzluğu halında əvəzetmə üçün kölələr lazımdır.

İndi edə bilsəydik daha yaxşı olardı əməliyyatlardan danışaq.

Redis-CLI vasitəsilə sistemə daxil olacağıq. Redis-in tək bir giriş nöqtəsi olmadığı üçün qovşaqların hər hansı birində aşağıdakı əməliyyatları yerinə yetirə bilərsiniz. Hər bir nöqtədə ayrıca yük altında əməliyyatın həyata keçirilməsinin mümkünlüyünə diqqət çəkirəm.

• Bizə lazım olan ilk və ən vacib şey klaster qovşaqlarının işləməsidir. O, klasterin vəziyyətini qaytarır, qovşaqların siyahısını, onların rollarını, yuvaların paylanmasını və s. Daha çox məlumatı klaster məlumatı və klaster yuvalarından istifadə etməklə əldə etmək olar.
• Düyünləri əlavə etmək və silmək yaxşı olardı. Bu məqsədlə klaster görüşmə və klaster unutma əməliyyatları mövcuddur. Nəzərə alın ki, klaster unutması HƏR node, həm master, həm də replikalara tətbiq edilməlidir. Və klaster görüşü yalnız bir qovşaqda çağırılmalıdır. Bu fərq narahatedici ola bilər, ona görə də klasterinizlə canlı yayıma çıxmazdan əvvəl bu barədə məlumat əldə etmək daha yaxşıdır. Düyün əlavə edilməsi döyüşdə təhlükəsiz şəkildə həyata keçirilir və klasterin işinə heç bir şəkildə təsir göstərmir (bu məntiqlidir). Əgər qovşağı çoxluqdan silmək niyyətindəsinizsə, onda heç bir yuva qalmadığından əmin olmalısınız (əks halda bu nodedakı bütün düymələrə girişi itirmək riskiniz var). Həmçinin, qulları olan ustanı silməyin, əks halda yeni usta üçün lazımsız səsvermə həyata keçiriləcək. Əgər qovşaqlarda artıq yuva yoxdursa, bu kiçik bir problemdir, amma əvvəlcə qulları silə bilsək, niyə əlavə seçimlərə ehtiyacımız var.
• Əgər master və slave mövqelərini zorla dəyişdirmək lazımdırsa, o zaman klasterin əvəzlənməsi əmri yerinə yetiriləcək. Döyüşdə çağırarkən, əməliyyat zamanı ustanın olmayacağını başa düşməlisiniz. Tipik olaraq keçid bir saniyədən az müddətdə baş verir, lakin atomik deyil. Bu müddət ərzində ustaya edilən bəzi sorğuların uğursuz olacağını gözləmək olar.
• Bir qovşağı çoxluqdan çıxarmazdan əvvəl onun üzərində heç bir yuva qalmamalıdır. Claster reshard əmrindən istifadə edərək onları yenidən bölüşdürmək daha yaxşıdır. Slotlar bir masterdən digərinə köçürüləcək. Bütün əməliyyat bir neçə dəqiqə çəkə bilər, bu, ötürülən məlumatların həcmindən asılıdır, lakin ötürmə prosesi təhlükəsizdir və heç bir şəkildə klasterin işinə təsir göstərmir. Beləliklə, bütün məlumatlar bir qovşaqdan digərinə birbaşa yük altında və mövcudluğundan narahat olmadan ötürülə bilər. Bununla belə, incəliklər də var. Birincisi, məlumat ötürülməsi alıcı və göndərici qovşaqlarında müəyyən bir yüklə əlaqələndirilir. Əgər alıcı node artıq prosessora çox yüklənibsə, onda siz onu yeni məlumatların qəbulu ilə yükləməməlisiniz. İkincisi, göndərən ustada bir dənə də olsun yuva qalmayan kimi, onun bütün qulları dərhal bu yuvaların köçürüldüyü ustaya gedəcək. Problem ondadır ki, bütün bu qullar məlumatları bir anda sinxronlaşdırmaq istəyəcəklər. Və tam sinxronizasiya deyil, qismən olsa, şanslı olacaqsınız. Bunu nəzərə alın və yuvaların ötürülməsi və qulların söndürülməsi/ötürülməsi əməliyyatlarını birləşdirin. Və ya kifayət qədər təhlükəsizlik marjanız olduğuna ümid edin.
• Köçürmə zamanı haradasa slotlarınızı itirdiyinizi görsəniz nə etməlisiniz? Ümid edirəm ki, bu problem sizə təsir etməyəcək, lakin əgər varsa, klaster düzəltmə əməliyyatı var. Ən azı, o, təsadüfi qaydada yuvaları qovşaqlar arasında səpələyəcək. Əvvəlcə paylanmış yuvaları olan qovşağı çoxluqdan çıxararaq onun işini yoxlamağı məsləhət görürəm. Ayrılmamış yuvalardakı məlumatlar artıq əlçatmaz olduğundan, bu yuvaların mövcudluğu ilə bağlı problemlər barədə narahat olmaq çox gecdir. Öz növbəsində əməliyyat paylanmış yuvalara təsir etməyəcək.
• Başqa bir faydalı əməliyyat monitordur. Bu, real vaxt rejimində node-a gedən sorğuların bütün siyahısını görməyə imkan verir. Üstəlik, onu araşdırıb lazımi trafikin olub olmadığını öyrənə bilərsiniz.

Usta uğursuzluq prosedurunu da qeyd etmək lazımdır. Bir sözlə, o, mövcuddur və mənim fikrimcə, əla işləyir. Ancaq düşünməyin ki, elektrik kabelini əsas qovşağı olan bir maşından çıxarsanız, Redis dərhal dəyişəcək və müştərilər itkini görməyəcəklər. Mənim praktikamda keçid bir neçə saniyə ərzində baş verir. Bu müddət ərzində bəzi məlumatlar əlçatan olmayacaq: masterin əlçatmazlığı aşkar edilir, qovşaqlar yenisinə səs verir, kölələr dəyişdirilir, məlumatlar sinxronlaşdırılır. Özünüz üçün sxemin işlədiyinə əmin olmağın ən yaxşı yolu yerli məşqlər etməkdir. Laptopunuzdakı klasteri qaldırın, ona minimum yük verin, qəzanı simulyasiya edin (məsələn, portları bloklamaqla) və keçid sürətini qiymətləndirin. Məncə, yalnız bir-iki gün bu şəkildə oynadıqdan sonra texnologiyanın işinə arxayın olmaq olar. Yaxşı, və ya ümid edirik ki, İnternetin yarısının istifadə etdiyi proqram yəqin ki, işləyir.

Konfiqurasiya

Çox vaxt alətlə işə başlamaq üçün ilk növbədə konfiqurasiya lazımdır və hər şey işlədikdə konfiqurasiyaya toxunmaq belə istəmirsiniz. Özünüzü parametrlərə qayıtmağa və onları diqqətlə keçməyə məcbur etmək bir qədər səy tələb edir. Yaddaşımda konfiqurasiyaya diqqətsizlik səbəbindən ən azı iki ciddi uğursuzluq yaşadıq. Aşağıdakı məqamlara xüsusi diqqət yetirin:

• 0 zamanaşımı
  Qeyri-aktiv əlaqələrin bağlandığı vaxt (saniyələrlə). 0 - bağlamayın
  Bizim hər kitabxanamız əlaqələri düzgün bağlaya bilmirdi. Bu ayarı deaktiv etməklə biz müştərilərin sayı limitinə çatmaq riskimiz var. Digər tərəfdən, əgər belə bir problem varsa, o zaman itirilmiş əlaqələrin avtomatik dayandırılması onu maskalayacaq və biz fərqinə varmaya bilərik. Bundan əlavə, davamlı bağlantılardan istifadə edərkən bu parametri aktivləşdirməməlisiniz.
• Xy-i saxla və əlavə olaraq bəli
  RDB snapshot saxlanır.
  RDB/AOF məsələlərini aşağıda ətraflı müzakirə edəcəyik.
• stop-writes on-bgsave-error no & slave-serve-stale-data bəli
  Aktiv edilərsə, RDB snapshot pozularsa, master dəyişiklik sorğularını qəbul etməyi dayandıracaq. Usta ilə əlaqə kəsilərsə, qul sorğulara cavab verməyə davam edə bilər (bəli). Və ya cavab verməyi dayandıracaq (yox)
  Redisin balqabağa çevrilməsi bizi qane etmir.
• repl-ping-qulluq dövrü 5
  Bu müddətdən sonra ustanın xarab olmasından narahat olmağa başlayacağıq və uğursuzluq prosedurunu yerinə yetirməyin vaxtı gəldi.
  Yanlış pozitivlər və uğursuzluğa səbəb olmaq arasında tarazlığı əl ilə tapmalı olacaqsınız. Təcrübəmizdə bu 5 saniyədir.
• repl-backlog-ölçüsü 1024mb & epl-backlog-ttl 0
  Uğursuz replika üçün tam bu qədər məlumatı buferdə saxlaya bilərik. Bufer bitərsə, siz tam sinxronizasiya etməli olacaqsınız.
  Təcrübə göstərir ki, daha yüksək dəyər təyin etmək daha yaxşıdır. Replikanın gecikməyə başlamasının bir çox səbəbi var. Əgər geridə qalırsa, çox güman ki, ustanız artıq öhdəsindən gəlmək üçün mübarizə aparır və tam sinxronizasiya son damla olacaq.
• maksimum müştəri 10000
  Birdəfəlik müştərilərin maksimum sayı.
  Təcrübəmizə görə, daha yüksək dəyər təyin etmək daha yaxşıdır. Redis 10k əlaqəni yaxşı idarə edir. Sadəcə sistemdə kifayət qədər yuva olduğundan əmin olun.
• maxmemory-policy volatile-ttl
  Mövcud yaddaş limitinə çatdıqda düymələrin silinməsi qaydası.
  Burada vacib olan qaydanın özü deyil, bunun necə baş verəcəyini anlamaqdır. Redis yaddaş limitinə çatdıqda normal işləmək qabiliyyətinə görə təriflənə bilər.

RDB və AOF problemləri

Redis özü bütün məlumatları RAM-da saxlasa da, verilənlərin diskdə saxlanması mexanizmi də mövcuddur. Daha doğrusu, üç mexanizm:

• RDB-snapshot - bütün məlumatların tam snapshot. SAVE XY konfiqurasiyasından istifadə edərək təyin edin və “Əgər ən azı Y düymələri dəyişibsə, hər X saniyədə bütün məlumatların tam şəklini yadda saxlayın” yazısını oxuyun.
• Yalnız əlavə fayl - yerinə yetirilən ardıcıllıqla əməliyyatların siyahısı. Fayla hər X saniyədə və ya hər Y əməliyyatında yeni daxil olan əməliyyatlar əlavə edir.
• RDB və AOF əvvəlki ikisinin birləşməsidir.

Bütün metodların öz üstünlükləri və mənfi cəhətləri var, hamısını sadalamayacağam, sadəcə olaraq, fikrimcə, aşkar olmayan məqamlara diqqət çəkəcəyəm.

Birincisi, RDB snapshotını saxlamaq FORK-a zəng etməyi tələb edir. Çox məlumat varsa, bu, bütün Redisləri bir neçə millisaniyədən bir saniyəyə qədər saxlaya bilər. Bundan əlavə, sistem belə bir snapshot üçün yaddaş ayırmalıdır ki, bu da məntiqi maşında ikiqat RAM ehtiyatının saxlanmasına səbəb olur: Redis üçün 8 GB ayrılıbsa, virtual maşında 16 GB mövcud olmalıdır. o.

İkincisi, qismən sinxronizasiya ilə bağlı problemlər var. AOF rejimində, qul yenidən qoşulduqda, qismən sinxronizasiya əvəzinə, tam sinxronizasiya həyata keçirilə bilər. Niyə belə olur, anlaya bilmədim. Ancaq bunu xatırlamağa dəyər.

Bu iki məqam, hər şey artıq qullar tərəfindən təkrarlanırsa, diskdə bu məlumatlara həqiqətən ehtiyacımız olub olmadığı barədə bizi düşünməyə vadar edir. Məlumat yalnız bütün qullar uğursuz olarsa itirilə bilər və bu, “DC-də yanğın” səviyyəli problemdir. Kompromis olaraq, məlumatların yalnız qullarda saxlanmasını təklif edə bilərsiniz, lakin bu halda əmin olmalısınız ki, bu qullar fəlakətin bərpası zamanı heç vaxt usta olmayacaq (bunun üçün onların konfiqurasiyasında qul prioriteti var). Özümüz üçün hər bir konkret halda məlumatları diskdə saxlamağın lazım olub-olmadığını düşünürük və əksər hallarda cavab "yox" olur.

Nəticə

Sonda ümid edirəm ki, redis-klasterin bu barədə ümumiyyətlə eşitməyənlər üçün necə işlədiyi barədə ümumi fikir verə bildim və bundan istifadə edənlər üçün bəzi qeyri-aşkar məqamlara diqqət çəkdim. uzun müddətə.
Vaxt ayırdığınız üçün təşəkkür edirik və həmişə olduğu kimi, mövzu ilə bağlı şərhlər qəbul olunur.

Mənbə: www.habr.com