1. Kirish
Korxona xizmatlarida foydalanuvchi huquqlarini boshqarish juda muhim funksiyalardan biridir. Foydalanuvchi tizimga kirgandan so'ng, qaysi menyu ko'rinishi, qanday funksiyalarni ishlatishi va qaysi ma'lumotlarga kirishi mumkinligi barchasi huquqlar ma'lumotlariga asoslanadi.
Davom etayotgan xizmat ham foydalanuvchi huquqlariga ko'ra ko'rinadigan menyular farqlanadigan strukturaga ega edi. Boshqaruvchi alohida boshqaruv sahifasi orqali foydalanuvchi yoki rollar (Role) bo'yicha menyu huquqlarini belgilashi mumkin. Foydalanuvchi tizimga kirganda, ushbu huquq ma'lumotlari asosida kirish mumkin bo'lgan menyu shakllanadi va ekranda taqdim etiladi.
Bunday huquq boshqarish funksiyasi xizmatni boshqarishda zarur bo'lsa-da, amalga oshirish usuliga qarab tizim samaradorligi va texnik xizmat ko'rsatishga jiddiy ta'sir ko'rsatishi mumkin. Ayniqsa, foydalanuvchilar soni oshganda va tizimga kirish so'rovlari ko'payganda, huquqlarni ko'rib chiqish usuliga e'tibor berish zarur.
Mazkur maqolada menyu huquqlari ma'lumotlarini boshqarishda yuzaga kelgan muammolar va ularni hal qilish uchun singlton dizayn naqshini qo'llagan holda ichki keshni joriy etishning sabablari, amalga oshirish usuli va joriy etishdan keyin erishilgan samaralar haqida baham ko'rmoqchimiz.
2. Mavjud tuzilma va muammolar
Dastlabki tizim nisbatan oddiy tuzilma bilan loyihalashtirilgan edi.
Foydalanuvchi tizimga kirganda, huquqlarni tekshirish xizmatini chaqiradi. Xizmat ma'lumotlar bazasida (DB) tegishli foydalanuvchining menyu huquqlari ma'lumotlarini qidiradi. Keyinchalik qidirilgan ma'lumotlarga asoslanib menyu ro'yxati hosil qilib, foydalanuvchiga qaytarish usuli edi.
Tuzilmani oddiy tarzda ifodalash kerak bo'lsa, quyidagicha bo'ladi.
1. Foydalanuvchi tizimga kiradi
2. Huquqlarni tekshirish xizmatini chaqirish
3. Ma'lumotlar bazasini qidirish
4. Menyu huquqlari ma'lumotlarini hosil qilish
5. Foydalanuvchiga ekran qaytarish
Dasturchilarning dastlabki bosqichida foydalanuvchilar soni ko'p bo'lmaganligi sababli bunday usulda ham yetarlicha operatsiya olib borish mumkin edi. Ma'lumotlar hajmi ham katta emasdi va tizimga kirish so'rovlari ko'p emasligi sababli ma'lumotlar bazasiga yuklama sezilarli darajada ro'y bermagan.
Biroq, xizmat ko'rsatish muddati uzayib, foydalanuvchilar soni oshgani sayin, bir necha muammo paydo bo'la boshladi.
takrorlanuvchi bir xil ma'lumotni ko'rish
Eng birinchi topilgan muammo bir xil ruxsat ma'lumotlarini takroran so'rayotganimiz edi.
Masalan, oddiy foydalanuvchilar guruhida 1,000 odam bor deb faraz qilaylik. Ular barchasi bir xil menyu huquqlari haqida ma'lumotlardan foydalanishadi. Biroq, har safar kirishda ma'lumotlar bazasini so'rov qilish tuzilmasida bir xil ma'lumotlarni 1,000 marta takroran o'qish kerak bo'ladi.
Majburiy ma'lumotlar odatda o'zgartirilmasada, har safar ma'lumotlar bazasiga kirish o'tayotgan edi.
Ma'lumotlar bazasi yuklanishi oshishi
Ruxsat ma'lumotlarini ko'rish, kirish jarayonida majburiy bajariladigan ishdir.
Shu sababli, kirish so‘rovlari ko‘paygan sari, ma'lumotlar bazasiga murojaat qilish soni ham proporsional ravishda ko‘payadi. Ayniqsa, dars boshlanish vaqti yoki tizimni tekshirishdan keyin foydalanuvchilar bir vaqtda kirishga harakat qilganida, ruxsatni tekshirish SQL qattiq bajarilgan. Bu ma'lumotlar bazasi yuklanishini oshirish sababchisi bo‘lishi mumkin.
Albatta, bitta so'rov o'z-o'zidan katta xarajat emas. Lekin yuzlab yoki minglab foydalanuvchilar bir vaqtda tizimga kirsa, kerak bo'lmagan so'rovlar to'planib, tizimning umumiy ishlashiga ta'sir qilishi mumkin.
Javob vaqti oshdi
Foydalanuvchi tizimga kirgach, birinchi ekran ko‘rsatilishi uchun ruxsatnoma ma'lumotlarini olish tugallangan bo‘lishi kerak.
Ma'lumotlar bazasining javob tezligi sekinlashsa yoki vaqtincha yuklanish yuzaga kelsa, kirish javob vaqti ham bevosita ta'sir qiladi. Huquqni tekshirish xizmat mantiqida zaruriy jarayon bo'lganligi sababli, ushbu bo'limning unumdorligini oshirish foydalanuvchi tajribasini yaxshilash uchun muhim omil edi.
kengayish cheklari
Hozirda muammo katta bo'lmasa-da, xizmat hajmi oshgan sari kirish so'rovlari ham ko'payadi.
Har bir so'rovning ma'lumotlar bazasini to'g'ridan-to'g'ri so'roq qilish tuzilmasi uzoq muddatda kengayish nuqtai nazaridan cheklovlarga ega bo'lishi mumkin. Shuning uchun so'rov samaradorligini yaxshilab, saqlash qulayligini ta'minlaydigan yangi tuzilma kerak edi.
3. Ma'lumotlar xususiyatlarini tahlil qilish
Samaraning oshirish imkoniyatlarini ko'rib chiqish uchun avvaldan menyu huquqlari ma'lumotlarining xususiyatlarini tahlil qildik. Tahlil natijalari ko'rsatdiki, menyu huquqlari ma'lumotlari quyidagi xususiyatlarga ega bo'lgan.
Birinchi, ma'lumotlarning o'zgarish tezligi juda past. Huquq ma'lumotlarini faqatgina administratorlar sahifasi orqali o'zgartirish mumkin. Oddiy foydalanuvchilar xizmatdan foydalanganida deyarli o'zgarmaydi.
Ikkinchidan, ko'rish tezligi juda yuqori. Foydalanuvchilar har safar tizimga kirganda huquq ma'lumotlarini ko'rishlari kerak. Ba'zi funksiyalarda qo'shimcha huquq tekshiruvi ham o'tkaziladi.
Uchinchi, bir xil ma'lumotni bir nechta foydalanuvchilar baham ko'rishadi. Bir xil rolga (Role) ega foydalanuvchilar odatda bir xil huquq ma'lumotlaridan foydalanishadi.
Xulosa qilib aytganda, menyu huquqlari ma'lumotlari "o'zgartirish kam, ko'rish ko'p (Read-Heavy) ma'lumot" xususiyatiga ega bo'lgan. Bunday ma'lumotlar kesh qo'llanilishi natijasi eng katta bo'lgan namunadir. Shuning uchun huquq ma'lumotlarini ma'lumotlar bazasidan emas, balki xotirada boshqarish rejalashtirildi.
4. Nima uchun Singleton patterini tanladik
Keshni qo'llashga qaror qilgandan so'ng yana bir muammo tug'di. Bu kesh ob'ektini qanday boshqarishning yo'li edi.
Huquq ma'lumotlari faqatgina tizimga kirish xizmatida emas, balki menyu yaratish xizmati, huquq tekshiruvi xizmati kabi turli komponentlarda foydalaniladi. Agar xizmatlar har biri uchun alohida kesh ob'ekti yaratilsa, bir xil ma'lumot bir necha marta xotiraga yuklanishi mumkin. Shuningdek, muayyan xizmatda kesh yangilanganda, boshqa xizmatlarning keshiga aks etmasligi natijasida ma'lumotlar noto'g'ri kelish muammosi yuzaga kelishi mumkin.
Buni hal qilish uchun ilova bo'ylab yagona kesh ob'ektidan foydalanishni rejalashtirdik. Bu paytda mos keladigan naqsh aynan Singleton (Yagona) naqshidir. Singleton naqshi ilova ichida ma'lum ob'ektni faqat bitta martalab yaratish va barcha komponentlarning ushbu ob'ektni baham ko'rishini ta'minlaydigan dizayn naqshidir. Singleton naqshidan foydalanganda quyidagi afzalliklarni olish mumkin.
Ma'lumotlar mosligini ta'minlash
Barcha xizmatlar bir xil kesh ob'ektidan foydalanishi sababli, huquq ma'lumotlarining mosligini saqlab qolish mumkin.
Xotira sarfini minimallashtirish
Huquq ma'lumotlarini bir marta xotiraga yuklash orqali takroriy saqlanishni oldini olish mumkin.
Tezkor ma'lumotlarga kirish
Ma'lumotlar bazasidan ko'ra xotirada ma'lumotlarni qidirilganda javob tezligi oshadi.
Saxiylikni oshirish
Kesh bilan bog'liq mantiq bitta ob'ektda to'planishi natijasida boshqarish osonlashadi. Spring Framework muhitida dastlab Bean Scope Singleton bo'lgani uchun bunday tuzilmani tabiiy ravishda amalga oshirish mumkin.
5. Amaliyot usuli
Amaliyot nisbatan oddiy tuzilish bilan amalga oshirildi.
Dastur boshlanishida ma'lumotlar bazasidan menyu huquqlari ma'lumotlarini qidirib keshda saqlanadi. Keyin, kirish so'rovi yuzaga kelganda ma'lumotlar bazasini qidirmasdan kesh ma'lumotlarini qaytaradi. Administrator huquq ma'lumotlarini o'zgartirsa, kesh yangilanadi va yangilangan holatni saqlaydi.
Amaliyot oqimi quyidagicha:
1. Dastur ishga tushiriladi
2. Menyu huquqlari ma'lumotlarini qidirish
3. Keshda saqlash
4. Kirish so'rovi yuzaga kelishi
5. Kesh ma'lumotlarini qaytarish
6. Administrator o'zgartirishda keshni yangilash
Quyida tushunchani soddalashtirgan misol kodi mavjud.
Yuqoridagi kodda huquq ma'lumotlarini saqlovchi kesh ob'ekti faqatgina bitta yaratiladi.
Kirishda getMenus() metodidan foydalanib keshga olingan menyu ma'lumotlarini ko'rib chiqamiz, va administrator sahifasida ruxsatnoma ma'lumotlari o'zgartirilganda refresh() metodini chaqirib eng so'nggi ma'lumotlarni aks ettiramiz.
Haqiqiy ishlash muhitida xizmat darajasini ajratish, istisno bilan ishlash, dastlabki yuklash muvaffaqiyatsizligi, monitoring kabi funksiyalarni qo'shib foydalanildi.
6. Ishlatishdan o'ylab ko'rgan jihatlar
Keshni qo'llashda eng muhim e'tibor qaratilgan jihat keshni bekor qilish (Cache Invalidation) bo'ldi. Keshni ishlatishning eng katta xavf omili bu haqiqiy ma'lumotlar va kesh ma'lumotlari o'rtasidagi farqdir. Ruxsatnoma ma'lumotlari tez-tez o'zgarilmaydi, ammo o'zgarish ehtimoli to'liq yo'q emas. Agar administrator ma'lum bir menyu ruxsatnomasini o'zgartirib, kesh yangilanmasa, foydalanuvchilar o'zgarishdan oldingi ruxsatnoma bilan davom etadilar. Buni oldini olish uchun administrator sahifasida ruxsatnoma o'zgartirilgandan so'ng darhol keshni qaytadan yuklash imkoniyatini amalga oshirdik.
Shuningdek, bir vaqtning o'zida bir necha foydalanuvchilar ruxsatnoma ma'lumotlarini ko'rib chiqishi mumkinligi sababli, oddiy HashMap o'rniga ConcurrentHashMapdan foydalanib, iplar xavfsizligini ta'minlashni ham ko'rib chiqdik.
Hozirgi tuzilma bitta server muhitiga asoslangan holda loyihalashtirilgan. Bitta instansiyada dastur xotirasida saqlangan keshni boshqarish kifoya, shuning uchun tuzilma nisbatan oddiydir. Ammo kelajakda xizmat ko'lami o'sib, ko'p instansiya muhitiga kengaytirilganda, har bir server bir-biridan farq qiluvchi kesh ma'lumotlarini saqlab qolish muammosi paydo bo'lishi mumkin.
Masalan, agar administrator ma'lum bir menyu ruxsatnomasini o'zgartirsa, bir serverning kesh qanday yangilanadi, lekin boshqa serverning kesh yangilanmasa, foydalanuvchilarda bir-biridan farq qiluvchi ruxsatnoma ma'lumotlari ko'rinishi mumkin. Bunday muammolarni oldini olish uchun Redis singari taqsimlangan keshni joriy etish yoki keshni yangilanish voqealarini har bir serverga tarqatish tuzilmasini ko'rib chiqish mumkin. Hozirda bitta server muhiti bo'lgani uchun qo'llanilmadi, lekin kelajakda kengaytirish paytida ko'rib chiqiladigan nuqtalar sifatida belgilandi.
Dastur qayta ishga tushirilishi holatlarida ham ko'rib chiqildi. Server qayta ishga tushirilganda, xotirada saqlangan kesh ma'lumotlari to'liq yo'q bo'lib ketadi. Shuning uchun dastur boshlanishida ruxsatnoma ma'lumotlarini avtomatik yuklash uchun dasturlash lojiğini amalga oshirib, xizmat ko'rsatish qulayligini saqladik.
Bunday tajribalar orqali keshni oddiygina saqlashdan ko'ra "qachon yangilanishini" loyihalashtirish yanada muhim ekanligini aniqladim.
7. Joriy qilish natijalari
Singleton pattern asosidagi xotira keshini joriy etgandan so'ng bir nechta ijobiy natijalar olindi.
Birinchidan, kirish jarayonida ruxsatnoma ko'rish bo'yicha SQL bajariladigan vaqtlar sezilarli darajada kamaydi. Ilgari har safar kirishda ma'lumotlar bazasini tekshirdik, lekin keshni qo'llaganimizdan beri aksariyat talablar xotiradan amalga oshirildi.
Ikkinchidan, ma'lumotlar bazasiga yuklamalar kamaydi. Ruxsatnoma ko'rish uchun ishlatiladigan aloqalar iste'moli kamayib, ma'lumotlar bazasi resurslarini yanada samarali ishlatishga imkon yaratdi.
Uchinchidan, javob tezligi yaxshilandi. Xotira tekshiruvi ma'lumotlar bazasi tekshiruvidan ancha tezroq bo'ladi, shuning uchun kirish jarayonining ishlash ko'rsatkichlari oshdi.
To'rtinchidan, xizmat ko'rsatish barqarorligi oshdi. Ruxsatnoma ma'lumotlari bir ob'ektda boshqarilishi sababli tuzilmani tushunish osonlashdi. Nosozliklar tahlili yoki funksiyalarni yaxshilash paytida ham tegishli logikalarni tezda tushunish imkoniyatiga ega bo'rgan edik.
Beshinchisi, kelajakda kengayish uchun asos yaratildi. Hozirda in-memoriy keshdan foydalanilmoqda, ammo kelajakda tizimning o'lchami oshganda Redis kabi tarqatilgan kesh yechimlariga o'tish uchun struktural asosga ega bo'ldik.
8. Xulosa qilib
Menyu huquqiy ma'lumotlar kabi o'zgarish chastotasi past va ko'rish chastotasi yuqori bo'lgan ma'lumotlar kesh qo'llanilishi samarali bo'lgan sohalardir. Foydalanuvchi kirgandan keyin kerakli menyu huquqiy ma'lumotlarni birlik dizayn asosida in-memoriy kesh bilan boshqarish orqali ma'lumotlar bazasi yukini kamaytirish va javob tezligini oshirishga muvaffaq bo'ldik.
Xususan, ushbu qo'llanish orqali keshdan foydalanishdan ko'ra ma'lumotlarning xususiyatlarini tahlil qilish va tegishli dizayn naqshini tanlash muhimligini yana bir bor tasdiqladik. Birlik dizayni nisbatan sodda tuzilma bo'lib, global ravishda bo compartilhaga o'tish uchun juda samarali tanlov bo'lishi mumkin.
Kelajakda xizmat xususiyatlariga mos kesh strategiyasi va arxitektura yaxshilanishini doimiy ravishda ko'rib chiqish orqali yanada barqaror va samarali tizimni qurishga reja qilyapmiz.
dwmoon