La mise en cache multicouche dans l'API Gateway relève les défis du trafic élevé
January 26, 2024
Avec l'utilisation croissante des API dans le développement moderne, la demande pour une passerelle API efficace et fiable a également augmenté. La passerelle API sert de point d'entrée unique pour toutes les requêtes API entrantes, permettant leur gestion et leur distribution efficaces à travers divers microservices. Bien que la passerelle API offre de nombreux avantages, elle peut rencontrer des défis dans des scénarios de trafic élevé.
Mécanisme de mise en cache d'APISIX
Le diagramme suivant illustre le mécanisme de mise en cache efficace utilisé par APISIX pour minimiser la latence et améliorer les performances. En mettant en cache les réponses à plusieurs niveaux, APISIX peut réduire efficacement la charge sur les serveurs en amont et offrir une expérience plus réactive pour les clients.
Client <-- Requête HTTP --> Worker APISIX
(Vérification du cache LRU au niveau du processus)
(Pas de correspondance dans le cache)
(Vérification du cache DICT partagé au niveau du plan de données)
(Verrou non acquis)
(Acquisition du verrou, vérification du cache)
(Correspondance dans le cache)
(Retour de la réponse mise en cache, libération des verrous)
(Absence dans le cache)
(Interrogation de Redis)
(Acquisition du Mutex)
(Interrogation de Redis)
(Absence dans le cache)
(Récupération de la réponse depuis l'amont)
(Mise en cache de la réponse dans le cache DICT partagé)
(Retour de la réponse au client)
(Correspondance dans le cache)
(Copie de la réponse dans le cache DICT partagé)
(Retour de la réponse mise en cache au client)
(Libération du Mutex Redis)
(Libération du verrou)
(Correspondance dans le cache)
(Retour de la réponse mise en cache)
LRU : Cache de première couche au niveau du worker unique d'APISIX
Le cache LRU (Least Recently Used) au niveau du worker d'APISIX est un composant crucial responsable de la mise en cache des données fréquemment accédées dans chaque processus de travail. Ce système de cache utilise l'algorithme d'éviction LRU, stockant et récupérant efficacement les données tout en priorisant la gestion des données les moins récemment utilisées. En mettant en cache les données fréquemment accédées en mémoire, APISIX réduit considérablement la latence et les coûts lors de l'interrogation de sources de données externes, telles que les règles de routage ou les jetons d'authentification, améliorant ainsi la vitesse de réponse du système.
Grâce à ce mécanisme de mise en cache intelligent, APISIX utilise efficacement les ressources du système lors de la gestion d'un grand volume de requêtes, améliorant ainsi les performances et la stabilité globales du système. APISIX, avec son cache LRU avancé, offre aux développeurs une solution de passerelle API fiable et efficace, facilitant une communication fluide avec les services externes.
Shared Dict : Cache de deuxième couche au niveau du nœud APISIX
Le dictionnaire de mémoire partagée (shared dict) entre tous les processus de travail dans un nœud APISIX. Il sert de cache centralisé pour les données fréquemment accédées, y compris les données de réponse API ou les en-têtes de réponse. Plusieurs processus de travail peuvent accéder et mettre à jour ce cache simultanément pour garantir la cohérence des données et éviter une duplication inutile des données.
Ce cache de dictionnaire de mémoire partagée présente des performances exceptionnelles, tirant parti de technologies avancées telles que le verrouillage de mémoire et des structures de données efficaces. Cela lui permet d'atteindre l'objectif de minimiser les conflits et de maximiser le débit. Grâce au verrouillage de mémoire, il contrôle efficacement l'accès concurrentiel, garantissant la cohérence lors des opérations de lecture et d'écriture simultanées dans plusieurs processus de travail. La conception efficace des structures de données permet au cache de dictionnaire de mémoire partagée d'exécuter les opérations de récupération et de mise à jour des données plus rapidement, améliorant ainsi les performances globales.
L'introduction du cache de dictionnaire de mémoire partagée injecte une plus grande performance et évolutivité dans le plan de données d'APISIX, offrant aux développeurs un outil fiable pour exceller dans la gestion de données et de requêtes à grande échelle.
Mécanisme de mise en cache multi-couches d'APISIX
Le diagramme ci-dessous illustre le mécanisme de mise en cache multi-couches d'APISIX, similaire au principe d'un entonnoir. Plus précisément, le cache L1 utilise un cache LRU au sein du worker, le cache L2 est un shared dict parmi plusieurs workers, et le cache L3 est une base de données Redis externe à la passerelle API.
Voici un exemple pour éclaircir : lorsque 10 000 requêtes utilisateurs interrogent des données via APISIX, en supposant un taux de correspondance du cache L1 de 90 %, 9 000 requêtes seront directement retournées. Les 1 000 requêtes restantes interrogeront ensuite le cache L2. En supposant un taux de correspondance du cache L2 également de 90 %, alors 100 requêtes interrogeront le cache L3, Redis. Avant que ces 100 requêtes n'interrogent Redis, elles interrogeront d'abord mutex (exclusion mutuelle) pour s'assurer qu'une seule requête interroge Redis à la fois, évitant ainsi l'effet Dogpile.
Conclusion
En tirant parti des capacités de la mise en cache multi-couches, APISIX gère efficacement la majorité des requêtes client sans avoir besoin d'interroger fréquemment des composants de stockage de données externes tels que Redis ou Postgres. Cela réduit considérablement la latence globale et améliore le débit de la passerelle API, offrant aux entreprises une solution efficace et robuste qui simplifie la communication avec les services externes. La conception optimisée garantit la robustesse du système, permettant à APISIX de répondre de manière flexible aux scénarios de haute concurrence et de créer un environnement de développement plus fiable et performant pour les ingénieurs.