Požadavky: Použijte Nginx k vytvoření reverzního proxy, který je zodpovědný za plánování všech požadavků, backend vyvíjí ASP.NET MVC a nasazuje ho na více různých serverů, čímž vzniká backendový clusterInformace o relaci nelze sdílet, což vede k tomu, že některé požadavky nejsou správně zpracovány。 Objeví se následující problémy:
ASP.NET Webové stránky lze označovat následovně:
Běžně používaná řešení jsou následující:
Použijte databázi k uložení SESSION
Protože každý server musí používat stejnou relaci, můžeme ji uložit do stejné databáze, pokaždé, když přistupujeme, jdeme do databáze zkontrolovat, zda tato relace existuje, nebo zda už vypršela, a pak můžeme synchronizovat relaci více serverů;
Zásluha:Použití této metody je jednoduché, pohodlné a snadné začít;
Nedostatek:Použití databáze k synchronizaci relací zvýší IO databáze a zvýší zátěž na databázi. Současně musí každý přístup zachytávat požadavky a dotazovat databázi, což vede k další vrstvě přístupu a zbytečnému času v databázové relaci.
Použijte cacheovací mechanismus, jako je Memcache nebo Redis, k uložení SESSION
Používání distribuovaných cacheových mechanismů, jako je memcache nebo redis pro ukládání dat relací, je oblíbeným řešením pro vyvažování zátěže a synchronní relace v mnoha velkých projektech. Principem projektu je, že projekt používá memcache nebo redis cache na stejném místě, když se uživatel přihlásí, relace se uloží do cache a bez ohledu na to, ke kterému serveru projektu se přistupuje, cache relace bude získána ze stejného místa, takže synchronizace relace je snadno realizovatelná;
Zásluha:Použití cache k synchronizaci relací nezvýší zátěž na databázi, ani nemusíte ručně posuzovat, zda relace existuje nebo vyprší, čímž odpadá část obchodní logiky.
Nedostatek:Memcache nebo Redis dělí paměť do mnoha specifikací úložných bloků a existují bloky s velikostí, což také určuje, že memcache nebo redis nemohou plně využít paměť, což způsobí fragmentaci paměti, a pokud jsou úložné bloky nedostatečné, dojde také k přetečení paměti.
Využití ip_hash vzoru v Nginx
Tato technika, známá také jako session keeping, je ip_hash technologií v nginx, která vám umožňujePožadavky z určité IP adresy jsou připnuty ke stejnému aplikačnímu serveru, takže klient a backend pod touto IP mohou navázat stabilní relaci.
(Ale existuje také nevýhoda, pokud je síť operátora volatilnější a nestabilnější,Výstupní IP je dynamickáAno, s touto metodou budou problémy. ）
Testovací metoda spočívá v otevření dvou lokalit založených na dockeru,Musíte vytvořit nový index.html soubor v adresářích /data/testsite/a a /data/testsite/b, příkaz je následující:
Přístup přes prohlížeč, jak je uvedeno níže:
Pokud vytvoříte nový nginx kontejner založený na Dockeru bez použití ip_hash technologie, může být požadavek odeslán na různé backendové servery, jak je znázorněno na obrázku níže:
Pomocí ip_hash technologie vytvořte nový soubor /data/testsite/nginx.conf s následující konfigurací:
Docker launch command je následující:
（Uchovávání relací založené na cookies, které lze konzultovat v připnutém modulu, bylo vynecháno）
Konfigurace Nginx:Přihlášení k hypertextovému odkazu je viditelné.
(Konec)
|
Zveřejněno 10.01.2023 20:38:39
|
|
|
|
