1. Čo je vyvažovanie záťaže
Nová webová stránka by nemala byť vyvážená záťažou, pretože objem návštevnosti nie je veľký, takže nie je potrebné sa do týchto vecí zapájať. Avšak s rýchlym rastom návštevnosti webu a návštevnosti je jeden server obmedzený vlastnými hardvérovými podmienkami a je ťažké zvládnuť taký veľký počet návštev. V tomto prípade sú na výber dve možnosti:
1. Aktualizovať hardvér jedného servera, z dvojjadrového na štvorjadrový, zvýšiť pamäť a podobne.
2. Zvýšiť počet serverov na zdieľanie záťaže serverov. Dosiahnuť účel zvýšenia šírky pásma siete a zvýšenia výpočtového výkonu servera.
Prvú metódu možno chápať ako vertikálny vývoj, ktorý je vždy obmedzený. Druhá metóda je správnou voľbou na vyriešenie problému
Metódy vyvažovania záťaže možno rozdeliť do dvoch smerov, jeden je použitie softvéru na dosiahnutie vyvažovania záťaže a druhý implementácia hardvérového vyvažovania záťaže (vrátane kombinovania hardvéru a softvéru)
Použite softvér na dosiahnutie vyvažovania záťaže a proces vyrovnávania záťaže tiež spotrebúva časť systémových zdrojov a zvyšuje dobu odozvy. Napríklad LVS, nginx, haproxy, apache a podobne, tieto aplikačné softvéry na vyvažovanie záťaže sú vhodné pre webové stránky, ktoré nemajú príliš veľký počet návštev. Ak máte webovú stránku s veľkým počtom návštev ako sina a 163, použitie hardvéru na implementáciu load balancing je najzrejmejšou voľbou.
Existuje mnoho algoritmov na vyvažovanie záťaže, vrátane vyvažovania záťaže na základe počtu požiadaviek, koreňových IP adries a algoritmov založených na prevádzke. Existujú dva algoritmy, ktoré často používam.
Jedna je založená na počte požiadaviek
Odpoveď, môže si uvedomiť, že každý server môže zdieľať požiadavku zákazníka rovnomerne, a ak jeden zo serverov vypadne, nebude to mať negatívny dopad.
b. Stav medzi servermi musí byť synchronizovaný, napríklad relácia, a sú potrebné ďalšie prostriedky na synchronizáciu týchto stavov.
Jeden je podľa duševného vlastníctva
Algoritmus ip_hash môže mapovať IP adresu na server, čo môže vyriešiť problém synchronizácie relácie
b. Nevýhodou ip_hash je, že ak jeden zo serverov vypadne, používatelia namapovaní na tento server budú deprimovaní.
c, ip_hash môže ľahko viesť k nevyváženému zaťaženiu, teraz vláda riečneho kraba filtruje kľúčové slová Google, často zistíte, že Google ho nedokáže otvoriť, ale po čase to bude v poriadku. To týchto nadšencov Google deprimovalo a mnohí používatelia odchádzali do zahraničia hľadať agentov. Ak sa to stane, tieto proxy súbory budú priradené na ten istý server, čo spôsobí nevyvážené zaťaženie a dokonca aj zlyhanie.
Po druhé, čo je držanie relácie a aká je jeho funkcia
Session hold označuje mechanizmus na load balanceri, ktorý zabezpečuje, že prístupové požiadavky spojené s tým istým používateľom sú distribuované na ten istý server počas vyvažovania záťaže.
Čo robí session hold, uveďte príklad
Ak je žiadosť o prístup používateľa priradená serveru A a prihlási sa na server A, a v krátkom čase tento používateľ pošle ďalšiu požiadavku, ak neexistuje funkcia udržania relácie, požiadavka tohto používateľa bude pravdepodobne priradená serveru B, v tomto čase nie je na serveri B žiadne prihlásenie, takže sa musíte znova prihlásiť, ale používateľ nevie, kde je jeho požiadavka priradená, má pocit, že je prihlásený, prečo sa musí znova prihlasovať, používateľská skúsenosť je veľmi zlá.
A ak si niečo kúpite na Taobao, z login = "Shoot something=" add address = "to pay", ide o sériu procesov, ktorú možno chápať aj ako operačný proces, pričom všetky tieto operácie by mal vykonať jeden server a load balancer ich nemôže priradiť rôznym serverom.
Session hold má časový limit (okrem serverov, ktoré sú namapované na pevný limit, napríklad ip_hash), a rôzne nástroje na vyvažovanie záťaže poskytujú toto nastavenie času držania relácie, LVS, apache a podobne. Dokonca aj jazyk PHP poskytuje session.gc_maxlifetime na nastavenie času držania relácie
Čas udržiavania relácie by mal byť nastavený dlhší ako čas prežitia relácie, čo môže znížiť potrebu synchronizácie relácií, ale nedá sa to odstrániť. Takže synchronizácia relácií je stále potrebná.
Po tretie, synchronizácia relácie
Prečo synchronizácia relácií, bolo to spomenuté pri rozprávaní o udržiavaní relácií. Pre viac informácií pozri Tri metódy synchronizácie relácií vo webovom klastri
Existujú tri metódy synchronizácie relácií vo webovom klastri
Po vytvorení webového klastra určite najskôr zvážite synchronizáciu relácie, pretože po vyvažovaní záťaže bude rovnaký IP prístup k tej istej stránke priradený rôznym serverom. Tento článok ponúka tri rôzne spôsoby, ako tento problém vyriešiť podľa tejto situácie:
Najprv použite databázu na synchronizáciu relácie
Túto metódu som nepoužil pri synchronizácii viacserverových relácií, ale ak by som ju mal použiť, napadli by mi dve metódy:
1. Použiť nízkorozpočtový počítač na vytvorenie databázy na uloženie relácie webového servera, alebo vytvoriť túto špeciálnu databázu na súborovom serveri, keď používateľ pristupuje k webovému serveru, navštívi túto špeciálnu databázu, aby skontroloval situáciu relácie a dosiahol tak účel synchronizácie relácie.
2. Táto metóda spočíva v tom, že tabuľka, v ktorej je relácia uložená, sa spojí s ostatnými databázovými tabuľkami, ak je mysql tiež klastrovaný, každý mysql uzol musí mať túto tabuľku a dátová tabuľka tejto relácie musí byť synchronizovaná v reálnom čase.
Vysvetlenie: Použitie databázy na synchronizáciu relácií zvýši záťaž na databázu, ktorá je prirodzene náchylná na úzke miesta. Prvá z týchto dvoch metód je lepšia, pretože oddeľuje tabuľku, kde je relácia umiestnená nezávisle, čím sa znižuje záťaž na skutočnú databázu
2. Používanie cookies na synchronizáciu relácií
Session je súborová situácia uložená na serverovej strane a cookie je súborová situácia na klientovi, ako dosiahnuť synchronizáciu? Metóda je veľmi jednoduchá, teda vložiť reláciu generovanú návštevnou stránkou používateľa do cookie, teda použiť cookie ako reléovú stanicu. Navštívite webový server A, vygenerujete reláciu a vložíte ju do cookie, váš prístup je priradený webovému serveru B, v tomto čase webový server B najprv posúdi, či server túto reláciu má, ak nie, pozrite, či je táto relácia v cookie-ku klienta, ak nie, znamená to, že relácia naozaj nie je uložená, ak v cookie vôbec je, Synchronizujte sessoin v cookie s webovým serverom B, aby sa relácia mohla synchronizovať.
Poznámka: Táto metóda je jednoduchá a pohodlná na implementáciu a nezvýši záťaž na databázu, ale ak klient vypne cookies, relácia sa nedá synchronizovať, čo spôsobí straty webovej stránke; Cookies nie sú vysoko zabezpečené a hoci boli zašifrované, stále ich možno sfalšovať.
3. Použitie memcache na synchronizáciu relácií
Memcache je možné distribuovať, ale bez tejto funkcie ju nie je možné použiť na synchronizáciu relácií. Môže spojiť pamäť na webovom serveri a vytvoriť tak "mempool", bez ohľadu na to, ktorý server generuje sessoin, môže byť vložený do tohto "mempoolu" a všetko ostatné môže byť použité.
Výhody: synchronizácia relácií týmto spôsobom nezvyšuje záťaž databázy a bezpečnosť je výrazne lepšia v porovnaní s používaním cookies a ukladanie relácií do pamäte je oveľa rýchlejšie ako čítanie zo súborov.
Nevýhody: memcache rozdeľuje pamäť na mnoho špecifikácií úložných blokov, existujú bloky a veľkosti, tento spôsob tiež určuje, že memcache nemôže plne využiť pamäť, spôsobí fragmentáciu pamäte, ak je blok nedostatočný, spôsobí aj pretečenie pamäte.
Po štvrté, zhrnutie
Všetky tri vyššie uvedené metódy sú možné
Prvá metóda, tá, ktorá najviac ovplyvňuje rýchlosť systému, sa neodporúča;
Druhá metóda prináša dobré výsledky, ale bezpečnostné riziká sú rovnaké;
Tretia metóda, osobne si myslím, že tretia metóda je najlepšia, odporúčam ju každému používať;
|
Zverejnené 14. 5. 2015 0:16:44
|
|
|
