1. Vad är lastbalansering
En ny webbplats bör inte vara lastbalanserad, eftersom trafikvolymen inte är stor, så det finns inget behov av att engagera sig i dessa saker. Men med den snabba tillväxten av webbplatstrafik och trafik är en enda server begränsad av sina egna hårdvaruförhållanden, och det är svårt att hantera ett så stort antal besök. I detta fall finns det två alternativ att välja mellan:
1. Uppdatera hårdvaran på en enskild server, från dual-core till quad-core, öka minnet, etc.
2. Öka antalet servrar för att dela på bördan av servrarna. För att uppnå syftet att öka nätverksbandbredden och serverns processorkraft.
Den första metoden kan förstås som vertikal utveckling, som alltid är begränsad. Den andra metoden är rätt val för att lösa problemet
Metoderna för lastbalansering kan delas in i två riktningar: det ena är att använda mjukvara för att uppnå lastbalansering, och det andra är att implementera hårdvarulastbalansering (inklusive att kombinera hårdvara och mjukvara)
Använd programvara för att uppnå lastbalansering, och processen att uppnå lastbalansering förbrukar också vissa systemresurser och ökar svarstiden. Till exempel LVS, nginx, haproxy, apache, etc., dessa applikationsbaserade lastbalanseringsprogram är lämpliga för webbplatser som inte har särskilt många besök. Om du har en webbplats med många besök som sina och 163, är det mest självklara alternativet att använda hårdvara för att implementera lastbalansering.
Det finns många lastbalanseringsalgoritmer, inklusive lastbalansering baserad på antal förfrågningar, root-IP-adresser och trafikbaserade algoritmer. Det finns två algoritmer som jag ofta använder.
Den ena baseras på antalet förfrågningar
A, den kan inse att varje server kan dela kundens förfrågan jämnt, och om en av servrarna går ner kommer det inte att orsaka någon negativ påverkan.
b. Tillståndet mellan servrar måste synkroniseras, såsom session, och andra metoder behövs för att synkronisera dessa tillstånd.
En är enligt IP
En ip_hash algoritm kan mappa en IP till en server, vilket kan lösa problemet med sessionssynkronisering
b. Det dåliga med ip_hash är att om en av servrarna går ner, blir användarna kopplade till denna server deprimerade.
c, ip_hash lätt kan leda till obalanserad belastning, nu filtrerar flodkrabbregeringen Googles sökord, du kommer ofta att upptäcka att Google inte kan öppna, men det kommer att fungera bra efter ett tag. Detta gjorde dessa Google-entusiaster deprimerade, och många användare åkte utomlands för att hitta agenter. Om detta händer kommer dessa proxyservrar att tilldelas samma server, vilket orsakar obalanserad belastning och till och med fel.
För det andra, vad är sessionshållande och vad är dess funktion
Session hold avser en mekanism på lastbalanseraren som säkerställer att åtkomstförfrågningar kopplade till samma användare distribueras till samma server vid lastbalansering.
Vad gör sessionshåll, ge ett exempel
Om en användaråtkomstförfrågan tilldelas server A, och loggar in på server A, och på kort tid skickar användaren en ny förfrågan, om det inte finns någon session hold-funktion, är användarens begäran sannolikt att tilldelas server B, vid denna tidpunkt finns ingen inloggning på server B, så du måste logga in igen, men användaren vet inte var hans begäran är tilldelad, användarens känsla är att han är inloggad, varför måste han logga in igen, användarupplevelsen är mycket dålig.
Och om du köper något på Taobao, från login = "Shoot something=" add address = "to pay", är detta en serie processer som också kan förstås som en operationsprocess, alla dessa operationer ska slutföras av en server och kan inte tilldelas olika servrar av lastbalanseraren.
Session hold har en tidsgräns (förutom servrar som är mappade till en fast sådan, som ip_hash), och olika lastbalanseringsverktyg tillhandahåller denna session hold-tidsinställning, LVS, apache, etc. Till och med PHP-språket ger en session.gc_maxlifetime för att ställa in väntetiden för sessioner
Sessionstiden för att hålla sessioner bör ställas in mer än överlevnadstiden för sessionen, vilket kan minska behovet av synkronisering, men den kan inte elimineras. Så synkronisering av sessioner måste fortfarande göras.
För det tredje, sessionssynkronisering
Varför sessionssynkronisering, det har nämnts när man pratar om sessionshantering. För mer information, se Tre metoder för sessionssynkronisering i ett webbkluster
Det finns tre metoder för sessionssynkronisering i ett webbkluster
Efter att ha gjort ett webbkluster kommer du definitivt att överväga sessionssynkronisering först, eftersom efter lastbalansering kommer samma IP-åtkomst till samma sida att tilldelas olika servrar. Så den här artikeln ger tre olika sätt att lösa detta problem beroende på situationen:
Använd först databasen för att synkronisera sessionen
Jag använde inte den här metoden när jag gjorde multi-server-sessionssynkronisering, men om jag var tvungen att använda den tänkte jag på två metoder:
1. Använd en lågpresterande dator för att bygga en databas för att lagra webbserverns session, eller bygg denna speciella databas på filservern, när användaren får tillgång till webbservern går han till denna speciella databas för att kontrollera sessionssituationen för att uppnå syftet med sessionssynkronisering.
2. Denna metod är att lägga tabellen där sessionen lagras tillsammans med andra databastabeller; om mysql också är klustrat måste varje mysql-nod ha denna tabell, och datatabellen för denna sessionstabell måste synkroniseras i realtid.
Förklaring: Att använda databasen för att synkronisera sessioner ökar belastningen på databasen, som är benägen för flaskhalsar. Den första av ovanstående två metoder är bättre, vilket separerar tabellen där sessionen placeras oberoende och minskar bördan på den verkliga databasen
2. Använd cookies för att synkronisera sessioner
Session är filsituationen som lagras på serversidan, och cookie är filsituationen på klienten, hur uppnår man synkronisering? Metoden är mycket enkel, det vill säga att lägga sessionen som genereras av användarens besökssida i cookien, det vill säga att använda cookien som en relästation. Du besöker webbserver A, genererar en session och lägger in den i cookien, din åtkomst tilldelas webbserver B, vid denna tidpunkt bedömer webbserver B först om servern har denna session, om inte, gå och se om det finns denna session i klientens cookie, annars betyder det att sessionen verkligen inte sparas, om det finns en i cookien, Synkronisera sessionoin i cookien till webbserver B, så att sessionen kan synkroniseras.
Obs: Denna metod är enkel och bekväm att implementera, och kommer inte att öka belastningen på databasen, men om klienten inaktiverar cookies kan sessionen inte synkroniseras, vilket kommer att medföra förluster för webbplatsen; Cookies är inte särskilt säkra, och även om de har krypterats kan de fortfarande förfalskas.
3. Använd memcache för att synkronisera sessioner
Memcache kan distribueras, och utan denna funktion kan den inte användas för sessionssynkronisering. Han kan kombinera minnet i webbservern för att bli en "mempool", oavsett vilken server som genererar sessoin, kan det läggas in i denna "mempool" och allt annat kan användas.
Fördelar: att synkronisera sessioner på detta sätt ökar inte belastningen på databasen, och säkerheten är avsevärt förbättrad jämfört med att använda cookies, och att lägga sessioner i minnet är mycket snabbare än att läsa från filer.
Nackdelar: memcache delar in minnet i många specifikationer av lagringsblock, det finns block och storlekar, detta avgör också, memcache kan inte utnyttja minnet fullt ut, vilket leder till minnesfragmentering, om lagringsblocket är otillräckligt kommer det också att orsaka minnesöverflöd.
För det fjärde, sammanfattning
Alla tre ovanstående metoder är genomförbara
Den första metoden, den som påverkar systemets hastighet mest, rekommenderas inte;
Den andra metoden ger goda resultat, men säkerhetsriskerna är desamma;
Den tredje metoden, jag tycker personligen att den tredje metoden är den bästa, jag rekommenderar alla att använda den;
|
Publicerad på 2015-05-14 00:16:44
|
|
|
