Mehrschichtiges Caching im API-Gateway bewältigt Herausforderungen bei hohem Datenverkehr

Da die Nutzung von APIs in der modernen Entwicklung weiter zunimmt, steigt auch die Nachfrage nach einem effizienten und zuverlässigen API-Gateway. Das API-Gateway dient als einziger Einstiegspunkt für alle eingehenden API-Anfragen, wodurch diese effizient verwaltet und auf verschiedene Microservices verteilt werden können. Obwohl das API-Gateway zahlreiche Vorteile bietet, kann es bei der Bewältigung von Hochlastszenarien auf Herausforderungen stoßen.

Caching-Mechanismus von APISIX

Das folgende Flussdiagramm veranschaulicht den effizienten Caching-Mechanismus, den APISIX verwendet, um Latenz zu minimieren und die Leistung zu verbessern. Durch das Caching von Antworten auf mehreren Ebenen kann APISIX die Last auf den Upstream-Servern effektiv reduzieren und ein reaktionsschnelleres Erlebnis für die Clients bieten.

Client <-- HTTP-Anfrage --> APISIX Worker
    (Überprüfung des LRU-Caches auf Prozessebene)
    (Kein Cache-Treffer)
    (Überprüfung des Shared DICT-Caches auf Datenebene)
        (Sperre nicht erworben)
            (Sperre erwerben, Cache überprüfen)
                (Cache-Treffer)
                (Gecachte Antwort zurückgeben, Sperren freigeben)
                (Cache-Fehler)
                    (Redis abfragen)
                        (Mutex erwerben)
                            (Redis abfragen)
                                (Cache-Fehler)
                                    (Antwort vom Upstream abrufen)
                                    (Antwort im Shared DICT-Cache speichern)
                                    (Antwort an Client zurückgeben)
                                (Cache-Treffer)
                                    (Antwort in Shared DICT-Cache kopieren)
                                    (Gecachte Antwort an Client zurückgeben)
                                (Redis-Mutex freigeben)
                        (Sperre freigeben)
    (Cache-Treffer)
        (Gecachte Antwort zurückgeben)

LRU: Erste Ebene des Cachings auf APISIX Single Worker Level

Der LRU (Least Recently Used) Cache auf der Worker-Ebene von APISIX ist eine entscheidende Komponente, die für das Caching häufig genutzter Daten innerhalb jedes Arbeitsprozesses verantwortlich ist. Dieses Cache-System verwendet den LRU-Algorithmus, um Daten effizient zu speichern und abzurufen, wobei die Verarbeitung der am wenigsten kürzlich verwendeten Daten priorisiert wird. Durch das Caching häufig genutzter Daten im Speicher reduziert APISIX die Latenz und die Kosten bei der Abfrage externer Datenquellen, wie z.B. Routing-Regeln oder Authentifizierungstoken, erheblich und verbessert so die Systemreaktionsgeschwindigkeit.

Durch diesen intelligenten Caching-Mechanismus nutzt APISIX Systemressourcen effizient, wenn eine große Anzahl von Anfragen verarbeitet wird, und verbessert so die Gesamtleistung und Stabilität des Systems. APISIX bietet mit seinem fortschrittlichen LRU-Cache Entwicklern eine zuverlässige und effiziente API-Gateway-Lösung, die eine reibungslose Kommunikation mit externen Diensten ermöglicht.

Shared Dict: Zweite Ebene des Cachings auf APISIX Node Level

Der gemeinsame Speicherdictionary-Cache (shared dict) zwischen allen Arbeitsprozessen in einem APISIX-Knoten. Er dient als zentraler Cache für häufig genutzte Daten, einschließlich API-Antwortdaten oder Antwortheader. Mehrere Worker-Prozesse können gleichzeitig auf diesen Cache zugreifen und ihn aktualisieren, um Datenkonsistenz zu gewährleisten und unnötige Datenredundanz zu vermeiden.

Dieser gemeinsame Speicherdictionary-Cache zeigt eine herausragende Leistung, indem er fortschrittliche Technologien wie Speichersperren und effiziente Datenstrukturen nutzt. Dies ermöglicht es, das Ziel der Minimierung von Konflikten und der Maximierung des Durchsatzes zu erreichen. Durch Speichersperren wird der gleichzeitige Zugriff effektiv gesteuert, wodurch die Konsistenz bei gleichzeitigen Lese- und Schreibvorgängen über mehrere Arbeitsprozesse hinweg gewährleistet wird. Die effiziente Gestaltung der Datenstruktur ermöglicht es dem gemeinsamen Speicherdictionary-Cache, Datenabruf- und Aktualisierungsvorgänge schneller auszuführen und so die Gesamtleistung zu verbessern.

Die Einführung des gemeinsamen Speicherdictionary-Caches verleiht der Datenebene von APISIX mehr Leistung und Skalierbarkeit und bietet Entwicklern ein zuverlässiges Werkzeug, um bei der Bewältigung großer Datenmengen und Anfragen zu glänzen.

APISIX Multi-Layer Caching-Mechanismus

Das folgende Diagramm veranschaulicht den mehrschichtigen Caching-Mechanismus von APISIX, ähnlich dem Prinzip eines Trichters. Konkret nutzt der L1-Cache einen LRU-Cache innerhalb des Workers, der L2-Cache ist ein gemeinsamer Dictionary-Cache (shared dict) zwischen mehreren Workern, und der L3-Cache ist eine Redis-Datenbank, die extern zum API-Gateway liegt.

Hier ein Beispiel zur Veranschaulichung: Wenn 10.000 Benutzeranfragen Daten über APISIX abfragen und die Trefferrate des L1-Caches 90 % beträgt, werden 9000 Anfragen direkt zurückgegeben. Die verbleibenden 1000 Anfragen fragen dann den L2-Cache ab. Wenn die Trefferrate des L2-Caches ebenfalls 90 % beträgt, werden 100 Anfragen den L3-Cache, Redis, abfragen. Bevor diese 100 Anfragen Redis abfragen, werden sie zunächst Mutex (gegenseitiger Ausschluss) abfragen, um sicherzustellen, dass nur eine Anfrage gleichzeitig Redis abfragt, und so den Dogpile-Effekt zu verhindern.

Fazit

Durch die Nutzung der Fähigkeiten des mehrschichtigen Cachings kann APISIX die meisten Client-Anfragen effizient verarbeiten, ohne dass häufige Abfragen an externe Datenspeicherkomponenten wie Redis oder Postgres erforderlich sind. Dies reduziert nicht nur die Gesamtlatenz erheblich, sondern erhöht auch den Durchsatz des API-Gateways und bietet Unternehmen eine effiziente und robuste Lösung, die die Kommunikation mit externen Diensten vereinfacht. Das optimierte Design gewährleistet die Robustheit des Systems und ermöglicht es APISIX, flexibel auf Hochlastszenarien zu reagieren und Entwicklern eine zuverlässige und leistungsstarke Entwicklungsumgebung zu bieten.