Eine komplexe Lösung für die einfachen Probleme von HighLoad WEB-Diensten



    Eine zentrale Aufgabe von hoch ausgelasteten WEB-Systemen ist die Bearbeitung einer Vielzahl von Anfragen. Es gibt verschiedene Möglichkeiten, um dieses Problem zu lösen. In diesem Artikel schlage ich vor, eine ungewöhnliche Methode zur Optimierung von Backend-Anforderungen durch die Content-Range (Range) -Technologie in Betracht zu ziehen. Das heißt, 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 technologische Präambel mit einem Beispiel für S2S sehr kurz und verständlich dargestellt wird. Außerdem ist es ratsam, meinen ersten Artikel über die Verwendung dieser Technologie zur Optimierung der Arbeit mit Marktdaten für das Krypto-Austausch-Projekt zu lesen.

    In diesem Artikel möchte ich zeigen, dass diese Technologie breiter eingesetzt werden kann als der erste gezeigte Artikel. Lassen Sie mich daran erinnern, dass dort Handelsinformationen ( Kerzen ) durch Bereichsanfragen für statische Dateien erhalten werden, die im Voraus von einem speziellen Dienst vorbereitet werden. Jetzt möchte ich Anfragen für ein vollständiges Backend am Beispiel derselben Marktdaten und derselben Kerzen prüfen, ohne dabei wichtige Gewinne zu verlieren.

    Also, was ist geplant, um zu erreichen:

    1. Backend-Anfragen optimieren (Anzahl reduzieren);
    2. Erhöhen Sie die Geschwindigkeit der Inhaltszustellung an den Endbenutzer.
    3. Optimieren Sie den Verkehr.

    Ich betone noch einmal, dass die Range-Technologie ein Standard ist ( RFC 2616 ). Es wird nativ von Browsern unterstützt und sie sind in der Lage, empfangene Teile von Daten zwischenzuspeichern. Daher wird die nächste Anforderung des Browsers, sofern 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, leistungsfähige Ebene für das Caching erhalten. Und wenn im ersten Fall die Zwischenspeicherung für einen bestimmten Endkunden erfolgt und anschließend mit einem CDN gekoppelt wird, haben Sie die Möglichkeit, Daten bereits für eine Gruppe von Endkunden zwischenzuspeichern.

    Um also eine echte Anforderung an den Server zu richten, muss die Anforderung zwei Cache-Ebenen überwinden, von denen jede das Anforderungsvolumen an den Zielserver verringert. Natürlich kann die letzte "Redoute" auf dem Anforderungspfad Ihr Server mit seinem Cache sein.

    Bei der Verwendung 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 die Byte-Intervalle anfordern. Sie müssen jeweils antworten - mit einem Binärblock.

    Ich denke einleitend genug. Gehen wir nun zu einem speziellen Fall über, und wir werden bereits beispielhaft 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, verschlüsseln wir unsere Kerze. Dazu nehmen wir zum Beispiel die 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 Bereichsheader analysiert. In diesem Fall werden wir das angeforderte Intervall durch einfache Division ohne Rest, d.h. Zum Beispiel eine Anfrage mit einem Intervall: Wir

    Range: 5200-52000

    sollten in der Dimension unseres Quantums interpretieren als:

    Range: 100-1000

    Im Wesentlichen wird dies der Offset und das Limit unserer Datenbankabfrage sein.

    Mit der Definition der Belichtung ist sehr einfach, wir können es in die URL setzen. Zum Beispiel:

    /api/v1/candles/7m

    d.h. 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äre Struktur (dasselbe Quantum) konvertiert und das resultierende binäre Array wird als Abfrageergebnis angezeigt. Der Inhaltsbereich wird im Antwortheader angegeben:

    Content-Range: [запрошенный интервал] / [[количество записей в БД] * [размер кванта]]

    Stop. Aber wie kann die Front das gewünschte Zeitintervall und sogar das Byte-Intervall anfordern? Woher kennt er Kerzennummern dort? Auch hier wurde alles erfunden. Der Bereich unterstützt den relativen Versatz, z.

    Range: -52

    Fordern 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 Gesamtanzahl der Kerzen berechnen und daraus 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 „maskiert“ analytische 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 Endkunden übertragen.

    Vielleicht stellt sich eine andere Frage: Warum nicht einfach GET-Anforderungen zwischenspeichern? Gut Lass es uns richtig machen. Wenn wir eine solche Anfrage im klassischen REST ausführen:

    GET /api/v1/candles/7m?from=01-03-2018&to=31-03-2018

    Wir 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-2018

    Wir werden einen weiteren einzigartigen Cache bekommen ... obwohl zu beachten ist, fordert die zweite Anforderung die Daten an, 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 kommt nicht auf den Server. Und das spart die Größe der Caches und reduziert die Anzahl der Aufrufe an den Server.

    Gibt es Nachteile dieser Technologie? Ja Sie sind offensichtlich:

    1. Diese Technologie eignet sich nicht für Datenänderungen im Laufe der Zeit basierend auf Gesamt-Caching.
    2. CDN CloudFlare speichert Dateien nur vollständig im Cache. Dies bedeutet, dass CloudFlare 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 zu Hause ablegen 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.
    3. Caches müssen mit Bedacht verwaltet werden. Hierfür gibt es genügend Mechanismen, die jedoch abgestimmt werden müssen.
    4. Das Frontend sollte in der Lage sein, binäre Daten 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 es brauchen, werden Sie verstehen. Wenn Sie jetzt Zweifel haben, ist es nützlich, über sie Bescheid zu wissen, aber kümmern Sie sich nicht darum.

    Jetzt auch beliebt: