Какой алгоритм балансировки нагрузки лучше подходит для распределения входящих запросов по группе серверов? Я читал, что это некоторые алгоритмы, такие как Round Robin ... но я хотел бы узнать ваше мнение о том, какой алгоритм лучше или, по крайней мере, наиболее часто используемый алгоритм для этого.
Надеюсь, вы, ребята, можете мне помочь.
Ответ: это зависит от обстоятельств. Наилучшая балансировка нагрузки достигается при рассмотрении множества факторов, специфичных для услуги. Например, предположим, что у вас есть служба, которая предоставляет API для кодирования строки, где кодировка зависит исключительно от содержимого строки. У вас работает N реплик службы.
Один из простых подходов - просто иметь индекс службы выбора клиента i = hash (string) / N. Предполагая, что входная строка равномерно распределена в хэш-пространстве, это будет хорошо работать и очень легко реализовать.
Скажем теперь по какой-то причине, что по какой-то причине строки плохо распределены в хэш-пространстве (например, может быть, много строк может повторяться). В этом случае вы можете использовать простой метод циклического перебора или случайный выбор индекса. Вы также можете измерить обратное давление со стороны серверов: например, если вызов RPC является синхронным, вы можете измерить на стороне клиента, сколько времени он занимает, и, в случае строкового кодирования, разделить это на длину нить; если клиент замечает, что это число увеличивается, это, вероятно, означает, что служба не может поддерживать его, и клиент может уменьшить трафик, который он отправляет такому клиенту. Очевидно, это немного сложнее.
TL; DR: существует множество вариантов балансировки нагрузки, выбор из которых "лучший" зависит от конкретной природы масштабируемой проблемы.
1- Круговая система
2- Взвешенный круговой алгоритм
3- Наименьшее количество подключений
4- Взвешенное наименьшее количество соединений
5- Случайный
пожалуйста, посмотрите этот URL:
https://www.jscape.com/blog/load-balancing-algorithms
Для HTTP-серверов Round Robin, Weight Round Robin и Random являются, вероятно, наиболее часто используемыми и безопасными шаблонами для использования, поскольку они не создают горячих точек, вызванных попытками определить, на какой хост отправлять.
Я понимаю, что можно использовать многоуровневый подход, чтобы равномерно распределить запросы. Здесь у вас есть 2 кластера, которые являются циклическими, и каждый кластер имеет несколько серверов, которые имеют случайное распределение.
Наименьшее количество подключений и самый быстрый ответ основаны на прогнозировании производительности каждого сервера на основе прошлой производительности. Хотя они могут быть полезны для определенных типов нагрузки - скажем, для большого количества длительных подключений, они могут быть проблематичными для веб-серверов с высоким трафиком, поскольку они могут вызвать поток запросов к недавно развернутому серверу или серверу, который только что вышел из строя.
Идеальный алгоритм балансировки нагрузки - это тот, который на самом деле не поддерживается HTTP - «Конкурирующие потребители». Так работают многие системы очередей (например, RabbitMq). Клиенты извлекают сообщения, а не отправляют их им. Тот, кто быстрее всех выполнит эту работу - и, следовательно, наиболее доступен для ее выполнения - получит ее.
Веб-серверы HTTP основаны на push, а не на pull, поэтому этот шаблон не совсем подходит.
Тем не менее, можно создать такое решение самостоятельно, используя промежуточный прокси-сервер, который реализует шаблон запрос-ответ, но имеет свой собственный набор проблем.
Я немного писал об этом здесь: https://www.quora.com/Why-use-message-queues-for-a-request- шаблон-ответа-который-синхронен-когда-очереди-асинхронны / answer / Tom-Burnell-5? nsrc = 4 & snid3 = 6113161011
