Hammamiz hikoyalarni yaxshi ko'ramiz. Biz olov atrofida o'tirib, o'tmishdagi g'alabalarimiz, janglarimiz yoki oddiygina ish tajribamiz haqida gapirishni yaxshi ko'ramiz.
Bugun aynan shunday kun. Va agar siz hozir olovda bo'lmasangiz ham, siz uchun hikoyamiz bor. Tarantool-da saqlash bilan ishlashni boshlaganimiz haqidagi hikoya.
Bir vaqtlar bizning kompaniyamizda hamma uchun bir nechta "monolit" va bitta "ship" bor edi, bu monolitlar asta-sekin, lekin ishonch bilan yaqinlashib, kompaniyamizning parvozini, rivojlanishimizni cheklab qo'ydi. Va aniq tushunish bor edi: bir kun biz bu shiftga qattiq uramiz.
Hozirda uskunadan tortib biznes mantig'igacha hamma narsani va hamma narsani ajratish mafkurasi hukm surmoqda. Natijada, bizda, masalan, tarmoq darajasida amalda mustaqil bo'lgan ikkita DC mavjud. Va keyin hamma narsa butunlay boshqacha edi.
Bugungi kunda CI/CD, K8S va boshqalar shaklida o'zgartirishlar kiritish uchun juda ko'p vositalar va vositalar mavjud. "Monolit" davrida bizga ko'p xorijiy so'zlar kerak emas edi. Ma'lumotlar bazasidagi "saqlash" ni oddiygina tuzatish kifoya edi.
Ammo vaqt oldinga siljidi va so'rovlar soni ham u bilan birga oldinga siljidi, ba'zida bizning imkoniyatlarimizdan tashqarida RPSni suratga oldi. MDH davlatlarining bozorga kirishi bilan birinchi monolitning ma'lumotlar bazasi protsessoriga yuk 90% dan pastga tushmadi va RPS 2400 darajasida qoldi. katta IO fonida ma'lumotlarning deyarli yarmi uchun ishlashi mumkin bo'lgan bir qator tekshiruvlar va JOINlar.
To'liq qora juma savdolari sahnada paydo bo'la boshlaganida - va Wildberries ularni Rossiyada birinchilardan bo'lib o'tkazgan - vaziyat butunlay achinarli bo'lib qoldi. Axir, bunday kunlarda yuk uch barobar ortadi.
Oh, bu "monolit vaqtlar"! Ishonchim komilki, siz shunga o'xshash narsani boshdan kechirdingiz va bu siz bilan qanday sodir bo'lishini hali ham tushunolmaysiz.
Nima qila olasiz - moda texnologiyaga xosdir. Taxminan 5 yil oldin, biz ushbu modlardan birini .NET va MS SQL serverlarida mavjud sayt shaklida qayta ko'rib chiqishga majbur bo'ldik, u saytning barcha mantiqlarini diqqat bilan saqlagan. Men uni shunchalik ehtiyotkorlik bilan saqladimki, bunday monolitni arralash uzoq va unchalik ham oson emas edi.
Kichkina chekinish.
Turli tadbirlarda men aytaman: "agar siz monolitni ko'rmagan bo'lsangiz, unda siz o'smagansiz!" Men bu masala bo'yicha fikringiz bilan qiziqaman, iltimos, sharhlarda yozing.
Momaqaldiroq ovozi
Keling, "gulxan"imizga qaytaylik. "Yaxlit" funksionallik yukini taqsimlash uchun biz tizimni ochiq manba texnologiyalari asosidagi mikroservislarga ajratishga qaror qildik. Chunki, hech bo'lmaganda, ular miqyosda arzonroq. Va biz 100% miqyoslashimiz kerakligini (va juda ko'p) tushundik. Axir, o'sha paytdayoq qo'shni mamlakatlar bozorlariga chiqish mumkin edi va ro'yxatdan o'tishlar soni, shuningdek, buyurtmalar soni yanada kuchli o'sishni boshladi.
Monolitdan mikroservislarga o'tish uchun birinchi nomzodlarni tahlil qilib, biz ulardagi yozuvlarning 80 foizi back-ofis tizimlaridan, o'qish esa front-ofisdan kelganligini angladik. Avvalo, bu biz uchun bir nechta muhim quyi tizimlarga taalluqli edi - foydalanuvchi ma'lumotlari va mijozlarning qo'shimcha chegirmalari va kuponlari haqidagi ma'lumotlarga asoslangan tovarlarning yakuniy narxini hisoblash tizimi.
Chekilgan. Endi tasavvur qilish qo'rqinchli, lekin yuqorida aytib o'tilgan quyi tizimlarga qo'shimcha ravishda mahsulot kataloglari, foydalanuvchi xarid qilish savati, mahsulotni qidirish tizimi, mahsulot kataloglari uchun filtrlash tizimi va har xil turdagi tavsiyalar tizimlari ham bizning monolitimizdan olib tashlandi. Ularning har birining ishlashi uchun tor moslashtirilgan tizimlarning alohida sinflari mavjud, ammo bir vaqtlar ularning barchasi bitta "uyda" yashagan.
Biz darhol mijozlarimiz haqidagi ma'lumotlarni sharded tizimga o'tkazishni rejalashtirdik. Tovarlarning yakuniy narxini hisoblash uchun funksionallikni olib tashlash o'qish uchun yaxshi miqyoslilikni talab qildi, chunki u eng katta RPS yukini yaratdi va ma'lumotlar bazasi uchun amalga oshirish eng qiyin bo'lgan (hisoblash jarayonida juda ko'p ma'lumotlar ishtirok etadi).
Natijada, biz Tarantool bilan yaxshi mos keladigan sxemani o'ylab topdik.
O'sha paytda mikroservislarning ishlashi uchun virtual va apparat mashinalarida bir nechta ma'lumotlar markazlari bilan ishlash sxemalari tanlangan. Rasmlarda ko'rsatilganidek, Tarantool replikatsiya imkoniyatlari ham master-master, ham master-slave rejimlarida qo'llanilgan.
Arxitektura. Variant 1. Foydalanuvchi xizmati
Ayni paytda 24 ta parcha bor, ularning har birida 2 tadan (har bir DC uchun bittadan) bor, barchasi master-master rejimida.
Ma'lumotlar bazasining yuqori qismida ma'lumotlar bazasi replikalariga kiradigan ilovalar mavjud. Ilovalar Tarantool Go drayver interfeysini amalga oshiradigan maxsus kutubxonamiz orqali Tarantool bilan ishlaydi. U barcha nusxalarni ko'radi va o'qish va yozish uchun usta bilan ishlashi mumkin. Asosan, u replikalarni tanlash, qayta urinishlar, elektron to'xtatuvchi va tezlik chegarasi uchun mantiqni qo'shadigan replika to'plami modelini amalga oshiradi.
Bunday holda, parchalar kontekstida replika tanlash siyosatini sozlash mumkin. Masalan, roundrobin.
Arxitektura. Variant 2. Tovarlarning yakuniy tannarxini hisoblash xizmati
Bir necha oy oldin, tovarlarning yakuniy narxini hisoblash bo'yicha so'rovlarning aksariyati yangi xizmatga yo'l oldi, u printsipial jihatdan ma'lumotlar bazasisiz ishlaydi, ammo bir muncha vaqt oldin hamma narsa Tarantool bilan kaput ostidagi xizmat tomonidan 100% qayta ishlandi.
Xizmat ma'lumotlar bazasi sinxronizator ma'lumotlarni to'playdigan 4 ta masterdan iborat va bu replikatsiya ustalarining har biri ma'lumotlarni faqat o'qish uchun nusxalarga tarqatadi. Har bir ustada taxminan 15 ta shunday nusxa mavjud.
Birinchi yoki ikkinchi sxemada, agar bitta DC mavjud bo'lmasa, dastur ikkinchisida ma'lumot olishi mumkin.
Shuni ta'kidlash kerakki, Tarantool-da replikatsiya juda moslashuvchan va uni ish vaqtida sozlash mumkin. Boshqa tizimlarda qiyinchiliklar paydo bo'ldi. Misol uchun, PostgreSQL-da max_wal_senders va max_replication_slots parametrlarini o'zgartirish sehrgarni qayta ishga tushirishni talab qiladi, bu ba'zi hollarda dastur va ma'lumotlar bazasi o'rtasidagi aloqalarning uzilishiga olib kelishi mumkin.
Izlang va topasiz!
Nega biz buni "oddiy odamlar kabi" qilmadik, lekin atipik yo'lni tanladik? Bu normal deb hisoblangan narsaga bog'liq. Ko'p odamlar odatda Mongo'dan klaster yaratadilar va uni uchta geo taqsimlangan DC bo'ylab tarqatadilar.
O'sha paytda bizda ikkita Redis loyihasi bor edi. Birinchisi kesh, ikkinchisi esa juda muhim bo'lmagan ma'lumotlar uchun doimiy saqlash edi. U bilan juda qiyin bo'ldi, qisman bizning aybimiz bilan. Ba'zan kalitda juda katta hajmlar bor edi va vaqti-vaqti bilan sayt yomonlashdi. Biz ushbu tizimni master-slave versiyasida ishlatganmiz. Va usta bilan nimadir sodir bo'lgan va replikatsiya buzilgan holatlar ko'p bo'lgan.
Ya'ni, Redis davlatga tegishli emas, fuqaroligi bo'lmagan vazifalar uchun yaxshi. Asosan, bu ko'pgina muammolarni hal qilishga imkon berdi, lekin faqat ular bir juft indeks bilan kalit-qiymatli echimlar bo'lsa. Ammo o'sha paytda Redis qat'iyat va takrorlash bilan juda g'amgin edi. Bundan tashqari, ishlash haqida shikoyatlar bor edi.
Biz MySQL va PostgreSQL haqida o'yladik. Ammo birinchisi qandaydir tarzda bizni qo'llab-quvvatlamadi, ikkinchisi esa o'z-o'zidan juda murakkab mahsulot va unga oddiy xizmatlarni qurish noo'rin bo'lar edi.
Biz RIAK, Cassandra, hatto grafik ma'lumotlar bazasini ham sinab ko'rdik. Bularning barchasi xizmatlarni yaratish uchun umumiy universal vosita roli uchun mos bo'lmagan juda muhim echimlardir.
Oxir-oqibat biz Tarantoolga joylashdik.
1.6 versiyasida bo'lganida biz unga murojaat qildik. Bizni kalit-qiymatning simbiozi va relyatsion ma'lumotlar bazasining funksionalligi qiziqtirdi. Ikkilamchi indekslar, tranzaktsiyalar va bo'shliqlar mavjud, ular jadvallarga o'xshaydi, lekin oddiy emas, ularda har xil sonli ustunlarni saqlashingiz mumkin. Ammo Tarantool-ning qotil xususiyati kalit-qiymat va tranzaksiya bilan birlashtirilgan ikkilamchi indekslar edi.
Chatda yordam berishga tayyor bo'lgan rusiyzabon hamjamiyat ham rol o'ynadi. Biz bundan faol foydalandik va bevosita chatda yashaymiz. Va aniq xatolar va xatolarsiz munosib qat'iylik haqida unutmang. Agar siz Tarantool bilan tariximizga nazar tashlasangiz, biz replikatsiya bilan juda ko'p og'riq va muvaffaqiyatsizlikka uchraganmiz, ammo uning aybi tufayli biz hech qachon ma'lumotlarni yo'qotmaganmiz!
Amalga oshirish qiyin boshlandi
O'sha paytda bizning asosiy ishlab chiqish stekimiz .NET edi, unga Tarantool uchun ulagich yo'q edi. Biz darhol Go'da nimadir qilishni boshladik. Bu Lua bilan ham yaxshi ishladi. O'sha paytdagi asosiy muammo disk raskadrovka bilan bog'liq edi: .NET'da bu bilan hamma narsa ajoyib, ammo bundan keyin loglardan boshqa disk raskadrovka bo'lmaganda, o'rnatilgan Lua dunyosiga kirish qiyin edi. Bundan tashqari, ba'zi sabablarga ko'ra replikatsiya vaqti-vaqti bilan parchalanib ketdi, shuning uchun men Tarantool dvigatelining tuzilishini o'rganishim kerak edi. Suhbat bunga yordam berdi va kamroq darajada hujjatlar; ba'zida biz kodni ko'rib chiqdik. O'sha paytda hujjatlar shunday edi.
Shunday qilib, bir necha oy davomida men boshimni aylantira oldim va Tarantool bilan ishlashdan munosib natijalarga erishdim. Biz git-da yangi mikroservislarni shakllantirishga yordam bergan ma'lumotnoma ishlanmalarini tuzdik. Masalan, vazifa paydo bo'lganda: boshqa mikroservis yaratish uchun ishlab chiquvchi ombordagi ma'lumotnoma yechimining manba kodini ko'rib chiqdi va yangisini yaratish uchun bir haftadan ko'proq vaqt kerak bo'lmadi.
Bu maxsus vaqtlar edi. Odatdagidek, siz keyingi stoldagi administratorga borib: "Menga virtual mashina bering", deb so'rashingiz mumkin. Taxminan o'ttiz daqiqadan so'ng mashina allaqachon siz bilan edi. Siz o'zingizni uladingiz, hamma narsani o'rnatdingiz va trafik sizga yuborildi.
Bugun bu ishlamaydi: siz xizmatga monitoring va ro'yxatga olishni qo'shishingiz, funksionallikni testlar bilan qoplashingiz, virtual mashinaga buyurtma berishingiz yoki Kuber-ga etkazib berishingiz va hk. Umuman olganda, bu ko'proq vaqt talab qiladigan va qiyinroq bo'lsa-da, bu tarzda yaxshiroq bo'ladi.
Ajrating va boshqaring. Lua bilan nima gap?
Jiddiy dilemma bor edi: ba'zi jamoalar Luada juda ko'p mantiqqa ega bo'lgan xizmatga o'zgarishlarni ishonchli tarzda kirita olmadilar. Bu ko'pincha xizmat ishlamasligi bilan birga bo'lgan.
Ya'ni, ishlab chiquvchilar qandaydir o'zgarishlarni tayyorlamoqda. Tarantool migratsiyani amalga oshirishni boshlaydi, lekin nusxasi hali ham eski kod bilan; Ba'zi DDL yoki boshqa narsa replikatsiya orqali u erga keladi va kod hisobga olinmagani uchun shunchaki parchalanadi. Natijada, ma'murlar uchun yangilash tartibi A4 varag'ida belgilandi: replikatsiyani to'xtating, buni yangilang, replikatsiyani yoqing, bu erda o'chiring, u erda yangilang. Dahshatli tush!
Natijada, biz ko'pincha Luada hech narsa qilmaslikka harakat qilamiz. Shunchaki iproto (server bilan o'zaro ishlash uchun ikkilik protokol) dan foydalaning va hammasi. Ehtimol, bu ishlab chiquvchilar orasida bilim etishmasligi, ammo bu nuqtai nazardan tizim murakkab.
Biz har doim ham bu skriptga ko'r-ko'rona amal qilmaymiz. Bugun bizda qora va oq rang yo'q: yo hamma narsa Luada, yoki hamma narsa Go'da. Keyinchalik migratsiya bilan bog'liq muammolarga duch kelmaslik uchun ularni qanday qilib birlashtirishimiz mumkinligini allaqachon tushunamiz.
Tarantool hozir qayerda?
Tarantool chegirma kuponlarini hisobga olgan holda tovarlarning yakuniy narxini hisoblash xizmatida qo'llaniladi, bu "Promoter" deb ham ataladi. Yuqorida aytib o'tganimdek, u endi nafaqaga chiqdi: uning o'rniga oldindan hisoblangan narxlarga ega yangi katalog xizmati kelyapti, ammo olti oy oldin barcha hisob-kitoblar Promouterda amalga oshirilgan. Ilgari uning mantiqining yarmi Lua tilida yozilgan. Ikki yil oldin xizmat saqlash joyiga aylantirildi va mantiq Go'da qayta yozildi, chunki chegirmalar mexanikasi biroz o'zgargan va xizmat unumdorligi yo'q edi.
Eng muhim xizmatlardan biri bu foydalanuvchi profilidir. Ya'ni, barcha Wildberries foydalanuvchilari Tarantool'da saqlanadi va ularning soni taxminan 50 millionni tashkil etadi.Foydalanuvchi identifikatori bilan ajratilgan tizim, Go xizmatlariga ulangan bir nechta DClar bo'ylab taqsimlanadi.
RPS ma'lumotlariga ko'ra, Promouter bir vaqtlar 6 ming so'rovga erishgan holda etakchi bo'lgan. Bir paytlar bizda 50-60 nusxa bor edi. Hozirda RPS bo'yicha yetakchi foydalanuvchi profillari bo'lib, taxminan 12 ming.Ushbu xizmat foydalanuvchi identifikatorlari diapazoniga bo'lingan maxsus shardingdan foydalanadi. Xizmat 20 dan ortiq mashinalarga xizmat qiladi, ammo bu juda ko'p, biz ajratilgan resurslarni qisqartirishni rejalashtirmoqdamiz, chunki buning uchun 4-5 ta mashinaning quvvati etarli.
Sessiya xizmati vshard va Kartrijdagi birinchi xizmatimizdir. Vshard-ni o'rnatish va Kartrijni yangilash bizdan biroz kuch talab qildi, ammo oxir-oqibat hammasi yaxshi bo'ldi.
Veb-sayt va mobil ilovada turli xil bannerlarni ko'rsatish xizmati Tarantool-da to'g'ridan-to'g'ri chiqarilgan birinchilardan biri bo'ldi. Ushbu xizmat 6-7 yil bo'lganligi, hali ham ishlayotgani va hech qachon qayta ishga tushirilmagani bilan ajralib turadi. Master-master replikatsiyasi ishlatilgan. Hech narsa buzilmagan.
Ba'zi hollarda ma'lumotni tezda ikki marta tekshirish uchun ombor tizimida tezkor mos yozuvlar funksiyasi uchun Tarantool-dan foydalanish misoli mavjud. Buning uchun Redis-dan foydalanishga harakat qildik, ammo xotiradagi ma'lumotlar Tarantoolga qaraganda ko'proq joy egalladi.
Kutish ro'yxati, mijozlar obunalari, hozirgi moda hikoyalari va kechiktirilgan tovarlar xizmatlari ham Tarantool bilan ishlaydi. Xotiradagi oxirgi xizmat taxminan 120 Gb ni egallaydi. Bu yuqoridagilardan eng keng qamrovli xizmatdir.
xulosa
Kalit-qiymat va tranzaksiya bilan birlashtirilgan ikkilamchi indekslar tufayli Tarantool mikroservislarga asoslangan arxitekturalar uchun juda mos keladi. Biroq, biz Lua-da juda ko'p mantiqqa ega xizmatlarga o'zgartirishlar kiritishda qiyinchiliklarga duch keldik - xizmatlar ko'pincha ishlashni to'xtatdi. Biz buni bartaraf eta olmadik va vaqt o'tishi bilan biz Lua va Goning turli kombinatsiyalariga keldik: biz bir tilni qayerda ishlatishni va boshqa tilni qayerda ishlatishni bilamiz.
Mavzu bo'yicha yana nimani o'qish kerak
- Tarantool yordamida noldan yuqori yuklangan dastur yaratish
- Tarantool kartridjida ishonchli yetakchi tanlovi
- Tarantool Telegram kanali mahsulot haqidagi yangiliklar bilan
- Jamoa chatida Tarantoolni muhokama qiling
Manba: www.habr.com