Əvvəl istifadəçinin işini dəqiqləşdir
Onlayn kurs platforması qururuq: istifadəçi kurslara baxır, dərs açır və irəliləyişini saxlayır. Bunlar eyni yük deyil. Kataloq səhifəsi cache-dən göstərilə bilər; irəliləyiş yazısını itirmək isə istifadəçinin gördüyü nəticəni dəyişir.
İlk görüşdə dörd şeyi soruş: gündə neçə aktiv istifadəçi var, hər biri nə qədər sorğu yaradır, pik vaxt nə vaxtdır və hansı nəticənin gecikməsi və ya itməsi qəbul edilmir. Video fayllarını API serverindən ötürəcəyimizi avtomatik fərz etmə: onların trafik modeli ayrıca hesablanmalıdır.
Bu qeyddəki rəqəmlər tədris ssenarisinin fərziyyələridir, production göstəricisi deyil. Hesabın məqsədi dəqiq proqnozdan əvvəl səhv ölçü sırasını tutmaqdır.
Gündəlik istifadəçidən saniyəlik sorğuya
100 000 gündəlik aktiv istifadəçinin hər biri 20 API sorğusu yaradırsa:
Gündəlik sorğu = 100 000 × 20 = 2 000 000
Orta RPS = 2 000 000 / 86 400 ≈ 23,1
Pik RPS = 23,1 × 5 ≈ 115,7
5 qat pik bu ssenari üçün seçdiyimiz fərziyyədir. Qeydiyyat açılışı və ya canlı dərs zamanı paylanma tamam başqa ola bilər. Orta göstəriciyə görə server seçib piki nəzərə almamaq ən asan hesablama səhvlərindən biridir.
Vizualda cache yalnız oxuma sorğularını azaldır. Yazılar yenə bazaya gedir. Hər cache miss və hər yazı üçün bir DB əməliyyatı fərz edirik; real endpoint bir neçə sorğu işlədə bilər.
Cache bazanın yükünü nə qədər azaldır?
100% cache hit olsa belə, yazılar bazaya gedir. 100.000 istifadəçi üçün gündə 2.000.000 API sorğusu fərz edilir.
Hər istifadəçi: 20 sorğu/gün · pik: ortanın 5 qatı · 90% oxuma, 10% yazı · hər miss/yazı: 1 DB əməliyyatı. Bu, tutum zəmanəti deyil; ölçmə ilə yoxlanan təxmini hesabdır.Saxlanma həcmini trafiklə qarışdırma
Tutaq ki, gündə 2 milyon sorğunun 10%-i 1 KB-lıq irəliləyiş hadisəsi yaradır. Xam artım gündə təxminən 200 MB, 30 gündə 6 GB edir. Bu hesabda KB və GB onluq vahidlərdir.
İndekslər, replikalar, backup və metadata bu rəqəmə daxil deyil. Məsələn, üç nüsxə saxlamaq təkcə xam məlumat üçün 18 GB deməkdir; onu yekun disk tələbi kimi qəbul etmə. Hadisələri 30 gün, yoxsa illərlə saxlayacağımız da dizayn qərarıdır.
Video üçün ayrıca hesab apar: 1 000 eyni vaxtlı izləyici hər biri 2 Mbit/s alırsa, çıxış trafiki 2 Gbit/s-dir. Bu, API sorğu sayından çıxmır. Video paylanmasını obyekt anbarı və CDN üzərindən planlamağın səbəbi burada görünür.
Cache nəyi azaldır, nəyi həll etmir?
Kurs kataloqu tez oxunur, nisbətən az dəyişir. Cache-aside modelində tətbiq əvvəl cache-ə baxır; məlumat yoxdursa bazadan oxuyub cache-ə qoyur. Bu, bahalı oxumanı azalda bilər, amma məlumatın nə vaxt köhnə sayılacağını müəyyənləşdirməlisən.
Qiymət yenilənəndə TTL bitənə qədər köhnə qiymət göstərmək olarmı? Kurs alışı zamanı qiyməti serverdə authoritative mənbədən yenidən yoxlamaq lazımdır. Cache-də gördüyün dəyəri ödənişin yekun həqiqəti hesab etmə.
Populyar açarın vaxtı eyni anda bitərsə, çox sorğu bazaya keçə bilər. TTL-ləri paylamaq, eyni açar üçün paralel doldurmaları birləşdirmək və uyğun hallarda köhnə dəyəri müvəqqəti göstərmək variantlarını müqayisə et. Cache-in əlçatmaz olduğu ssenarini də yük testinə daxil et.
Növbə işi yox etmir, vaxtını dəyişir
Dərs tamamlananda istifadəçiyə təsdiq göstərmək üçün email göndərişinin bitməsini gözləmək lazım deyil. Hadisəni etibarlı qəbul edib ayrıca worker ilə göndərmək olar. Amma növbədə yığılan işin sayı və ən köhnə işin yaşı görünməlidir.
Təkrar çatdırılma gözlənilirsə, consumer eyni hadisəni ikinci dəfə alanda təhlükəsiz işləməlidir. Sadəcə processed=true yazmaqla xarici email və ya ödəniş əməliyyatını atomik etmiş olmursan; sərhəddə hansı zəmanətin olduğunu dəqiqləşdir.
Növbənin qəbul sürəti emal sürətindən uzun müddət yüksəkdirsə, backlog böyüyəcək. Worker sayını artırmaq yalnız asılı bazada və xarici servisdə kifayət qədər resurs olduqda kömək edir.
Əvvəl darboğazı göstər, sonra komponent seç
| Ölçülən problem | Yoxlanacaq ilk addım | Yeni risk |
|---|---|---|
| Bir SQL sorğusu yavaşdır | Plan, indeks və qaytarılan sətir sayı | İndeks yazını və diski bahalaşdırır |
| Eyni məlumat tez-tez oxunur | Uyğun TTL ilə cache | Köhnə nəticə, cache miss sıçrayışı |
| Tətbiqin CPU-su dolur | Profil və horizontal scale | Session və ortaq vəziyyət |
| Oxuma primary-ni yükləyir | Sorğu optimizasiyası, sonra replika | Replication lag |
| Bir cədvəl davamlı limitə çatır | Giriş modelinə uyğun bölüşdürmə | Hot partition və cross-partition sorğuları |
Tətbiq instansiyasını üç dəfə artırmaq DB connection limitini də üç dəfə artıra bilər. Hər instansiyada 30 connection varsa, 10 instansiya 300 connection istəyəcək. Miqyaslanan hissənin qonşusuna nə etdiyini də hesabla.
Dizaynı bir kiçik sınaqla yoxla
Bir endpoint seç, giriş məlumatını və yük profilini yaz. Əvvəl adi trafiki, sonra piki, sonra bir asılılığın yavaşlamasını sına. Gecikmə, xəta, saturation və biznes nəticəsini birlikdə ölç.
Hesab cədvəlinin yanında fərziyyələri saxla: aktiv istifadəçi, sorğu sayı, pik əmsalı, oxuma nisbəti, cavab ölçüsü və retention. Ölçmə fərqli nəticə verəndə rəqəmi dəyiş, bütün dizaynı kor-koranə müdafiə etmə.
Müsahibədə yaxşı cavab “Redis və Kafka əlavə edərdim” ilə bitmir. Hansı yükü azaltdığını, hansı yeni nasazlığı yaratdığını və işlədiyini necə anlayacağını göstərə bilmək lazımdır.