Многоуровневое кэширование в API Gateway решает проблемы высокой нагрузки
January 26, 2024
По мере того как использование API продолжает расти в современной разработке, спрос на эффективный и надежный API-шлюз также увеличивается. API-шлюз служит единой точкой входа для всех входящих запросов API, позволяя эффективно управлять ими и распределять их между различными микросервисами. Хотя API-шлюз предлагает множество преимуществ, он может столкнуться с трудностями при обработке сценариев с высокой нагрузкой.
Механизм кэширования APISIX
Следующая блок-схема иллюстрирует эффективный механизм кэширования, используемый APISIX для минимизации задержек и повышения производительности. Кэшируя ответы на нескольких уровнях, APISIX может эффективно снизить нагрузку на вышестоящие серверы и обеспечить более быстрый отклик для клиентов.
Client <-- HTTP Request --> APISIX Worker (Check LRU Cache in process level) (No cache hit) (Check Shared DICT Cache in data plane level) (Lock not acquired) (Acquire lock, check cache) (Cache hit) (Return cached response, release locks) (Cache miss) (Query Redis) (Acquire Mutex) (Query Redis) (Cache miss) (Retrieve response from upstream) (Cache response in shared DICT cache) (Return response to client) (Cache hit) (Copy response to shared DICT cache) (Return cached response to client) (Release Redis Mutex) (Release lock) (Cache hit) (Return cached response)
LRU: Кэширование первого уровня на уровне одного воркера APISIX
Кэш LRU (Least Recently Used) на уровне воркера APISIX является важным компонентом, отвечающим за кэширование часто запрашиваемых данных в каждом рабочем процессе. Эта система кэширования использует алгоритм вытеснения LRU, эффективно сохраняя и извлекая данные, при этом приоритет отдается обработке наименее недавно использованных данных. Кэшируя часто запрашиваемые данные в памяти, APISIX значительно снижает задержки и затраты при запросах к внешним источникам данных, таким как правила маршрутизации или токены аутентификации, тем самым повышая скорость отклика системы.
Благодаря этому интеллектуальному механизму кэширования, APISIX эффективно использует системные ресурсы при обработке большого объема запросов, что улучшает общую производительность и стабильность системы. APISIX, с его продвинутым LRU кэшем, предоставляет разработчикам надежное и эффективное решение для API-шлюза, облегчая плавное взаимодействие с внешними сервисами.
Shared Dict: Кэширование второго уровня на уровне узла APISIX
Общий словарь памяти (shared dict) между всеми рабочими процессами в одном узле APISIX. Он служит централизованным кэшем для часто запрашиваемых данных, включая данные ответов API или заголовки ответов. Несколько рабочих процессов могут одновременно обращаться к этому кэшу и обновлять его, чтобы обеспечить согласованность данных и избежать ненужного дублирования данных.
Этот общий словарь памяти демонстрирует выдающуюся производительность, используя передовые технологии, такие как блокировка памяти и эффективные структуры данных. Это позволяет достичь цели минимизации конкуренции и максимизации пропускной способности. Благодаря блокировке памяти, он эффективно контролирует одновременный доступ, обеспечивая согласованность при одновременных операциях чтения и записи в нескольких рабочих процессах. Эффективная структура данных позволяет общему словарю памяти быстрее выполнять операции извлечения и обновления данных, повышая общую производительность.
Введение общего словаря памяти добавляет больше производительности и масштабируемости в плоскость данных APISIX, предоставляя разработчикам надежный инструмент для эффективной обработки больших объемов данных и запросов.
Многоуровневый механизм кэширования APISIX
На диаграмме ниже показан многоуровневый механизм кэширования APISIX, аналогичный принципу воронки. В частности, кэш L1 использует LRU кэш внутри воркера, кэш L2 — это общий словарь (shared dict) между несколькими воркерами, а кэш L3 — это база данных Redis, внешняя по отношению к API-шлюзу.
Вот пример для пояснения: когда 10 000 пользовательских запросов запрашивают данные через APISIX, предполагая, что уровень попаданий в кэш L1 составляет 90%, 9000 запросов будут возвращены напрямую. Оставшиеся 1000 запросов затем запросят кэш L2. Предполагая, что уровень попаданий в кэш L2 также составляет 90%, то 100 запросов перейдут к запросу кэша L3, Redis. Перед тем как эти 100 запросов запросят Redis, они сначала запросят мьютекс (взаимное исключение), чтобы гарантировать, что только один запрос запрашивает Redis одновременно, предотвращая эффект Dogpile.

Заключение
Используя возможности многоуровневого кэширования, APISIX эффективно обрабатывает большинство клиентских запросов без необходимости частых запросов к внешним компонентам хранения данных, таким как Redis или Postgres. Это не только значительно снижает общую задержку, но и повышает пропускную способность API-шлюза, предоставляя бизнесу эффективное и надежное решение, упрощающее взаимодействие с внешними сервисами. Оптимизированный дизайн обеспечивает устойчивость системы, позволяя APISIX гибко справляться с сценариями высокой конкуренции и создавать более надежную и высокопроизводительную среду разработки для инженеров.