1. Hvad er load balancing
En ny hjemmeside bør ikke være loadbalanceret, fordi trafikmængden ikke er stor, så der er ikke behov for at engagere sig i disse ting. Men med den hurtige vækst i webtrafik og trafik er en enkelt server begrænset af sine egne hardwareforhold, og det er svært at modstå så mange besøg. I dette tilfælde er der to muligheder at vælge imellem:
1. Opdater hardwaren på en enkelt server fra dual-core til quad-core, øger hukommelsen osv.
2. Øge antallet af servere, der skal dele serverbyrden. For at opnå formålet at øge netværksbåndbredden og øge serverens processorkraft.
Den første metode kan forstås som vertikal udvikling, som altid er begrænset. Den anden metode er det rigtige valg til at løse problemet
Metoderne til load balancing kan opdeles i to retninger: den ene er at bruge software til at opnå load balancing, og den anden er at implementere hardware load balancing (herunder at kombinere hardware og software)
Brug software til at opnå load balancing, og processen med load balancing bruger også nogle systemressourcer og øger responstiden. For eksempel LVS, nginx, haproxy, apache osv., disse applikationsbaserede load balancing-programmer er velegnede til hjemmesider, der ikke har et særligt stort antal besøg. Hvis du har en hjemmeside med mange besøg som Sina og 163, er det mest oplagte valg at bruge hardware til load balancing.
Der findes mange lastbalanceringsalgoritmer, herunder belastningsbalancering baseret på antallet af forespørgsler, rod-IP-adresser og trafikbaserede algoritmer. Der er to algoritmer, jeg ofte bruger.
Den ene er baseret på antallet af forespørgsler
A, den kan indse, at hver server kan dele kundens anmodning ligeligt, og hvis en af serverne går ned, vil det ikke have en dårlig effekt.
b. Tilstanden mellem servere skal synkroniseres, såsom session, og andre midler er nødvendige for at synkronisere disse tilstande.
Den ene er ifølge IP
A, ip_hash algoritme kan kortlægge en IP til en server, hvilket kan løse problemet med sessionssynkronisering
b. Det dårlige ved ip_hash er, at hvis en af serverne går ned, vil de brugere, der er mappet til denne server, blive deprimerede.
c, ip_hash let kan føre til ubalanceret belastning, nu hvor flodkrabberegeringen filtrerer Googles søgeord, vil du ofte opdage, at Google ikke kan åbne, men det går fint efter et stykke tid. Dette gjorde Google-entusiaster deprimerede, og mange brugere rejste til udlandet for at finde agenter. Hvis dette sker, vil disse proxies blive tildelt samme server, hvilket forårsager ubalanceret belastning og endda fejl.
For det andet, hvad er sessionsafholdelse, og hvad er dens funktion
Session hold refererer til en mekanisme på load balanceren, der sikrer, at adgangsanmodninger tilknyttet den samme bruger distribueres til den samme server, mens belastningsbalancering udføres.
Hvad gør session hold, giv et eksempel
Hvis en brugeradgangsanmodning tildeles server A, og logger ind på server A, og denne bruger sender en ny anmodning på kort tid, hvis der ikke er nogen session hold-funktion, vil denne brugers anmodning sandsynligvis blive tildelt server B, på dette tidspunkt er der ingen login på server B, så du skal logge ind igen, men brugeren ved ikke, hvor hans anmodning er tildelt, brugerens følelse er, at han er logget ind, hvorfor skal han logge ind igen, brugeroplevelsen er meget dårlig.
Og hvis du køber noget på Taobao, fra login = "Skyd noget=" tilføj adresse = "for at betale", er dette en række processer, som også kan forstås som en operationsproces, alle disse rækker af operationsprocesser skal gennemføres af én server og kan ikke tildeles forskellige servere af load balanceren.
Session hold har en tidsbegrænsning (undtagen for servere, der er kortlagt til en fast en, såsom ip_hash), og forskellige load balancing-værktøjer tilbyder denne session hold-tidsindstilling, LVS, apache osv. Selv PHP-sproget giver en session.gc_maxlifetime til at indstille sessionstiden
Sessionens ventetid bør sættes højere end sessionens overlevelsestid, hvilket kan reducere behovet for at synkronisere sessioner, men det kan ikke elimineres. Så synkronisering af sessioner skal stadig foretages.
For det tredje, sessionssynkronisering
Hvorfor sessionssynkronisering, det er blevet nævnt, når man taler om sessionshold. For mere information, se Tre metoder til sessionssynkronisering i en webklynge
Der er tre metoder til sessionssynkronisering i en webklynge
Efter at have lavet en webklynge vil du helt sikkert overveje sessionssynkronisering først, fordi efter load balancing vil den samme IP-adgang til den samme side blive tildelt forskellige servere. Så denne artikel giver tre forskellige måder at løse dette problem på i forhold til denne situation:
Først skal du bruge databasen til at synkronisere sessionen
Jeg brugte ikke denne metode, da jeg lavede multi-server session synkronisering, men hvis jeg skulle bruge denne metode, tænkte jeg på to metoder:
1. Brug en lav-end computer til at bygge en database til at gemme webserverens session, eller opbygge denne specielle database på filserveren, når brugeren tilgår webserveren, vil han gå til denne specielle database for at tjekke sessionssituationen for at opnå formålet med sessionssynkronisering.
2. Denne metode er at lægge tabellen, hvor sessionen er gemt, sammen med andre databasetabeller; hvis MySQL også er klynget, skal hver mysql-node have denne tabel, og datatabellen for denne sessionstabel skal synkroniseres i realtid.
Forklaring: At bruge databasen til at synkronisere sessioner vil øge belastningen på databasen, som er iboende tilbøjelig til flaskehalse. Den første af de to ovenstående metoder er bedre, da den adskiller tabellen, hvor sessionen placeres, uafhængigt og dermed reducerer byrden på den reelle database
2. Brug cookies til at synkronisere sessioner
Session er filsituationen, der er lagret på serversiden, og cookie er filsituationen på klienten, hvordan opnår man synkronisering? Metoden er meget enkel, det vil sige at indtaste den session, der genereres af brugerens besøgsside, i cookien, det vil sige at bruge cookien som en relæstation. Du besøger webserver A, genererer en session og lægger den i cookien, din adgang tildeles webserver B, på dette tidspunkt vurderer webserver B først, om serveren har denne session, hvis ikke, så gå for at se, om der er denne session i klientens cookie, hvis ikke, betyder det, at sessionen virkelig ikke er gemt, hvis der er en i cookien, Synkroniser sessionoinen i cookien til webserver B, så sessionen kan synkroniseres.
Bemærk: Denne metode er enkel og bekvem at implementere og vil ikke øge belastningen på databasen, men hvis klienten deaktiverer cookies, kan sessionen ikke synkroniseres, hvilket vil medføre tab for hjemmesiden; Cookies er ikke særligt sikre, og selvom de er krypteret, kan de stadig forfalskes.
3. Brug memcache til at synkronisere sessioner
Memcache kan distribueres, og uden denne funktion kan den ikke bruges til sessionssynkronisering. Han kan kombinere hukommelsen i webserveren til at blive en "mempool", uanset hvilken server der genererer sessoin, kan det lægges i denne "mempool", og alt andet kan bruges.
Fordele: Synkronisering af sessioner på denne måde øger ikke belastningen på databasen, og sikkerheden er væsentligt forbedret sammenlignet med brugen af cookies, og at lægge sessioner i hukommelsen er meget hurtigere end at læse fra filer.
Ulemper: Memcache opdeler hukommelsen i mange specifikationer af lagringsblokke, der findes blokke og størrelser, og på denne måde afgøres det også, Memcache kan ikke udnytte hukommelsen fuldt ud, vil forårsage hukommelsesfragmentering, hvis lagringsblokken er utilstrækkelig, vil det også skabe hukommelsesoverløb.
For det fjerde, resumé
Alle tre ovenstående metoder er mulige
Den første metode, den der påvirker systemets hastighed mest, anbefales ikke;
Den anden metode giver gode resultater, men sikkerhedsrisiciene er de samme;
Den tredje metode, jeg synes personligt, den tredje metode er den bedste, jeg anbefaler alle at bruge den;
|
Opslået på 14/05/2015 00.16.44
|
|
|
