Meniul
AcasăiOS

Scalare verticală și orizontală, scalare pentru web. Impactul arhitecturii asupra accesibilității. Probleme de scalare verticală

Fiecare programator vrea să devină cel mai bun, să primească din ce în ce mai interesant și sarcini complexe si rezolva-le din ce in ce mai mult în moduri eficiente. În lumea dezvoltării Internetului, astfel de sarcini le includ pe cele cu care se confruntă dezvoltatorii de sisteme foarte încărcate.

Majoritatea informațiilor publicate pe tema încărcărilor mari pe Internet sunt doar descrieri caracteristici tehnice sisteme mari. Vom încerca să conturăm principiile după care sunt construite arhitecturile celor mai avansate și mai vizitate proiecte de internet ale vremurilor noastre.

  • Separarea funcțională
  • Scalare orizontală clasică
    • Nimicul comun și conceptele apatride
    • Critica Nimicului împărtășit și a conceptelor apatride
    • Coerență între cod și date
  • Memorarea în cache
    • Problemă de invalidare a memoriei cache
    • Problemă care începe cu un cache rece

Să începem a treia lecție, dedicată logicii de business a proiectului. Aceasta este cea mai importantă componentă în procesarea oricărei cereri. Astfel de calcule necesită backend - servere grele cu putere mare de calcul. Dacă front-end-ul nu poate oferi singur ceva clientului (și după cum am aflat în ultimul număr, îl putem oferi clientului fără probleme, de exemplu, poze), atunci face o cerere către back-end . Pe backend, logica de afaceri este procesată, adică datele sunt generate și procesate, în timp ce datele sunt stocate într-un alt strat - stocare în rețea, bază de date sau sistem de fișiere. Stocarea datelor este subiectul următoarei lecții, dar astăzi ne vom concentra pe scalarea backend-ului.

Permiteți-ne să vă avertizăm imediat: scalarea backend-urilor de calcul este una dintre cele mai multe subiecte dificile, în care există multe mituri. Cloud computing rezolvă problema performanței - mulți sunt siguri. Totuși, acest lucru nu este în întregime adevărat: pentru ca tu să fii cu adevărat ajutat servicii cloud, trebuie să vă pregătiți corect codul programului. Puteți configura câte servere doriți în, de exemplu, Amazon EC2, dar la ce sunt bune dacă codul nu poate folosi puterea fiecăruia dintre ele. Deci, cum scalați backend-ul?

Separarea funcțională

Prima și cea mai simplă metodă pe care o întâlnește toată lumea este partiționarea funcțională, în care diferite părți ale sistemului, fiecare dintre acestea rezolvând cu strictețe propria problemă, sunt separate în servere fizice separate. De exemplu, un forum pe care îl vizitați este transferat pe un server și totul funcționează pe altul.

În ciuda simplității sale, mulți oameni uită de această abordare. De exemplu, de foarte multe ori întâlnim proiecte web în care este folosit doar unul Baza de date MySQL complet sub Tipuri variate date. Aceeași bază de date conține articole, bannere și statistici, deși cu bună credință ar trebui să fie diferite Instanțele MySQL. Dacă aveți date fără legătură funcțional (ca în acest exemplu), atunci este logic să le distribuiți la diferite instanțe de baze de date sau chiar la servere fizice. Să ne uităm la asta din cealaltă parte. Dacă aveți atât un banner spinner integrat încorporat, cât și un serviciu care afișează postările utilizatorilor într-un singur proiect, atunci o soluție rezonabilă este să realizați imediat că aceste date nu au nicio legătură între ele și, prin urmare, ar trebui să trăiască în versiune simplăîn două MySQL care rulează diferite. Acest lucru este valabil și pentru backend-urile de calcul - ele pot fi, de asemenea, diferite. Cu absolut setări diferite, cu diferite tehnologii utilizate și scrise în limbi diferite programare. Revenind la exemplu: pentru a afișa postări puteți folosi cel mai comun PHP ca backend, iar pentru sistemul de bannere puteți rula un modul pe nginx. În consecință, pentru postări puteți aloca un server cu o cantitate mare memorie (ei bine, PHP la urma urmei), în timp ce pentru un sistem banner memoria poate să nu fie la fel de importantă ca capacitatea procesorului.

Să tragem concluziile: este recomandabil să folosiți partiționarea funcțională a backend-ului ca cea mai simplă metodă de scalare. Grupați funcții similare și rulați handlerele lor pe diferite servere fizice. Să ne uităm la următoarea abordare.

De la autori

Principala activitate a companiei noastre este rezolvarea problemelor legate de cu sarcină mare, consultanta, proiectare arhitecturi scalabile, conducere testarea sarcinii optimizarea site-ului web. Clienții noștri includ investitori din Rusia și din întreaga lume, precum și proiecte precum VKontakte, Eldorado, Imhonet, Photosight.ru și altele. În timpul consultărilor, întâlnim adesea faptul că mulți nu cunosc elementele de bază - ce este scalarea și cum se întâmplă, ce instrumente sunt folosite și pentru ce. Această publicație continuă seria de articole „Tutorial despre sarcini mari" În aceste articole vom încerca să vorbim în mod constant despre toate instrumentele care sunt folosite pentru a construi arhitectura sistemelor cu sarcină mare.

Scalare orizontală clasică

În principiu, știm deja ce este scalarea orizontală. Dacă sistemul dvs. nu are suficientă putere, pur și simplu adăugați încă zece servere și acestea continuă să ruleze. Dar nu orice proiect vă va permite să faceți acest lucru. Există câteva paradigme clasice care trebuie luate în considerare la începutul procesului de proiectare, astfel încât codul să poată scala pe măsură ce volumul de lucru crește.

Nimicul comun și conceptele apatride

Să luăm în considerare două concepte - Shared Nothing și Stateless, care pot oferi capacitatea de a scala orizontal.

Abordarea Shared Nothing înseamnă că fiecare nod este independent, autosuficient și nu există un singur punct de eșec. Acest lucru, desigur, nu este întotdeauna posibil, dar, în orice caz, numărul de astfel de puncte este sub controlul strict al arhitectului. Prin punct de eșec înțelegem niște date sau calcule care sunt comune tuturor backend-urilor. De exemplu, un fel de administrator de stat sau de identificare. Un alt exemplu este utilizarea sistemelor de fișiere din rețea. Aceasta este o modalitate directă de a obține un blocaj în arhitectură la o anumită etapă de creștere a proiectului. Dacă fiecare nod este independent, atunci putem adăuga cu ușurință mai multe pe măsură ce sarcina crește.

Conceptul de apatrid înseamnă că un proces de program nu își stochează propria stare. Utilizatorul a venit și a ajuns la acest server specific și nu are nicio diferență dacă utilizatorul a ajuns la acest server sau altul. Odată procesată cererea, acest server va uita complet informațiile despre acel utilizator. Utilizatorul nu este deloc obligat să trimită toate cererile următoare către același server și nu trebuie să vină a doua oară pe același server. Astfel, putem schimba dinamic numărul de servere și nu ne facem griji cu privire la direcționarea utilizatorului către serverul dorit. Acesta este probabil unul dintre marile motive pentru care web-ul crește atât de repede. Este mult mai ușor să faci aplicații în el decât să scrii programe clasice offline. Conceptul de răspuns-cerere și faptul că programul tău trăiește timp de 200 de milisecunde sau maxim o secundă (după care este complet distrus) a dus la faptul că limbajele de programare obișnuite precum PHP încă nu au un colector de gunoi.

Abordarea descrisă este clasică: este simplă și solidă. Cu toate acestea, în În ultima vreme trebuie să renunțăm la ea din ce în ce mai des.

Critica Nimicului împărtășit și a conceptelor apatride

Astăzi, web-ul se confruntă cu noi provocări care ridică noi provocări. Când vorbim despre Stateless, asta înseamnă că redesenăm toate datele pentru fiecare utilizator din stocare, iar acest lucru poate fi uneori foarte costisitor. Există o dorință rezonabilă de a pune unele date în memorie, pentru a le face să nu fie chiar Stateless. Acest lucru se datorează faptului că astăzi web-ul devine din ce în ce mai interactiv. Dacă ieri o persoană a mers pe webmail și a făcut clic pe butonul „Reîncărcare” pentru a verifica dacă există mesaje noi, atunci astăzi serverul face deja acest lucru. El îi spune: „O, omule, în timp ce stăteai pe această pagină, ai primit mesaje noi.”

Apar noi provocări care înseamnă că uneori nu este necesară abordarea Nimicului Partajat și apatridiei. Am întâlnit deja în mod repetat situații cu clienții noștri cărora le spunem: „Renunțați la asta, puneți datele în memorie” și invers, „Dirijați oamenii către același server”. De exemplu, atunci când există o cameră de chat deschisă, este logic să direcționați oamenii către același server, astfel încât totul să funcționeze mai repede.

Să vorbim despre un alt caz pe care l-am întâlnit. Unul dintre prietenii noștri dezvolta o jucărie precum „Arena” (lupte și lupte online) folosind Ruby on Rails. La scurt timp după lansare a întâlnit problema clasica: dacă mai multe persoane sunt în aceeași bătălie, fiecare utilizator scoate constant din baza de date datele care au apărut în timpul acestei bătălii. Drept urmare, întreaga structură a putut supraviețui doar până la 30 de mii de utilizatori înregistrați, apoi pur și simplu a încetat să funcționeze.

Situația opusă s-a dezvoltat pentru compania Vuga, care face jocuri pentru Facebook. Cu toate acestea, când s-au confruntat cu o problemă similară, au avut o scară diferită: câteva miliarde de SELECT-uri de la PostgreSQL pe zi pe un singur sistem. Au trecut complet la abordarea privind starea memoriei: datele au început să fie stocate și servite direct în memorie cu acces aleator. Rezultatul: băieții au abandonat practic baza de date și câteva sute de servere s-au dovedit a fi de prisos. Pur și simplu au fost oprite: nu mai erau necesare.

În principiu, orice scalare (inclusiv orizontală) este realizabilă pe multe tehnologii. Acum foarte des despre care vorbim astfel încât atunci când creați un serviciu nu trebuie să plătiți prea mult pentru hardware. Pentru a face acest lucru, este important să știți care tehnologie este cea mai potrivită acest profil incarca cu costuri minime glandă. În același timp, de foarte multe ori, când încep să se gândească la scalare, uită de aspectul financiar al aceleiași scalari orizontale. Unii oameni cred că scalarea orizontală este cu adevărat un panaceu. Am separat datele, am împrăștiat totul pe servere separate - și totul a devenit normal. Cu toate acestea, acești oameni uită de costurile generale - atât financiare (achiziționarea de noi servere), cât și operaționale. Când împărțim totul în componente, există o suprasarcină de comunicare componente softwareîntre ei. În linii mari, există mai multe hameiuri. Să ne amintim un exemplu deja cunoscut pentru tine. Când mergem la pagina de Facebook, JavaScript puternic merge la server, care se gândește mult, mult timp și abia după un timp începe să vă ofere datele. Toată lumea a văzut o imagine similară: vrei să te uiți la ea și să alergi și să bei cafea, dar doar se încarcă și se încarcă și se încarcă. Ar fi necesar să stocăm datele puțin „mai aproape”, dar Facebook nu mai are această opțiune.

Stratificarea codului

Încă câteva sfaturi pentru a ușura scalarea orizontală. Prima recomandare: programați astfel încât codul dvs. să fie format din straturi, iar fiecare strat să fie responsabil pentru un anumit proces din lanțul de prelucrare a datelor. Să presupunem că, dacă lucrați cu o bază de date, atunci ar trebui să fie făcută într-un singur loc și să nu fie împrăștiată în toate scripturile. De exemplu, construim o pagină de utilizator. Totul începe cu nucleul care rulează modulul logic de afaceri pentru a construi pagina de utilizator. Acest modul interogează stratul de stocare de date de bază pentru informații despre acel utilizator anume. Nivelul logic al afacerii nu știe nimic despre locul în care sunt datele: dacă sunt stocate în cache, sharded (sharding-ul este distribuția datelor pe diferite servere de stocare a datelor, despre care vom vorbi în lecțiile viitoare), sau s-a făcut altceva cu ele nu bine. . Modulul solicită pur și simplu informații apelând funcția corespunzătoare. Funcția de citire a informațiilor utilizatorului este localizată în stratul de stocare a datelor. La rândul său, stratul de stocare a datelor după tipul de solicitare determină în ce stocare este stocat utilizatorul. În cache? În baza de date? Pe sistemul de fișiere? Și apoi apelează funcția corespunzătoare a stratului de bază.

Ce oferă o astfel de schemă stratificată? Face posibilă rescrierea, aruncarea sau adăugarea de straturi întregi. De exemplu, să presupunem că decideți să adăugați cache pentru utilizatori. A face acest lucru într-o schemă stratificată este foarte simplu: trebuie să adăugați doar un singur loc - stratul de stocare a datelor. Sau adăugați sharding, iar acum utilizatorii pot locui în diferite baze de date. În schema obișnuită, va trebui să săpați prin întregul site și să introduceți peste tot verificările corespunzătoare. Într-un circuit stratificat, trebuie doar să corectați logica unui strat, a unui modul specific.

Coerență între cod și date

Următoarea sarcină importantă care trebuie abordată pentru a evita problemele la scalarea orizontală este de a minimiza cuplarea atât a codului, cât și a datelor. De exemplu, dacă utilizați JOIN-uri în interogările dvs. SQL, aveți deja potenţială problemă. Puteți face un JOIN într-o singură bază de date. Dar în cadrul a două baze de date situate pe servere diferite, acest lucru nu mai este posibil. Recomandare generală: încercați să comunicați cu depozitul folosind interogări minim simple, iterații, pași.

Ce să faci dacă nu poți să faci fără JOIN? Faceți-o singur: faceți două cereri, înmulțiți în PHP - nu este nimic greșit în asta. De exemplu, luați în considerare sarcina clasică de a construi un feed de prieteni. Trebuie să ridici toți prietenii utilizatorului, să ceri totul pentru ei ultimele note, pentru toate postările, strângeți numărul de comentarii - aici tentația de a face acest lucru într-o singură interogare (cu un anumit număr de JOIN-uri imbricate) este deosebit de mare. O singură cerere și veți obține toate informațiile de care aveți nevoie. Dar ce vei face când sunt prea mulți utilizatori și înregistrări și baza de date nu mai poate face față? Într-un mod bun, ar fi necesar să partajați utilizatorii (împrăștiați-i uniform pe diferite servere de baze de date). Este clar că în acest caz nu se va mai putea efectua operația JOIN: datele sunt împărțite în diferite baze de date. Deci trebuie să faci totul manual. Concluzia este evidentă: fă-o manual de la bun început. Mai întâi interogați baza de date pentru toți prietenii utilizatorului (prima interogare). Apoi luați ultimele postări ale acestor utilizatori (a doua interogare sau grup de interogări). Apoi sortați memoria și selectați ceea ce aveți nevoie. De fapt, efectuați manual operația JOIN. Da, s-ar putea să nu o faci la fel de eficient ca o bază de date. Dar nu sunteți în niciun fel limitat de volumul acestei baze de date în stocarea informațiilor. Puteți împărți și distribui datele pe diferite servere sau chiar către diferite SGBD-uri! Toate acestea nu sunt deloc atât de înfricoșătoare pe cât ar părea. Într-un sistem stratificat construit corespunzător, majoritatea acestor solicitări vor fi stocate în cache. Sunt simple și ușor de memorat în cache - spre deosebire de rezultatele unei operațiuni JOIN. Un alt dezavantaj al opțiunii JOIN: atunci când este adăugată de utilizator intrare nouă trebuie să resetați probele cache ale tuturor prietenilor săi! Și în această situație, nu se știe ce va funcționa de fapt mai repede.

Memorarea în cache

Următorul instrument important cu care ne vom familiariza astăzi este stocarea în cache. Ce este memoria cache? Un cache este un loc în care puteți pune date sub o cheie care durează mult timp pentru a calcula. Amintiți-vă unul dintre punctele cheie: memoria cache ar trebui să vă ofere date folosind această cheie mai rapid decât recalculând-o. Am întâlnit în mod repetat o situație în care nu a fost cazul și oamenii și-au pierdut timpul fără rost. Uneori baza de date funcționează destul de repede și este mai ușor să accesați direct la ea. Al doilea moment cheie: Cache-ul ar trebui să fie același pentru toate backend-urile.

Al doilea punct important. Cache-ul este mai mult o modalitate de a acoperi o problemă de performanță decât de a o rezolva. Dar, desigur, există situații în care este foarte costisitor să rezolvi o problemă. Așa că spui: „Bine, voi acoperi această crăpătură a peretelui cu tencuială și vom crede că nu este acolo”. Uneori funcționează - de fapt, funcționează foarte des. Mai ales când intri în cache și datele pe care ai vrut să le arăți sunt deja acolo. Un exemplu clasic este contorul de prieteni. Acesta este un contor în baza de date și, în loc să parcurgeți întreaga bază de date în căutarea prietenilor dvs., este mult mai ușor să memorați aceste date în cache (și să nu le recalculați de fiecare dată).

Pentru cache, există un criteriu pentru eficacitatea utilizării, adică un indicator că funcționează - se numește Hit Ratio. Acesta este raportul dintre numărul de solicitări pentru care a fost găsit răspunsul în cache la numărul total cereri. Dacă este scăzut (50-60%), atunci aveți un cache suplimentar. Aceasta înseamnă că aproape la fiecare a doua pagină utilizatorul, în loc să obțină date din baza de date, merge și în cache: află că acolo nu există date pentru el și apoi merge direct în baza de date. Și acestea sunt două, cinci, zece, patruzeci de milisecunde în plus.

Cum să vă asigurați un raport de lovituri bun? În acele locuri în care baza ta de date este lentă și în acele locuri în care datele pot fi recalculate pentru o perioadă destul de lungă de timp, conectezi Memcache, Redis sau un instrument similar care va servi ca cache rapid - și asta începe să te salveze. Cel puțin temporar.

Oleg Bunin

Cunoscut specialist în proiecte Highload. Firma sa Laboratorul Oleg Bunin este specializată în consultanță, dezvoltare și testare de proiecte web de mare încărcare. În prezent, el este organizatorul conferinței HighLoad++ (www.highload.ru). Aceasta este o conferință dedicată sarcinilor mari, care reunește anual cele mai bune din lume specialişti în dezvoltare proiecte majore. Datorită acestei conferințe, fac cunoștință cu toți specialiștii de top din lumea sistemelor de sarcină mare.

Constantin Osipov

Specialist baze de date care pentru o lungă perioadă de timp am lucrat la MySQL, unde am fost responsabil pentru un sector cu sarcină mare. Viteza MySQL se datorează în mare parte lui Kostya Osipov. Pe vremea mea a lucrat la scalabilitatea MySQL 5.5. În prezent, el este responsabil la Mail.Ru pentru baza de date NoSQL în cluster Tarantool, care servește 500-600 de mii de solicitări pe secundă. Foloseste asta Sursa deschisa Oricine poate face proiectul.

Maxim Lapshin

Soluții de organizare a difuzării video care există în lume pe acest moment, poate fi numărat pe o mână. Max a dezvoltat unul dintre ele - Erlyvideo (erlyvideo.org). Acest aplicație server, care se ocupă de streaming video. Când creați astfel de instrumente, o mulțime de cele mai dificile probleme cu viteza. Maxim are și o oarecare experiență în scalarea site-urilor de dimensiuni medii (nu la fel de mari ca Mail.Ru). Prin medie ne referim la astfel de site-uri, numărul de accesări la care ajunge la aproximativ 60 de milioane pe zi.

Constantin Mashukov

Analist de afaceri la firma lui Oleg Bunin. Konstantin a venit din lumea supercalculatoarelor, unde multă vreme a lucrat la diverse aplicații științifice legate de cruncherele de numere. Ca analist de afaceri, ea participă la toate proiectele de consultanță ale companiei, fie că este vorba despre rețele sociale, marile magazine online sau sisteme electronice de plată.

Problemă de invalidare a memoriei cache

Dar cu utilizarea unui cache, obțineți problema de invalidare a memoriei cache ca bonus. Care e ideea? Puneți date în cache și le luați din cache, dar până acum datele originale s-au schimbat deja. De exemplu, Mashenka a schimbat legenda de sub imaginea ei și, din anumite motive, ați pus o linie în cache în loc să o scoateți din baza de date de fiecare dată. Ca rezultat, afișați date vechi - aceasta este o problemă de invalidare a memoriei cache. ÎN caz general nu are nicio soluție deoarece această problemă este legată de utilizarea datelor de către aplicația dvs. de afaceri. Întrebarea principală este: când să actualizezi memoria cache? Uneori este greu să răspunzi. De exemplu, un utilizator postează pe rețea socială postare nouă - să spunem că în acest moment încercăm să scăpăm de toate datele nevalide. Se pare că trebuie să resetați și să actualizați toate cache-urile care au legătură cu această postare. În cel mai rău caz, dacă o persoană face o postare, resetați memoria cache din feedul său de postări, resetați toate cache-urile din feedul prietenilor, resetați toate cache-urile din feedul persoanelor care au ca prieteni persoane din acea comunitate, și așa mai departe. Ajungi prin a spăla jumătate din cache-urile din sistem. Când Zuckerberg publică o postare pentru unsprezece milioane și jumătate de abonați ai săi, ar trebui să resetam cele unsprezece milioane și jumătate de cache de prieteni ale tuturor acestor abonați? Cum să faci față acestei situații? Nu, vom merge invers și vom actualiza memoria cache atunci când vom solicita un feed de prieteni care conține această nouă postare. Sistemul detectează că nu există cache, merge și recalculează. Abordarea este simplă și solidă. Există însă și dezavantaje: dacă se resetează memoria cache a unei pagini populare, riști să obții așa-numita condiție de cursă, adică o situație în care același cache va fi calculat simultan de mai multe procese (mai mulți utilizatori au decis să acceseze date noi). Drept urmare, sistemul dvs. este angajat într-o activitate destul de goală - calculul simultan al celei de-a n-a cantități de date identice.

O cale de ieșire este să folosiți mai multe abordări simultan. Nu ștergeți pur și simplu valoarea învechită din cache, ci doar o marcați ca învechită și, în același timp, puneți în coadă sarcina pentru a recalcula noua valoare. În timp ce jobul din coadă este procesat, utilizatorului i se dă o valoare învechită. Aceasta se numește degradare a funcționalității: presupuneți în mod deliberat că unii utilizatori nu vor primi cele mai recente date. Majoritatea sistemelor cu o logică de afaceri bine gândită au o abordare similară în arsenalul lor.

Problemă de pornire cu memoria cache neîncălzită

O altă problemă este începerea cu un cache neîncălzit (adică neumplut). Această situație ilustrează clar faptul că un cache nu poate rezolva problema unei baze de date lente. Să presupunem că doriți să afișați utilizatorilor primele 20 postări bune pentru orice perioadă. Aceste informații se aflau în memoria cache, dar până la pornirea sistemului, memoria cache fusese șters. În consecință, toți utilizatorii accesează baza de date, care durează, să zicem, 500 de milisecunde pentru a construi un index. Ca rezultat, totul începe să funcționeze lent și ți-ai cauzat DoS (Denial-of-service). Site-ul nu funcționează. De aici concluzia: nu faceți memorarea în cache până când nu aveți alte probleme rezolvate. Faceți ca baza de date să funcționeze rapid și nu va trebui să vă deranjați deloc cu memorarea în cache. Cu toate acestea, chiar și problema de a începe cu un cache gol are soluții:

  1. Utilizați stocarea cache cu înregistrarea pe disc (pierdem viteza);
  2. Umpleți manual memoria cache înainte de a începe (utilizatorii așteaptă și sunt indignați);
  3. Permiteți utilizatorilor să intre pe site în loturi (utilizatorii încă așteaptă și sunt indignați).

După cum puteți vedea, orice metodă este proastă, așa că vom repeta: încercați să vă faceți sistemul să funcționeze fără cache.

Scalabilitate - capacitatea unui dispozitiv de a-și crește
posibilităților
prin creșterea numărului de blocuri funcționale,
performând singur şi
aceleași sarcini.
Glosar.ru

De obicei, oamenii încep să se gândească la scalare atunci când sunt
serverul nu poate face față muncii care i se atribuie. Cu ce ​​nu este mai exact?
face față? Operarea oricărui server web în general se reduce la elementele de bază
Ocupația calculatoarelor este prelucrarea datelor. Răspuns la o solicitare HTTP (sau orice alta).
presupune efectuarea unor operaţii asupra unor date. Respectiv,
avem două entităţi principale – datele (caracterizate prin volumul lor) şi
calcule (caracterizate prin complexitate). Este posibil ca serverul să nu poată face față
funcționează din cauza cantității mari de date (este posibil să nu se potrivească fizic
server), sau din cauza sarcinii de calcul grele. Discuția aici este
desigur, despre sarcina totală - complexitatea procesării unei cereri poate fi
este mic, dar un număr mare dintre ele poate copleși serverul.

Vom vorbi în principal despre scalare folosind un exemplu
proiect web tipic în creștere, dar principiile descrise aici sunt potrivite și pentru
alte domenii de aplicare. Mai întâi ne vom uita la arhitectura proiectului și simplă
distributia acestuia componente pe mai multe servere și apoi vom vorbi despre
scalarea calculului și a datelor.

Arhitectura tipică a site-ului

Viața unui site web tipic începe cu o arhitectură foarte simplă
- acesta este un server web (de obicei Apache își joacă rolul),
care se ocupă de toată munca de deservire a solicitărilor HTTP,
primit de la vizitatori. El le dă clienților așa-numita „statică”, atunci
există fișiere aflate pe discul serverului care nu necesită procesare: imagini (gif,
jpg, png), foi de stil (css), scripturi client (js, swf). Același server
răspunde întrebărilor care necesită calcule – de obicei formând
pagini html, deși uneori imagini și alte documente sunt create din mers.
Cel mai adesea, răspunsurile la astfel de solicitări sunt generate de scripturi scrise în PHP,
perl sau alte limbi.

Dezavantajul unei scheme de lucru atât de simple este atât de diferit
natura solicitărilor (încărcarea fișierelor de pe disc și munca de calcul scenarii)
procesate de același server web. Interogările de calcul necesită
păstrați o mulțime de informații în memoria serverului (interpret de limbaj de script,
scripturile în sine, datele cu care lucrează) și pot ocupa mult
resurse de calcul. Emiterea de date statice, dimpotrivă, necesită puține resurse
procesor, dar poate ocupa perioadă lungă de timp, dacă clientul are scăzut
viteza de comunicare. Organizare internă server Apache presupune că fiecare
conexiunea se face printr-un proces separat. Acest lucru este convenabil pentru rularea scripturilor,
totuși nu este optim pentru prelucrare interogări simple. Se dovedește că greu (de la
scripturi și alte date) Procesele Apache petrec mult timp așteptând (mai întâi când primesc
cerere, apoi la trimiterea unui răspuns), pierderea memoriei serverului.

Soluția la această problemă este distribuirea lucrărilor de procesare
cereri între doi diferite programe- adica împărțirea în frontend și
backend Un server frontend ușor îndeplinește sarcinile de difuzare a conținutului static și restul
cererile sunt redirecționate (proxy) către backend, unde se realizează formarea
pagini. Așteptarea clienților lenți este, de asemenea, îngrijită de front-end și dacă folosește
multiplexare (când un proces deservește mai mulți clienți - deci
funcționează, de exemplu, nginx sau lighttpd), atunci așteptarea este practic nimic
cheltuieli.

Printre alte componente ale site-ului, trebuie remarcată baza de date, în
care stochează de obicei datele principale ale sistemului - cele mai populare aici sunt
DBMS gratuit MySQL și PostgreSQL. Depozitarea este adesea alocată separat
fișiere binare, care conține imagini (de exemplu, ilustrații pentru articole
site-ul, avatarele și fotografiile utilizatorului) sau alte fișiere.

Astfel, am primit o diagramă de arhitectură formată din
mai multe componente.

De obicei, la începutul vieții unui site, toate componentele arhitecturii
situat pe același server. Dacă nu mai face față sarcinii, atunci
există o soluție simplă - mutați părțile cele mai ușor separate în alta
Server. Cel mai simplu mod de a începe cu o bază de date este să o mutați pe un server separat și
modificați detaliile de acces în scripturi. Apropo, în acest moment ne confruntăm
importanța unei arhitecturi adecvate codul programului. Dacă lucrați cu o bază de date
prezentat la modul separat, comun pentru întregul site - apoi remediați parametrii
conexiunile vor fi ușoare.

Modalitățile de separare suplimentară a componentelor sunt, de asemenea, clare - de exemplu, puteți muta interfața pe un server separat. Dar de obicei frontend
necesită puțin resursele sistemului iar în această etapă eliminarea sa nu va oferi semnificativ
câștiguri de productivitate. Cel mai adesea, site-ul este limitat de performanță.
scripturi - generarea unui răspuns (pagina html) durează prea mult.
De aceea urmatorul pas de obicei scalarea serverului backend.

Distribuția de calcul

O situație tipică pentru un site în creștere - baza de date este deja
mutat pe o mașină separată, împărțirea în frontend și backend este finalizată,
cu toate acestea, traficul continuă să crească și backend-ul nu are timp să proceseze
cereri. Aceasta înseamnă că trebuie să distribuim calculele pe mai multe
servere. Acest lucru este ușor de făcut - doar cumpărați un al doilea server și instalați-l
Conține programe și scripturi necesare pentru ca backend-ul să funcționeze.
După aceasta, trebuie să vă asigurați că solicitările utilizatorilor sunt distribuite
(echilibrat) între serverele primite. DESPRE în diverse feluri balansare
va fi discutat mai jos, dar deocamdată observăm că acest lucru se face de obicei de către interfață,
care este configurat astfel încât să distribuie uniform cererile între
servere.

Este important ca toate serverele backend să fie capabile corect
raspunde la solicitari. Acest lucru necesită de obicei să lucreze cu fiecare dintre ei
același set de date actualizat. Dacă stocăm toate informațiile într-un singur
baza de date, atunci DBMS-ul însuși va furniza partajareași consistența datelor.
Dacă unele date sunt stocate local pe server (de exemplu, sesiuni php
client), atunci ar trebui să vă gândiți să le transferați către stocare partajată, sau despre mai multe
algoritm complex de distribuție a cererilor.

Nu numai munca poate fi distribuită pe mai multe servere
scripturi, dar și calcule efectuate de baza de date. Dacă SGB-ul funcționează foarte mult
interogări complexe, ocupând timpul CPU al serverului, puteți crea mai multe
copii ale bazei de date către servere diferite. Acest lucru ridică problema sincronizării
date atunci când se modifică și mai multe abordări sunt aplicabile aici.

  • Sincronizare la nivel de aplicație. În acest caz nostru
    scripturile scriu în mod independent modificări la toate copiile bazei de date (și ele însele poartă
    responsabilitatea pentru corectitudinea datelor). Nu este cea mai bună opțiune deoarece el
    necesită atenție în implementare și este foarte tolerant la erori.
  • Replicare- adică replicare automată
    modificările efectuate pe un server afectează toate celelalte servere. De obicei când
    Când se utilizează replicarea, modificările sunt întotdeauna scrise pe același server - se numește master, iar copiile rămase sunt numite slave. Majoritatea SGBD-urilor au
    încorporat sau fonduri externe pentru a organiza replicarea. Distinge
    replicare sincronă - în acest caz, va aștepta o solicitare de modificare a datelor
    până când datele sunt copiate pe toate serverele și numai atunci se vor finaliza cu succes - și asincron - în acest caz, modificările sunt copiate pe serverele slave de la
    întârziere, dar cererea de scriere se finalizează mai repede.
  • Multi-master replicare. Această abordare este similară
    anterior, dar aici putem face modificări de date fără a accesa
    un anumit server, dar la orice copie a bazei de date. În același timp, schimbări
    sincron sau asincron vor fi transferate în alte copii. Uneori se numește această schemă
    termenul „cluster de baze de date”.

Posibil diferite variante distribuirea sistemului între servere.
De exemplu, putem avea un server de baze de date și mai multe backend-uri (foarte
schema tipică), sau invers - un backend și mai multe baze de date. Dacă am scala
atât serverul backend, cât și baza de date, apoi puteți combina backend-ul și o copie a bazei de date
o mașină. În orice caz, de îndată ce avem mai multe exemplare
orice server, se pune întrebarea cum să se distribuie corect între ele
sarcină.

Metode de echilibrare

Să creăm mai multe servere (pentru orice scop - http, bază de date etc.), fiecare dintre ele poate procesa cereri. Inainte de
ne confruntăm cu sarcina de a distribui munca între ei, cum să aflăm care
serverul trimite o cerere? Există două moduri principale de a distribui cererile.

  • Unitate de echilibrare. În acest caz, clientul trimite o cerere către unul
    un server fix cunoscut de el și redirecționează deja cererea către unul dintre
    servere de lucru. Exemplu tipic- un site cu un front-end și mai multe
    servere backend la care solicitările sunt trimise proxy. Cu toate acestea, „clientul” poate
    fi în interiorul sistemului nostru - de exemplu, un script poate trimite o solicitare către
    către un server proxy de bază de date care va transmite cererea unuia dintre serverele DBMS.
    Nodul de echilibrare în sine poate funcționa atât pe un server separat, cât și pe unul singur
    de pe serverele de lucru.

    Avantajele acestei abordări sunt
    despre care clientul nu trebuie să știe nimic structura interna sisteme - despre cantitate
    servere, despre adresele și caracteristicile lor - numai
    echilibrist Cu toate acestea, dezavantajul este că unitatea de echilibrare este una singură
    punctul de defecțiune al sistemului - dacă eșuează, întregul sistem va fi
    inoperant. În plus, sub sarcină mare, balansierul se poate opri pur și simplu
    să facă față muncii lor, așa că această abordare nu este întotdeauna aplicabilă.

  • Echilibrare partea clientului. Dacă vrem să evităm
    există un singur punct de eșec Opțiune alternativă- încredințați selecția serverului
    clientului însuși. În acest caz, clientul trebuie să cunoască structura internă a noastră
    sisteme pentru a putea alege corect ce server să contacteze.
    Un avantaj incontestabil este absența unui punct de eșec - dacă unul dintre
    servere clientul va putea contacta alții. Cu toate acestea, prețul pentru aceasta este
    logica client mai complexa si mai putina flexibilitate de echilibrare.


Desigur, există și combinații ale acestor abordări. De exemplu,
astfel de metoda cunoscuta echilibrarea încărcăturii, ca și echilibrarea DNS, se bazează pe
ca la determinarea adresei IP a unui site, clientul este dat
adresa unuia dintre mai multe servere identice. Astfel, DNS acționează ca un
rolul nodului de echilibrare de la care clientul primește „distribuția”. in orice caz
însăși structura serverelor DNS implică absența unui punct de eșec din cauza
duplicarea - adică avantajele a două abordări sunt combinate. Desigur, acesta
Există și dezavantaje ale metodei de echilibrare - de exemplu, un astfel de sistem este dificil de dinamic
reconstrui.

Lucrul cu un site nu se limitează de obicei la o singură solicitare.
Prin urmare, atunci când proiectați, este important să înțelegeți dacă interogările secvențiale pot
clientul să fie procesat corect de diferite servere, sau clientul trebuie să fie
legat de un server în timp ce lucrați cu site-ul. Acest lucru este deosebit de important dacă
site-ul stochează informații temporare despre sesiunea utilizatorului (în acest
În acest caz, este posibilă și distribuția gratuită - dar atunci este necesar să se depoziteze
sesiuni (stocare comună tuturor serverelor). „Leagă” vizitatorul de
puteți specifica un anumit server după adresa sa IP (care, totuși, se poate schimba),
sau prin cookie (în care identificatorul serverului este preînregistrat), sau chiar
pur și simplu redirecționând-o către domeniul dorit.

Pe de altă parte, este posibil ca serverele de calcul să nu aibă drepturi egale.
În unele cazuri, este avantajos să faci invers, să aloci un server separat pentru
procesarea cererilor de un singur tip - și obțineți o divizare verticală
funcții. Apoi clientul sau nodul de echilibrare va selecta serverul în
in functie de tipul cererii primite. Această abordare ne permite să ne despărțim
solicitări importante (sau invers, nu critice, ci dificile) de la alții.

Distribuția datelor

Am învățat să distribuim calcule, deci un mare
prezența nu este o problemă pentru noi. Cu toate acestea, volumele de date continuă să crească,
stocarea și procesarea acestora devine din ce în ce mai dificilă - ceea ce înseamnă că este timpul să le construiți
stocarea distribuită a datelor. În acest caz, nu vom mai avea unul sau
mai multe servere care conțin o copie completă a bazei de date. În schimb, datele
vor fi distribuite pe diferite servere. Ce scheme de distribuție sunt posibile?

  • Distribuție verticală(compartimentare verticală) - în cel mai simplu caz
    constituie o hotărâre mese separate baza de date către un alt server. La
    În acest caz, va trebui să schimbăm scripturile pentru a accesa diferite servere pentru
    date diferite. În limită, putem stoca fiecare tabel pe un server separat
    (deși în practică este puțin probabil ca acest lucru să fie benefic). Evident, cu asta
    distribuție, pierdem capacitatea de a face interogări SQL care combină date din
    două mese situate pe servere diferite. Dacă este necesar, puteți implementa
    logica de îmbinare în aplicație, dar nu va fi la fel de eficientă ca într-un SGBD.
    Prin urmare, atunci când partiționați o bază de date, trebuie să analizați relațiile dintre tabele,
    pentru a distribui mese cât mai independente.

    Caz mai complex
    distribuția verticală a bazei este o descompunere a unui tabel atunci când este parte
    unele dintre coloanele sale ajung pe un server, iar unele dintre ele ajung pe altul. Această tehnică
    este mai puțin comun, dar poate fi folosit, de exemplu, pentru a separa mici
    și date actualizate frecvent dintr-un volum mare de date rar utilizate.

  • Distribuție orizontală(compartimentare orizontală) - constă din
    distribuirea datelor dintr-un tabel pe mai multe servere. De fapt, pe
    fiecare server creează un tabel cu aceeași structură și stochează
    o anumită bucată de date. Puteți distribui date pe servere în moduri diferite
    criterii: după interval (înregistrări cu id< 100000 идут на сервер А, остальные - на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО» сохраняем на сервер
    A, restul - către serverul B) sau prin valoarea hash a unui anumit câmp
    înregistrări. Partiționarea orizontală a datelor vă permite să stocați nelimitat
    numărul de înregistrări complică însă selecția. Cel mai eficient mod de a alege
    înregistrează numai atunci când se știe pe ce server sunt stocate.

Pentru selecție schema corecta distribuirea datelor este necesară
analizați cu atenție structura bazei de date. Tabelele existente(și poate,
câmpuri individuale) pot fi clasificate în funcție de frecvența accesului la înregistrări, după frecvență
actualizări și relații (necesitatea de a face selecții din mai multe
Mese).

După cum am menționat mai sus, pe lângă o bază de date, un site are adesea nevoie
stocare pentru fișiere binare. Sisteme distribuite Stocarea fișierelor
(de fapt, sisteme de fișiere) pot fi împărțite în două clase.

  • Lucru la nivel sistem de operare . Mai mult, pentru
    aplicațiile care lucrează cu fișiere într-un astfel de sistem nu sunt diferite de munca regulata Cu
    fişiere. Schimbul de informații între servere este gestionat de sistemul de operare.
    Exemple de astfel de sisteme de fișiere includ cel mult cunoscut
    Familia NFS sau mai puțin cunoscută, dar mai mult sistem modern Luciu.
  • Implementat la nivel de aplicație distribuite
    depozitele implică faptul că munca de schimb de informații se desfășoară de la sine
    aplicarea. De obicei, sunt plasate funcții pentru lucrul cu stocarea
    bibliotecă separată. Unul dintre exemplele izbitoare de astfel de stocare este MogileFS, dezvoltat de
    de creatorii LiveJournal. Un alt exemplu comun este utilizarea
    Protocolul WebDAV și stocarea suportată a acestuia.

Trebuie menționat că distribuția datelor decide nu numai
o chestiune de depozitare, dar și parțial o problemă de distribuție a sarcinii - pe fiecare
serverul devine mai puține intrăriși, prin urmare, sunt procesate mai rapid.
Combinația de metode de distribuire a calculelor și a datelor face posibilă construirea
arhitectură potențial scalabilă nelimitat, capabilă să lucreze cu
orice cantitate de date și orice încărcare.

concluzii

Pentru a rezuma cele spuse, să formulăm concluzii sub forma unor scurte teze.

  • Cele două provocări principale (și legate) de scalare sunt distribuția de calcul și distribuția datelor
  • Arhitectura tipică a site-ului implică separarea rolurilor și
    include frontend, backend, bază de date și uneori stocare de fișiere
  • La volume mici date și sarcini grele aplica
    oglindirea bazei de date - replicare sincronă sau asincronă
  • Pentru cantități mari de date, este necesar să se distribuie baza de date - împărțită
    acesta pe verticală sau pe orizontală
  • Binarele sunt stocate pe sisteme de fișiere distribuite
    (implementat la nivel de sistem de operare sau în aplicație)
  • Echilibrarea (distribuirea cererilor) poate fi uniformă sau
    împărțit după funcționalitate; cu un nod de echilibrare sau pe partea clientului
  • Combinația corectă de metode vă va permite să rezistați oricărei sarcini;)

Legături

Puteți continua să studiați acest subiect pe site-uri și bloguri interesante în limba engleză.

ALEXANDER KALENDAREV, RBC Media, programator, [email protected]


Probleme și soluții

Mai devreme sau mai târziu, un proiect web sau mobil popular cu o parte server va întâmpina o problemă de performanță. O soluție este să scalați baza de date pe orizontală. Noi vorbim despre capcaneleși despre moduri posibile ocolindu-le

Fiecare proiect în creștere se confruntă cu o provocare de productivitate. Prin urmare, dacă credeți că proiectul dvs. este ambițios și va cuceri în curând întreaga lume, atunci este indicat să includeți posibilitatea de scalare deja la nivelul dezvoltării inițiale a arhitecturii.

Să clarificăm terminologia:

  • Performanţă– capacitatea aplicației de a îndeplini cerințe precum timp maxim reacții, debit.
  • Debit (capacitate)– capacitatea maximă a unei aplicații de a trece printr-un anumit număr de solicitări pe unitatea de timp sau de a păstra un anumit număr de sesiuni de utilizator.
  • Scalabilitate este o caracteristică a unei aplicații care își arată capacitatea de a menține performanța pe măsură ce crește lățime de bandă. La rândul său, scalarea este procesul de asigurare a creșterii sistemului. Scalare poate fi verticală sau orizontală.
  • Scalare pe verticală– aceasta este o creștere a productivității datorită creșterii puterii hardware-ului, cantității de RAM etc. Mai devreme sau mai târziu, scalarea verticală își va atinge limita superioară.
  • Scalare orizontală este o creștere a productivității prin împărțirea datelor pe mai multe servere.

Separarea datelor funcționale

Există mai multe opțiuni pentru scalarea orizontală. De exemplu, este foarte des folosit pentru a separa datele pe baza utilizării funcționale. De exemplu, datele pentru albumele foto sunt conținute într-un grup de servere, datele profilului utilizatorului sunt situate într-un alt grup, iar corespondența utilizatorului este localizată într-un al treilea. În fig. Figura 1 prezintă o diagramă de scalare orizontală prin distribuție funcțională.

Scalare folosind replicare

Cea mai ușoară modalitate de scalare, folosită adesea pentru proiecte mici și mijlocii, este să folosești replicarea. Replicarea este un mecanism pentru sincronizarea mai multor copii ale unui obiect și a tabelelor bazei de date (vezi Fig. 2). Replicarea master-slave este sincronizarea datelor de la serverul principal principal la serverele slave.

Din moment ce majoritatea web și proiecte mobile Există un ordin de mărime mai multe operațiuni de citire decât operațiuni de scriere, apoi putem efectua operațiuni de scriere pe un server master și citim date de pe mai multe servere slave. Replicarea trebuie configurată între serverele master și slave.

Multe baze de date au replicare încorporată sau, după cum se spune, o „soluție gata de fabricație”. De exemplu, replicarea PostgreSQL poate fi efectuată de următoarele utilitare:

  • Slony-I – replicare asincronă (master la mai mulți sclavi);
  • pgpool-I/II – replicare multimaster sincronă;
  • Pgcluster – replicare multimaster sincronă;
  • Bucardo;
  • Londra;
  • RubyRep.
  • începând cu versiunea 9.0, replicare în flux încorporată.

Când scalați folosind replicarea, trebuie să utilizați conexiuni diferite: unul cu server master, doar pentru scriere sau actualizare, iar al doilea, doar cu server slave, direct pentru citire. Mai mult, dacă folosim mai multe servere slave, atunci strategia de selecție poate fi aleatorie, sau un anumit server de bază de date este alocat unui anumit server web.

Citiți întregul articol în revistă " Administrator de sistem”, nr. 10 pentru 2014 la paginile 54-62.

Versiune PDF număr dat poate fi achiziționat din magazinul nostru.


In contact cu

Scalare pe verticală— extindere — creșterea numărului de resurse disponibile pentru software prin creșterea puterii utilizate de la servere.

— scaling out — creșterea numărului de noduri combinate într-un cluster de servere atunci când există o lipsă de CPU, memorie sau spațiu pe disc.

Ambele sunt soluții de infrastructură care situatii diferite necesar atunci când un proiect web crește.

Scalare verticală și orizontală, scalare pentru web

De exemplu, luați în considerare serverele de baze de date. Pentru aplicații mari aceasta este întotdeauna cea mai încărcată componentă a sistemului.

Capacitățile de scalare pentru serverele de baze de date sunt determinate de aplicabil soluții software: cel mai adesea acestea sunt baze de date relaționale (MySQL, Postgresql) sau NoSQL(, Cassandra etc.).

Scalare orizontală pentru serverele de baze de date sub sarcini grele este mult mai ieftină

Un proiect web este de obicei pornit pe un server, ale cărui resurse se epuizează pe măsură ce crește. Într-o astfel de situație, există 2 opțiuni:

  • muta site-ul pe un server mai puternic
  • adăugați un alt server de consum redus și combinați mașinile într-un cluster

MySQL este cel mai popular RDBMS și, ca oricare dintre ele, necesită o mulțime de resurse de server pentru a rula sub sarcină. Scalare este posibilă în principal în sus. Există sharding (care necesită modificări de cod pentru a configura) și sharding, care poate fi dificil de suportat.

Scalare pe verticală

NoSQL se scalează cu ușurință, iar a doua opțiune cu, de exemplu, MongoDB, va fi mult mai profitabilă din punct de vedere financiar și nu va necesita setări care necesită forță de muncă și suport pentru soluția rezultată. Partajarea se realizează automat.

Astfel, cu MySQL veți avea nevoie de un server cu o cantitate mare de CPU și astfel de servere au un cost semnificativ;

Scalare orizontală
Cu MongoDB poți mai adauga unul server mediu iar soluția rezultată va funcționa stabil, oferind toleranță suplimentară la erori.


Extindere sau este o etapă naturală a dezvoltării infrastructurii. Orice server are limitări și atunci când acestea sunt atinse sau când costul unui server mai puternic se dovedește a fi nerezonabil de mare, se adaugă noi mașini. Sarcina este distribuită între ele. De asemenea, oferă toleranță la erori.

Ar trebui să începeți să adăugați servere de dimensiuni medii și să configurați clustere atunci când posibilitățile de creștere a resurselor unei mașini au fost epuizate sau când achiziționarea unui server mai puternic se dovedește a fi neprofitabilă

Exemplul dat cu bazele de date relaționale și NoSQL este o situație care apare cel mai des. Serverele frontend și backend sunt, de asemenea, scalabile.

Citiți despre echilibrator

|

Un număr în continuă creștere de vizitatori ai site-ului este întotdeauna o mare realizare pentru dezvoltatori și administratori. Desigur, cu excepția acelor situații în care traficul crește atât de mult încât blochează serverul web sau alt software. Întreruperile constante ale site-ului web sunt întotdeauna foarte costisitoare pentru companie.

Cu toate acestea, acest lucru poate fi remediat. Și dacă acum te gândești la scalare, ești pe drumul cel bun.

Pe scurt, scalabilitatea este capacitatea unui sistem de a gestiona un volum mare de trafic și de a se adapta la creșterea acestuia, menținând în același timp UX-ul dorit. Există două metode de scalare:

  • Verticală (numită și scalare): creșterea resurselor sistemului, cum ar fi adăugarea de memorie și putere de calcul. Această metodă vă permite să rezolvați rapid problemele legate de procesarea traficului, dar resursele sale se pot epuiza rapid.
  • Orizontală (sau extindere): adăugarea de servere la cluster. Să ne uităm la această metodă mai detaliat.

Ce este scalarea orizontală?

Mai simplu spus, un cluster este un grup de servere. Un echilibrator de încărcare este un server care distribuie sarcina de lucru între serverele dintr-un cluster. În orice moment, puteți adăuga un server web la un cluster existent pentru a gestiona mai mult trafic. Aceasta este esența scalarii orizontale.

Echilibratorul de încărcare este responsabil doar pentru a decide care server din cluster va procesa cererea primită. Practic, funcționează ca un proxy invers.

Scalare orizontală este, fără îndoială, mai mult metoda de incredere creșterea performanței aplicației, dar este mai dificil de configurat decât scalarea verticală. Sarcina principală și cea mai dificilă în acest caz este să păstrați în mod constant toate nodurile aplicației actualizate și sincronizate. Să presupunem că utilizatorul A trimite o cerere către mydomain.com, după care echilibratorul transmite cererea către serverul 1. Apoi cererea utilizatorului B va fi procesată de serverul 2.

Ce se întâmplă dacă utilizatorul A face modificări în aplicație (de exemplu, încarcă un fișier sau actualizează conținutul bazei de date)? Cum poate fi transmisă această modificare către restul serverelor din cluster?

Răspunsul la aceste și alte întrebări poate fi găsit în acest articol.

Separarea serverelor

Pregătirea sistemului pentru scalare necesită separarea serverelor; este foarte important ca serverele cu mai puține resurse să aibă mai puține responsabilități decât serverele mai mari. În plus, împărțirea aplicației în astfel de „părți” vă va permite să identificați rapid elementele sale critice.

Să presupunem că aveți o aplicație PHP care vă permite să vă autentificați și să încărcați fotografii. Aplicația se bazează pe stiva LAMP. Fotografiile sunt salvate pe disc, iar linkurile către ele sunt stocate în baza de date. Provocarea aici este de a sprijini sincronizarea între mai multe servere de aplicații care partajează aceste date (fișiere încărcate și sesiuni de utilizator).

Pentru a scala această aplicație, trebuie să separați serverul web și serverul bazei de date. Astfel, în cluster vor apărea noduri care partajează serverul bazei de date. Acest lucru va crește performanța aplicației prin reducerea încărcării pe serverul web.

În viitor, puteți configura echilibrarea sarcinii; Puteți citi despre acest lucru în manualul ""

Consecvența sesiunii

Cu serverul web și baza de date separate, trebuie să vă concentrați pe gestionarea sesiunilor utilizatorilor.

Baze de date relaționale și sisteme de fișiere de rețea

Datele sesiunii sunt adesea stocate în baze de date relaționale date (cum ar fi MySQL), deoarece aceste baze de date sunt ușor de configurat.

Cu toate acestea, această soluție nu este cea mai fiabilă, deoarece în acest caz sarcina crește. Serverul trebuie să intre în baza de date fiecare operație de citire și scriere pentru fiecare cerere separată, iar în cazul unei creșteri bruște a traficului, baza de date tinde să eșueze înaintea altor componente.

Sistemele de fișiere din rețea reprezintă o altă modalitate simplă de stocare a datelor; nu este nevoie să faceți modificări în baza de date textele sursă, in orice caz sisteme de rețea procesează operațiunile I/O foarte lent, iar acest lucru poate avea un impact negativ asupra performanței aplicației.

Sesiuni lipicioase

Sesiunile sticky sunt implementate pe echilibrator de încărcare și nu necesită nicio modificare a nodurilor aplicației. Aceasta este metoda cea mai convenabilă pentru gestionarea sesiunilor de utilizator. Echilibratorul de încărcare va indica întotdeauna utilizatorul către același server, eliminând nevoia de a distribui datele de sesiune între nodurile rămase din cluster.

Cu toate acestea, această soluție are și un dezavantaj serios. Acum balansierul nu numai că distribuie sarcina, ci și are sarcină suplimentară. Acest lucru îi poate afecta performanța și poate duce la blocarea acestuia.

Servere Memcached și Redis

De asemenea, puteți configura unul sau mai multe servere suplimentare a procesa sesiunile. Acesta este cel mai mult mod de încredere rezolvarea problemelor legate de procesarea sesiunilor.

Acțiuni finale

Scalarea orizontală a unei aplicații poate părea o soluție foarte complexă și confuză la început, dar ajută la eliminarea problemelor grave de trafic. Principalul lucru este să învățați cum să lucrați cu un echilibrator de încărcare pentru a înțelege ce componente necesită o configurație suplimentară.

Scalarea și performanța aplicației sunt foarte strâns legate. Desigur, nu toate aplicațiile și site-urile au nevoie de scalare. Cu toate acestea, este mai bine să vă gândiți la acest lucru în avans, de preferință în etapa de dezvoltare a aplicației.

Etichete: ,