Kesh strategiyasi yordamida hal qilingan javob sekinligi muammosi

1. Umumiy ma'lumot

Mening ma'lumotlarim xizmatini boshqarish bilan shug'ullanar ekanman, birinchi uchragan muammo foydalanuvchi soni tez o'sib borganida paydo bo'lgan asosiy ekran javob kechikishi bo'ldi. Xizmat dastlabki paytlarda katta muammo bo'lmagan tuzilma, foydalanuvchilar soni oshgani sayin sezilarli kechikish sifatida yuzaga keldi. Ushbu maqola o'sha paytdagi muammoni qanday aniqlaganimiz, hal qilganimiz va hal etish usulining o'z vaqtida qanday texnik oqimlar bilan bog'liq ekanligini tizimli ravishda muhokama qiladi.

O'sha paytdagi xizmat Vue 2 asosidagi WebApp edi va kesh klientga emas, balki server tomonida amalga oshirilgan edi. Bu jihatdan zamonaviy ma'lumot olish kutubxonalari tomonidan odatda taqdim etiladigan klient xotira keshidan farq qiladi. Shuni ta'kidlash kerakki, 'eski ma'lumotlarni birinchi bo'lib ko'rsatish va fonida yangilash' strategiyasi o'z-o'zidan, hozirgi Vue ekosistemasi TanStack Query (ilgari Vue Query deb atalardi) yoki React ekosistemasi SWR tomonidan standart ravishda taqdim etiladigan Stale-While-Revalidate (keyingi SWR) kesh strategiyasi bilan mohiyatan bir xil yo'nalishda edi. Ushbu maqolada muammoni aniqlashdan hal etishga, qo'llash natijasi va SWR nuqtai nazaridan qayta talqin qilishgacha ko'rib chiqamiz va tendensiyalarni hisobga olmagan holda bir xil xulosaga kelishimizning sabablarini o'rganamiz.

2. Muammo holati: Asosiy ekran javob kechikishi

2-1. Mavjud tuzilma

Mening ma'lumotlarim xizmatining asosiy qiymati foydalanuvchi asosiy ekraniga kirgan zahoti bir nechta moliya muassasalariga ro'yxatga olingan mablag‘ va tranzaksiya ma'lumotlarini bir ekranga to'plash edi. Buning uchun ekran kirish vaqtida faol foydalanuvchilarning ma'lumotlarini real vaqtda ko'rib chiqib, eng so'nggi ma'lumotlarni ko'rsatish usulini qabul qildik. Xizmat dastlabki paytlarda foydalanuvchilar soni kam edi, shuning uchun bu tuzilmada jiddiy muammo yo'q edi va aksincha, 'har doim eng so'nggi ma'lumotlarni ko'rsatadi' degan oddiy va aniq dizayn printsipi afzallik sifatida xizmat qildi.

2-2. Muammo oshkor bo'lgan nuqtalar

Foydalanuvchilar soni oshishi bilan muammo sekin-sekin kashf etila boshladi. Har bir ekran kirishda bir nechta tashqi muassasalarga bir vaqtning o'zida so'rovlarni yuborish strukturasida, bir vaqtning o'zida ulanayotganlar soni oshishi bilan tashqi javob kutish vaqti to'g'ridan-to'g'ri foydalanuvchilar tomonidan seziladigan kechikishga to'planadi. Operatsion monitoring ko'rsatkichlari orqali asosiy ekran kirganidan so'ng ekran ko'rsatilishi uchun sarflangan vaqt foydalanuvchilar soni ko'payganiga proporsional ravishda o'sib borish naqshlarini aniqlash mumkin edi.

Ayniqsa, tashqi muassasalardan ba'zilarining javoblari sekinlashganda, bunday kechikish umumiy ekran yuklash vaqtini uzaytiradigan struktural zaiflik ham ochilganini ko'rdik. 'Har doim eng so'nggi ma'lumotlar' printsipini saqlab qolishga imkon beradigan tuzilma, foydalanuvchilar soni oshib ketganda, xizmatning umumiy sezilarli ish faoliyatiga ta'sir qiluvchi tor joyga aylanib ketdi. Ushbu nuqtada aniq bo'lgan narsa, har bir ekran kirishida 100% eng so'nggi ma'lumotlarni ta'minlaydigan tuzilma va foydalanuvchilar darhol ekranni qabul qilish imkoniyatini bir vaqtning o'zida qondirish qiyinligini aniqlash edi. Ikki xil qiymatdan birini ustuvorlikka qo'yib, dizaynni qayta tuzishimiz kerak edi.

3. Hal qilish strategiyasi: Keshni birinchi joyda renderlash + fon ko'rinishi

3-1. Dizayn printsipi

Muammoni qayta aniqlashda qabul qilingan printsip 'darhol javob' va 'yangilikni ta'minlash' ni bir vaqtning o'zida bitta so'rov ichida emas, balki ikki bosqichga ajratish edi. Ekran kirish nuqtasida eng oxirgi ko'rib chiqilgan va saqlangan ma'lumotni darhol ko'rsatish va undan keyin fonida eng so'nggi ma'lumotni qayta ko'rib chiqib ekranni yangilash usuli. Foydalanuvchilar bo'sh ekran yoki yuklanish holatini uzoq vaqt ko'rish o'rniga hayotiy ma'lumotlarni darhol olishadi va bir oz vaqt farqi bilan eng so'nggi ma'lumotga tabiiy ravishda o'tish tajribasini boshdan kechiradilar.

Ushbu printsipni tadbiq qilish uchun eng so'nggi ko'rib chiqish natijalarini saqlaydigan kesh saqlash joyi va ekran ko'rsatish uchun ma'lumotlarni ko'rish va yangilash maqsadida ko'rishni ajratib ishlov berish imkonini beruvchi asinxron ishlov berish tuzilmasi zarur edi.

3-2. Ishlov berish oqimi

Ishlov berish oqimini pseudokodda jadvalga keltirganimizda quyidagi ko'rinishda bo'ladi.

function 메인화면진입(사용자ID):
  캐시데이터 = 캐시저장소.조회(사용자ID)
 
  if 캐시데이터 존재:
    화면.즉시렌더링(캐시데이터)
  else:
    화면.로딩상태표시()
 
  비동기작업큐.등록(갱신작업, 사용자ID)
  return
 
function 갱신작업(사용자ID):
  최신데이터 = 외부기관조회.전체조회(사용자ID)
  캐시저장소.갱신(사용자ID, 최신데이터)
  if 화면.현재활성상태(사용자ID):
    화면.부분갱신(최신데이터)

Ushbu tuzilmaning asosiy jihati ekran renderlash yo'lini va ma'lumotlarni yangilash yo'lini ajratishidir. Ekran faqat kesh saqlanish joyiga qaraydi va darhol javob beradi, tashqi muassasa so'rovi kabi og'ir vazifalar alohida yo'lda asinxron tarzda ishlanadi va ekran javob vaqtiga ta'sir qilmaydi.

3-3. Xabar navbatini orqali yangilanish ishlarini taqsimlash

Yangilash ishlarini faqatgina asinxron ravishda bajarish yetarli emas edi. Bir vaqtda ko'p foydalanuvchilar ulanishi vaqtida yangilash ishining o'zi bir qancha o'zlashtirilishi natijasida tashqi tashkilotga so'rovlar ko'payishi mumkin edi. Buni yumshatish maqsadida yangilash ishlarini xabarlar navbatiga yuklash va ishchi ma'lum bir ishlov berish hajmiga muvofiq navbatni iste'mol qilish uchun tuzish kerak bo'ldi.

Foydalanuvchi nuqtai nazaridan ekran kirishi paytida darhol kesh ma'lumotlarini olish imkoniga ega bo'lgani uchun navbatni qayta ishlash tezligidan qat'i nazar, sezilarli javob tezligi saqlanib qoldi va tizim nuqtai nazaridan tashqi tashkilotlarga chiqayotgan so'rovlar soni navbat orqali tekislanib, yuklamaning ma'lum bir paytda to'planishi holati kamaydi.

3-4. strukturalar taqqoslash

[Jadval 1] tuzilmani yaxshilashdan oldin va keyin taqqoslash

4. Amalga oshirish natijalari

Tuzilishni yaxshilagandan so'ng eng aniq o'zgarish ekran kirish vaqtida seziladigan kutish vaqtining ancha qisqarishidir. Foydalanuvchilar tashqi tashkilotlarning javob tezligidan qat'i nazar har doim bir xil tezlikda ekranni olishi mumkin bo'ldi va ma'lum tashkilotning javobi sekinlashganda ham, bu ta'sir umumiy ekran yuklanishiga ta'sir o'tkazmadi.

Ishlash nuqtai nazaridan tashqi tashkilotlarga yuborilgan so'rovlar xabarlar qatori orqali tekislanganligi sababli, bir vaqtning o'zida ulanishchilar soni ko'paygan vaqtlarida yangilash jarayoni barqaror amalga oshirildi. Eng muhimi, “yangilikni” rad etmasdan, “yangilikni kafolatlaydigan vaqtni” ekran kirish vaqtidan keyinroq surib qo'yishdir, shuning uchun ma'lumot ishonchliligini va foydalanuvchi tajribasini saqlab qolish mumkin bo'ldi.

5. Hozirda ko'rinadi: SWR naqshiga bog'lanish

5-1. SWR naqshi nima

Stale-While-Revalidate - bu kashfiy etilgan (eski, Stale) ma'lumotlarni birinchi bo'lib qaytarib, bir vaqtda orqa fonda tasdiqlash (Revalidate)ni amalga oshiradigan va tasdiqlash tugagach eng yangi ma'lumotlar bilan almashtiriladigan kesh strategiyasidir. Ushbu strategiyada mexanizm jihatdan uch xil yo'nalish mavjud. Birinchisi HTTP protokol darajasida, Cache-Control: stale-while-revalidate headerini (RFC 5861) brauzer yoki CDN, revers proksi ko'rayotganda avtomatik ravishda keshlangan javobni birinchi bo'lib qaytaradi va orqa fonda qayta tasdiqlaydi. Ikkinchisi qo'llanma darajasida, protokol yoki kutubxonaga tayanmasdan kesh so'rovini va orqa fond yangilash mantiqini backend kodida to'g'ridan-to'g'ri amalga oshirish usuli. Uchinchi daraja esa mijoz kutubxonasi darajasida, TanStack Query yoki SWR.js kabi bir xil strategiyani brauzer xotirasida deklarativ ravishda taqdim etadigan usuldir.

Ushbu misol ushbu uchala yo'nalishdan dasht emas. Protokol yoki kutubxonalarni foydalanmasdan, bir xil strategiyani mustaqil ravishda kodinga o‘tkazish natijasida qiziqish mavjud.

5-2. To'g'ridan-to'g'ri amalga oshirilgan usul va mijoz kutubxonasining amalga oshirilishi bilan solishtirish

Mexanizm qatlamlari turli, lekin “eski ma'lumotlarni birinchi ko'rsatuvchi va orqa fonda yangilaydigan” strategiyani amalga oshirish nuqtai nazaridan taqqoslash quyidagi kabi.

[Jadval 2] Amalga oshirish usullari taqqosi

5-3. Xuddi shu xulosaga kelish sababi

Oʻsha paytda Stale-While-Revalidate degan nom ham, bunday strategiyani standart tarzda taqdim etadigan protokol yoki kutubxonalar mavjudligini ham bilmasdim. Biroq “foydalanuvchilarga darhol koʻrsatadigan maʼlumot” va “aniqlikni kafolatlash zarur bo'lgan maʼlumot” bir vaqtda bir xil usulda qayta ishlash zarur emasligini operatsion maʼlumotlarga qarab his etgan edim va bu tushunchani tuzilishga koʻchirish natijasida harakatlarim nazariyaga mos ravishda kelib chiqdi. Bu yaxshi arxitektura naqshlari ba'zi bir texnologik tendensiyalardan boshlanmasdan, haqiqiy muammolarni aniq ko‘rib chiqish jarayonida mustaqil ravishda qayta kashf etilishi ko‘p hollarda ro‘y berishini ko‘rsatadi deb o‘ylayman.

6. Cheklovlar va savdo-sotiqlar

Bu tuzilishda aniq savdo-sotiqlar ham mavjud edi. Ekranda ko‘rsatiladigan maʼlumot aniqlanishiga ko‘ra, biroz eski (Stale) maʼlumotdir, shuning uchun maʼlumotlarning yangiligi muhim bo‘lgan ekran yoki funksiyalarda uni bevosita qo‘llash qiyin.

Amalda ekranlar bo'yicha ma'lumotlarning xususiyatlariga qarab keshni saqlash vaqtini va yangilanish ustuvorligini boshqacha qo'llash zarur edi. Masalan, aktivlar umumiy summasi kabi tez-tez ko‘rsatiladigan va nisbatan kam o‘zgaradigan maʼlumotlar uchun keshni saqlash vaqtini uzaytirdik, savdo tarixi kabi yangilik muhim bo‘lgan maʼlumotlar uchun esa keshni saqlash vaqtini qisqa qilib, yangilanish ustuvorligini oshirdik. Bu mezonlarni belgilash jarayoni esa alohida tuning ishini talab qildi va bir xil javob emas, maʼlumot maʼnosi bo'yicha alohida qarorlar qabul qilish zarur edi.

7. Ishlatish qoʻllanmasiga joylashish

Bir marotaba tuzilish yaxshilanishi bilan tugamasdan, maʼlumot turlari bo'yicha keshni saqlash va yangilanish ustuvorligi mezonlarini jamoa ichki qoʻllanmasiga tushuntirib qo'ydim. Yangi ekran qo'shilganda, kesh siyosatini boshidan qayta o'ylab chiqmasdan, maʼlumotlarning xususiyatini quyidagi mezonlarga moslashtirib tezda qaror qabul qilish imkoniyatini yaratdik.

[Jadval 3] Maʼlumot turlari bo'yicha keshni boshqarish mezonlari (misol)

Ushbu mezon jadvali oddiy sozlash qiymatlari toʻplami emas, balki “Bu ma'lumot qanchalik tez-tez o‘zgaradi va foydalanuvchilar qanchalik tez yangilanishini kutmoqdalar?” degan savolga birinchi navbatda javob berish va bu javobni kesh siyosatiga olib oʻtgan fikrlash jarayoni jamoa tomonidan baham ko‘rilganidir. Keyinchalik yangi ekranlarni loyihalash bosqichida ushbu jarayondan oʻtish orqali, kesh strategiyasi bir marta muammoni hal qilish emas, balki takroriy ish yuritish mezoni sifatida o‘rnashdi.

8. Yakun

Ushbu tajribani eslarsam, tendensiyalar yoki belgilangan shablonlarni avval o‘rganish va qo‘llash emas, balki operatsiya davomida duch kelgan muammoni aniq ajratish jarayonida yechimga erishdim. Hozirda TanStack Query yoki SWR.js kabi kutubxonalar orqali bir xil strategiyani bir necha qatorda e'lon qiluvchi kod yordamida qo'llash mumkin, lekin undan oldin “Nima uchun bu strategiya zarur?” degan savolni o'ylab ko‘rgan tajriba kutubxonani oddiygina olib foydalanishdan ko‘ra yanada chuqurroq tushuncha berdi.

Yangi vositalarni kiritayotganimizda, o‘sha vosita hal qilayotgan muammoning mohiyatini avvalroq tushunib olsak, tadbiq qamrovi va chuqurligi o'zgacha darajada bo‘lishini yana bir bor tasdiqlagan tajriba.

cryss