Основная идея балансировки нагрузки проста:
Максимально возможная средняя нагрузка в кластере серверов.
Основываясь на этой идее, наша обычная практика заключается в настройке интерфейсного сервера Балансировщик нагрузки . Роль балансировщика нагрузки заключается в маршрутизации запросов на наиболее простаивающие доступные серверы. На рисунке 1 показана настройка балансировки нагрузки для большого веб-сайта. Один отвечает за HTTP-трафик, а другой-за доступ к MySQL.
Балансировка нагрузки имеет пять общих целей:
- Масштабируемость . Балансировка нагрузки полезна для некоторых расширений, таких как чтение данных из режима ожидания при разделении чтения и записи.
- Эффективность . Балансировка нагрузки помогает более эффективно использовать ресурсы, поскольку она может контролировать направление запросов.
- Удобство использования . Гибкие схемы балансировки нагрузки могут значительно повысить доступность услуг.
- Прозрачность . Клиенту не нужно знать, есть ли балансировщик нагрузки или нет, и ему не нужно знать, сколько машин находится за балансировщиком нагрузки. То, что представлено клиенту, является прозрачным сервером.
- Единообразие 。 Если приложение отслеживает состояние (транзакции базы данных, сеансы веб-сайта и т.д.), балансировщик нагрузки может направлять связанные запросы на один и тот же сервер, чтобы предотвратить потерю состояния.
Для реализации балансировки нагрузки, как правило, существует два способа: Прямое подключение и Внедрение промежуточного программного обеспечения .
1 Прямое Подключение
Некоторые люди думают, что балансировка нагрузки-это прямая настройка приложений и серверов MySQL, но на самом деле это не единственный метод балансировки нагрузки. Далее мы обсудим некоторые общие методы использования прямой связи и связанные с этим вопросы, требующие внимания.
1.1 Разделение воспроизведения на Чтение и Запись
Таким образом, вероятно, возникнет одна из самых больших проблем: Грязные данные . Типичный пример-когда пользователь комментирует сообщение в блоге, а затем перезагружает страницу, не видя никаких новых комментариев.
Конечно, мы не должны отказываться от разделения чтения и записи из-за грязных данных. На самом деле, для многих приложений допустимость “грязных” данных может быть относительно высокой, и в настоящее время этот метод можно смело внедрять.
Итак, для приложений с низкой устойчивостью к грязным данным, как отделить чтение от записи? Далее давайте проведем еще одно различие между чтением и письмом. Я верю, что вы всегда можете найти подходящую вам стратегию.
1) Разделение запросов
Если только несколько приложений не могут переносить грязные данные, мы можем назначить все операции чтения и записи, которые не могут переносить грязные данные, ведущему. Другие запросы на чтение распределяются на подчиненных устройствах. Эту стратегию легко реализовать, но если будет меньше терпимости к ошибочным запросам данных, то, скорее всего, резервный режим будет использоваться неэффективно.
2) Разделение Грязных Данных
Это небольшое улучшение стратегии разделения запросов. Необходимо выполнить дополнительную работу, например, проверить приложение на наличие задержек репликации, чтобы определить, являются ли данные резервной копии базы данных актуальными. Многие приложения для отчетов могут использовать эту стратегию: им нужно только скопировать данные, загруженные ночью, в интерфейс ожидания, и им все равно, будут ли они работать в основной библиотеке.
3) Разделение сессий
Эта стратегия идет глубже, чем стратегия разделения грязных данных. Это делается для того, чтобы определить, изменил ли пользователь данные, пользователю не нужно просматривать последние данные других пользователей, просто нужно видеть их собственные обновления.
В частности, бит тега может быть установлен на уровне сеанса, чтобы указать, обновился пользователь или нет. Как только пользователь обновится, он на некоторое время направит запрос пользователя в основную библиотеку.
Эта стратегия представляет собой хороший компромисс между простотой и эффективностью и является рекомендуемой стратегией.
Конечно, если у вас достаточно идей, вы можете объединить стратегию разделения на основе сеанса со стратегией мониторинга задержки репликации. Если пользователь обновил данные 10 секунд назад, а весь режим ожидания задерживается в течение 5 секунд, он может смело считывать данные из режима ожидания. Важно не забывать выбирать одну и ту же резервную копию для всего сеанса, иначе, если задержка нескольких резервных копий будет несогласованной, это вызовет проблемы у пользователей.
4) Разделение Глобальной Версии/Сеанса
Записав координаты журнала основной библиотеки и сравнив координаты реплицированного режима ожидания, мы можем подтвердить, обновляет ли режим ожидания данные. Когда приложение указывает на операцию записи, после совершения транзакции оно выполняет операцию ОТОБРАЖЕНИЯ ОСНОВНОГО СОСТОЯНИЯ, а затем сохраняет координаты журнала основной библиотеки в кэше в качестве номера версии измененного объекта или сеанса. Когда приложение подключено к режиму ожидания, выполняется ОТОБРАЖЕНИЕ СТАТУСА ВЕДОМОГО устройства, и координаты в режиме ожидания сравниваются с номерами версий в кэше. Если резервный режим обновлен по сравнению с основной точкой записи, это указывает на то, что резервный режим обновил соответствующие данные и может быть безопасно использован.
Фактически, многие стратегии разделения чтения и записи требуют Отслеживать задержку репликации Для определения распределения запросов на чтение. Однако следует отметить, что значение столбца Seconds_behind_master, полученное при отображении СТАТУСА ВЕДОМОГО устройства, не точно отражает задержку. Мы можем использовать инструмент pt-heartbeat в наборе инструментов Percona для лучшего мониторинга задержки.
1.2 Изменение DNS-имени
Для некоторых относительно простых приложений DNS может быть создан для различных целей. Самый простой способ-иметь DNS-имя (читай. MySQL – db. com) для сервера, доступного только для чтения, и другого DNS-имени (запись. MySQL – db. com) для сервера, ответственного за операцию записи. Если резервная копия может поддерживать основную библиотеку, укажите DNS-имя, доступное только для чтения, на библиотеку резервной копии, в противном случае укажите на основную библиотеку.
Эту стратегию очень легко реализовать, но есть большая проблема: отсутствует полный контроль над DNS.
- Изменение DNS не является немедленным или атомарным. Требуется много времени, чтобы передать изменения DNS во всю сеть или распространить их между сетями.
- Данные DNS кэшируются везде, и время их истечения рекомендуется, а не обязательно.
- Для полной эффективности измененного DNS может потребоваться перезагрузка приложения или сервера.
Эта стратегия опасна, даже если вы можете избежать проблемы, которую DNS не может полностью контролировать, изменив файл/etc/hosts, у нее все равно есть идеальная стратегия.
1.3 Передача IP-адреса
Балансировка нагрузки достигается за счет передачи виртуальных адресов между серверами. Похоже ли это на изменение DNS? Но на самом деле все совершенно по-другому. Передача IP-адресов позволяет DNS – именам оставаться неизменными. Мы можем заставить IP-адреса быстро и атомарно меняться с помощью команд ARP (см. Здесь).
Удобным способом является назначение фиксированного IP-адреса каждому физическому серверу. IP – адрес фиксирован на сервере и не изменится. Затем вы можете использовать виртуальный IP-адрес для каждой логической “службы” (которую можно понимать как контейнер).
Таким образом, IP-адрес можно легко передавать между серверами, не перенастраивая приложение, и его проще реализовать.
2. Внедрение Промежуточного программного обеспечения
Описанные выше стратегии предполагают, что приложения подключены к серверам MySQL, но многие балансировщики нагрузки используют промежуточное программное обеспечение в качестве прокси-сервера для сетевых коммуникаций. Он принимает все сообщения, отправляя результаты выполнения обратно на запрашивающую машину на назначенном сервере, где распределяются запросы. На рисунке 2 показана эта архитектура.
2.1 Балансировщик Нагрузки
Существует множество аппаратных и программных средств для балансировки нагрузки, но лишь немногие из них специально разработаны для серверов MySQL. Веб-серверам обычно больше требуется балансировка нагрузки, поэтому многие многоцелевые устройства балансировки нагрузки поддерживают HTTP, в то время как для других целей существует всего несколько основных функций.
Соединения MySQL-это обычные соединения TCP/IP, поэтому вы можете использовать универсальный балансировщик нагрузки на MySQL. Однако из-за отсутствия собственных функций MySQL будет больше ограничений:
- Запросы на распространение могут не обеспечить хорошую балансировку нагрузки.
- Существует недостаточная поддержка сеансов MySQL, и вы можете не знать, как “исправить” все запросы на подключение, отправленные из одного сеанса HTTP на сервер MySQL.
- Пулы соединений и длинные соединения могут препятствовать распределению запросов на подключение балансировщиками нагрузки.
- Вы не можете выполнить проверку работоспособности и загрузки на серверах MySQL.
2.2 Алгоритмы Балансировки Нагрузки
Существует множество алгоритмов для принятия решения о том, какой сервер примет следующее соединение. У каждого производителя свои алгоритмы. Существуют следующие распространенные методы:
- Случайное распределение . Случайный выбор сервера из доступного пула серверов для обработки запросов.
- опрос . Отправка запросов на серверы в циклическом порядке, например, A, B, C, A, B, C.
- Хэш . Хэшируйте соединение через исходный IP-адрес и сопоставьте его с тем же сервером в пуле.
- Самый быстрый ответ . Назначьте подключения серверам, которые обрабатывают запросы быстрее всего.
- Минимальное количество подключений . Выделите подключения для серверов с наименее активными подключениями.
- вес . В зависимости от производительности машины и других условий различным машинам присваивается разный вес, чтобы высокопроизводительные машины могли обрабатывать больше соединений.
Вышеперечисленные методы не являются лучшими, только наиболее подходящими, в зависимости от конкретной рабочей нагрузки.
Кроме того, мы описываем только алгоритм обработки в реальном времени. Но иногда алгоритмы организации очередей могут быть более эффективными. Например, алгоритм может поддерживать только заданное количество одновременных серверов баз данных, позволяя одновременно выполнять не более N активных транзакций. Если активных транзакций слишком много, поместите новые запросы в очередь и дайте возможность обработать список доступных серверов.
2.3 Балансировка нагрузки между основным и несколькими режимами ожидания
Наиболее распространенной структурой репликации является Одна основная библиотека плюс несколько резервных библиотек . Эта архитектура обладает плохой масштабируемостью, но мы можем добиться лучших результатов, комбинируя некоторые методы с балансировкой нагрузки.
- Функциональный раздел . Для функций производителя, включая отчет, анализ, хранилище данных и полнотекстовый индекс, настройте одну или группу библиотек резервных копий для расширения возможностей одной функции.
- Гарантируйте, что запас соответствует основному запасу . Проблема с резервным копированием-это грязные данные. Для этой цели мы можем использовать функцию MASTER_POS_WAIT (), чтобы заблокировать работу основной библиотеки до тех пор, пока режим ожидания не достигнет заданной точки синхронизации основной библиотеки. Кроме того, мы можем использовать повторяющиеся сердцебиения для проверки задержек.
Мы не можем и не должны думать о создании архитектуры, подобной архитектуре Али, в начале приложения. Лучший способ-это Достижение того, что явно необходимо, и планирование на будущее для возможного быстрого роста 。
Кроме того, разработайте масштабируемость Цифровые цели Это имеет смысл, так же как мы поставили точную цель для производительности, чтобы соответствовать параллелизму 10K или 100K. Таким образом, мы можем избежать накладных расходов, таких как сериализация или совместимость, которые привносятся в наше приложение с помощью связанных теорий.
В стратегии расширения MySQL, когда типичные приложения достигают очень больших масштабов, они обычно перемещаются с одного сервера на внешнюю расширенную архитектуру резервного копирования, а затем на фрагментацию данных или разделение по функциям. Здесь следует отметить, что мы не выступаем за такие предложения, как “разделение как можно раньше и разделение как можно дальше”. На самом деле фрагментация сложна и дорогостояща, и, самое главное, многим приложениям она может вообще не понадобиться. Вместо того, чтобы тратить много денег на фрагментацию, лучше посмотреть на изменения в новом оборудовании и новой версии MySQL, которые могут вас удивить.
резюме
- Прямое подключение и повторное разделение, эквалайзер и алгоритм имеют ограничения.
- Количественные показатели масштабируемости.