предисловие
В реальном проекте я столкнулся с пиком 5 Вт + QPS в Интернете, а также испытал большой запрос трафика 10 Вт + QPS в состоянии стресс-теста.Тема этого блога — в основном мои собственные мысли об управлении параллельным трафиком.
Некоторые идеи для борьбы с интенсивным движением
Прежде всего, давайте поговорим о том, что такое высокий трафик?
Большой трафик, скорее всего, появится: TPS (транзакций в секунду), QPS (запросов в секунду), 1W+, 5W+, 10W+, 100W+…. На самом деле абсолютного числа нет, если это количество вызывает давление в системе и влияет на производительность системы, то это количество можно назвать большим расходом.
Во-вторых, каковы некоторые распространенные способы борьбы с большим трафиком?
Кэш: Чтобы положить его прямо, это позволить данные вводить в кэш как можно скорее, подойдите ближе к программе и не доступа к DB часто.
Downgrade: Если это не основная ссылка, то отключите эту деградацию сервиса. Аналогия, APP теперь тысячи людей обращают внимание на тысячу лиц, получают данные, делают персонализированное отображение рейтинга, если при большом потоке, этот вид может понизить в должности!
Ограничение тока: как мы все знаем, в утренний час пик пекинского метро станция метро будет делать одну вещь, то есть ограничивать поток! Идея очень проста, просто нужно ограничить запрос определенным диапазоном в течение определенного периода времени, чтобы гарантировать, что система не будет перегружена, и в то же время максимально улучшить пропускную способность системы.
Обратите внимание, что иногда кэширование и понижение версии не могут решить проблему. Например, в электронной коммерции Double Eleven покупки, заказы и другие действия пользователей включают большое количество операций записи, и они являются основными ссылками, которые не могут быть понижены. ограничение тока важнее.
Итак, теперь давайте сосредоточимся на текущем лимите.
Распространенные способы ограничения тока
Общие методы обработки для ограничения тока включают в себя: счетчики, скользящие окна, дырявые ведра и токены.
прилавок
Счетчик представляет собой относительно простой алгоритм ограничения тока, который широко используется.На уровне интерфейса этот метод используется во многих местах для ограничения тока. В течение определенного периода времени считайте и сравнивайте с пороговым значением, и когда достигается критическая точка времени, счетчик очищается до 0.
Здесь следует отметить, что существует критический момент времени. Например, нет запросов пользователей с 12:01:00 до 12:01:58, а затем выдается 100 запросов в момент 12:01:59, ок, а затем в момент 12:02:00 Было сделано еще 100 запросов. Здесь вы должны почувствовать, что в этот критический момент может быть большое количество запросов от злоумышленников, даже больше, чем система ожидает выдержать.
раздвижное окно
Из-за дефекта критической точки счетчика позже появился алгоритм скользящего окна для его решения.
Скользящее окно означает, что фиксированный квант времени делится и перемещается по прошествии времени, так что проблема критической точки счетчика ловко избегается. Другими словами, это фиксированное количество подвижных сеток будет подсчитывать и определять порог, поэтому количество сеток влияет на точность алгоритма скользящего окна.
дырявое ведро
Хотя скользящее окно эффективно позволяет избежать проблемы критических точек по времени, все еще существует концепция временных срезов, и алгоритм дырявого ведра в этом отношении является более продвинутым, чем скользящее окно.
Есть фиксированное ведро, скорость притока воды не определена, но скорость оттока воды постоянна, и когда вода наполнится, оно переполнится.
ведро с жетонами
Учтите, что расход воды дырявого ведра постоянен, а это значит, что при мгновенном большом расходе большая часть заявок будет отброшена (т. е. так называемый перелив). Чтобы решить эту проблему, ведро токенов было улучшено алгоритмически.
Скорость, с которой генерируются токены, постоянна, и для запросов на получение токенов нет ограничения скорости. Это означает, что в условиях мгновенного большого трафика алгоритм может запросить большое количество токенов за короткий промежуток времени, а процесс получения токенов не очень затратен. (Есть небольшой смысл производить токены, потреблять токены)
Вне зависимости от того, не удается ли получить токен из корзины токенов и она отклонена, или из-за того, что дырявая корзина переполняется, разумно пожертвовать небольшой частью трафика, чтобы обеспечить нормальное использование большей части трафика.Если необходимо гарантировать небольшой объем трафика, это может привести к тому, что система достигнет предела и зависнет, что не стоит потери.
Текущий ограничивающий артефакт: Guava RateLimiter
Guava не только эффективен с точки зрения коллекций, кэширования, асинхронных обратных вызовов и т. д., но также инкапсулирует для нас API, ограничивающий ток!
Guava RateLimiter основан на алгоритме корзины токенов, нам нужно только сообщить RateLimiter, какой QPS ограничен системой, тогда RateLimiter положит токен в корзину на этой скорости, а затем при запросе получит разрешение от RateLimiter через метод tryAcquire() (пусть Card).
Текущее ограничение в распределенных сценариях
Некоторые из упомянутых выше методов ограничения тока предназначены только для одной машины.На самом деле, в большинстве сценариев достаточно ограничения тока одной машины. Средства распределенного нижнего предела потока часто требуют комбинации нескольких технологий, таких как Nginx+Lua, Redis+Lua и т. д. В этой статье в основном обсуждается текущий лимит одной машины, и текущий лимит в распределенном сценарии здесь подробно не рассматривается.
Одним словом, дайте трафику системы встать в очередь и сначала ограничить ток в очереди, и не давать трафику напрямую попасть в систему.