1. Hva er lastbalansering
Et nytt nettsted bør ikke være lastbalansert, fordi trafikkvolumet ikke er stort, så det er ikke nødvendig å engasjere seg i disse tingene. Men med den raske veksten i nettsidetrafikk og trafikk, er en enkelt server begrenset av sine egne maskinvareforhold, og det er vanskelig å tåle et så stort antall besøk. I dette tilfellet finnes det to alternativer å velge mellom:
1. Oppdater maskinvaren på en enkelt server, fra dual-core til quad-core, øker minnet, osv.
2. Øke antallet servere for å dele servernes byrde. For å oppnå formålet å øke nettverksbåndbredden og øke serverens prosesseringskraft.
Den første metoden kan forstås som vertikal utvikling, som alltid er begrenset. Den andre metoden er det riktige valget for å løse problemet
Metodene for lastbalansering kan deles inn i to retninger: den ene er å bruke programvare for å oppnå lastbalansering, og den andre er å implementere maskinvarelastbalansering (inkludert å kombinere maskinvare og programvare)
Bruk programvare for å oppnå lastbalansering, og prosessen med å oppnå lastbalansering bruker også noen systemressurser og øker responstiden. For eksempel LVS, nginx, haproxy, apache osv., disse applikasjonsbaserte lastbalanseringsprogrammene er egnet for nettsteder som ikke har et spesielt stort antall besøk. Hvis du har et nettsted med mange besøk som sina og 163, er det mest åpenbare valget å bruke maskinvare for å implementere lastfordeling.
Det finnes mange lastbalanseringsalgoritmer, inkludert lastbalansering basert på antall forespørsler, rot-IP-adresser og trafikkbaserte algoritmer. Det er to algoritmer jeg ofte bruker.
Den ene er basert på antall forespørsler
A, den kan innse at hver server kan dele kundens forespørsel jevnt, og hvis en av serverne går ned, vil det ikke ha en negativ effekt.
b. Tilstanden mellom serverne må synkroniseres, som for eksempel sesjon, og andre metoder er nødvendige for å synkronisere disse tilstandene.
Den ene er ifølge IP
A, ip_hash algoritme kan mappe en IP til en server, noe som kan løse problemet med sesjonssynkronisering
B. Det negative med ip_hash er at hvis en av serverne går ned, vil brukerne som er tilknyttet denne serveren bli deprimerte.
c, ip_hash lett kan føre til ubalansert belastning, nå som elvekrabbemyndighetene filtrerer Googles søkeord, vil du ofte oppdage at Google ikke kan åpne, men det går fint etter en stund. Dette gjorde Google-entusiastene deprimerte, og mange brukere dro utenlands for å finne agenter. Hvis dette skjer, vil disse proxyene bli tildelt samme server, noe som fører til ubalansert belastning og til og med feil.
For det andre, hva er sesjonsavholdelse og hva er dens funksjon
Sesjonshold refererer til en mekanisme på lastbalansereren som sikrer at tilgangsforespørsler knyttet til samme bruker distribueres til samme server under lastbalansering.
Hva gjør session hold, gi et eksempel
Hvis en brukerforespørsel er tildelt server A, og logger inn på server A, og i løpet av kort tid sender denne brukeren en ny forespørsel, hvis det ikke finnes noen session hold-funksjon, vil brukerens forespørsel sannsynligvis bli tildelt server B, på dette tidspunktet er det ingen pålogging på server B, så du må logge inn igjen, men brukeren vet ikke hvor forespørselen hans er tildelt, brukeren føler at han er logget inn, hvorfor må han logge inn igjen, brukeropplevelsen er veldig dårlig.
Og hvis du kjøper noe på Taobao, fra login = "Skyt noe=" legg til adresse = "å betale", er dette en serie prosesser som også kan forstås som en operasjonsprosess, alle disse operasjonsprosessene skal fullføres av én server, og kan ikke tildeles forskjellige servere av lastbalansereren.
Sesjonshold har en tidsbegrensning (bortsett fra servere som er mappet til en fast en, som ip_hash), og ulike lastbalanseringsverktøy tilbyr denne innstillingen for sesjonsventetid, LVS, apache, osv. Selv PHP-språket gir en session.gc_maxlifetime for å sette ventetiden for øktene
Ventetiden for øktene bør settes høyere enn overlevelsestiden for økten, noe som kan redusere behovet for å synkronisere økter, men det kan ikke elimineres. Så synkronisering av økter må fortsatt gjøres.
For det tredje, sesjonssynkronisering
Hvorfor sesjonssynkronisering, det har blitt nevnt når man snakker om sesjonsføring. For mer informasjon, se Tre metoder for sesjonssynkronisering i en webklynge
Det finnes tre metoder for sesjonssynkronisering i en webklynge
Etter å ha laget en webklynge, vil du definitivt vurdere sesjonssynkronisering først, fordi etter lastbalansering vil samme IP-tilgang til samme side bli tildelt forskjellige servere. Så denne artikkelen gir tre forskjellige måter å løse dette problemet på i henhold til denne situasjonen:
Først, bruk databasen for å synkronisere sesjonen
Jeg brukte ikke denne metoden da jeg gjorde multi-server sesjonssynkronisering, men hvis jeg måtte bruke denne metoden, tenkte jeg på to metoder:
1. Bruk en lavprestisjedatamaskin for å bygge en database for å lagre sesjonen til webserveren, eller bygg denne spesielle databasen på filserveren; når brukeren får tilgang til webserveren, vil han gå til denne spesielle databasen for å sjekke sesjonssituasjonen for å oppnå formålet med sesjonssynkronisering.
2. Denne metoden er å sette tabellen der sesjonen lagres sammen med andre databasetabeller; hvis mysql også er klynget, må hver mysql-node ha denne tabellen, og datatabellen til denne sesjonstabellen må synkroniseres i sanntid.
Forklaring: Å bruke databasen til å synkronisere økter vil øke belastningen på databasen, som er iboende utsatt for flaskehalser. Den første av de to ovennevnte metodene er bedre, som skiller tabellen der sesjonen plasseres uavhengig, og reduserer byrden på den virkelige databasen
2. Bruk informasjonskapsler for å synkronisere økter
Session er filsituasjonen lagret på serversiden, og cookie er filsituasjonen på klienten, hvordan oppnå synkronisering? Metoden er veldig enkel, det vil si å legge økten som genereres av brukerens besøksside inn i informasjonskapslen, det vil si å bruke informasjonskapselen som en reléstasjon. Du besøker webserver A, genererer en økt og legger den i informasjonskapslen, tilgangen din er tildelt webserver B, på dette tidspunktet vurderer webserver B først om serveren har denne økten, hvis ikke, gå for å se om det finnes denne økten i klientens informasjonskapsel, hvis ikke, betyr det at økten egentlig ikke er lagret, hvis det er en i informasjonskapslen, Synkroniser sessionoinen i informasjonskapselen til webserver B, slik at sesjonen kan synkroniseres.
Merk: Denne metoden er enkel og praktisk å implementere, og vil ikke øke belastningen på databasen, men hvis klienten deaktiverer informasjonskapsler, kan ikke sesjonen synkroniseres, noe som vil medføre tap for nettstedet; Informasjonskapsler er ikke svært sikre, og selv om de er kryptert, kan de fortsatt forfalskes.
3. Bruk memcache for å synkronisere økter
Memcache kan distribueres, og uten denne funksjonen kan den ikke brukes til sesjonssynkronisering. Han kan kombinere minnet i webserveren for å bli en "mempool", uansett hvilken server som genererer sessoin, kan det legges inn i denne "mempoolen", og alt annet kan brukes.
Fordeler: Synkronisering av økter på denne måten øker ikke belastningen på databasen, og sikkerheten er betydelig bedre sammenlignet med bruk av informasjonskapsler, og å legge sesjoner i minnet er mye raskere enn å lese fra filer.
Ulemper: memcache deler minnet inn i mange spesifikasjoner av lagringsblokker, det finnes blokker og størrelser, og på denne måten avgjøres også, memcache kan ikke utnytte minnet fullt ut, vil føre til minnefragmentering, og hvis lagringsblokken er utilstrekkelig, vil det også gi minneoverløp.
For det fjerde, sammendrag
Alle de tre ovennevnte metodene er gjennomførbare
Den første metoden, den som påvirker systemets hastighet mest, anbefales ikke;
Den andre metoden gir gode resultater, men sikkerhetsrisikoene er de samme;
Den tredje metoden, jeg personlig synes den tredje metoden er den beste, jeg anbefaler alle å bruke den;
|
Publisert på 14.05.2015 00:16:44
|
|
|
