1. Kirish
Bu maqola ro'yxatdan o'tish yoki reja asosidagi ariza tizimi doirasida yuzaga keladigan ommaviy so'rovlarni qayta ishlashning optimallashtirish tajribasini DB tranzaktsiya markazida to'plagan ma'lumotdir. Ushbu tizim ariza boshlangandan keyinqisqa vaqt ichida minglab arizalarto'plangan xususiyatga ega. Foydalanuvchilar so'rov, ariza berish, bekor qilishni takrorlash bilan birga maksimal kredit, ariza berish mumkin bo'lgan shaxslar soni, reja chegarasi kabi bir nechta shartlarni qondirishlari kerak. Shuning uchun ma'lumotlarning to'g'riligini saqlash uchun ma'lumotlar bazasi tranzaktsiya qayta ishlashi juda muhimdir.
Amaliy muhitda taxminan 20 ming foydalanuvchi bir vaqtda xizmatdan foydalanadi va5 dan 10 minutgachataxminan 80 mingdan 100 minggachaariza va bekor qilish so'rovlari yuzaga kelgan. Bunday sharoitdaariza ma'lumotlarini yaratish va ariza beruvchilar sonini to'plash bo'yicha ma'lumotni yangilashasosan muhim tranzaktsiya qayta ishlash obyekti bo'lgan.
2. Dastlabki amalga oshirish va samaradorlik muammolari
Loyihani ishlab chiqish tugagach, Apache JMeter yordamida ishga tushirish muhitiga o'xshash sharoitdayuk testi o‘tkazildiDastlabki amalga oshirishda ariza API va bekor qilish API har biri API boshlanishidan tugashi nuqtasigacha Jami doiraga tranzaksiya qoʻllanildibo'ldi.
Ammo ariza berish imkoniyati haqida hukm qilish uchun ko'p old shartlar mavjud edi, shuningdek, meros boʻyicha tizimdan o'tkazilgan SQL ning samaradorlik muammolari ham bor edi. Buning natijasida API ishlov berish vaqti uzoqlashdi va tranzaksiya saqlash vaqti ham ortdi. Natijada ma'lumotlar bazasi bilan aloqa uzoq vaqt davomida saqlanib qoldi Ulanish havzasi yetarli emasbo'ldi.
Katta miqdordagi so'rovlar yuzaga kelgan taqdirda DBCP da ulanishingizni olish uchun kutish vaqti uzoq bo'lib qoldi va ba'zi so'rovlar vaqt o'tishi bilan muvaffaqiyatsizlikka uchradi. Norma javob darajasi kutilgan darajadan past bo'lgan muammoyuzaga keldi. Yakuniy maqsad - barcha so'rovlarning norma javobini olishdir.
3. Samaradorlikni oshirish jarayoni
Birinchi yaxshilash bosqichida DB indeksini qo'shishva SQL tuningio'tkazildi. Buning natijasida qarash tezligi oshdi va API ishlov berish vaqti kamaydi. Ammo hali ham ulanishingiz havzasi yetarli emasligi muammosi hal etilmadi.
Ikkinchi bosqichda MSA muhitida xizmat Pod sonini oshirdikskale out ni amalga oshirdik. Yakunida taxminan 30 ta Podni boshqarishimiz mumkin bo'ldiishlash tezligi oshdibiroqtormozlanish ma'lumotlar bazasi ulanishida mavjudshuning uchun so'rovlar muvaffaqiyatsizligi muammosi to'liq hal qilinmagan.
Uchinchi bosqichdaHikariCPning ulanish sonini asosiy qiymat 10 tadan 100 taga kengaytirildinatijada WASda bir vaqtda ishlov berayotgan so'rovlar soni oshdi, lekin xotira iste'moli keskin oshishi bilan Out Of Memory xatosi yuzaga keldi.
To'rtinchi bosqichda TomcatHeap xotirasini 256MBdan 4GBgacha kengaytirildiOOM muammosi hal qilindi, ammo ulanish yetishmovchiligi davom etdi. Biroq, umumanmuvaffaqiyatsizlik darajasi biroz kamaydibo'ldi.
4. WAS va DB resurslari muvozanatini sozlash
Muammoning mohiyati shunchaki ishlov berish qobiliyatining yetishmasligi emas, balki ma'lumotlar bazasi ulanishini qo'llash usulida ekanligi aniqlandi. DB ulanish so'rov qismi tor joyga aylanganda k8s ushbu PODni xizmat ko'rsata olmaydigan holatga o'tkazib, tor joyni bartaraf etishi kerak edi, lekin Tomcat WAS doimiy ravishda so'rovlarni qabul qila olishi natijasida so'rov muvaffaqiyatsiz bo'lib qoldi.
Shuning uchun Tomcat WAS ning so'rovlarini bir vaqtda qayta ishlashso'rov iplari sonini asosiy qiymat 200 dan 50 gaqisqartirdik,DBCPning ulanishlari ham 100 dan 50 gaqaytadan sozlandi.
Ushbu o'zgartirishlar orqaliDB ulanishlari yetishmasligi holati sezilarli darajada yumshatildi.Biroq, shu bilan birgaqayta ishlanishi mumkin bo'lgan so'rovlar soni cheklanganbo'lib, yangi bir performans cheklovi paydo bo'ldi.
Qo'shimcha ravishda, integratsiyalashgan ma'lumotlar bazasi muhitida cheklovlar mavjud edi. Bir nechta tizimlar bitta jismoniy ma'lumotlar bazasini bo'lishganligi sababli foydalanish mumkin bo'lganmaksimal DB ulanishlari soni cheklanganedi. Shuning uchun shunchaki ulanishlar sonini oshirish yo'li bilan muammoni hal etish mumkin emas edi.
5. So'rovlarni boshqarish va tranzaksiyalarni optimallashtirish
Ishlatilgan eski meros tizimidan foydalanish orqali boshqaruv barqarorligini ta'minlash uchunSo'rov kutish yechimi (NetPanel) qayta joriy etishBuni amalga oshirdik. Buning yordamida vaqtinchalik trafik to‘siqlarini boshqarish imkoniyatiga ega bo‘ldik, shuningdek, ish jarayonida yuzaga kelgan Katta muvaffaqiyatsizlik muammosi yoʻqoldi.
keyinchalik Transaktsiya doirasini minimal darajaga keltirishIshni bajarishga kirishdik. Ariza berish imkoniyati haqida qaror qabul qilish uchun turli shartlar orasida real vaqtda o'zgartirishni talab qilmaydigan va real vaqtda o'zgartirilmaydigan ma'lumotlarni ko'rish jarayonini tranzaksiya doirasidan tashqariga o'tkazdik. Buning natijasida DB ulanishining umumiy egallash vaqti kamaydi va Bajarish mumkin bo'lgan so'rovlar soni oshdiamalga oshirildi.
6. Deadlock muammosi va yechimi
Transaction optimallashtirilgandan so'ng yangi muammo yuzaga keldi. Arizachilar sonini hisoblash ma'lumotlarini yangilash jarayonida select for update so'rov ya'ni biyorqaq rakSiz foydalanayotgan edingiz, bir xil rekordga oid katta talablar to‘planganda, deadlock holati yuzaga keldi.
Xususan, bitta tranzaksiyaQo'shimcha DB ulanishini talab qiluvchi vaziyatAgar bog'lanish havzasi etarli bo'lmasa, o'zaro to'siqlar yuzaga kelishi mumkin edi. Buni hal qilish uchun har bir so'rovga kerak bo'lgan maksimal bog'lanish sonini tahlil qildikmos bog'lanish havzasi o'lchamini aniqladikqildik.
DB Pool Size = T × (C - 1) + 1Bu yerda T WASning maksimal ip soni, C esa bir so'rov uchun zarur bo'lgan maksimal ma'lumotlar bazasi bog'lanish sonidir. Ushbu formulaga asoslanib sozlamalarni o'zgartirgandan so'ngo'zaro to'siqlar holati yo'qoldi.
7. Ariza beruvchilar sonining ortishi muammosiga javob berish
Katta so'rovlar muhitida ariza cheklov sonini oshirib ariza tugallanishi holatiham yuzaga keldi. Buni hal qilish uchun ariza tugallangandan so'ng darhol vaqtga asoslanibyana bir bor tasdiqlashamalga oshirdik. Belgilangan tartibda belgilangan sonni oshirganini tekshirish usuli sifatida vaqt o'tsa ham farqi yo'q deb tekshirish mumkin edi.
Tasdiqlash natijasi sifatida belgilangan sonni oshirib ketgan holatdaushbu tranzaksiyani orqaga qaytarish yoki arizani bekor qilishbunga asoslanib, yakuniy ma'lumotlarning to'g'riligini ta'minlashga эrişildi.
8. Pessimistice Locks'dan Optimistic Locks'ga o'tish
korxona sifatida Pessimistice Lockning samaradorlik tahlil natijalarimuhimtugmacha elementi sifatidabiriktirilgan edi. Shu sababli Pessimistice Lock asosidagi tuzilmaOptimistic Lock asosidagi tuzilma bo'lib o'zgartirildi.
Optimistic Lockni qo'llash uchuntahrir vaqt mulkini versiya ma'lumotlarisifatida ishlatiladi. Entitining tahrir vaqti o'zgarganda versiya oshadi, to'qnashuvlar yuzaga kelganda esa OptimisticLockException istisnosi chiqariladi.
Bundan tashqariSpring Retry funktsiyasidanfoydalanibto'qnashuv yuzaga kelgandaistisnolarni shart sifatidaAvtomatik qayta urinib ko‘rishni bajarishga qaror qildik. Qayta urinib ko‘rish oralig‘i 0.5 soniyadan kam belgilandi va eng ko‘pi bilan 10 marta qayta urinib ko‘rish amalga oshirildi.
Ushbu tuzilma o‘zgarishidan so‘ng ma'lumotlar bazasi ulanishidan foydalanish samaradorligi sezilarli darajada oshdi. Deadlock muammosi deyarli yo‘qoldi va ulanish yetishmasligi holati bartaraf etildi. Yakuniy natija WAS iplari soni 50 ta, DB ulanishlari soni 20 ta darajasida barqaror ishlashni amalga oshirish mumkin bo‘ldi.
9. Xulosa
Ushbu misol oddiy серверni kengaytirish yoki ulanishni oshirish orqali katta so‘rov muammosini hal qilish mumkin emasligini ko‘rsatmoqda. Haqiqiy tiqilib qolish nuqtalarini aniq tahlil qilish, tranzaksiya doirasini minimalizatsiya qilish va mos keluvchi blokirovka strategiyasini tanlash muhimdir.
Ayniqsa, pessimist blokirovkasini optimist blokirovkaga o‘tkazish va qayta urinib ko‘rish strategiyasini joriy etish eng samarali takomillashtirish choralaridan biri bo‘ldi. Bundan tashqari, ma'lumotlar bazasi ulanishlari, WAS iplari soni va tranzaksiya doirasi o‘rtasida muvozanatni saqlash katta so‘rovlarni qabul qilish tizimining barqarorligi va unumdorligini ta'minlashning muhim omili ekanini tasdiqlash mumkin.
Ushbu tajribadan o‘qish ro‘yxati, rezervatsiya tizimi, tadbirlar konkursi, birinchi navbatda sotish kabi turli xil katta trafik tizimlari dizayniga qo‘llanilishi mumkin bo‘lgan muhim omillarni bilib oldik.
Daniel(K)