Comments 7
А просто класть в наименее заполненное ведро безо всякого рандома - слишком просто?
Балансировка нагрузки round robin знать не знает про состояние узлов. Балансировки least connection, least utilizаtion и т.п. которую вы предлагаете это другая крайность, знаем постоянно и про всех. Описанный алгоритм показывает, как с минимальными усилиями существенно улучшить легковесний round robin, и почему это работает.
round robin и про рандом ничего не знает. А ваш алгоритм требует знания заполненности любого наперёд неизвестного ведра.
Не совсем. Наперёд знать не надо, можно просто спросить.
Если у вас миллион серверов, то каждый из балансировщиков не будет непрерывно опрашивать их про нагрузку и хранить эти данные. Он выберет два, спросит только их, и примет решение. Можно вокруг этого наворотить оптимизаций в виде кратковременного кэширования и т.д., но в любом случае нам надо иметь и обрабатывать информацию только о двух серверах, а не о всех.
Вы вот сейчас серьёзно предлагаете перед каждым запросом делать round-trip к двум серверам, вместо того, чтобы просто каждому серверу периодически уведомлять балансировщик о своей нагрузке или даже на самом балансировщике вести учёт кому сколько задач было отправлено?
Если трафик достаточно велик, чтобы каждый балансировщик часто общался с каждым сервером, то смысла в таких запросах действительно нет: проще подцепить информацию о нагрузке к очередному ответу.
А вот если трафик состоит из небольшого числа очень дорогих запросов, как оно вполне может быть с каким-нибудь ChatGPT, то ситуация меняется. Постоянно долбить каждый балансер данными со всех серверов становится накладно: зачем ему этот миллион служебных RPS, если сам балансер раскидывает всего тысячу? Round-trip внутри датацентра короткие, ну добавим к трёхсекундному ответу ещё миллисекунду. На P99.9 не повлияет.
Метод интересный, но к реальности отношения имеет мало. Разные запросы, могут грузить сервер, совершенно по разному.
Балансировка нагрузки: простыми словами о всей мощи двух случайных вариантов