1. Що таке балансування навантаження
Новий вебсайт не повинен мати балансування навантаження, оскільки обсяг трафіку невеликий, тому немає потреби займатися цими справами. Однак із швидким зростанням трафіку та трафіку на сайті один сервер обмежений власними апаратними умовами, і важко витримати таку велику кількість відвідувань. У цьому випадку є два варіанти на вибір:
1. Оновити апаратне забезпечення одного сервера — з двоядерного на чотириядерний, збільшити пам'ять тощо.
2. Збільшити кількість серверів, щоб розподілити навантаження серверів. Досягти мети збільшення пропускної здатності мережі та збільшення обчислювальної потужності сервера.
Перший метод можна розуміти як вертикальний розвиток, який завжди обмежений. Другий метод — це правильний вибір для розв'язання задачі
Методи балансування навантаження можна поділити на два напрямки: один — використання програмного забезпечення для досягнення балансування навантаження, інший — реалізація апаратного балансування навантаження (включаючи поєднання апаратного та програмного забезпечення)
Використовуйте програмне забезпечення для досягнення балансування навантаження, і процес балансування навантаження також споживає частину системних ресурсів і збільшує час відгуку. Наприклад, LVS, nginx, haproxy, apache тощо, ці додаткові програми для балансування навантаження підходять для сайтів із невеликою кількістю відвідувань. Якщо у вас є сайт із великою кількістю відвідувань, як Sina і 163, використання апаратного забезпечення для балансування навантаження — найочевидніший вибір.
Існує багато алгоритмів балансування навантаження, зокрема балансування навантаження на основі кількості запитів, кореневих IP-адрес та алгоритмів на основі трафіку. Є два алгоритми, які я часто використовую.
Одна з них базується на кількості запитів
A, він може усвідомити, що кожен сервер може рівномірно ділитися запитами клієнта, і якщо один із серверів вийде з ладу, це не спричинить негативних наслідків.
b. Стан між серверами має бути синхронізований, наприклад, сесія, а також потрібні інші засоби для синхронізації цих станів.
Одна з них — за інтелектуальною власністю
A, ip_hash алгоритм може відображати IP на сервер, що може вирішити проблему синхронізації сесій
b. Мінус у ip_hash в тому, що якщо один із серверів виходить з ладу, користувачі, підключені до нього, будуть пригнічені.
c, ip_hash легко може призвести до незбалансованого навантаження, тепер, коли уряд річкових крабів фільтрує ключові слова пошуку Google, часто можна виявити, що Google не може відкритися, але з часом все буде гаразд. Це пригнічувало ентузіастів Google, і багато користувачів поїхали за кордон шукати агентів. Якщо це станеться, ці проксі будуть призначені на той самий сервер, що призведе до незбалансованого навантаження і навіть збоїв.
По-друге, що таке утримання сесії та яка його функція
Утримання сесії — це механізм на балансуванні навантаження, який гарантує, що запити на доступ, пов'язані з тим самим користувачем, розподіляються на один сервер під час балансування навантаження.
Що робить сесійне утримання, наведіть приклад
Якщо запит на доступ користувача призначений серверу A і він входить на сервер A, і за короткий час цей користувач надсилає ще один запит, якщо функції утримання сесії немає, ймовірно, цей запит буде призначений серверу B, наразі на сервері B немає входу, тому потрібно увійти знову, але користувач не знає, де призначений його запит, він вважає, що він увійшов, навіщо йому знову входити, досвід дуже поганий.
І якщо ви купуєте щось на Taobao, з login = "Shoot something=" add address = "to pay", це серія процесів, яку також можна розуміти як операційний процес, усі ці серії операційних процесів мають виконувати один сервер і не можуть бути призначені на різні сервери за допомогою балансувальника навантаження.
Утримання сесії має обмеження за часом (за винятком серверів, які відкладені на фіксований, наприклад ip_hash), і різні інструменти балансування навантаження забезпечують встановлення часу утримання сесії, LVS, Apache тощо. Навіть мова PHP надає session.gc_maxlifetime для встановлення часу утримання сесії
Час утримання сесії слід встановлювати більше, ніж час виживання сесії, що може зменшити потребу в синхронізації сесій, але його не можна усунути. Отже, синхронізація сесій ще треба робити.
По-третє, синхронізація сесій
Чому саме синхронізація сесій — це вже згадували, коли йдеться про ведення сесій. Для детальнішої інформації див. розділ «Три методи синхронізації сесій у веб-кластері»
Існує три методи синхронізації сесій у веб-кластері
Після проходження веб-кластера ви обов'язково розглянете синхронізацію сесій першими, бо після балансування навантаження однаковий IP-доступ до однієї й тієї ж сторінки буде призначений різним серверам. Отже, у цій статті наведено три різні способи розв'язання цієї проблеми відповідно до цієї ситуації:
По-перше, використовуйте базу даних для синхронізації сесії
Я не використовував цей метод при синхронізації сесій між кількома серверами, але якщо доводилося застосовувати цей метод, я придумав два способи:
1. Використовуйте комп'ютер низького рівня для створення бази даних для зберігання сесії веб-сервера, або створіть цю спеціальну базу даних на файловому сервері; коли користувач звертається до веб-сервера, він звернеться до цієї спеціальної бази даних, щоб перевірити ситуацію сесії з метою синхронізації сесії.
2. Цей метод полягає в тому, щоб помістити таблицю, де зберігається сесія, разом з іншими таблицями бази даних, якщо mysql також кластеризований, кожен вузол mysql повинен мати цю таблицю, а таблиця даних цієї сесійної таблиці має бути синхронізована в реальному часі.
Пояснення: Використання бази даних для синхронізації сесій збільшує навантаження на базу, яка за своєю суттю схильна до вузьких місць. Перший із двох вищезазначених методів є кращим, оскільки він розділяє таблицю, де сесія розміщується незалежно, зменшуючи навантаження на реальну базу даних
2. Використовуйте файли cookie для синхронізації сесій
Session — це файлова ситуація, що зберігається на стороні сервера, а cookie — це ситуація з файлом на клієнті. Як досягти синхронізації? Метод дуже простий: вмістити сесію, згенеровану сторінкою відвідування користувача, у файл cookie, тобто використовувати файл cookie як ретрансляційну станцію. Ви відвідуєте веб-сервер A, генеруєте сесію і додаєте її в cookie, ваш доступ призначається веб-серверу B, на цьому етапі веб-сервер B спочатку оцінює, чи має сервер цю сесію, якщо ні — перевіряєте, чи є ця сесія в cookie клієнта; якщо ні — це означає, що сесія фактично не збережена, якщо вона є в cookie, Синхронізуйте сессоїн у cookie з веб-сервером B, щоб можна було синхронізувати сесію.
Примітка: цей метод простий і зручний у реалізації і не збільшить навантаження на базу даних, але якщо клієнт вимикає cookie, сесію не можна синхронізувати, що призведе до втрат для сайту; Файли cookie не є надто захищеними, і хоча вони були зашифровані, їх все одно можна підробити.
3. Використовуйте memcache для синхронізації сесій
Memcache можна розподіляти, і без цієї функції він не може використовуватися для синхронізації сесій. Він може об'єднати пам'ять у веб-сервері, щоб зробити «мемпул», незалежно від того, який сервер генерує сессоїн, його можна помістити в цей «мемпул», і все інше можна використовувати.
Переваги: синхронізація сесій таким чином не збільшує навантаження на базу даних, безпека значно покращується порівняно з використанням cookie, а перенесення сесій у пам'ять відбувається значно швидше, ніж читання з файлів.
Недоліки: memcache ділить пам'ять на багато специфікацій блоків зберігання, існують блоки та розміри, цей спосіб також визначає, що memcache не може повністю використовувати пам'ять, спричиняє фрагментацію пам'яті, якщо блок зберігання недостатній, це також призводить до переповнення пам'яті.
По-четверте, короткий виклад
Усі три вищезазначені методи є здійсненними
Перший метод, який найбільше впливає на швидкість системи, не рекомендується;
Другий метод дає хороші результати, але небезпеки залишаються тими ж;
Третій метод, особисто я вважаю, що третій — найкращий, рекомендую всім його використовувати;
|
Опубліковано 14.05.2015 00:16:44
|
|
|
