Смысл значения текущего лимита
Ограничение тока, безусловно, имеет большое значение — это механизм самозащиты, формирующийся в условиях неопределенности внешнего мира (всплески трафика, непредвиденные пользователи), когда системных ресурсов недостаточно. Но чувство ценности очень низкое, потому что 99,99% времени система всегда работает под страховочной линией, и даже не имеет шанса попасть в линию круглый год. Это как закон, он всегда здесь, но большую часть времени для большинства людей его просто нет или он не подозревает о его существовании.
Программная система часто имеет много скрытых ошибок, а наиболее часто используемые функциональные ошибки часто немногочисленны. Редко используемые функции всегда будут спрятаны там и ждут возможности прорваться, потому что на них давно не обращали внимания и не было возможности воспроизвести. И поскольку система программного обеспечения обновляется итеративно, весьма вероятно, что незамеченные функции будут пропущены тестировщиками и забыты при тестировании покрытия. В результате, как только возникает внезапная сцена (закон Мерфи), пробуждается запущенная и ошибочная логика кода, и тогда система дает сбой или даже крах. Функция ограничения тока является одной из таких незаметных функций.
Чтобы решить проблему смысла значения ограничения тока, инженерам необходимо выполнять периодические тренировки функции ограничения тока, которые необходимо повторять несколько раз с использованием модульных тестов и стресс-тестов. Короче говоря, попробуйте всевозможные способы запуска функции ограничения тока, чтобы она попала в строку, чтобы воспроизвести логику else, которая почти никогда не выполняется в производственной среде.
Алгоритм ограничения тока
Двумя наиболее распространенными базовыми алгоритмами ограничения тока в отрасли являются алгоритм воронки и алгоритм токена, которые похожи друг на друга. Алгоритм воронки можно понять, так как каждый запрос будет потреблять определенное количество воздуха, а воздух в воронке ограничен, и скорость получения воздуха через утечку воды также ограничена. Алгоритм токена можно понять, поскольку каждый запрос потребляет токен, а способность бакета токенов производить токены ограничена, и емкость бакета для хранения токенов также ограничена.
Запрос QPS производственной среды является гладким на кривой, потому что большинство статистических систем используют алгоритм сглаживания (среднее значение за период времени), но в реальном процессе работы будет определенная случайность и волатильность, и будет Некоторые выбросы пакета, это обычно называется пакетным трафиком.
Текущий алгоритм ограничения должен учитывать этот тип пакетного трафика.Он должен быть в состоянии допускать краткосрочный контент, и допуск также ограничен, то есть время допуска должно быть очень коротким. Вышеупомянутые два алгоритма имеют этот допуск, который выражается в накоплении воздуха в воронке, накоплении токенов в ведре токенов и исчерпании накопления достигает верхней границы допуска.
Распределенное ограничение тока
Если ваше приложение представляет собой один процесс, то дросселирование простое, а алгоритм подсчета запросов может выполняться в памяти. Алгоритм ограничения тока почти не имеет потерь и представляет собой расчет чистой памяти. Однако приложения в мире Интернета распределены по нескольким узлам, и возможности обработки запросов каждого узла не обязательно одинаковы. Что нам нужно учитывать, так это общую способность обработки запросов этих нескольких узлов.
Мощность обработки одного процесса составляет 1 Вт QPS, но это не означает, что общая мощность обработки запросов составляет N * 1 Вт QPS, потому что общая мощность обработки также будет ограничена возможностью совместного использования ресурсов. Этот общий ресурс обычно относится к базе данных или может быть таким ресурсом, как ЦП и диск, совместно используемым несколькими процессами на одном компьютере, а коэффициент пропускной способности сети также будет ограничивать общий объем запроса.
В это время алгоритм подсчета запросов должен быть завершен в одном месте (текущий ограничивающий промежуточный слой). Приложение должно подать заявку на трафик (воздух, ведро токенов) от этого централизованного менеджера перед обработкой запроса. Для каждого запроса требуется сетевой ввод-вывод, от приложения до промежуточного программного обеспечения регулирования.
Например, мы можем использовать Redis + Lua для реализации этой функции ограничения тока, но производительность Lua намного слабее, чем у C. Обычно этот алгоритм ограничения тока может достигать QPS около 1 Вт. Вы также можете использовать модуль Redis-Cell, который реализован внутри Rust, и он может достигать предела QPS около 5 Вт. На данный момент все они работают на полную мощность, но в производственной среде мы бы не хотели, чтобы они работали на полную мощность все время.
Итак, как выполнить текущий лимит 10 Вт QPS?
Простая идея состоит в том, чтобы сгруппировать ключи с ограниченным текущим значением, а затем использовать кластер Redis для расширения емкости, чтобы инструкции приложения с ограниченным текущим числом группировались по хэшу клиента, а затем распределялись по нескольким точкам кластера, тем самым рассеивая давление.
Как выполнить текущий лимит в один миллион запросов в секунду (1M)?
Если вы также используете описанный выше метод, ресурсы полосы пропускания и требуемые экземпляры Redis также будут потрясающими. Для выполнения этой работы нам могут понадобиться десятки узлов Redis плюс сотни M (1M * 20 байт * 8) полосы пропускания.
В настоящее время мы должны изменить свое мышление и больше не использовать этот централизованный метод управления и контроля для работы. Это как страна со слишком большим количеством людей, поэтому необходимо разделить управление на провинции, города и уезды - децентрализация.
Мы распределяем общий QPS на каждую подноду в соответствии с весом, и ограничиваем ток одной машины в памяти для каждой точки байта. Если все узлы равны, то каждый дочерний узел может получить 1/n QPS.
Его преимущество заключается в том, что он рассеивает давление, ограничивающее ток, и превращает операции ввода-вывода в чистые вычисления в памяти, так что он может легко справляться со сверхвысоким ограничением тока QPS. Однако это также увеличивает сложность системы.Требуется централизованный центр конфигурации для распределения порогового значения QPS для каждого подузла, каждая точка байта приложения должна быть зарегистрирована в этом центре конфигурации, и для мониторинга требуется фон управления конфигурацией. Распределение QPS управляется.
Если нет полного, простого в использовании и зрелого программного обеспечения с открытым исходным кодом, такая служба центра управления и SDK часто требуют небольшой команды. Это часто недоступно для малых и средних предприятий, а учитывая, что значение ограничения тока настолько низкое, эта возможность еще более отдалена.