Crocusoft | Redis və Caching Nədir? Sayt Niyə Yavaşlayır və Necə Sürətləndirmək Olar
Redis cache sxemi: istifadəçi sorğusu cache-dən və verilənlər bazasından cavablanır
Texnologiya 5 MIN READ 14.10.2026 11:36:33

Redis və Caching Nədir? Sayt Niyə Yavaşlayır və Necə Sürətləndirmək Olar

Yeni sayt hazırlanıb, ilk günlər hər şey sürətli işləyir. Sonra istifadəçi sayı artır, kampaniya başlayır, trafik qalxır və birdən səhifələr üç-dörd saniyəyə açılmağa başlayır. Komanda serveri gücləndirir, bir az kömək edir, amma problem bir həftə sonra yenidən qayıdır. Tanış gəlir?

Çox vaxt səbəb serverin zəifliyi olmur. Sistem eyni işi dəfələrlə təkrar görür. Eyni məhsul siyahısı hər istifadəçi üçün verilənlər bazasından yenidən çəkilir, eyni hesablama hər sorğuda yenidən aparılır. Caching məhz bu təkrarı aradan qaldırmaq üçündür, Redis isə bu işdə ən çox istifadə olunan alətdir.

Caching Nədir?

Caching, tez-tez lazım olan nəticəni bir dəfə hazırlayıb sürətli yerdə saxlamaq və növbəti dəfə yenidən hazırlamaq əvəzinə oradan götürməkdir.

Gündəlik həyatdan nümunə verək. Hər səhər çay içirsiniz. Hər dəfə çayı sıfırdan çəkmək əvəzinə termosa doldurub masanın üstünə qoyursunuz. Termos cache-dir: çay artıq hazırdır, əlinizin altındadır, mətbəxə getməyə ehtiyac yoxdur. Mətbəx isə verilənlər bazasıdır: nəticə orada da var, amma ora getmək daha çox vaxt aparır.

Sayt Niyə Yavaşlayır?

Yavaşlamanın səbəbləri müxtəlifdir, amma ən çox rast gəlinənlər bunlardır:

  • Verilənlər bazasına həddindən artıq sorğu: Hər səhifə açılışında onlarla sorğu göndərilir, trafik artanda baza bunu çəkə bilmir.
  • Ağır hesablamalar: Hesabat, filtr nəticələri, qiymət hesablaması kimi əməliyyatlar hər dəfə yenidən aparılır.
  • Xarici API-lərə asılılıq: Valyuta məzənnəsi, çatdırılma qiyməti və ya ödəniş statusu üçün hər sorğuda kənar servisə müraciət olunur.
  • Böyük fayllar: Şəkillər, skriptlər və stil faylları optimallaşdırılmayıb.
  • Eyni məlumatın təkrar çəkilməsi: Dəyişməyən məlumat hər istifadəçi üçün yenidən hazırlanır.

Bunların bir çoxunun həlli eynidir: nəticəni yadda saxlamaq. Burada isə sual yaranır, harada saxlamaq?

Redis Nədir?

Redis məlumatı birbaşa operativ yaddaşda (RAM) saxlayan açıq mənbəli sistemdir. Verilənlər bazası məlumatı adətən diskdə saxlayır, disk isə yaddaşdan xeyli yavaşdır. Redis isə hər şeyi yaddaşda saxladığı üçün cavab müddəti çox qısadır, adətən millisaniyələrlə ölçülür.

Redis açar və dəyər prinsipi ilə işləyir. Siz bir açar verirsiniz (məsələn, mehsullar:populyar), onun qarşısında nəticəni saxlayırsınız. Növbəti sorğuda eyni açarla müraciət edəndə cavab dərhal gəlir.

Cache Necə İşləyir? Sadə Ssenari

Ən çox istifadə olunan yanaşma belədir:

  1. İstifadəçi populyar məhsullar səhifəsini açır.
  2. Sistem əvvəlcə Redis-ə baxır: bu nəticə varmı?
  3. Varsa, dərhal qaytarır. Verilənlər bazasına müraciət etmir.
  4. Yoxdursa, verilənlər bazasından alır, Redis-ə yazır və istifadəçiyə qaytarır.
  5. Növbəti istifadəçilər artıq hazır nəticəni alır.

Sadə şəkildə bu məntiq belə görünür:

nəticə = redis.al("mehsullar:populyar")
 
əgər nəticə yoxdursa:
    nəticə = baza.sorğu("populyar məhsullar")
    redis.yaz("mehsullar:populyar", nəticə, müddət=5 dəqiqə)
 
qaytar nəticə

Burada "müddət" vacib detaldır. Cache-də saxlanan məlumat sonsuza qədər qalmır, müəyyən vaxtdan sonra silinir və növbəti sorğuda yenidən hazırlanır. Buna TTL deyilir.

Redis Harada İstifadə Olunur?

İstifadə sahəsiNümunə
Səhifə və sorğu nəticələrinin cache-iPopulyar məhsullar, kateqoriya siyahısı, xəbər lenti
Session saxlamaİstifadəçinin daxil olmuş vəziyyəti, səbət məlumatı
Rate limitingBir istifadəçinin dəqiqədə göndərə biləcəyi sorğu sayını məhdudlaşdırmaq
Növbə və sürətli hesablamaBildiriş növbəsi, reytinq cədvəli, sayğaclar
Müvəqqəti kodlarSMS təsdiq kodu, bir dəfəlik link

Rate limiting mövzusu təhlükəsizliklə də bağlıdır. Bu barədə API təhlükəsizliyi yazımızda ətraflı danışmışdıq.

Redis Olmadan Caching Mümkündürmü?

Bəli. Cache yalnız Redis demək deyil, bir neçə səviyyədə işləyir:

  • Brauzer cache-i: Şəkillər, stil və skript faylları istifadəçinin brauzerində saxlanır, hər dəfə yenidən yüklənmir.
  • CDN cache-i: Statik fayllar istifadəçiyə coğrafi olaraq yaxın serverdən verilir.
  • Tətbiq daxili cache: Proqramın öz yaddaşında saxlanan kiçik nəticələr. Sadədir, amma bir neçə serverdə işləyəndə hər serverin cache-i ayrı olur.
  • Paylaşılan cache (Redis): Bütün serverlər eyni cache-dən istifadə edir.

Kiçik layihə üçün çox vaxt brauzer cache-i və CDN kifayət edir. Redis o zaman lazım olur ki, dinamik məlumat çoxdur, trafik artıb və sistem bir neçə serverdə işləyir.

Cache-in Ən Çətin Hissəsi: Köhnəlmiş Məlumat

Proqramçılar arasında məşhur bir deyim var: kompüter elmində iki çətin məsələ var, biri də cache-in nə vaxt silinməsidir. Bu zarafatın arxasında real problem dayanır.

Tutaq ki, məhsulun qiyməti dəyişdi, amma cache-də köhnə qiymət qalıb. İstifadəçi köhnə qiyməti görür, sifariş verir. Bu artıq sürət problemi yox, biznes problemidir. Buna görə cache strategiyası aşağıdakı suallara cavab verməlidir:

  • Bu məlumat nə qədər tez-tez dəyişir? Seyrək dəyişirsə, uzun TTL verilə bilər.
  • Köhnə məlumat göstərmək nə qədər təhlükəlidir? Bloq yazısı üçün bir neçə dəqiqə gecikmə normaldır, qiymət və stok üçün isə yox.
  • Məlumat dəyişəndə cache-i necə yeniləyəcəyik? Ən təhlükəsiz yol dəyişiklik anında müvafiq cache açarını silməkdir.

Nəyi Cache Etmək Olar, Nəyi Yox?

Cache etmək üçün yaxşı namizədlər: az dəyişən, çox oxunan məlumat. Kateqoriya siyahısı, populyar məhsullar, ana səhifə bloku, məzənnə, tənzimləmə parametrləri.

Ehtiyatla yanaşmaq lazım olanlar: hər istifadəçiyə fərqli göstərilən məlumat, stok sayı, ödəniş statusu, balans. Bunları cache etmək mümkündür, amma yenilənmə qaydası çox dəqiq düşünülməlidir.

Cache etməməli olanlar: həssas məlumat (parol, kart məlumatı), hər dəfə dəqiq olmalı olan maliyyə əməliyyatları.

Cache İşləyirmi? Necə Yoxlamaq Olar?

Cache qurmaq yarım işdir, işlədiyini ölçmək lazımdır. Əsas göstərici cache hit nisbətidir: sorğuların neçə faizi cache-dən cavablanıb. Bu rəqəm aşağıdırsa, ya TTL çox qısadır, ya da yanlış məlumat cache edilir.

Bundan əlavə cavab müddətinə, verilənlər bazasının yüklənməsinə və Redis-in özünün yaddaş istifadəsinə baxmaq lazımdır. Bunlar üçün monitoring qurulmayıbsa, monitoring və logging yazımız yaxşı başlanğıc ola bilər.

Mikroservis və Kubernetes Mühitində Redis

Sistem mikroservis arxitekturası ilə qurulubsa, Redis çox vaxt servislər arasında paylaşılan sürətli yaddaş rolunu oynayır. Məsələn, bir servis sessiyanı yazır, digəri oxuyur.

Redis-i Kubernetes Cluster-ində işlədəndə iki məqamı unutmaq olmaz. Birincisi, Pod yenidən başlayanda yaddaşdakı məlumat itə bilər, buna görə Redis-in cache kimi, yəni itirilməsi fəlakət olmayan məlumat üçün istifadəsi daha təhlükəsizdir. İkincisi, kritik məlumat saxlanırsa, persistence və ehtiyat nüsxə (replica) qurulmalıdır.

Ən Çox Edilən Səhvlər

  • Hər şeyi cache etmək: Cache mürəkkəbliyi artırır. Yalnız real yük yaradan yerləri hədəfləyin.
  • TTL təyin etməmək: Məlumat sonsuza qədər qalır, yaddaş dolur, köhnə nəticə göstərilir.
  • Cache-i yeganə həqiqət mənbəyi saymaq: Əsas məlumat həmişə verilənlər bazasında olmalıdır. Cache sadəcə sürətləndiricidir.
  • Redis-ə qoruma qoymamaq: Parolsuz və açıq şəbəkəyə çıxarılmış Redis ciddi təhlükəsizlik riskidir.
  • Problemin əsl səbəbini axtarmamaq: Yavaş sorğunun indeksi yoxdursa, cache onu gizlədir, düzəltmir. Əvvəl sorğunun özünü optimallaşdırın.
  • Cache boş qalanda yaranan yükü nəzərə almamaq: Cache birdən silinəndə bütün sorğular eyni anda verilənlər bazasına gedə bilər. Böyük trafikli sistemdə bu ciddi problem yaradır.

Necə Başlamaq Olar?

  1. Əvvəlcə ölçün: ən yavaş səhifələr və ən ağır sorğular hansılardır?
  2. Sorğunun özünü optimallaşdırın (indeks, lazımsız sorğuların azaldılması).
  3. Brauzer cache-i və CDN-i düzgün tənzimləyin.
  4. Ən çox oxunan və az dəyişən bir-iki nəticəni Redis-ə köçürün.
  5. TTL və yeniləmə qaydasını müəyyən edin.
  6. Cache hit nisbətini və cavab müddətini izləyin.
  7. Nəticə yaxşıdırsa, tədricən digər yerlərə genişləndirin.

Ağır yük altında işləyən və ya mürəkkəb məlumat axını olan layihələrdə cache strategiyasını arxitektura mərhələsində planlamaq sonradan düzəltməkdən xeyli sərfəlidir. Bu cür qərarlar adətən fərdi proqram təminatı layihələrində ilkin dizaynın tərkib hissəsi olur.

Tez-tez Verilən Suallar

Redis verilənlər bazasını əvəz edə bilərmi?
Adətən yox. Redis yaddaşda işlədiyi üçün sürətlidir, amma böyük həcmli və uzunmüddətli məlumat üçün klassik verilənlər bazası daha uyğundur. Redis çox vaxt onun yanında köməkçi kimi istifadə olunur.

Kiçik sayt üçün Redis lazımdır?
Çox vaxt yox. Əvvəl brauzer cache-i, CDN və sorğu optimallaşdırması kifayət edir. Redis trafik və dinamik məlumat artanda məna kəsb edir.

Cache sayta SEO baxımından təsir edirmi?
Dolayı yolla bəli. Saytın sürəti istifadəçi təcrübəsinə və axtarış nəticələrinə təsir edən faktorlardandır. Cache cavab müddətini azaldırsa, bu faydalıdır.

Redis-də məlumat itə bilərmi?
Bəli, xüsusilə yenidən başlama zamanı. Buna görə orada itirilməsi fəlakət olmayan məlumat saxlamaq daha etibarlıdır, kritik məlumat üçün isə persistence tənzimlənməlidir.

Cache-i nə vaxt silmək lazımdır?
Məlumat dəyişəndə. Ən təhlükəsiz yol dəyişiklik anında müvafiq açarı silməkdir, bununla yanaşı TTL ehtiyat tədbiri kimi saxlanılır.

Nəticə

Sayt yavaşlayanda ilk reaksiya adətən serveri gücləndirmək olur. Amma çox vaxt problem gücün azlığında yox, eyni işin təkrar-təkrar görülməsindədir. Caching bu təkrarı aradan qaldırır, Redis isə dinamik məlumat üçün bunu ən praktik yollardan biri edir. Əsas qayda sadədir: əvvəl ölçün, sonra lazım olan yeri cache edin, köhnəlmiş məlumat riskini isə əvvəlcədən düşünün.

Saytınızın və ya sisteminizin sürət problemini birlikdə araşdırmaq istəyirsinizsə, Crocusoft komandası ilə əlaqə saxlayın. Əvvəlcə darboğazın harada olduğunu tapaq, sonra uyğun həlli seçək.