1. Какво е балансиране на натоварването
Нов уебсайт не трябва да бъде балансиран с натоварване, защото трафикът не е голям и няма нужда да се занимавате с тези неща. Въпреки това, с бързия растеж на трафика и трафика на уебсайта, един сървър е ограничен от собствените си хардуерни условия и е трудно да издържи на толкова голям брой посещения. В този случай има две опции за избор:
1. Актуализиране на хардуера на един сървър, от двуядрен към четириядрен, увеличаване на паметта и др.
2. Увеличете броя на сървърите, за да се сподели тежестта на сървърите. Да се постигне целта за увеличаване на мрежовата пропускателна способност и увеличаване на изчислителната мощ на сървъра.
Първият метод може да се разбере като вертикално развитие, което винаги е ограничено. Вторият метод е правилният избор за решаване на проблема
Методите за балансиране на натоварването могат да се разделят на две посоки: едната е използването на софтуер за постигане на балансиране на натоварването, а другата е реализиране на хардуерно балансиране на натоварването (включително комбиниране на хардуер и софтуер)
Използвайте софтуер за постигане на балансиране на натоварването, а процесът на постигане на балансиране на натоварването също изразходва част от системните ресурси и увеличава времето за отговор. Например, LVS, nginx, haproxy, apache и др., тези софтуери за балансиране на натоварването, базирани на приложения, са подходящи за уебсайтове, които нямат особено голям брой посещения. Ако имате уебсайт с голям брой посещения като sina и 163, използването на хардуер за реализиране на балансиране на натоварването е най-очевидният избор.
Съществуват много алгоритми за балансиране на натоварването, включително балансиране на натоварването, базирано на броя заявки, root IP адреси и алгоритми, базирани на трафик. Има два алгоритъма, които често използвам.
Единият се базира на броя заявки
А, може да осъзнае, че всеки сървър може да споделя заявката на клиента равномерно и ако някой от сървърите спре, това няма да има лошо въздействие.
b. Състоянието между сървърите трябва да бъде синхронизирано, като сесия, и са необходими други средства за синхронизация на тези състояния.
Единият е според IP
А, ip_hash алгоритъм може да съпоставя IP към сървър, което решава проблема със синхронизацията на сесиите
b. Лошото при ip_hash е, че ако някой от сървърите спре, потребителите, свързани с този сървър, ще бъдат депресирани.
c, ip_hash лесно може да доведе до небалансирано натоварване, сега правителството на речните раци филтрира ключовите думи за търсене на Google, често ще откриете, че Google не може да отвори, но след време всичко ще се оправи. Това депресира ентусиастите на Google и много потребители отидоха в чужбина, за да намерят агенти. Ако това се случи, тези проксита ще бъдат назначени на един и същ сървър, което води до небалансирано натоварване и дори провали.
Второ, какво представлява сесията и каква е неговата функция
Сесийното задържане се отнася до механизъм на балансьора на натоварването, който гарантира, че заявките за достъп, свързани с един и същ потребител, се разпределят до същия сървър при извършване на балансиране на натоварването.
Какво прави session hold, дайте пример
Ако заявка за достъп на потребител е назначена на сървър А и се впише в сървър А, и за кратък период този потребител изпрати нова заявка, ако няма функция за задържане на сесията, заявката на този потребител вероятно ще бъде назначена на сървър Б, в момента няма вход на сървър Б, така че трябва да влезете отново, но потребителят не знае къде е назначена заявката му, усещането е, че е влязъл, защо трябва да влиза отново, потребителското изживяване е много лошо.
Ако купиш нещо в Taobao, от login = "Shoot something=" add address = "to pay", това е серия от процеси, които могат да се разбират и като оперативен процес, всички тези операции трябва да се изпълняват от един сървър и не могат да бъдат назначени на различни сървъри от load balancer.
Session hold има времево ограничение (с изключение на сървъри, които са свързани с фиксиран, като ip_hash), а различни инструменти за балансиране на натоварването предоставят настройка на времето за задържане на сесията, LVS, apache и др. Дори езикът PHP предоставя session.gc_maxlifetime за задаване на времето за задържане на сесията
Времето за задържане на сесията трябва да се задава повече от времето за оцеляване в сесията, което може да намали нуждата от синхронизиране на сесиите, но не може да бъде елиминирано. Така че сесиите за синхронизация все още трябва да се правят.
Трето, синхронизация на сесиите
Защо синхронизация на сесиите? Това беше споменато, когато се говори за запазване на сесиите. За повече информация вижте Три метода за синхронизация на сесии в уеб клъстер
В уеб клъстер има три метода за синхронизация на сесии
След като направите уеб клъстер, определено първо ще обмислите синхронизацията на сесиите, защото след балансиране на натоварването един и същ IP достъп до една и съща страница ще бъде назначен на различни сървъри. Тази статия дава три различни начина за решаване на този проблем според тази ситуация:
Първо, използвайте базата данни, за да синхронизирате сесията
Не използвах този метод при синхронизация на сесии между няколко сървъра, но ако трябваше да го използвам, се сетих за два метода:
1. Използвайте нискокачествен компютър за изграждане на база данни за съхранение на сесията на уеб сървъра или изграждане на тази специална база данни на файловия сървър; когато потребителят достъпи уеб сървъра, той ще отиде в тази специална база данни, за да провери ситуацията на сесиите и да постигне целта на синхронизация на сесиите.
2. Този метод е да се постави таблицата, в която се съхранява сесията, заедно с други таблици от базата данни, ако mysql също е клъстериран, всеки MySQL възел трябва да има тази таблица, а таблицата с данни на тази сесийна таблица трябва да се синхронизира в реално време.
Обяснение: Използването на базата данни за синхронизиране на сесиите ще увеличи натоварването върху базата данни, която по природа е склонна към тесни места. Първият от горните два метода е по-добър, който отделя масата, в която сесията е поставена независимо, намалявайки натоварването върху реалната база данни
2. Използвайте бисквитки за синхронизиране на сесиите
Session е файловата ситуация, съхранявана на сървърната страна, а cookie е ситуацията на файла на клиента, как да се постигне синхронизация? Методът е много прост – да се постави сесията, генерирана от страницата за посещение на потребителя, в бисквитката, тоест да се използва бисквитката като ретранслируема станция. Посещавате уеб сървър А, генерирате сесия и я поставяте в бисквитката, достъпът ви се присвоява на уеб сървър B, в този момент уеб сървър B първо преценява дали сървърът има тази сесия, ако не, отидете да проверите дали има тази сесия в бисквитката на клиента, ако не, това означава, че сесията всъщност не е запазена, ако има такава в бисквитката, Синхронизирайте сесоина в бисквитката с уеб сървър B, за да може сесията да бъде синхронизирана.
Забележка: Този метод е прост и удобен за реализиране и няма да увеличи натоварването върху базата данни, но ако клиентът изключи бисквитките, сесията не може да бъде синхронизирана, което ще доведе до загуби за уебсайта; Бисквитките не са силно защитени и въпреки че са криптирани, все пак могат да бъдат фалшифицирани.
3. Използвайте memcache за синхронизиране на сесиите
Memcache може да се разпространява и без тази функция не може да се използва за синхронизация на сесиите. Той може да комбинира паметта в уеб сървъра, за да стане "mempool", независимо кой сървър генерира сесоин, може да се постави в този "mempool", а всичко останало може да се използва.
Предимства: синхронизирането на сесиите по този начин не увеличава натоварването върху базата данни, а сигурността е значително подобрена в сравнение с използването на бисквитки, а поставянето на сесии в паметта е много по-бързо от четенето от файлове.
Недостатъци: memcache разделя паметта на много спецификации на блокове за съхранение, има блокове и размери, този начин също определя, че memcache не може напълно да използва паметта, ще доведе до фрагментация на паметта, ако блокът за съхранение е недостатъчен, ще доведе и до препълване на паметта.
Четвърто, обобщение
И трите горепосочени метода са възможни
Първият метод, този, който най-силно влияе на скоростта на системата, не се препоръчва;
Вторият метод дава добри резултати, но опасностите за безопасността са същите;
Третият метод, лично аз мисля, че третият е най-добрият, препоръчвам на всички да го използват;
|
Публикувано в 14.05.2015 г. 0:16:44 ч.
|
|
|
