1. Mis on koormuse tasakaalustamine
Uut veebisaiti ei tohiks koormust tasakaalustada, sest liiklusmaht pole suur, seega pole vaja nendesse asjadesse tegeleda. Kuid veebiliikluse ja liikluse kiire kasvu tõttu on üks server piiratud oma riistvaraliste tingimuste tõttu ning on raske taluda nii suurt külastusarvu. Sellisel juhul on valida kahe valiku vahel:
1. Uuendada ühe serveri riistvara kahetuumalisest neljatuumaliseks, suurendada mälu jne.
2. Suurendada serverite arvu, et jagada serverite koormust. Eesmärgi saavutamiseks suurendada võrgu ribalaiust ja suurendada serveri töötlemisvõimsust.
Esimest meetodit võib mõista kui vertikaalset arengut, mis on alati piiratud. Teine meetod on õige valik probleemi lahendamiseks
Koormuse tasakaalustamise meetodid jagunevad kaheks suunaks: üks on tarkvara kasutamine koormuse tasakaalustamiseks ja teine riistvaralise koormuse tasakaalustamise rakendamine (sh riistvara ja tarkvara kombineerimine)
Kasuta tarkvara koormuse tasakaalustamiseks ning koormuse tasakaalustamise protsess kulutab ka osa süsteemi ressurssidest ja suurendab reageerimisaega. Näiteks LVS, nginx, haproxy, apache jne – need rakenduspõhised koormuse tasakaalustamise tarkvarad sobivad veebilehtedele, millel pole eriti palju külastusi. Kui sul on veebileht, kus on palju külastusi, nagu SINA ja 163, siis riistvara kasutamine koormuse tasakaalustamiseks on kõige ilmsem valik.
On palju koormuse tasakaalustamise algoritme, sealhulgas koormuse tasakaalustamine päringute arvu, juur-IP-aadresside ja liikluspõhiste algoritmide alusel. On kaks algoritmi, mida ma tihti kasutan.
Üks põhineb päringute arvul
V: ta suudab mõista, et iga server saab kliendi päringut võrdselt jagada ning kui üks serveritest läheb maha, ei põhjusta see halba mõju.
b. Serverite vaheline olek peab olema sünkroniseeritud, näiteks sessioon, ning nende olekute sünkroniseerimiseks on vaja muid meetodeid.
Üks on IP järgi
V, ip_hash algoritm suudab IP-aadressi kaardistada serveriga, mis lahendab sessioonide sünkroniseerimise probleemi
b. Halb asi ip_hash on see, et kui üks serveritest läheb rivist välja, on selle serveriga seotud kasutajad masenduses.
c, ip_hash võib kergesti viia tasakaalustamata koormuseni, nüüd filtreerib jõekrabi valitsus Google'i otsingumärksõnu, sageli ei suuda Google avada, kuid pärast mõnda aega on kõik korras. See tegi Google'i entusiastid masendunuks ja paljud kasutajad läksid välismaale, et leida agente. Kui see juhtub, määratakse need proksid samale serverile, põhjustades tasakaalustamata koormust ja isegi rikkeid.
Teiseks, mis on sessiooni pidamine ja mis on selle funktsioon
Sessiooni hoidmine viitab koormuse tasakaalustaja mehhanismile, mis tagab, et sama kasutajaga seotud juurdepääsupäringud jaotatakse samale serverile koormuse tasakaalustamise ajal.
Mida teeb sessiooni hoidmine, too näide
Kui kasutaja juurdepääsupäring määratakse serverile A ja logitakse serverisse A ning lühikese aja pärast saadab see kasutaja uue päringu, kui sessiooni peatamise funktsiooni pole, määratakse selle kasutaja päring tõenäoliselt serverile B, praegu serveris B sisselogimist ei ole, seega tuleb uuesti sisse logida, kuid kasutaja ei tea, kuhu tema päring on määratud, kasutaja tunneb, et ta on sisse logitud, miks ta peab uuesti sisse logima, kasutajakogemus on väga halb.
Ja kui ostad midagi Taobaos, login = "Shoot something=" add address = "to pay", siis see on protsesside jada, mida võib mõista ka operatsiooniprotsessina, kõik need protsesside jada peaks olema ühe serveri poolt täidetud ja koormuse tasakaalustaja ei saa neid erinevatele serveritele määrata.
Sessiooni hoidmisel on ajapiirang (välja arvatud serverid, mis on määratud fikseeritud serverile, näiteks ip_hash), ning erinevad koormuse tasakaalustamise tööriistad pakuvad seda sessiooni hoidmise aja seadet, LVS-i, apache'i jne. Isegi PHP keel pakub session.gc_maxlifetime sessiooni peatamise aja määramiseks
Sessiooni hoidmise aeg peaks olema määratud pikemaks kui sessiooni ellujäämisaeg, mis võib vähendada sessioonide sünkroniseerimise vajadust, kuid seda ei saa välistada. Seega tuleb sessioonide sünkroniseerimine veel ära teha.
Kolmandaks, sessioonide sünkroniseerimine
Miks sessioonide sünkroniseerimine, seda on mainitud, kui räägitakse sessioonide hoidmisest. Lisateabe saamiseks vaata Kolm meetodit sessioonide sünkroniseerimiseks veebiklastris
Veebiklastris on kolm seansi sünkroniseerimise meetodit
Pärast veebiklastri tegemist kaalud kindlasti esmalt sessioonide sünkroniseerimist, sest pärast koormuse tasakaalustamist määratakse sama IP ligipääs samale lehele erinevatele serveritele. See artikkel annab kolm erinevat viisi selle probleemi lahendamiseks vastavalt sellele olukorrale:
Esiteks kasuta andmebaasi sessiooni sünkroniseerimiseks
Ma ei kasutanud seda meetodit mitme serveri sessioonide sünkroniseerimisel, kuid kui peaksin seda meetodit kasutama, mõtlesin kahele meetodile:
1. Kasuta madala klassi arvutit, et ehitada andmebaas veebiserveri sessiooni salvestamiseks või ehita see eriline andmebaas failiserveris; kui kasutaja veebiserverile ligi pääseb, läheb ta sinna spetsiaalsesse andmebaasi, et kontrollida sessiooni olukorda ja saavutada sessiooni sünkroniseerimise eesmärk.
2. See meetod on panna tabel, kus sessioon on salvestatud, koos teiste andmebaasitabelitega, kui mysql on samuti klasterdatud, peab iga mysql sõlm omama seda tabelit ning selle sessioonitabeli andmetabel peab olema reaalajas sünkroniseeritud.
Selgitus: Andmebaasi kasutamine sessioonide sünkroniseerimiseks suurendab andmebaasi koormust, mis on olemuslikult kitsaskohtadele vastuvõtlik. Esimene kahest eelmainitud meetodist on parem, mis eraldab tabeli, kus sessioon asub, iseseisvalt, vähendades reaalse andmebaasi koormust
2. Kasuta küpsiseid sessioonide sünkroniseerimiseks
Sessioon on failisituatsioon, mis on salvestatud serveri poolele, ja küpsis on failisituatsioon kliendis, kuidas sünkroniseerimist saavutada? Meetod on väga lihtne – kasutaja külastuslehe poolt genereeritud sessioon panna küpsisesse, st kasutada küpsist edastusjaamana. Külastad veebiserverit A, genereerid sessiooni ja paned selle küpsisesse, sinu ligipääs määratakse veebiserverile B, sel hetkel hindab veebiserver B esmalt, kas serveril on see sessioon, kui mitte, siis mine vaatama, kas see sessioon on kliendi küpsises, kui ei, tähendab see, et sessioon pole tegelikult salvestatud, kui see on küpsises, Sünkroniseeri küpsise sessoin veebiserveriga B, et sessioon saaks sünkroniseerida.
Märkus: See meetod on lihtne ja mugav rakendada ning ei suurenda andmebaasi koormust, kuid kui klient keelab küpsised, ei saa sessiooni sünkroniseerida, mis toob veebilehele kahjusid; Küpsised ei ole väga turvalised ja kuigi need on krüpteeritud, saab neid siiski võltsida.
3. Kasuta memcache'i sessioonide sünkroniseerimiseks
Memcache'i saab levitada ning ilma selle funktsioonita ei saa seda kasutada sessioonide sünkroniseerimiseks. Ta suudab ühendada veebiserveri mälu, et moodustada "mempool", sõltumata sellest, milline server genereerib sessoini, saab selle panna sellesse "mempooli" ja kõike muud saab kasutada.
Eelised: sessioonide sünkroniseerimine sellisel viisil ei suurenda andmebaasi koormust ning turvalisus on võrreldes küpsistega oluliselt parem ning sessioonide mällu salvestamine on palju kiirem kui failidest lugemine.
Puudused: memcache jagab mälu paljudeks salvestusplokkide spetsifikatsioonideks, seal on plokke ja suurusi, mis määrab ka, et memcache ei suuda mälu täielikult kasutada, põhjustab mälu killustumist, kui salvestusplokk on ebapiisav, põhjustab see ka mälu üleujutust.
Neljandaks, kokkuvõte
Kõik kolm ülaltoodud meetodit on teostatavad
Esimene meetod, mis mõjutab süsteemi kiirust kõige enam, ei ole soovitatav;
Teine meetod annab häid tulemusi, kuid ohutusriskid on samad;
Kolmas meetod, minu arvates on parim, soovitan kõigil seda kasutada;
|
Postitatud 14.05.2015 00:16:44
|
|
|
