1. Co je to vyvažování zátěže
Nový web by neměl být vyvažován zatížením, protože objem návštěvnosti není velký, takže není třeba se do těchto věcí zapojovat. Nicméně s rychlým růstem návštěvnosti a provozu na webu je jeden server omezen vlastními hardwarovými podmínkami a je obtížné zvládnout tak velký počet návštěv. V tomto případě jsou k dispozici dvě možnosti:
1. Aktualizovat hardware jednoho serveru, z dvoujádrového na čtyřjádrový, zvýšit paměť atd.
2. Zvýšit počet serverů, aby se podělila o zátěž serverů. Za účelem dosažení cíle zvýšení šířky pásma sítě a zvýšení výpočetního výkonu serveru.
První metodu lze chápat jako vertikální vývoj, který je vždy omezený. Druhá metoda je správnou volbou pro řešení problému
Metody vyvažování zátěže lze rozdělit do dvou směrů: jedním je použití softwaru k dosažení vyvažování zátěže a druhým implementace hardwarového vyvažování zátěže (včetně kombinace hardwaru a softwaru)
Použijte software k dosažení vyvažování zátěže a proces jeho dosažení také spotřebovává některé systémové zdroje a prodlužuje dobu odezvy. Například LVS, nginx, haproxy, apache atd., tyto aplikační programy pro vyvažování zátěže jsou vhodné pro webové stránky, které nemají příliš velký počet návštěv. Pokud máte web s velkým počtem návštěv, jako je sina a 163, použití hardwaru pro implementaci load balancing je nejzřejmější volbou.
Existuje mnoho algoritmů pro vyvažování zátěže, včetně vyvažování zátěže založeného na počtu požadavků, root IP adres a algoritmů založených na provozu. Existují dva algoritmy, které často používám.
Jedna je založena na počtu žádostí
Odpověď, může si uvědomit, že každý server může sdílet požadavek zákazníka rovnoměrně, a pokud jeden ze serverů vypadne, nebude to mít vážný dopad.
b. Stav mezi servery musí být synchronizován, například relace, a jsou potřeba další prostředky k synchronizaci těchto stavů.
Jeden je podle duševního vlastnictví
Algoritmus ip_hash může mapovat IP adresu na server, což může vyřešit problém synchronizace relace
B. Špatné na ip_hash je, že pokud jeden ze serverů vypadne, uživatelé přiřazení k tomuto serveru budou depresivní.
c, ip_hash může snadno vést k nevyváženému zatížení, nyní vláda říčních krabů filtruje klíčová slova Googlu, často zjistíte, že Google to nedokáže otevřít, ale po čase to bude v pořádku. To tyto nadšence do Googlu deprimovalo a mnoho uživatelů odjelo do zahraničí hledat agenty. Pokud k tomu dojde, tyto proxy budou přiřazeny ke stejnému serveru, což způsobí nevyvážené zatížení a dokonce i selhání.
Za druhé, co je držení relace a jaká je jeho funkce
Session hold označuje mechanismus na load balanceru, který zajišťuje, že přístupové požadavky spojené se stejným uživatelem jsou distribuovány na stejný server při provádění load balancingu.
Co dělá session hold, uveďte příklad
Pokud je uživatelský požadavek přiřazen serveru A a přihlásí se na server A, a během krátké doby odešle další požadavek, pokud není funkce session hold, pravděpodobně bude požadavek přiřazen serveru B, v tuto chvíli není přihlášení na serveru B, takže se musíte znovu přihlásit, ale uživatel neví, kam je jeho požadavek přiřazen, uživatel má pocit, že je přihlášený, proč se musí znovu přihlašovat, uživatelská zkušenost je velmi špatná.
A pokud něco koupíte na Taobao, z login = "Shoot something=" add address = "to pay", jedná se o sérii procesů, kterou lze chápat i jako provozní proces, všechny tyto operace by měl provádět jeden server a nelze je přiřadit různým serverům load balancerem.
Session hold má časový limit (kromě serverů, které jsou namapovány na pevný režim, například ip_hash), a různé nástroje pro vyvažování zátěže poskytují toto nastavení doby držení relace, LVS, apache atd. Dokonce i jazyk PHP poskytuje session.gc_maxlifetime nastavení doby držení relace
Doba udržení relace by měla být nastavena déle než doba přežití relace, což může snížit potřebu synchronizace relací, ale nelze ji eliminovat. Takže synchronizace relací je stále potřeba.
Za třetí, synchronizace relace
Proč synchronizace relací, bylo to zmíněno při mluvení o udržování relací. Pro více informací viz Tři metody synchronizace relací ve webovém clusteru
Existují tři způsoby synchronizace relací ve webovém clusteru
Po vytvoření webového clusteru určitě nejprve zvážíte synchronizaci relací, protože po vyvažování zátěže bude stejný IP přístup ke stejné stránce přiřazen různým serverům. Tento článek tedy uvádí tři různé způsoby, jak tento problém vyřešit podle této situace:
Nejprve použijte databázi k synchronizaci relace
Tuto metodu jsem při synchronizaci multiserverových relací nepoužil, ale kdybych měl použít tuto metodu, napadly mě dvě metody:
1. Použít nízkorozpočtový počítač k vytvoření databáze pro uložení relace webového serveru, nebo vytvořit tuto speciální databázi na souborovém serveru; když uživatel přistupuje k webovému serveru, přejde do této speciální databáze, aby zkontroloval situaci relace a dosáhl tak synchronizace relace.
2. Tato metoda spočívá v tom, že tabulka, kde je relace uložena, je spojena s dalšími databázovými tabulkami; pokud je mysql také clusterován, každý uzel mysql musí mít tuto tabulku a datová tabulka této relací tabulky musí být synchronizována v reálném čase.
Vysvětlení: Použití databáze k synchronizaci relací zvýší zátěž na databázi, která je sama o sobě náchylná k úzkým hrdlům. První z výše uvedených dvou metod je lepší, protože odděluje tabulku, kde je relace umístěna samostatně, a snižuje zátěž na skutečnou databázi
2. Používejte cookies k synchronizaci relací
Session je situace se souborem uložená na straně serveru a cookie je situace se souborem na klientovi, jak dosáhnout synchronizace? Metoda je velmi jednoduchá, tedy vložit relaci generovanou stránkou uživatele do cookie, tedy použít cookie jako reléovou stanici. Navštívíte webový server A, vygenerujete relaci a vložíte ji do cookie, váš přístup je přiřazen webovému serveru B, v tomto okamžiku webový server B nejprve posoudí, zda server tuto relaci má, pokud ne, zkontrolujete, zda je tato relace v cookie, pokud ne, znamená to, že relace není uložena, pokud v cookie je, Synchronizujte sessoin v cookie s webovým serverem B, aby bylo možné synchronizovat relaci.
Poznámka: Tato metoda je jednoduchá a pohodlná na implementaci a nezvyšuje zátěž na databázi, ale pokud klient zakáže cookies, relace nemůže být synchronizována, což způsobí ztráty na webu; Cookies nejsou vysoce zabezpečené a i když byly zašifrované, stále je lze zfalšovat.
3. Použití memcache k synchronizaci relací
Memcache lze distribuovat, ale bez této funkce ji nelze použít pro synchronizaci relací. Může zkombinovat paměť webového serveru a vytvořit "mempool", bez ohledu na to, který server generuje sessoin, může být vložen do tohoto "mempoolu" a vše ostatní lze použít.
Výhody: synchronizace relací tímto způsobem nezvyšuje zátěž na databázi a bezpečnost je výrazně lepší než používání cookies a ukládání relací do paměti je mnohem rychlejší než čtení ze souborů.
Nevýhody: memcache rozděluje paměť do mnoha specifikací úložných bloků, existují bloky a velikosti, tento způsob také určuje, že memcache nemůže plně využít paměť, což způsobí fragmentaci paměti, pokud je blok nedostačující, dojde také k přetečení v paměti.
Za čtvrté, shrnutí
Všechny tři výše uvedené metody jsou proveditelné
První metoda, ta, která nejvíce ovlivňuje rychlost systému, se nedoporučuje;
Druhá metoda má dobré výsledky, ale bezpečnostní rizika jsou stejná;
Třetí metodu, osobně si myslím, že třetí metoda je nejlepší, doporučuji ji všem používat;
|
Zveřejněno 14.05.2015 0:16:44
|
|
|
