Biz hamımız hekayələri sevirik. Biz odun ətrafında oturub keçmiş qələbələrimiz, döyüşlərimiz və ya sadəcə iş təcrübəmiz haqqında danışmağı sevirik.
Bu gün məhz belə bir gündür. Hal-hazırda yanğında olmasanız belə, sizin üçün bir hekayəmiz var. Tarantool-da saxlama ilə necə işləməyə başladığımızın hekayəsi.
Bir vaxtlar şirkətimizin hamı üçün bir-iki “monolit”i və bir “tavanı” var idi ki, bu monolitlər yavaş-yavaş, lakin əminliklə yaxınlaşırdı, şirkətimizin uçuşunu, inkişafımızı məhdudlaşdırırdı. Və aydın bir anlayış var idi: bir gün biz bu tavanı möhkəm vuracağıq.
İndi avadanlıqdan tutmuş biznes məntiqinə qədər hər şeyi və hər kəsi ayırmaq ideologiyası üstünlük təşkil edir. Nəticədə, bizdə, məsələn, şəbəkə səviyyəsində praktiki olaraq müstəqil olan iki DC var. Və sonra hər şey tamamilə fərqli oldu.
Bu gün CI/CD, K8S və s. şəklində dəyişikliklər etmək üçün çoxlu alətlər və alətlər mövcuddur. “Monolit” dövründə bizə bu qədər əcnəbi söz lazım deyildi. Verilənlər bazasındakı "saxlamanı" düzəltmək kifayət idi.
Ancaq vaxt irəli getdi və sorğuların sayı da onunla birlikdə irəlilədi, bəzən RPS imkanlarımızdan kənara çıxdı. MDB ölkələrinin bazara daxil olması ilə ilk monolitin verilənlər bazası prosessorunun yükü 90%-dən aşağı düşmədi və RPS 2400 səviyyəsində qaldı. Bunlar təkcə kiçik seçicilər deyil, həm də böyük sorğular idi. böyük IO fonunda məlumatların demək olar ki, yarısı üçün işləyə bilən bir dəstə çek və JOIN.
Tam hüquqlu Qara Cümə satışları səhnədə görünməyə başlayanda - və Wildberries Rusiyada onları ilk keçirənlərdən biri idi - vəziyyət tamamilə kədərli oldu. Axı belə günlərdə yük üç dəfə artır.
Oh, bu "monolit dövrlər"! Əminəm ki, siz də buna bənzər bir şeylə qarşılaşmısınız və bunun sizinlə necə baş verə biləcəyini hələ də başa düşə bilmirsiniz.
Nə edə bilərsiniz - moda texnologiyaya xasdır. Təxminən 5 il əvvəl biz bu modlardan birini saytın özünün bütün məntiqini diqqətlə saxlayan .NET və MS SQL serverində mövcud sayt şəklində yenidən nəzərdən keçirməli olduq. Mən onu o qədər diqqətlə saxladım ki, belə bir monolit mişar etmək uzun və heç də asan olmayan bir zövq oldu.
Kiçik bir fərq.
Müxtəlif tədbirlərdə deyirəm: "Əgər monolit görməmisənsə, deməli böyüməmisən!" Bu məsələ ilə bağlı fikriniz məni maraqlandırır, zəhmət olmasa şərhlərdə yazın.
Bir ildırım səsi
Qayıdaq öz “tonqal”ımıza. “Monolit” funksionallıq yükünü bölüşdürmək üçün sistemi açıq mənbə texnologiyalarına əsaslanan mikroservislərə bölmək qərarına gəldik. Çünki, ən azı, onların miqyası daha ucuzdur. Və biz 100% başa düşdük ki, miqyas almalı olacağıq (və çoxlu). Axı, artıq o dövrdə qonşu ölkələrin bazarlarına çıxmaq mümkün idi və qeydiyyat, eləcə də sifarişlərin sayı daha da güclü artmağa başladı.
Monolitdən mikroservislərə keçmək üçün ilk namizədləri təhlil etdikdən sonra anladıq ki, onlarda yazıların 80%-i back-ofis sistemlərindən, oxu isə ön ofisdən gəlir. İlk növbədə, bu, bizim üçün bir neçə vacib alt sistemə aiddir - istifadəçi məlumatları və əlavə müştəri endirimləri və kuponları haqqında məlumat əsasında malların son dəyərinin hesablanması sistemi.
girintili. İndi təsəvvür etmək qorxuludur, lakin yuxarıda qeyd olunan alt sistemlərdən əlavə məhsul kataloqları, istifadəçi səbəti, məhsul axtarış sistemi, məhsul kataloqları üçün filtrasiya sistemi, müxtəlif növ tövsiyə sistemləri də monolitimizdən çıxarılıb. Onların hər birinin işləməsi üçün dar uyğunlaşdırılmış sistemlərin ayrı-ayrı sinifləri var, lakin bir vaxtlar hamısı bir "evdə" yaşayırdılar.
Müştərilərimiz haqqında məlumatları dərhal parçalanmış sistemə köçürməyi planlaşdırdıq. Malların son dəyərini hesablamaq üçün funksionallığın aradan qaldırılması oxumaq üçün yaxşı miqyaslılıq tələb etdi, çünki o, ən böyük RPS yükünü yaratdı və verilənlər bazası üçün həyata keçirilməsi ən çətin idi (hesablama prosesində çoxlu məlumatlar iştirak edir).
Nəticədə, Tarantool ilə yaxşı uyğunlaşan bir sxem hazırladıq.
O zaman mikroservislərin işləməsi üçün virtual və aparat maşınlarında bir neçə məlumat mərkəzləri ilə işləmək sxemləri seçilirdi. Şəkillərdə göstərildiyi kimi, Tarantool replikasiya variantları həm master-master, həm də master-slave rejimlərində tətbiq edilmişdir.
Memarlıq. Seçim 1. İstifadəçi xidməti
Hazırda hər birində 24 instansiya (hər DC üçün bir), hamısı master-master rejimində olan 2 parça var.
Verilənlər bazasının üstündə verilənlər bazası replikalarına daxil olan proqramlar var. Proqramlar Tarantool Go sürücü interfeysini tətbiq edən xüsusi kitabxanamız vasitəsilə Tarantool ilə işləyir. O, bütün replikaları görür və oxumaq və yazmaq üçün usta ilə işləyə bilər. Əsasən, o, replikaların seçilməsi, təkrar cəhdlərin yerinə yetirilməsi, elektron açar və sürət həddi üçün məntiq əlavə edən replika dəsti modelini həyata keçirir.
Bu halda, replika seçimi siyasətini qırıntılar kontekstində konfiqurasiya etmək mümkündür. Məsələn, roundrobin.
Memarlıq. Variant 2. Malların son dəyərinin hesablanması xidməti
Bir neçə ay əvvəl, malların son dəyərinin hesablanması üçün sorğuların əksəriyyəti, prinsipcə, verilənlər bazası olmadan işləyən yeni bir xidmətə getdi, lakin bir müddət əvvəl hər şey başlıq altında Tarantool ilə bir xidmət tərəfindən 100% emal edildi.
Xidmət verilənlər bazası sinxronizatorun məlumatları topladığı 4 masterdan ibarətdir və bu replikasiya ustalarının hər biri məlumatları yalnız oxunan replikalara paylayır. Hər ustada təxminən 15 belə replika var.
Birinci və ya ikinci sxemdə bir DC mövcud deyilsə, proqram ikincidə məlumat ala bilər.
Qeyd etmək lazımdır ki, Tarantool-da replikasiya olduqca çevikdir və iş vaxtında konfiqurasiya edilə bilər. Digər sistemlərdə çətinliklər yarandı. Məsələn, PostgreSQL-də max_wal_senders və max_replication_slots parametrlərinin dəyişdirilməsi sehrbazın yenidən işə salınmasını tələb edir ki, bu da bəzi hallarda proqram və DBMS arasında əlaqələrin kəsilməsinə səbəb ola bilər.
Axtarın və tapacaqsınız!
Niyə biz bunu “normal insanlar kimi” etmədik, atipik bir yol seçdik? Bu, normal hesab ediləndən asılıdır. Bir çox insan ümumiyyətlə Mongo-dan bir klaster düzəldir və onu üç coğrafi paylanmış DC-yə yayır.
O vaxt bizim artıq iki Redis layihəmiz var idi. Birincisi önbellek, ikincisi isə çox kritik olmayan məlumatlar üçün davamlı yaddaş idi. Onunla kifayət qədər çətin oldu, qismən də bizim günahımız üzündən. Bəzən kifayət qədər böyük həcmlər açarda olurdu və zaman zaman sayt pisləşirdi. Biz bu sistemi master-slave versiyasında istifadə etdik. Və bir çox hallar olub ki, ustaya nəsə olub və replikasiya pozulub.
Yəni, Redis statuslu deyil, vətəndaşlığı olmayan vəzifələr üçün yaxşıdır. Prinsipcə, bu, əksər problemləri həll etməyə imkan verirdi, ancaq onlar bir cüt indekslə əsas-dəyər həlləri olsaydı. Lakin Redis o vaxt əzmkarlıq və təkrarlama ilə olduqca kədərli idi. Bundan əlavə, performansla bağlı şikayətlər olub.
MySQL və PostgreSQL haqqında düşündük. Ancaq birincisi birtəhər bizi tutmadı, ikincisi isə özlüyündə olduqca mürəkkəb məhsuldur və onun üzərində sadə xidmətlər qurmaq yersiz olardı.
RIAK, Cassandra, hətta qrafik verilənlər bazasını da sınadıq. Bunların hamısı xidmətlərin yaradılması üçün ümumi universal alət roluna uyğun olmayan kifayət qədər niş həllərdir.
Nəhayət, Tarantool-a yerləşdik.
1.6 versiyada olanda ona müraciət etdik. Bizi onunla açar-dəyər simbiozu və əlaqəli verilənlər bazasının funksionallığı maraqlandırırdı. İkinci dərəcəli indekslər, əməliyyatlar və boşluqlar var, bunlar cədvəllərə bənzəyir, lakin sadə deyil, onlarda müxtəlif sayda sütun saxlaya bilərsiniz. Lakin Tarantool-un öldürücü xüsusiyyəti açar-dəyər və əməliyyat qabiliyyəti ilə birləşən ikinci dərəcəli indekslər idi.
Çatda kömək etməyə hazır olan həssas rusdilli icma da rol oynadı. Biz bundan fəal şəkildə istifadə etdik və birbaşa söhbətdə yaşayırıq. Aşkar səhvlər və səhvlər olmadan layiqli davamlılığı unutma. Tarantool ilə tariximizə baxsanız, replikasiya ilə bağlı çox ağrı və uğursuzluqlarımız oldu, lakin onun günahı üzündən heç vaxt məlumatları itirmədik!
Tətbiq çətin bir başlanğıcla başladı
O zaman bizim əsas inkişaf yığınımız Tarantool üçün heç bir bağlayıcı olmayan .NET idi. Biz dərhal Go-da nəsə etməyə başladıq. Lua ilə də yaxşı işləyirdi. O zaman əsas problem sazlama ilə idi: .NET-də bununla hər şey əladır, lakin bundan sonra loglardan başqa heç bir sazlama olmadıqda, quraşdırılmış Lua dünyasına qərq olmaq çətin idi. Bundan əlavə, nədənsə təkrarlama vaxtaşırı dağıldı, buna görə Tarantool mühərrikinin strukturunu araşdırmalı oldum. Çat bu işdə kömək etdi və daha az dərəcədə sənədlər; bəzən koda baxırdıq. O vaxt sənədlər belə idi.
Beləliklə, bir neçə ay ərzində mən başımı çevirə bildim və Tarantool ilə işləməkdən layiqli nəticələr əldə etdim. Biz git-də yeni mikroservislərin formalaşmasına kömək edən istinad inkişaflarını tərtib etdik. Məsələn, tapşırıq yarandıqda: başqa bir mikroservis yaratmaq üçün tərtibatçı depoda istinad həllinin mənbə koduna baxdı və yenisini yaratmaq bir həftədən çox çəkmədi.
Bunlar xüsusi vaxtlar idi. Şərti olaraq, növbəti masadakı admin yanına gedib soruşa bilərsiniz: "Mənə virtual maşın verin." Təxminən otuz dəqiqədən sonra maşın artıq səninlə idi. Özünüzü bağladınız, hər şeyi quraşdırdınız və trafik sizə göndərildi.
Bu gün bu artıq işləməyəcək: xidmətə monitorinq və giriş əlavə etməli, funksionallığı testlərlə əhatə etməli, virtual maşın sifariş etməli və ya Kuber-ə çatdırılma və s. Ümumiyyətlə, bu şəkildə daha yaxşı olacaq, baxmayaraq ki, daha uzun sürəcək və daha əziyyətli olacaq.
Bölün və idarə edin. Lua ilə nə işin var?
Ciddi bir dilemma var idi: bəzi komandalar Lua-da çox məntiqli bir xidmətə dəyişiklikləri etibarlı şəkildə həyata keçirə bilmədilər. Bu, tez-tez xidmətin işləməməsi ilə müşayiət olunurdu.
Yəni tərtibatçılar bir növ dəyişiklik hazırlayırlar. Tarantool miqrasiya etməyə başlayır, lakin replika hələ də köhnə koddadır; Bəzi DDL və ya başqa bir şey replikasiya yolu ilə ora gəlir və kod nəzərə alınmadığı üçün sadəcə dağılır. Nəticədə, idarəçilər üçün yeniləmə proseduru A4 vərəqində tərtib edildi: replikasiyanı dayandırın, bunu yeniləyin, təkrarlamağı yandırın, burada söndürün, orada yeniləyin. kabus!
Nəticədə, indi biz çox vaxt Luada heç nə etməyə çalışırıq. Sadəcə olaraq iproto (serverlə qarşılıqlı əlaqə üçün ikili protokol) istifadə edin və bu qədər. Bəlkə də bu, tərtibatçılar arasında bilik çatışmazlığıdır, lakin bu baxımdan sistem mürəkkəbdir.
Biz həmişə bu ssenariyə kor-koranə əməl etmirik. Bu gün bizdə ağ-qara yoxdur: ya hər şey Lua-da, ya da hər şey Go-da. Daha sonra miqrasiya problemləri ilə nəticələnməmək üçün onları necə birləşdirə biləcəyimizi artıq başa düşürük.
Tarantool indi haradadır?
Tarantool, "Promoter" kimi də tanınan endirim kuponları nəzərə alınmaqla malların son dəyərinin hesablanması xidmətində istifadə olunur. Daha əvvəl dediyim kimi, o, indi təqaüdə çıxır: onu əvvəlcədən hesablanmış qiymətlərlə yeni kataloq xidməti əvəz edir, lakin altı ay əvvəl bütün hesablamalar Promotizerdə aparılıb. Əvvəllər onun məntiqinin yarısı Lua dilində yazılmışdı. İki il əvvəl xidmət saxlama obyektinə çevrildi və məntiq Go-da yenidən yazıldı, çünki endirimlərin mexanikası bir az dəyişmişdi və xidmətdə performans yox idi.
Ən vacib xidmətlərdən biri istifadəçi profilidir. Yəni, bütün Wildberries istifadəçiləri Tarantool-da saxlanılır və onların təxminən 50 milyonu var.İstifadəçi ID-si ilə parçalanmış sistem, Go xidmətlərinə qoşulmuş bir neçə DC-də paylanmışdır.
RPS-ə görə, Promoter vaxtilə 6 min sorğuya çatan lider idi. Bir vaxtlar bizdə 50-60 nüsxə var idi. İndi RPS-də lider istifadəçi profilləridir, təxminən 12 min. Bu xidmət istifadəçi identifikatorlarının diapazonlarına bölünən xüsusi parçalanmadan istifadə edir. Xidmət 20-dən çox maşına xidmət göstərir, lakin bu, həddindən artıq çoxdur, biz ayrılan resursları azaltmağı planlaşdırırıq, çünki 4-5 maşının gücü bunun üçün kifayətdir.
Session xidməti vshard və Cartridge-də ilk xidmətimizdir. Vshard-ın qurulması və Kartricin yenilənməsi bizdən bir qədər səy tələb etdi, lakin sonda hər şey nəticə verdi.
Vebsaytda və mobil proqramda müxtəlif bannerlərin nümayiş etdirilməsi xidməti birbaşa Tarantool-da buraxılan ilk xidmətlərdən biri olub. Bu xidmət 6-7 il olması, hələ də işlək vəziyyətdə olması və heç vaxt yenidən işə salınmaması ilə diqqət çəkir. Master-master replikasiyasından istifadə edilmişdir. Heç bir şey qırılmayıb.
Bəzi hallarda məlumatı iki dəfə tez yoxlamaq üçün anbar sistemində sürətli istinad funksionallığı üçün Tarantool-dan istifadə nümunəsi var. Bunun üçün Redis-dən istifadə etməyə çalışdıq, lakin yaddaşdakı məlumatlar Tarantool-dan daha çox yer tutdu.
Gözləmə siyahısı, müştəri abunələri, hazırda dəbdə olan hekayələr və təxirə salınmış mallar xidmətləri də Tarantool ilə işləyir. Yaddaşdakı sonuncu xidmət təxminən 120 GB yer tutur. Bu, yuxarıda göstərilənlərin ən əhatəli xidmətidir.
Nəticə
Açar-dəyər və tranzaksiya ilə birləşən ikinci dərəcəli indekslər sayəsində Tarantool mikroservislərə əsaslanan arxitekturalar üçün yaxşı uyğun gəlir. Bununla belə, Lua-da bir çox məntiqlə xidmətlərə dəyişikliklər edərkən çətinliklərlə qarşılaşdıq - xidmətlər tez-tez işləməyi dayandırırdı. Biz bunun öhdəsindən gələ bilmədik və zaman keçdikcə Lua və Go-nun müxtəlif birləşmələrinə gəldik: biz bir dildən harada istifadə edəcəyimizi və digərindən harada istifadə edəcəyimizi bilirik.
Mövzuda başqa nə oxumaq olar
- Tarantool istifadə edərək sıfırdan yüksək yüklü proqram yaratmaq
- Tarantool kartricində etibarlı lider seçimi
- Telegram kanalı Tarantool məhsul haqqında xəbərlər
- İcma söhbətində Tarantool-u müzakirə edin
Mənbə: www.habr.com