Artem Denisov ( , )
Badoo - dunyodagi eng katta tanishuv sayti. Hozirda butun dunyo bo'ylab 330 millionga yaqin ro'yxatdan o'tgan foydalanuvchilarimiz bor. Ammo bugungi suhbatimiz kontekstida muhimroq narsa shundaki, biz taxminan 3 petabayt foydalanuvchi fotosuratlarini saqlaymiz. Har kuni bizning foydalanuvchilarimiz 3,5 millionga yaqin yangi fotosuratlarni yuklaydi va o'qish yuki taxminan Bir soniyada 80 ming so'rov. Bu bizning orqa tomonimiz uchun juda ko'p va ba'zida bu bilan bog'liq qiyinchiliklar mavjud.
Men umuman fotosuratlarni saqlaydigan va yuboradigan ushbu tizimning dizayni haqida gapirib beraman va men uni ishlab chiquvchi nuqtai nazaridan ko'rib chiqaman. Uning qanday rivojlanganligi haqida qisqacha retrospektiv bo'ladi, u erda men asosiy bosqichlarni aytib beraman, lekin men hozirda biz foydalanayotgan echimlar haqida batafsilroq gaplashaman.
Endi boshlaymiz.
Aytganimdek, bu retrospektiv bo'ladi va uni biron bir joyda boshlash uchun eng keng tarqalgan misolni olaylik.
Bizning umumiy vazifamiz bor, biz foydalanuvchi fotosuratlarini qabul qilishimiz, saqlashimiz va yuborishimiz kerak. Ushbu shaklda vazifa umumiy bo'lib, biz hamma narsani ishlatishimiz mumkin:
- zamonaviy bulutli saqlash,
- qutili yechim, ulardan hozir juda ko'p;
- Biz ma'lumotlar markazimizda bir nechta mashinalarni o'rnatishimiz va ularga katta qattiq disklar qo'yishimiz va u erda fotosuratlarni saqlashimiz mumkin.
Badoo tarixan - hozir ham, keyin ham (u endigina go'daklik davrida) - o'z serverlarida, o'z DC'larimiz ichida yashaydi. Shuning uchun, bu variant biz uchun maqbul edi.
Biz shunchaki bir nechta mashinalarni oldik, ularni "fotosuratlar" deb nomladik va biz fotosuratlarni saqlaydigan klasterga ega bo'ldik. Lekin nimadir etishmayotganga o'xshaydi. Bularning barchasi ishlashi uchun biz qaysi fotosuratlarni qaysi mashinada saqlashimizni qandaydir tarzda aniqlashimiz kerak. Va bu erda ham Amerikani ochishning hojati yo'q.
Biz foydalanuvchilar haqidagi ma'lumotlar bilan xotiramizga ba'zi maydonlarni qo'shamiz. Bu sharding kaliti bo'ladi. Bizning holatda, biz uni place_id deb nomladik va bu joy identifikatori foydalanuvchi fotosuratlari saqlanadigan joyni ko'rsatadi. Biz xaritalar qilamiz.
Birinchi bosqichda bu hatto qo'lda ham amalga oshirilishi mumkin - biz aytamizki, ushbu foydalanuvchining bunday joyga ega fotosurati bunday serverga tushadi. Ushbu xarita tufayli biz har doim foydalanuvchi fotosuratni qachon yuklashini, uni qayerda saqlashni va uni qayerdan berishni bilamiz.
Bu mutlaqo ahamiyatsiz sxema, ammo u juda muhim afzalliklarga ega. Birinchisi, men aytganimdek, oddiy, ikkinchisi, bu yondashuv bilan biz oddiygina yangi mashinalarni yetkazib berish va ularni xaritaga qo‘shish orqali gorizontal o‘lchamlarni osongina o‘lchashimiz mumkin. Boshqa hech narsa qilishingiz shart emas.
Bir muncha vaqt biz uchun shunday bo'ldi.
Bu taxminan 2009 yil edi. Ular mashinalarni etkazib berishdi, etkazib berishdi ...
Va bir nuqtada biz ushbu sxemaning ma'lum kamchiliklari borligini payqadik. Kamchiliklari qanday?
Birinchidan, cheklangan imkoniyatlar mavjud. Biz xohlagancha qattiq disklarni bitta jismoniy serverga joylashtira olmaymiz. Va bu vaqt o'tishi bilan va ma'lumotlar to'plamining o'sishi bilan muayyan muammoga aylandi.
Va ikkinchi. Bu mashinalarning atipik konfiguratsiyasi, chunki bunday mashinalarni ba'zi boshqa klasterlarda qayta ishlatish qiyin; ular juda o'ziga xosdir, ya'ni. ular ishlashda zaif bo'lishi kerak, lekin ayni paytda katta qattiq disk bilan.
Bularning barchasi 2009 yil uchun edi, lekin, qoida tariqasida, bu talablar bugungi kunda ham dolzarbdir. Bizda retrospektiv bor, shuning uchun 2009 yilda bu bilan hamma narsa butunlay yomon edi.
Va oxirgi nuqta - bu narx.
O'sha paytda narx juda keskin edi va biz ba'zi alternativalarni izlashimiz kerak edi. Bular. Biz ma'lumotlar markazlari va bularning barchasi joylashgan jismoniy serverlardagi bo'sh joydan qandaydir tarzda yaxshiroq foydalanishimiz kerak edi. Va bizning tizim muhandislarimiz katta tadqiqotni boshladilar, unda ular turli xil variantlarni ko'rib chiqdilar. Ular, shuningdek, PolyCeph va Luster kabi klasterli fayl tizimlarini ko'rib chiqdilar. Ishlash muammolari va juda qiyin operatsiya bor edi. Ular rad etishdi. Biz uni qandaydir tarzda kengaytirish uchun barcha ma'lumotlar to'plamini NFS orqali har bir mashinaga o'rnatishga harakat qildik. O'qish ham yomon ketdi, biz turli sotuvchilardan turli xil echimlarni sinab ko'rdik.
Va nihoyat, biz saqlash hududi tarmog'idan foydalanishga qaror qildik.
Bular katta hajmdagi ma'lumotlarni saqlash uchun maxsus mo'ljallangan katta SHD'lardir. Ular oxirgi optik chiqish mashinalariga o'rnatilgan diskli javonlardir. Bu. Bizda juda kichik mashinalar havzasi bor va bu SHD-lar bizning yuborish mantig'imiz uchun shaffofdir, ya'ni. bizning nginx yoki boshqa birov ushbu fotosuratlar uchun so'rovlarni bajarishi uchun.
Bu qarorning aniq afzalliklari bor edi. Bu SHD. Bu fotosuratlarni saqlashga qaratilgan. Bu mashinalarni qattiq disklar bilan jihozlashdan ko'ra arzonroq ishlaydi.
Ikkinchi ortiqcha.
Bu imkoniyatlar ancha katta bo'ldi, ya'ni. biz juda kichikroq hajmda ko'proq saqlashni sig'dira olamiz.
Ammo juda tez paydo bo'lgan kamchiliklar ham bor edi. Foydalanuvchilar soni va ushbu tizimdagi yuk o'sishi bilan ishlash muammolari paydo bo'la boshladi. Va bu erda muammo juda aniq - kichik hajmdagi ko'plab fotosuratlarni saqlash uchun mo'ljallangan har qanday SHD, qoida tariqasida, intensiv o'qishdan aziyat chekadi. Bu har qanday bulutli saqlash yoki boshqa narsalar uchun amal qiladi. Endi bizda cheksiz darajada kengaytiriladigan ideal xotira yo'q, siz unga biron bir narsani to'ldirishingiz mumkin va u o'qishni juda yaxshi qabul qiladi. Ayniqsa, tasodifiy o'qishlar.
Bizning fotosuratlarimizda bo'lgani kabi, chunki fotosuratlar mos kelmaydigan tarzda so'raladi va bu ularning ishlashiga katta ta'sir qiladi.
Hatto bugungi raqamlarga ko'ra, agar biz xotira ulangan mashinada fotosuratlar uchun 500 RPS dan ko'proq joy olsak, muammolar allaqachon boshlanadi. Va bu biz uchun yomon edi, chunki foydalanuvchilar soni ortib bormoqda, ishlar faqat yomonlashadi. Bu qandaydir tarzda optimallashtirilishi kerak.
Optimallashtirish uchun biz o'sha paytda, aniqki, yuk profilini ko'rib chiqishga qaror qildik - umuman olganda, nima sodir bo'lmoqda, nima optimallashtirilishi kerak.
Va bu erda hamma narsa bizning qo'limizda o'ynaydi.
Men birinchi slaydda aytdim: bizda kuniga atigi 80 million yuklash bilan sekundiga 3,5 ming o'qish so'rovlari bor. Ya'ni, bu uchta kattalikdagi farq. O'qishni optimallashtirish kerakligi aniq va qanday qilib amalda aniq.
Yana bir kichik nuqta bor. Xizmatning o'ziga xosligi shundaki, odam ro'yxatdan o'tadi, fotosuratni yuklaydi, keyin boshqa odamlarga faol qarashni boshlaydi, ular kabi va boshqa odamlarga faol ravishda ko'rsatiladi. Keyin u turmush o'rtog'ini topadi yoki topolmaydi, bu qanday bo'lishiga bog'liq va bir muddat xizmatdan foydalanishni to'xtatadi. Ayni paytda, u foydalanganda, uning fotosuratlari juda issiq - ular talabga ega, ko'pchilik ularni ko'radi. U buni qilishni to'xtatgandan so'ng, u avvalgidek boshqa odamlarga ta'sir qilishdan tezda voz kechadi va uning fotosuratlari deyarli hech qachon so'ralmaydi.
Bular. Bizda juda kichik issiq ma'lumotlar to'plami mavjud. Lekin ayni paytda unga bo'lgan talablar ko'p. Va bu erda to'liq aniq yechim kesh qo'shishdir.
LRU bilan kesh bizning barcha muammolarimizni hal qiladi. Biz nima qilyapmiz?
Biz fotokeshlar deb ataladigan xotirasi bo'lgan katta klasterimiz oldiga yana bir nisbatan kichikni qo'shamiz. Bu, aslida, keshlash proksi-serveridir.
U ichkaridan qanday ishlaydi? Mana bizning foydalanuvchimiz, bu yerda saqlash. Hammasi avvalgidek. Orasiga nima qo'shamiz?
Bu shunchaki jismoniy mahalliy diskli mashina, u tez. Bu, masalan, SSD bilan. Va bu diskda qandaydir mahalliy kesh saqlanadi.
Bu nimaga o'xshaydi? Foydalanuvchi suratga olish uchun so'rov yuboradi. NGINX uni birinchi navbatda mahalliy keshda qidiradi. Agar yo'q bo'lsa, shunchaki bizning xotiramizga proxy_pass qiling, u yerdan fotosuratni yuklab oling va foydalanuvchiga bering.
Ammo bu juda oddiy va ichkarida nima sodir bo'layotgani noma'lum. Bu shunga o'xshash narsa ishlaydi.
Kesh mantiqan uchta qatlamga bo'lingan. Men "uch qatlam" deganimda, bu qandaydir murakkab tizim borligini anglatmaydi. Yo'q, bu fayl tizimidagi shartli ravishda uchta katalog:
- Bu proksi-serverdan yuklab olingan suratlar ketadigan bufer.
- Bu hozirda faol so'ralgan fotosuratlarni saqlaydigan issiq kesh.
- Va sovuq kesh, bu erda fotosuratlar kamroq so'rovlar kelganda asta-sekin issiq keshdan chiqariladi.
Buning ishlashi uchun biz ushbu keshni qandaydir tarzda boshqarishimiz kerak, undagi fotosuratlarni qayta tartibga solishimiz kerak va hokazo. Bu ham juda ibtidoiy jarayon.
Nginx har bir so'rov uchun oddiygina RAMDisk access.log-ga yozadi, unda u hozirda xizmat qilgan fotosuratga yo'lni (albatta, nisbiy yo'l) va qaysi bo'limga xizmat ko'rsatganligini ko'rsatadi. Bular. u "1-rasm", keyin esa bufer, issiq kesh, sovuq kesh yoki proksi-server deb aytishi mumkin.
Bunga qarab, biz qandaydir tarzda fotosurat bilan nima qilishni hal qilishimiz kerak.
Bizda har bir mashinada ishlaydigan kichik demon bor, u doimiy ravishda ushbu jurnalni o'qiydi va uning xotirasida ma'lum fotosuratlardan foydalanish statistikasini saqlaydi.
U shunchaki u erda yig'adi, hisoblagichlarni saqlaydi va vaqti-vaqti bilan quyidagilarni bajaradi. U juda ko'p so'rovlar mavjud bo'lgan faol so'ralgan fotosuratlarni qayerda bo'lishidan qat'i nazar, issiq keshga ko'chiradi.
Kamdan-kam so'raladigan va kamroq so'raladigan fotosuratlar asta-sekin issiq keshdan sovuqqa suriladi.
Va keshda bo'sh joy tugagach, biz sovuq keshdan hamma narsani tasodifiy o'chirishni boshlaymiz. Aytgancha, bu yaxshi ishlaydi.
Fotosurat uni buferga proksi-serverga ulashda darhol saqlanishi uchun biz proxy_store direktivasidan foydalanamiz va bufer ham RAMDisk, ya'ni. foydalanuvchi uchun u juda tez ishlaydi. Bu keshlash serverining ichki qismlariga tegishli.
Qolgan savol so'rovlarni ushbu serverlar bo'ylab qanday tarqatishdir.
Aytaylik, yigirmata saqlash mashinasi va uchta keshlash serveridan iborat klaster mavjud (bu shunday bo'ldi).
Qaysi so'rovlar qaysi fotosuratlar va ularni qaerga qo'yish kerakligini qandaydir tarzda aniqlashimiz kerak.
Eng keng tarqalgan variant - Round Robin. Yoki tasodifan qilyapsizmi?
Bu, shubhasiz, bir qator kamchiliklarga ega, chunki biz bunday vaziyatda keshdan juda samarasiz foydalanamiz. So'rovlar ba'zi tasodifiy mashinalarga tushadi: bu erda u keshlangan, ammo keyingisida u yo'q. Va agar bularning barchasi ishlasa, bu juda yomon bo'ladi. Klasterda kam sonli mashinalar bilan ham.
Qaysi server qaysi so'rovni ishga tushirishni qandaydir tarzda aniqlab olishimiz kerak.
Banal yo'l bor. Biz URL manzilidan xeshni yoki URL manzilida joylashgan sharding kalitimizdan xeshni olamiz va uni serverlar soniga ajratamiz. Ishlaydimi? iroda.
Bular. Bizda 2% so'rov bor, masalan, ba'zi "example_url" uchun u har doim "XNUMX" indeksli serverga tushadi va kesh doimiy ravishda iloji boricha yo'q qilinadi.
Ammo bunday sxemada qayta taqsimlash muammosi mavjud. Qayta taqsimlash - men serverlar sonini o'zgartirishni nazarda tutyapman.
Faraz qilaylik, bizning keshlash klasterimiz endi bardosh bera olmaydi va biz boshqa mashina qo'shishga qaror qildik.
Qo'shamiz.
Endi hamma narsa uchga emas, to'rtga bo'linadi. Shunday qilib, bizda mavjud bo'lgan deyarli barcha kalitlar, deyarli barcha URL manzillar endi boshqa serverlarda yashaydi. Butun kesh bir lahzaga bekor qilindi. Barcha so'rovlar bizning saqlash klasterimizga tushdi, u yomonlashdi, xizmat ishlamay qoldi va foydalanuvchilarning norozi bo'ldi. Men buni qilishni xohlamayman.
Bu variant ham bizga mos kelmaydi.
Bu. nima qilishimiz kerak? Biz qandaydir tarzda keshdan samarali foydalanishimiz, bir xil so'rovni bir xil serverga qayta-qayta yuborishimiz kerak, lekin qayta taqsimlashga chidamli bo'lishimiz kerak. Va bunday yechim bor, bu unchalik murakkab emas. Bu izchil xeshlash deb ataladi.
Bu nimaga o'xshaydi?
Sharding kalitidan ba'zi funktsiyalarni olamiz va uning barcha qiymatlarini aylanaga yoyamiz. Bular. 0 nuqtada uning minimal va maksimal qiymatlari yaqinlashadi. Keyinchalik, biz barcha serverlarimizni taxminan shu tarzda bir xil doiraga joylashtiramiz:
Har bir server bitta nuqta bilan belgilanadi va unga soat yo'nalishi bo'yicha ketadigan sektor mos ravishda ushbu xost tomonidan xizmat qiladi. Bizga so'rovlar kelganda, biz darhol ko'ramiz, masalan, A so'rovi - u erda xesh bor - va u 2-server tomonidan xizmat qiladi. B so'rovi - server tomonidan 3. Va hokazo.
Qayta kesish paytida bu vaziyatda nima sodir bo'ladi?
Biz avvalgidek butun keshni bekor qilmaymiz va barcha kalitlarni siljitmaymiz, lekin biz har bir sektorni qisqa masofaga siljitamiz, shunday qilib, nisbatan aytganda, biz qo'shmoqchi bo'lgan oltinchi serverimiz bo'sh joyga mos keladi va u erda qo'shamiz.
Albatta, bunday vaziyatda kalitlar ham tashqariga chiqadi. Lekin ular avvalgidan ancha kuchsizroq chiqib ketishadi. Va biz birinchi ikkita kalitimiz o'z serverlarida qolganini va keshlash serveri faqat oxirgi kalit uchun o'zgarganini ko'ramiz. Bu juda samarali ishlaydi va agar siz yangi xostlarni asta-sekin qo'shsangiz, bu erda katta muammo bo'lmaydi. Bir vaqtning o'zida bir oz qo'shing va qo'shing, kesh yana to'lguncha kuting va hamma narsa yaxshi ishlaydi.
Yagona savol rad etish bilan qoladi. Faraz qilaylik, qandaydir mashina ishdan chiqqan.
Va, masalan, mashina qayta ishga tushirilgan bo'lsa va biz qandaydir tarzda so'rovlarga xizmat ko'rsatishimiz kerak bo'lsa, biz hozir ushbu xaritani qayta tiklashni, keshning bir qismini bekor qilishni va hokazolarni xohlamaymiz. Biz har bir saytda bitta zaxira foto keshini saqlab qolamiz, bu hozirda ishlamay qolgan har qanday mashinaning o‘rnini bosadi. Va agar to'satdan bizning serverlarimizdan biri ishlamay qolsa, trafik u erga boradi. Tabiiyki, bizda u erda hech qanday kesh yo'q, ya'ni. sovuq, lekin hech bo'lmaganda foydalanuvchi so'rovlari ko'rib chiqilmoqda. Agar bu qisqa vaqt oralig'i bo'lsa, biz buni butunlay xotirjam boshdan kechiramiz. Xotirada ko'proq yuk bor. Agar bu interval uzoq bo'lsa, biz allaqachon qaror qabul qilishimiz mumkin - bu serverni xaritadan olib tashlash yoki yo'q qilish yoki uni boshqasi bilan almashtirish.
Bu keshlash tizimi haqida. Keling, natijalarni ko'rib chiqaylik.
Bu erda hech qanday murakkab narsa yo'qdek tuyuladi. Ammo keshni boshqarishning bu usuli bizga taxminan 98% hiyla tezligini berdi. Bular. Bu soniyada 80 ming so'rovdan atigi 1600 tasi saqlashga yetadi va bu mutlaqo normal yuk, ular xotirjamlik bilan bardosh berishadi, bizda doimo zaxira bor.
Biz ushbu serverlarni uchta DC-ga joylashtirdik va uchta mavjudlik nuqtasini oldik - Praga, Mayami va Gonkong.
Bu. ular bizning maqsadli bozorlarimizning har birida ko'proq yoki kamroq mahalliy darajada joylashgan.
Va yoqimli bonus sifatida biz ushbu keshlash proksi-serverini oldik, unda protsessor aslida ishlamaydi, chunki u kontentga xizmat ko'rsatish uchun unchalik kerak emas. Va u erda NGINX + Lua-dan foydalanib, biz juda ko'p utilitar mantiqni amalga oshirdik.
Misol uchun, biz webp yoki progressiv jpeg bilan tajriba qilishimiz mumkin (bular samarali zamonaviy formatlar), uning trafikka qanday ta'sir qilishini ko'rishimiz, ba'zi qarorlar qabul qilishimiz, uni ma'lum mamlakatlar uchun yoqishimiz va hokazo; dinamik o'lchamini o'zgartiring yoki tezda fotosuratlarni kesib oling.
Bu, masalan, sizda fotosuratlarni ko'rsatadigan mobil ilovangiz bo'lsa va mobil ilova mijozning protsessorini katta hajmdagi fotosuratni so'rab, keyin uni ma'lum o'lchamga o'zgartirish uchun sarflashni istamasa, yaxshi foydalanish mumkin. ko'rinish. Biz UPort shartli URL manzilidagi ba'zi parametrlarni shunchaki dinamik ravishda belgilashimiz mumkin va fotosurat keshi fotosuratning o'lchamini o'zgartiradi. Qoidaga ko'ra, u bizda diskda mavjud bo'lgan o'lchamni so'raganiga iloji boricha yaqinroq tanlaydi va uni ma'lum koordinatalarda sotadi.
Aytgancha, biz yuqori yuklangan tizimlarni ishlab chiquvchilar konferentsiyasining so'nggi besh yillik video yozuvlarini hamma uchun ochiq qildik. . Ko'ring, o'rganing, baham ko'ring va obuna bo'ling .
Shuningdek, biz u erda juda ko'p mahsulot mantig'ini qo'shishimiz mumkin. Misol uchun, biz URL parametrlari yordamida turli xil moybo'yoqlarni qo'shishimiz mumkin, biz fotosuratlarni xiralashtirishimiz, xiralashtirishimiz yoki piksellashimiz mumkin. Bu biz odamning fotosuratini ko'rsatmoqchi bo'lganimizda, lekin uning yuzini ko'rsatishni xohlamaymiz, bu yaxshi ishlaydi, bu erda hammasi amalga oshiriladi.
Biz nima oldik? Bizda uchta mavjudlik nuqtasi, yaxshi ayyorlik tezligi va shu bilan birga, bizda bu mashinalarda bo'sh CPU yo'q. U endi, albatta, avvalgidan ham muhimroq bo'lib qoldi. Biz o'zimizga kuchliroq mashinalarni berishimiz kerak, ammo bunga arziydi.
Bu fotosuratlarni qaytarish bilan bog'liq. Bu erda hamma narsa aniq va aniq. Men Amerikani kashf qilmaganman deb o'ylayman, deyarli har qanday CDN shu tarzda ishlaydi.
Va, ehtimol, murakkab tinglovchida savol bo'lishi mumkin: nima uchun hamma narsani CDN-ga o'zgartirmaslik kerak? Bu taxminan bir xil bo'ladi; barcha zamonaviy CDNlar buni qila oladi. Va bir qancha sabablar bor.
Birinchisi - fotosuratlar.
Bu bizning infratuzilmamizning asosiy nuqtalaridan biri va biz uni imkon qadar ko'proq nazorat qilishimiz kerak. Agar bu uchinchi tomon sotuvchisining qandaydir yechimi bo'lsa va sizda bu borada hech qanday kuch bo'lmasa, sizda katta ma'lumotlar to'plamiga ega bo'lganingizda va juda katta oqimga ega bo'lsangiz, u bilan yashash juda qiyin bo'ladi. foydalanuvchi so'rovlari.
Sizga bir misol keltiraman. Endi, infratuzilmamiz bilan, masalan, ba'zi muammolar yoki er osti taqillatishlari bo'lsa, mashinaga borib, nisbatan aytganda, u erda chalkashlik qilishimiz mumkin. Biz faqat kerak bo'lgan ba'zi o'lchovlar to'plamini qo'shishimiz mumkin, biz qandaydir tarzda tajriba o'tkazishimiz, bu grafiklarga qanday ta'sir qilishini ko'rishimiz mumkin va hokazo. Endi ushbu keshlash klasterida ko'plab statistik ma'lumotlar to'planmoqda. Va biz vaqti-vaqti bilan unga qaraymiz va ba'zi anomaliyalarni o'rganish uchun uzoq vaqt sarflaymiz. Agar u CDN tomonida bo'lsa, uni nazorat qilish ancha qiyin bo'lar edi. Yoki, masalan, qandaydir baxtsiz hodisa yuz bergan bo'lsa, biz nima bo'lganini bilamiz, u bilan qanday yashashni va uni qanday engish kerakligini bilamiz. Bu birinchi xulosa.
Ikkinchi xulosa ham ancha tarixiydir, chunki tizim uzoq vaqtdan beri rivojlanib kelmoqda va turli bosqichlarda turli xil biznes talablari mavjud edi va ular har doim ham CDN kontseptsiyasiga mos kelmaydi.
Va avvalgisidan kelib chiqadigan nuqta
Buning sababi shundaki, fotosurat keshlarida bizda juda ko'p o'ziga xos mantiq bor, ularni har doim ham so'rov bo'yicha qo'shib bo'lmaydi. Har qanday CDN sizning so'rovingiz bo'yicha sizga ba'zi narsalarni qo'shishi dargumon. Misol uchun, agar mijoz biror narsani o'zgartira olishini xohlamasangiz, URL manzillarini shifrlash. Serverdagi URL-manzilni o'zgartirib, uni shifrlamoqchimisiz, so'ngra bu yerga ba'zi dinamik parametrlarni yuboring.
Bu qanday xulosani taklif qiladi? Bizning holatlarimizda CDN juda yaxshi alternativ emas.
Va sizning holatingizda, agar sizda biron bir biznes talablari bo'lsa, men o'zingiz ko'rsatgan narsani osongina amalga oshirishingiz mumkin. Va bu xuddi shunday yuk profili bilan mukammal ishlaydi.
Ammo agar sizda qandaydir umumiy yechim mavjud bo'lsa va vazifa unchalik aniq bo'lmasa, siz CDNni mutlaqo xavfsiz qabul qilishingiz mumkin. Yoki vaqt va resurslar siz uchun nazoratdan ko'ra muhimroq bo'lsa.
Zamonaviy CDN-larda men hozir aytganlarimning deyarli barchasi mavjud. Plyus yoki minus ba'zi xususiyatlar bundan mustasno.
Bu fotosuratlarni berish haqida.
Keling, retrospektivimizda biroz oldinga siljiymiz va saqlash haqida gapiramiz.
2013 yil o'tayotgan edi.
Keshlash serverlari qo'shildi, ishlash muammolari yo'qoldi. Hammasi yaxshi. Ma'lumotlar to'plami o'sib bormoqda. 2013 yil holatiga ko'ra, bizda saqlashga ulangan 80 ga yaqin server va har bir DCda 40 ga yaqin keshlash mavjud edi. Bu har bir DCda 560 terabayt ma'lumot, ya'ni. jami petabaytga yaqin.
Va ma'lumotlar to'plamining o'sishi bilan operatsion xarajatlar sezilarli darajada o'sishni boshladi. Bu nimani anglatadi?
Chizilgan ushbu diagrammada - SAN bilan, unga ulangan mashinalar va keshlar bilan - ko'plab nosozliklar mavjud. Agar biz ilgari serverlarni keshlashning ishdan chiqishi bilan shug'ullangan bo'lsak, hamma narsa ko'proq yoki kamroq bashorat qilinadigan va tushunarli edi, lekin saqlash tomonida hamma narsa yomonroq edi.
Birinchidan, Storage Area Network (SAN) ning o'zi, bu muvaffaqiyatsiz bo'lishi mumkin.
Ikkinchidan, u optika orqali oxirgi mashinalarga ulanadi. Optik kartalar va shamlar bilan bog'liq muammolar bo'lishi mumkin.
Albatta, ularning soni SAN ning o'zida bo'lgani kabi emas, lekin shunga qaramay, bular ham muvaffaqiyatsizlik nuqtalari.
Keyinchalik, saqlashga ulangan mashinaning o'zi. Bundan tashqari, muvaffaqiyatsiz bo'lishi mumkin.
Umuman olganda, bizda uchta muvaffaqiyatsizlik bor.
Bundan tashqari, nosozlik nuqtalariga qo'shimcha ravishda, saqlashning o'ziga ham jiddiy texnik xizmat ko'rsatish mavjud.
Bu murakkab ko'p komponentli tizim bo'lib, tizim muhandislari u bilan ishlashda qiyinchiliklarga duch kelishlari mumkin.
Va oxirgi, eng muhim nuqta. Agar ushbu uchta nuqtadan birida nosozlik yuzaga kelsa, bizda foydalanuvchi ma'lumotlarini yo'qotish ehtimoli nolga teng, chunki fayl tizimi ishdan chiqishi mumkin.
Aytaylik, fayl tizimimiz buzilgan. Birinchidan, uning tiklanishi uzoq vaqt talab etadi - katta hajmdagi ma'lumotlar bilan bir hafta davom etishi mumkin. Ikkinchidan, oxirida biz tushunarsiz fayllar to'plamiga ega bo'lamiz, ularni qandaydir tarzda foydalanuvchi fotosuratlariga birlashtirish kerak bo'ladi. Va biz ma'lumotlarni yo'qotish xavfi bor. Xavf ancha yuqori. Va bunday holatlar qanchalik tez-tez sodir bo'lsa va butun zanjirda qanchalik ko'p muammolar paydo bo'lsa, bu xavf shunchalik yuqori bo'ladi.
Bu borada nimadir qilish kerak edi. Va biz faqat ma'lumotlarni zaxiralashimiz kerak deb qaror qildik. Bu, aslida, aniq va yaxshi yechim. Biz nima qildik?
Bizning serverimiz avval xotiraga ulanganda shunday ko'rinishga ega edi. Bu bitta asosiy bo'lim, bu shunchaki optika orqali masofaviy saqlash uchun moslamani ifodalovchi blokli qurilma.
Biz faqat ikkinchi qismni qo'shdik.
Biz uning yoniga ikkinchi saqlash joyini joylashtirdik (xayriyatki, bu pul jihatidan unchalik qimmat emas) va uni zaxira bo'limi deb nomladik. U optika orqali ham ulanadi va xuddi shu mashinada joylashgan. Lekin biz qandaydir tarzda ular orasidagi ma'lumotlarni sinxronlashtirishimiz kerak.
Bu erda biz shunchaki yaqin joyda asinxron navbat hosil qilamiz.
U unchalik band emas. Bizda rekordlar yetarli emasligini bilamiz. Navbat shunchaki MySQL-dagi jadval bo'lib, unda "siz ushbu fotosuratni zaxiralashingiz kerak" kabi qatorlar yozilgan. Har qanday o'zgartirish yoki yuklash bilan biz asinxron yoki shunchaki fon ishchisi yordamida asosiy bo'limdan zaxiraga nusxa olamiz.
Shunday qilib, biz doimo ikkita izchil bo'limga egamiz. Ushbu tizimning bir qismi muvaffaqiyatsiz bo'lsa ham, biz har doim asosiy bo'limni zaxira bilan o'zgartirishimiz mumkin va hamma narsa ishlashda davom etadi.
Ammo shu sababli, o'qish yuki sezilarli darajada oshadi, chunki ... asosiy bo'limdan o'qigan mijozlarga qo'shimcha ravishda, chunki ular birinchi navbatda u erda fotosuratga qarashadi (u erda yangiroq), keyin uni topa olmasalar, zaxiradan qidiradilar (lekin NGINX buni qiladi), bizning tizim ham ortiqcha zaxira endi asosiy bo'limdan o'qiydi. Bu qiyinchilik emas, lekin men yukni oshirishni xohlamadim, asosan, xuddi shunday.
Va biz kichik SSD bo'lgan uchinchi diskni qo'shdik va uni bufer deb nomladik.
Endi u qanday ishlaydi.
Foydalanuvchi buferga fotosurat yuklaydi, keyin navbatga voqea ikki qismga ko'chirilishi kerakligini ko'rsatadi. U nusxalanadi va fotosurat buferda bir muncha vaqt (aytaylik, bir kun) yashaydi va shundan keyingina u erdan tozalanadi. Bu foydalanuvchi tajribasini sezilarli darajada yaxshilaydi, chunki foydalanuvchi fotosuratni yuklaydi, qoida tariqasida, so'rovlar darhol bajarila boshlaydi yoki o'zi sahifani yangiladi va uni yangiladi. Lekin barchasi yuklashni amalga oshiradigan dasturga bog'liq.
Yoki, masalan, u o'zini ko'rsatishni boshlagan boshqa odamlar ushbu fotosuratdan keyin darhol so'rov yuborishadi. U hali keshda yo'q; birinchi so'rov juda tez sodir bo'ladi. Fotosurat keshidagi bilan bir xil. Sekin saqlash bunga umuman aloqador emas. Va bir kundan keyin u tozalanganda, u bizning keshlash qatlamimizda keshlangan yoki, ehtimol, endi hech kimga kerak emas. Bular. Bunday oddiy manipulyatsiyalar tufayli bu erda foydalanuvchi tajribasi juda yaxshi o'sdi.
Xo'sh, va eng muhimi: biz ma'lumotlarni yo'qotishni to'xtatdik.
Aytaylik, biz to'xtadik potentsial ma'lumotlarni yo'qotamiz, chunki biz uni yo'qotmadik. Ammo xavf bor edi. Ko'ramiz, bu yechim, albatta, yaxshi, lekin bu muammoni butunlay hal qilish o'rniga, uning alomatlarini yumshatishga o'xshaydi. Va bu erda ba'zi muammolar qolmoqda.
Birinchidan, bu barcha mexanizmlar ishlaydigan jismoniy xostning o'zi ko'rinishidagi muvaffaqiyatsizlik nuqtasidir; u o'tib ketmagan.
Ikkinchidan, SAN'lar bilan bog'liq muammolar hali ham mavjud, ularga jiddiy texnik xizmat ko'rsatish va hokazo. Bu muhim omil emas edi, lekin men qandaydir tarzda usiz yashashga harakat qilmoqchi edim.
Va biz uchinchi versiyani (aslida ikkinchisini) - bron qilish versiyasini yaratdik. Bu nimaga o'xshardi?
Bu shunday edi -
Bizning asosiy muammolarimiz bu jismoniy uy egasi ekanligi bilan bog'liq.
Birinchidan, biz SAN'larni olib tashlaymiz, chunki biz tajriba o'tkazmoqchimiz, faqat mahalliy qattiq disklarni sinab ko'rmoqchimiz.
Bu allaqachon 2014-2015 yillar va o'sha paytda bitta xostdagi disklar va ularning sig'imi bilan bog'liq vaziyat ancha yaxshilandi. Nega sinab ko'rmaslikka qaror qildik.
Va keyin biz shunchaki zaxira bo'limimizni olamiz va uni jismoniy ravishda alohida mashinaga o'tkazamiz.
Shunday qilib, biz ushbu diagrammani olamiz. Bizda bir xil ma'lumotlar to'plamini saqlaydigan ikkita mashina bor. Ular bir-birining to'liq zaxira nusxasini yaratadilar va bir xil MySQL-da asinxron navbat orqali tarmoq orqali ma'lumotlarni sinxronlashtiradilar.
Nima uchun bu yaxshi ishlaydi, chunki bizda bir nechta yozuvlar mavjud. Bular. Agar yozishni o'qish bilan solishtirish mumkin bo'lsa, ehtimol bizda qandaydir tarmoq yuki va muammolari bo'lar edi. Bir oz yozish, ko'p o'qish - bu usul yaxshi ishlaydi, ya'ni. Biz bu ikki server o'rtasida fotosuratlarni kamdan-kam nusxalaymiz.
Bu qanday ishlaydi, agar siz biroz batafsilroq ko'rib chiqsangiz.
Yuklash. Balanslashtiruvchi shunchaki juftlik bilan tasodifiy xostlarni tanlaydi va unga yuklaydi. Shu bilan birga, u tabiiy ravishda sog'lig'ini tekshiradi va mashina tushib ketmasligiga ishonch hosil qiladi. Bular. u fotosuratlarni faqat jonli serverga yuklaydi, keyin esa asinxron navbat orqali hammasi qo'shnisiga ko'chiriladi. Yuklab olish bilan hamma narsa juda oddiy.
Vazifa biroz qiyinroq.
Bu erda bizga Lua yordam berdi, chunki vanil NGINX-da bunday mantiqni qilish qiyin bo'lishi mumkin. Biz birinchi bo'lib birinchi serverga so'rov yuboramiz, fotosurat u erda yoki yo'qligini bilib olamiz, chunki uni, masalan, qo'shniga yuklash mumkin, lekin bu erga hali kelmagan. Agar fotosurat u erda bo'lsa, bu yaxshi. Biz uni darhol mijozga beramiz va, ehtimol, keshlaymiz.
Agar u yo'q bo'lsa, biz shunchaki qo'shnimizga so'rov yuboramiz va u erdan olish kafolatlanadi.
Bu. yana aytishimiz mumkin: ishlash bilan bog'liq muammolar bo'lishi mumkin, chunki doimiy aylanma sayohatlar mavjud - fotosurat yuklangan, u bu erda emas, biz bitta so'rov o'rniga ikkita so'rov yubormoqdamiz, bu sekin ishlashi kerak.
Bizning vaziyatimizda bu sekin ishlamaydi.
Biz ushbu tizimda bir qancha ko'rsatkichlarni yig'amiz va bunday mexanizmning shartli aqlli darajasi taxminan 95% ni tashkil qiladi. Bular. Ushbu zaxiraning kechikishi kichik va shuning uchun biz deyarli kafolatlanganmiz, fotosurat yuklangandan keyin biz uni birinchi marta olamiz va ikki marta hech qaerga borishimiz shart emas.
Xo'sh, bizda juda ajoyib yana nima bor?
Ilgari bizda asosiy zaxira bo'limi bor edi va biz ulardan ketma-ket o'qiymiz. Bular. Biz har doim birinchi navbatda asosiysini, keyin esa zaxirani qidirardik. Bu bitta harakat edi.
Endi biz bir vaqtning o'zida ikkita mashinadan o'qishdan foydalanamiz. Biz so'rovlarni Round Robin yordamida tarqatamiz. Kam hollarda biz ikkita so'rov yuboramiz. Ammo umuman olganda, hozir bizda avvalgidan ikki baravar ko'p o'qish zaxiralari mavjud. Va yuk jo'natuvchi mashinalarda ham, to'g'ridan-to'g'ri o'sha paytda bizda ham bo'lgan saqlash mashinalarida sezilarli darajada kamaydi.
Xatolarga chidamliligiga kelsak. Aslida, biz asosan shu uchun kurashganmiz. Xatolarga chidamlilik bilan bu erda hamma narsa ajoyib bo'ldi.
Bir mashina buziladi.
Hammasi joyida! Tizim muhandisi hatto kechasi ham uyg'onmasligi mumkin, u ertalabgacha kutadi, hech qanday yomon narsa bo'lmaydi.
Agar bu mashina ishdan chiqqan bo'lsa ham, navbat ishdan chiqqan bo'lsa, hech qanday muammo bo'lmasa, jurnal avval tirik mashinada to'planadi, keyin u navbatga qo'shiladi, keyin esa mashinaga qo'shiladi. bir muncha vaqt o'tgach, ishga kirish.
Xizmat bilan ham xuddi shunday. Biz shunchaki mashinalardan birini o'chirib qo'yamiz, uni barcha hovuzlardan qo'l bilan tortib olamiz, u trafikni qabul qilishni to'xtatadi, biz qandaydir texnik xizmat ko'rsatamiz, biz biror narsani tahrirlaymiz, keyin uni xizmatga qaytaramiz va bu zaxira juda tez ushlanib qoladi. Bular. kuniga bitta mashinaning ishlamay qolishi bir necha daqiqaga yetadi. Bu haqiqatan ham juda oz. Xatolarga chidamlilik bilan, yana aytaman, bu erda hamma narsa ajoyib.
Ushbu ortiqcha sxemadan qanday xulosalar chiqarish mumkin?
Bizda xatolarga chidamlilik bor.
Foydalanish oson. Mashinalarda mahalliy qattiq disklar mavjud bo'lganligi sababli, bu u bilan ishlaydigan muhandislar uchun operatsion nuqtai nazardan ancha qulaydir.
Ikki marta o‘qish uchun nafaqa oldik.
Bu xatoga chidamlilikdan tashqari, juda yaxshi bonusdir.
Lekin muammolar ham bor. Endi bizda bu bilan bog'liq ba'zi xususiyatlarning ancha murakkab rivojlanishi bor, chunki tizim oxir-oqibat 100% izchil bo'ldi.
Aytaylik, biron bir fon ishida biz doimo o'ylashimiz kerak: "Biz hozir qaysi serverda ishlayapmiz?", "Bu erda haqiqatan ham hozirgi fotosurat bormi?" va hokazo. Bu, albatta, hammasi yakunlanadi va biznes mantig'ini yozadigan dasturchi uchun shaffofdir. Ammo, shunga qaramay, bu katta murakkab qatlam paydo bo'ldi. Ammo biz undan olgan yaxshilik evaziga bunga chidashga tayyormiz.
Va bu erda yana qandaydir ziddiyat paydo bo'ladi.
Men boshida hamma narsani mahalliy qattiq disklarda saqlash yomon ekanligini aytdim. Va endi aytaman, bu bizga yoqdi.
Ha, haqiqatan ham, vaqt o'tishi bilan vaziyat juda o'zgardi va endi bu yondashuv juda ko'p afzalliklarga ega. Birinchidan, biz operatsiyani ancha soddalashtiramiz.
Ikkinchidan, bu samaraliroq, chunki bizda bunday avtomatik boshqaruvchilar yoki disk javonlariga ulanishlar yo'q.
U erda juda ko'p mashinalar mavjud va bu mashinada reydga yig'ilgan bir nechta disklar.
Lekin kamchiliklari ham bor.
Bu bugungi narxlarda ham SAN lardan foydalanishdan taxminan 1,5 baravar qimmatroq. Shuning uchun biz butun yirik klasterimizni mahalliy qattiq disklari bo'lgan avtomobillarga jasorat bilan aylantirmaslikka qaror qildik va gibrid yechimni qoldirishga qaror qildik.
Mashinalarimizning yarmi qattiq disklar bilan ishlaydi (yaxshi, yarmi emas - ehtimol 30 foiz). Qolganlari esa birinchi bron qilish sxemasiga ega bo'lgan eski mashinalardir. Biz ularni shunchaki qayta o'rnatdik, chunki bizga yangi ma'lumotlar yoki boshqa hech narsa kerak emas edi, biz shunchaki o'rnatishlarni bitta jismoniy xostdan ikkitaga o'tkazdik.
Va endi bizda o'qishning katta zaxirasi bor va biz uni kengaytirdik. Agar ilgari biz bitta xotirani bitta mashinaga o'rnatgan bo'lsak, endi biz to'rttasini, masalan, bitta juftlikka o'rnatamiz. Va u yaxshi ishlaydi.
Keling, nimaga erishganimiz, nima uchun kurashganimiz va muvaffaqiyatga erishganimiz haqida qisqacha ma'lumot beraylik.
natijalar
Bizning foydalanuvchilarimiz bor - 33 millionga yaqin.
Bizda uchta mavjud nuqta bor - Praga, Mayami, Gonkong.
Ular tezkor mahalliy disklarga (SSD) ega avtomobillardan tashkil topgan keshlash qatlamini o'z ichiga oladi, ularda NGINX oddiy texnikalari, uning access.log va Python demonlari ishlaydi, bularning barchasini qayta ishlaydi va keshni boshqaradi.
Agar xohlasangiz, siz o'zingizning loyihangizdasiz, agar fotosuratlar siz uchun biz uchun bo'lgani kabi muhim bo'lmasa yoki rivojlanish tezligi va resurs xarajatlari bilan taqqoslash siz uchun boshqa yo'nalishda bo'lsa, uni xavfsiz almashtirishingiz mumkin. CDN bilan zamonaviy CDNlar yaxshi ishlaydi.
Keyinchalik saqlash qatlami keladi, unda bizda bir-birining zaxira nusxasini yaratadigan juft mashinalar klasterlari mavjud, fayllar har doim o'zgarganda asinxron ravishda biridan ikkinchisiga ko'chiriladi.
Bundan tashqari, ushbu mashinalarning ba'zilari mahalliy qattiq disklar bilan ishlaydi.
Ushbu mashinalarning ba'zilari SAN-larga ulangan.
Va, bir tomondan, foydalanish uchun qulayroq va biroz samaraliroq, boshqa tomondan, joylashtirish zichligi va gigabayt narxi bo'yicha qulay.
Bu biz olgan narsalarning arxitekturasi va barchasi qanday rivojlanganligi haqida qisqacha ma'lumot.
Kapitandan yana bir nechta maslahatlar, juda oddiy.
Birinchidan, agar siz to'satdan foto infratuzilmangizdagi hamma narsani zudlik bilan yaxshilashga qaror qilsangiz, avval o'lchab ko'ring, chunki hech narsani yaxshilash kerak emas.
Sizga bir misol keltiraman. Bizda chatlardagi qo'shimchalardan fotosuratlar yuboradigan mashinalar klasteri mavjud va sxema 2009 yildan beri u erda ishlaydi va hech kim bundan aziyat chekmaydi. Hamma yaxshi, hamma hamma narsani yaxshi ko'radi.
O'lchash uchun birinchi navbatda bir nechta ko'rsatkichlarni osib qo'ying, ularga qarang va keyin nimadan norozi ekanligingizni va nimani yaxshilash kerakligini hal qiling. Buni o'lchash uchun bizda Pinba deb nomlangan ajoyib vosita mavjud.
Bu sizga har bir soʻrov va javob kodlari uchun NGINX’dan juda batafsil statistik maʼlumotlarni toʻplash va vaqtlarni taqsimlash imkonini beradi – xohlaganingizcha. U har xil turdagi tahliliy tizimlar bilan bog'langan va keyin siz hamma narsani chiroyli ko'rishingiz mumkin.
Avval o‘lchab, keyin yaxshiladik.
Keyinchalik. Biz kesh bilan o'qishni, sharding bilan yozishni optimallashtiramiz, ammo bu aniq nuqta.
Keyinchalik. Agar siz tizimingizni endigina qurishni boshlayotgan bo'lsangiz, fotosuratlarni o'zgarmas fayllar sifatida yaratish yaxshiroqdir. Chunki siz keshni yaroqsizlantirish, mantiq qanday qilib fotosuratning to'g'ri versiyasini topishi va hokazolar bilan bog'liq muammolarning butun sinfini darhol yo'qotasiz.
Aytaylik, siz yuzta yukladingiz, keyin uni aylantirdingiz va uni jismonan boshqa faylga aylantiring. Bular. o'ylashning hojati yo'q: endi men bir oz joyni tejayman, uni xuddi shu faylga yozaman, versiyani o'zgartiraman. Bu har doim ham yaxshi ishlamaydi va keyinchalik ko'p bosh og'rig'iga sabab bo'ladi.
Keyingi nuqta. Tezda o'lchamini o'zgartirish haqida.
Ilgari, foydalanuvchilar fotosuratni yuklaganlarida, biz darhol barcha holatlar uchun, turli mijozlar uchun o'lchamlarni kesib tashladik va ularning barchasi diskda edi. Endi biz bundan voz kechdik.
Biz faqat uchta asosiy o'lchamni qoldirdik: kichik, o'rta va katta. Biz shunchaki Uport-da bizga so'ralgan o'lchamdan orqada qolgan hamma narsani pasaytiramiz, biz shunchaki pasaytirishni amalga oshiramiz va uni foydalanuvchiga beramiz.
Bu erda keshlash qatlamining protsessorlari har bir xotirada ushbu o'lchamlarni doimiy ravishda qayta tiklaganimizdan ko'ra ancha arzonroq bo'ladi. Aytaylik, biz yangisini qo'shmoqchimiz, bunga bir oy kerak bo'ladi - bularning barchasini klasterni buzmasdan, aniq bajaradigan skriptni hamma joyda ishga tushiring. Bular. Agar sizda hozir tanlash imkoni bo'lsa, iloji boricha kamroq jismoniy o'lchamlarni qilish yaxshiroqdir, lekin hech bo'lmaganda bir nechta taqsimot, aytaylik, uchta bo'lishi uchun. Va qolgan hamma narsani tayyor modullar yordamida tezda o'zgartirish mumkin. Hozir hammasi juda oson va foydalanish mumkin.
Va qo'shimcha asenkron zaxira yaxshi.
Bizning amaliyotimiz ko'rsatganidek, ushbu sxema o'zgartirilgan fayllarni kechiktirilgan nusxalash bilan ajoyib ishlaydi.
Oxirgi nuqta ham aniq. Agar sizning infratuzilmangizda hozir bunday muammolar bo'lmasa, lekin buzilmasligi mumkin bo'lgan narsa bo'lsa, u biroz ko'proq bo'lganda, albatta buziladi. Shuning uchun, bu haqda oldindan o'ylash va u bilan bog'liq muammolarga duch kelmaslik yaxshiroqdir. Aytmoqchi bo‘lganim shu edi.
Aloqalar
»
»
Ushbu ma'ruza yuqori yuklangan tizimlarni ishlab chiquvchilar konferentsiyasidagi eng yaxshi nutqlardan birining transkriptidir . HighLoad++ 2017 konferensiyasiga bir oydan kamroq vaqt qoldi.
Bizda allaqachon tayyor , hozirda jadval faol shakllantirilmoqda.
Bu yil biz arxitektura va masshtabni o'rganishni davom ettirmoqdamiz:
- / Igor Vasilev
- / Dmitriy Egorov
- / Anatoliy Plaskovskiy
- / Roman Shexovtsov, Aleksey Gromatchikov
- / Filipp Delgado
Biz ushbu materiallarning ba'zilarini yuqori yuklangan tizimlarni ishlab chiqish bo'yicha onlayn o'quv kursimizda ham ishlatamiz maxsus tanlangan harflar, maqolalar, materiallar, videolar zanjiri. Bizning darsligimizda allaqachon 30 dan ortiq noyob materiallar mavjud. Ulanmoq!
Manba: www.habr.com