1. Wat is load balancing
Een nieuwe website zou niet in load balanced moeten zijn, omdat het verkeersvolume niet groot is, dus er is geen noodzaak om deze dingen te doen. Echter, met de snelle groei van websiteverkeer en verkeer wordt een enkele server beperkt door zijn eigen hardwareomstandigheden, en is het moeilijk om zo'n groot aantal bezoeken te weerstaan. In dit geval zijn er twee opties om uit te kiezen:
1. De hardware van één server bijwerken, van dual-core naar quad-core, het geheugen vergroten, enzovoort.
2. Het aantal servers vergroten om de last van servers te delen. Het doel bereiken van het vergroten van de netwerkbandbreedte en het verhogen van de verwerkingskracht van de server.
De eerste methode kan worden begrepen als verticale ontwikkeling, die altijd beperkt is. De tweede methode is de juiste keuze om het probleem op te lossen
De methoden van load balancing kunnen in twee richtingen worden onderverdeeld: de ene is het gebruik van software om load balancing te bereiken, en de andere is het implementeren van hardware load balancing (inclusief het combineren van hardware en software)
Gebruik software om load balancing te bereiken, en het proces van load balancing verbruikt ook enkele systeembronnen en verhoogt de responstijd. Bijvoorbeeld, LVS, nginx, haproxy, apache, enzovoort, deze applicatiegebaseerde load balancing-software zijn geschikt voor websites die niet een bijzonder groot aantal bezoeken hebben. Als je een website hebt met veel bezoeken zoals Sina en 163, is het gebruik van hardware voor load balancing de meest voor de hand liggende keuze.
Er zijn veel load balancing-algoritmen, waaronder load balancing gebaseerd op het aantal verzoeken, root IP-adressen en verkeersgebaseerde algoritmen. Er zijn twee algoritmen die ik vaak gebruik.
Eén is gebaseerd op het aantal verzoeken
A, het kan beseffen dat elke server het verzoek van de klant gelijkmatig kan delen, en als een van de servers uitvalt, zal dat geen slechte impact hebben.
b. De toestand tussen servers moet gesynchroniseerd zijn, zoals sessie, en andere middelen zijn nodig om deze toestanden te synchroniseren.
Eén daarvan is volgens IP
A, ip_hash algoritme kan een IP aan een server koppelen, wat het probleem van sessiesynchronisatie oplost
b. Het slechte aan ip_hash is dat als een van de servers uitvalt, de gebruikers die aan deze server zijn gekoppeld worden gedeprimeerd.
c, ip_hash gemakkelijk kan leiden tot een onevenwichtige belasting, filtert de rivierkrabregering nu Google's zoekwoorden; je zult vaak merken dat Google niet kan openen, maar na een tijdje komt het wel goed. Dit maakte die Google-enthousiastelingen depressief, en veel gebruikers gingen naar het buitenland om agenten te vinden. Als dit gebeurt, worden deze proxies aan dezelfde server toegewezen, wat leidt tot een onevenwichtige belasting en zelfs uitval.
Ten tweede, wat is sessie houden en wat is de functie ervan
Sessie hold verwijst naar een mechanisme op de load balancer dat ervoor zorgt dat toegangsverzoeken die aan dezelfde gebruiker gekoppeld zijn, worden verdeeld naar dezelfde server tijdens load balancing.
Wat doet sessie hold, geef een voorbeeld?
Als een gebruikersverzoek wordt toegewezen aan server A, en hij logt in op server A, en deze gebruiker binnen korte tijd een nieuw verzoek stuurt, als er geen sessie-holdfunctie is, wordt het verzoek van deze gebruiker waarschijnlijk toegewezen aan server B, op dat moment is er geen login op server B, dus je moet opnieuw inloggen, maar de gebruiker weet niet waar zijn verzoek is toegewezen, de gebruiker heeft het gevoel dat hij ingelogd is, waarom moet hij dan weer inloggen, de gebruikerservaring is erg slecht.
En als je iets koopt op Taobao, van login = "Shoot something=" add address = "to pay", is dit een reeks processen die ook als een operatieproces kunnen worden begrepen; al deze reeks operatieprocessen moet door één server worden voltooid en kan niet door de load balancer aan verschillende servers worden toegewezen.
Sessie hold heeft een tijdslimiet (behalve voor servers die aan een vaste limiet zijn gekoppeld, zoals ip_hash), en verschillende load balancing-tools bieden deze sessie-wachttijdinstelling, LVS, Apache, enzovoort. Zelfs de PHP-taal biedt een session.gc_maxlifetime om de wachttijd van de sessie in te stellen.
De wachttijd voor sessies moet hoger worden ingesteld dan de overlevingstijd van de sessie, wat de noodzaak om sessies te synchroniseren kan verminderen, maar het kan niet worden geëlimineerd. Dus het synchroniseren van sessies moet nog gebeuren.
Ten derde, sessiesynchronisatie
Waarom sessiesynchronisatie, het is genoemd bij het bewaken van sessies. Voor meer informatie, zie Drie methoden van sessiesynchronisatie in een webcluster
Er zijn drie methoden voor sessiesynchronisatie in een webcluster
Na het maken van een webcluster zul je zeker eerst sessiesynchronisatie overwegen, want na load balancing wordt dezelfde IP-toegang tot dezelfde pagina aan verschillende servers toegewezen. Dit artikel geeft drie verschillende manieren om dit probleem op te lossen volgens deze situatie:
Gebruik eerst de database om de sessie te synchroniseren
Ik gebruikte deze methode niet bij multi-server sessiesynchronisatie, maar als ik deze methode moest gebruiken, bedacht ik twee methoden:
1. Gebruik een low-end computer om een database te bouwen om de sessie van de webserver op te slaan, of bouw deze speciale database op de bestandsserver; wanneer de gebruiker toegang krijgt tot de webserver, zal hij naar deze speciale database gaan om de sessiesituatie te controleren en zo het doel van sessiesynchronisatie te bereiken.
2. Deze methode is om de tabel waarin de sessie is opgeslagen samen met andere databasetabellen te plaatsen; als MySQL ook geclusterd is, moet elke mysql-knoop deze tabel hebben, en de datatabel van deze sessietabel moet in realtime gesynchroniseerd zijn.
Uitleg: Het gebruik van de database om sessies te synchroniseren zal de last op de database vergroten, die van nature gevoelig is voor knelpunten. De eerste van bovenstaande twee methoden is beter, omdat deze de tabel waarin de sessie onafhankelijk wordt geplaatst wordt gescheiden en zo de last op de echte database vermindert
2. Gebruik cookies om sessies te synchroniseren
Session is de bestandssituatie die aan de serverzijde wordt opgeslagen, en cookie is de bestandssituatie op de client, hoe bereik je dan synchronisatie? De methode is heel eenvoudig, dat wil zeggen, de sessie die door de bezoekpagina van de gebruiker wordt gegenereerd in de cookie te plaatsen, dat wil zeggen om de cookie als relaisstation te gebruiken. Je bezoekt webserver A, genereert een sessie en stopt die in de cookie, je toegang wordt toegewezen aan webserver B, op dat moment beoordeelt webserver B eerst of de server deze sessie heeft, zo niet, ga dan kijken of er een sessie in de cookie van de client zit, zo niet, betekent dat dat de sessie echt niet is opgeslagen, als die er wel in de cookie zit, Synchroniseer de sessoin in de cookie met webserver B, zodat de sessie gesynchroniseerd kan worden.
Opmerking: Deze methode is eenvoudig en handig te implementeren, en zal de last voor de database niet vergroten, maar als de client cookies uitschakelt, kan de sessie niet worden gesynchroniseerd, wat schade voor de website zal veroorzaken; Cookies zijn niet zeer veilig, en hoewel ze versleuteld zijn, kunnen ze nog steeds worden vervalst.
3. Gebruik memcache om sessies te synchroniseren
Memcache kan worden gedistribueerd, en zonder deze functie kan het niet worden gebruikt voor sessiesynchronisatie. Hij kan het geheugen van de webserver combineren tot een "mempool", ongeacht welke server sessoin genereert, het kan in deze "mempool" worden geplaatst, en alles wat verder kan worden gebruikt.
Voordelen: het synchroniseren van sessies op deze manier verhoogt de belasting voor de database niet, de beveiliging is aanzienlijk verbeterd ten opzichte van het gebruik van cookies, en het opzetten van sessies in het geheugen gaat veel sneller dan lezen uit bestanden.
Nadelen: memcache verdeelt het geheugen in veel specificaties van opslagblokken, er zijn blokken en groottes, op deze manier bepaalt ook dat memcache het geheugen niet volledig kan benutten, geheugenfragmentatie veroorzaakt, en als het opslagblok onvoldoende is, veroorzaakt het ook geheugenoverloop.
Ten vierde, samenvatting
Alle drie bovenstaande methoden zijn haalbaar
De eerste methode, die de snelheid van het systeem het meest beïnvloedt, wordt niet aanbevolen;
De tweede methode levert goede resultaten op, maar de veiligheidsrisico's zijn hetzelfde;
De derde methode, ik denk persoonlijk dat de derde methode de beste is, ik raad iedereen aan om die te gebruiken;
|
Geplaatst op 14-05-2015 00:16:44
|
|
|
