Серверный троттлер и ограничитель скорости | Лестница проектирования систем 🪜 | HLD 101

В этом руководстве рассматриваются две идеи, которые, как ожидают интервьюеры, вы должны различать. Ограничение скорости — это обеспечение соблюдения политики. Сброс нагрузки — это выживание в условиях перегрузки. Когда вас спрашивают, как справляться с неожиданными всплесками нагрузки, и вы рассматриваете оба механизма как один и тот же, вы показываете, что не понимаете разницы между отказом пользователям и защитой умирающего сервера.

Этот анализ показывает, как сервисы масштабируются горизонтально, как автоматическое масштабирование отстает от реальности и почему перегрузки создают каскадные задержки в распределенной системе. Когда мощность не может быть добавлена ​​достаточно быстро, сервис либо замедляется для всех, либо дешево отклоняет задачи и защищает согласованность. Быстрый возврат ошибки 503 защищает ЦП, память, очереди и нижестоящие зависимости. Замедление увеличивает переключение контекста, глубину очереди, нагрузку на сборщик мусора и в конечном итоге приводит к зависаниям или ошибкам нехватки памяти. Сброс нагрузки поддерживает работу сервиса достаточно долго, чтобы масштабирование успело компенсировать потери.

В видеоролике рассматривается нагрузка на многопользовательскую сеть. Одна чрезмерно ресурсоемкая рабочая нагрузка не должна приводить к сбоям во всех остальных. Ограничение скорости запросов обеспечивает справедливость на уровне бизнес-процессов. Вы устанавливаете квоты для каждого клиента или рабочей нагрузки. Когда клиент превышает квоту, вы возвращаете ошибку 429 и сообщаете клиенту о необходимости снизить скорость. Сервер не выходит из строя. Клиент ведет себя некорректно. Это обеспечивает предсказуемую производительность для всех пользователей и предотвращает «голодание» ресурсов.

Вы увидите, как токен-корзины позволяют пропускать всплески запросов, как «протекающие корзины» сглаживают поток запросов и как фиксированные или скользящие окна подсчитывают события. Вы увидите, как работает локальная справедливость на одном сервере без глобальной координации, и как глобальная справедливость зависит от распределенного состояния, такого как Redis. Вы увидите, как Envoy, sidecar-контейнеры или серверы приложений отслеживают загрузку ЦП, задержки в очередях, давление памяти, пулы соединений, тенденции задержки и адаптивные циклы обратной связи регулирования. Когда показатели работоспособности превышают пороговые значения, система вероятностно отбрасывает запросы для обеспечения дальнейшего прогресса.

Этот учебник завершается ментальным разделением. Ограничение скорости запросов спрашивает, кто вы и сколько квоты вы использовали. Сброс нагрузки проверяет, достаточно ли работоспособен сервер для продолжения работы. Ограничение скорости запросов связано с политикой и справедливостью. Сброс нагрузки основан на физике и пропускной способности. Разница между ними определяет, замедлится ли ваша система и выйдет из строя, или же она отклонит запрос на ранней стадии и продолжит работу.

Хэштеги:
#systemdesign #loadshedding #ratelimiting #scalability #backendengineering #distributed systems #autoscaling #overloadprotection #apigateway #multitenancy #fairness #tokenbucket #leakybucket #latency #throughput #capacity #oom #sre #productionengineering #softwarearchitecture #google #amazon #faang #netflix #softwareengineer #systemdesigninterview #hld #corporate #server #microservicesarchitecture #distributed #throttleresponse #ratelimiter #systemdesigninterview

Связанные каналы:
@hello_interview @takeUforward @gkcs @IGotAnOffer-Engineering @tryexponent @tryexponent