Eine Schlüsselaufgabe hoch geladener WEB-Systeme ist die Fähigkeit, eine große Anzahl von Anfragen zu verarbeiten. Dieses Problem kann auf verschiedene Arten gelöst werden. In diesem Artikel schlage ich vor, eine ungewöhnliche Methode zur Optimierung von Backend-Anforderungen mithilfe der Content-Range-Technologie (Range-Technologie) in Betracht zu ziehen. Das heißt, um ihre Anzahl zu reduzieren, ohne die Systemqualität durch effizientes Caching zu verlieren.
Zunächst schlage ich vor,
einen Artikel zu studieren, in dem die Technologiepräambel mit einem Beispiel für S2S sehr präzise und verständlich dargestellt wird. Außerdem ist es ratsam, sich mit meinem ersten
Artikel über die Verwendung dieser Technologie vertraut zu machen, um die Arbeit mit Marktdaten in einem Kryptowährungsaustauschprojekt zu optimieren.
In diesem Artikel möchte ich zeigen, dass diese Technologie weiter verbreitet werden kann als der erste demonstrierte Artikel. Ich möchte Sie daran erinnern, dass dort Handelsinformationen (
Kerzen ) durch Bereichsanfragen für statische Dateien erhalten werden, die im Voraus von einem speziellen Dienst erstellt werden. Jetzt möchte ich Anfragen für ein vollständiges Backend anhand derselben Marktdaten als Beispiel und für dieselben Kerzen berücksichtigen, ohne wichtige Gewinne zu verlieren.
Also, was ist geplant, um zu erreichen:
- Backend-Anfragen optimieren (Anzahl reduzieren);
- Erhöhen Sie die Geschwindigkeit der Bereitstellung von Inhalten an den Endbenutzer.
- Verkehr optimieren.
Ich betone noch einmal, dass die Range-Technologie ein Standard ist (
RFC 2616 ). Es wird von Browsern nativ unterstützt und sie können empfangene Teile von Daten zwischenspeichern. Daher wird die nächste Anforderung vom Browser, wenn ein tatsächlicher Cache des angeforderten Teils vorhanden ist, auf dem Client implementiert, ohne Ihre Server zu stören.
Wenn Sie
CDN zwischen dem Client und den Servern hinzufügen, können Sie eine weitere leistungsstarke Caching-Ebene erhalten. Wenn im ersten Fall das Caching für einen bestimmten Endclient erfolgt und dann mit einem CDN gekoppelt wird, haben Sie die Möglichkeit, Daten bereits für eine Gruppe von Endclients zwischenzuspeichern.
Um eine echte Anfrage an den Server zu stellen, muss die Anfrage zwei Ebenen des Caching überwinden, von denen jede das Volumen der Anfragen an den Zielserver verringert. Natürlich kann die letzte "Redoute" auf dem Anforderungspfad Ihr Server mit seinem Cache sein.
Bei den Funktionen der Range-Technologie müssen Sie berücksichtigen, dass sie mit Teilen von Bytes funktioniert. Das heißt, mit binären Daten. Und wir können genau Byte-Intervalle anfordern. Sie müssen jeweils mit einem Binärblock antworten.
Ich denke einleitend genug. Kommen wir zu einem speziellen Fall, und wir werden bereits als Beispiel herausfinden, wie wir all dieses „Glück“ in einem bestimmten Problem nutzen können - indem wir Kerzen für ein bestimmtes Intervall mit einer bestimmten Belichtung anfordern.
Für den Anfang als Wir müssen mit binären Strukturen arbeiten, lasst uns unsere Kerze codieren. Dazu nehmen wir zum Beispiel folgende Struktur:
moment: int32 // min: float64 // max: float64 // open: float64 // close: float64 // volume: float64 // average: float64 //
Somit wird unsere Struktur 52 Bytes belegen. Wir nehmen es als ein Quantum - den minimalen Binärblock.
Als nächstes implementieren wir einen Controller, der GET-Anforderungen akzeptiert und den Bereichskopf analysiert. In diesem Fall werden wir das angeforderte Intervall durch einfache Division ohne Rest in Quanten übersetzen, d.h. Zum Beispiel eine Intervallanforderung:
Range: 5200-52000Wir müssen in der Dimension unseres Quantums interpretieren als:
Range: 100-1000Im Wesentlichen ist dies der Offset und das Limit unserer Datenbankabfrage.
Da die Definition der Belichtung sehr einfach ist, können wir sie in die URL einfügen. Z.B:
/api/v1/candles/7mDas heißt, Wir werden Kerzen mit einer Belichtung von 7 Minuten anfordern. Wir gehen natürlich davon aus, dass dieser Parameter auf Wunsch des Frontends geändert werden kann.
Wenn wir nun die erforderliche Belichtung, die Nummer der ersten Kerze und die Nummer der letzten Kerze kennen, die das Frontend anfordert, können wir die entsprechende Abfrage an die Datenbank ausführen.
Im Allgemeinen erinnert es sehr an das klassische Paginierungsproblem.
Es sind noch kleine Dinge übrig. Jede Zeile des Abfrageergebnisses wird in eine Binärstruktur (dasselbe Quantum) konvertiert, und das resultierende Binärarray wird als Abfrageergebnis angezeigt, und der Inhaltsbereich wird an den Antwortheader zurückgegeben:
Content-Range: [ ] / [[ ] * [ ]]Hör auf Aber wie kann die Front das gewünschte Zeitintervall und sogar das Byte-Intervall anfordern können? Woher kennt er dort irgendwelche Kerzenzahlen? Auch hier wurde alles erfunden. Der Bereich unterstützt den relativen Versatz, z.
Range: -52Fordern Sie 52 Bytes vom Ende an. Das heißt, die letzte Kerze. Wenn Sie nun den letzten Zeitpunkt der letzten Kerze kennen und aus der Antwort die Gesamtgröße der „Datei“ kennen, können Sie die Gesamtzahl der Kerzen berechnen und von hier aus das Byte-Intervall für die Anforderung der gewünschten Zeitbelichtung bestimmen.
Wenn Sie plötzlich eine Frage stellen wollten - warum solche Schwierigkeiten? Bitte kehren Sie zu Ihren Zielen zurück. Diese Technologie "maskierte" die analytischen Abfragen an die Datenbank in Binärdateien für das CDN und den Browser. Auf diese Weise können Sie die meisten wiederholten Anforderungen an das CDN und den Endclient übertragen.
Vielleicht stellt sich eine andere Frage: Warum nicht das einfache Zwischenspeichern von GET-Anforderungen verwenden? Gut. Lass es uns richtig machen. Wenn wir eine solche Anforderung in klassischem REST ausführen:
GET /api/v1/candles/7m?from=01-03-2018&to=31-03-2018Wir erhalten einen eindeutigen Cache für diese Anfrage. Durch Ausführen der folgenden Abfrage:
GET /api/v1/candles/7m?from=15-03-2018&to=20-03-2018Wir werden einen weiteren einzigartigen Cache bekommen ... Beachten Sie jedoch, dass die zweite Anforderung die Daten anfordert, die in der Antwort der ersten enthalten sind.
Im Fall der oben vorgeschlagenen Implementierung (Bereich) bildet die zweite Anforderung keinen separaten Cache, sondern verwendet die Daten, die bereits von der ersten Anforderung empfangen wurden. Und es wird nicht auf den Server gelangen. Dies spart die Größe der Caches und reduziert die Anzahl der Anrufe an den Server.
Gibt es Nachteile dieser Technologie? Ja Sie sind offensichtlich:
- Diese Technologie eignet sich nicht für Datenänderungen im Laufe der Zeit basierend auf Total Caching.
- CDN CloudFlare speichert Dateien nur vollständig zwischen. Dies bedeutet, dass CloudFlare tatsächlich die gesamte Datei vom Server anfordert, wenn der Endclient ein Intervall von beispielsweise 1 bis 100 Byte anfordert. Das heißt, In unserem Fall werden alle Kerzen mit einer bestimmten Belichtung geladen. Er wird es selbst stellen und es bereits selbst verteilen. Dies könnte sogar als Plus angesehen werden, wenn nicht die Einschränkungen des Ortes. Und wenn Sie "schwere" Antworten und viele Parameter bilden können, dann ... Im Allgemeinen ist es klar, dass der Ort enden wird. Vielleicht konnten wir es nicht richtig konfigurieren. Bisher ist das Ergebnis jedoch wie folgt.
- Es ist erforderlich, Caches mit Bedacht zu verwalten. Hierfür gibt es genügend Mechanismen, die jedoch abgestimmt werden müssen.
- Das Frontend sollte in der Lage sein, Binärdaten zu analysieren und einen Datensatz an Bord zu haben, um mit Bereichsanforderungen arbeiten zu können.
Ich würde die Machbarkeit der Umsetzung dieser Strategie wie folgt formulieren - wenn Sie sie brauchen, werden Sie verstehen. Wenn jetzt Zweifel bestehen, ist es nützlich, über sie Bescheid zu wissen, aber stören Sie sich nicht.