
Während des Refactorings unseres Krypto-Austauschs wurde beschlossen, das Konzept der Arbeit mit einem Marktdatum zu überarbeiten. Im klassischen Fall wird das Marktdatum auf zwei Arten verteilt:
1. REST-Schnittstelle;
2. WEBSocket-Broadcast-Abonnement.
Die REST-Methode wird häufig verwendet, um historische Daten abzurufen, während das WEBSocket Live-Informationen online sendet. In einigen Fällen wird WEBSocket überhaupt nicht verwendet, und Aktualisierungen werden durch regelmäßige Anforderungen über REST durchgeführt.
Und anscheinend sind alle glücklich. Bei näherer Betrachtung wird jedoch der enorme Aufwand eines solchen Konzepts deutlich. Ihre Masse ruht auf REST. Um die Funktionsweise der REST-Schnittstelle sicherzustellen, müssen wir ein Backend erstellen, das die Anforderungen hoch ausgelasteter Systeme erfüllt. Natürlich können Sie hier verschiedene Lösungsoptionen von PHP bis zum jetzt modischen Golang auswählen.
Es ist auch erforderlich, eine leicht zugängliche Infrastruktur zu schaffen, Kleinigkeiten wie CI / CD für Dienste zu implementieren und all dies mit den richtigen Spezialisten für Entwicklung, Wartung usw. usw. zu versorgen.
Gleichzeitig ist es das historische Marktdatum, das den größten Teil des Speicherplatzes einnimmt. Es wird normalerweise in der Datenbank gespeichert. Dies ermöglicht es uns einerseits, das Problem des Clustering zu lösen, aber bei kritischen Größen wird es zu einer unerträglichen Belastung und stellt das DevOps-Team und die Entwickler vor nicht triviale Aufgaben.
Im Allgemeinen ... wird die scheinbare Einfachheit und Konsistenz dieses Konzepts in ein hartes Leben zerschmettert.
Separat müssen Sie die Besonderheit des Marktdatums beachten. Es sammelt sich immer an (wächst). Das heißt, In der Sprache des Datenbankprogrammierers fügen wir immer ein und wählen dann aus. Aber nicht teilbar. Das heißt, wunderbare Datenbankfunktionalität für Systematisierung, Optimierung usw. Die gespeicherten Daten werden nicht beansprucht.
Eine weitere wichtige Eigenschaft eines Marktdatums ist seine klar definierte Struktur. Beispielsweise hat eine Kerze in einem Diagramm nur acht Parameter:
1. Der Moment der Zeit;
2. Ausstellung;
3. Der Höchstpreis;
4. den Mindestpreis;
5. Eröffnungspreis;
6. Schlusskurs;
7. Lautstärke;
8. Durchschnittspreis.
Gleiches gilt für Deals.
Aufgrund dieser Voraussetzungen und der Erfahrung bin ich schnell zu dem Schluss gekommen, dass es korrekter ist, das Marktdatum als strukturierten Strom zu betrachten.
Ein Stream mit Kerzen kann beispielsweise als Array von Binärstrukturen betrachtet werden:
moment: int32
exposition: int32
min: float64
max: float64
open: float64
close: float64
volume: float64
average: float64
Gesamt: 56 Bytes.
Beispielsweise wird eine solche Kerze in JSON wie folgt beschrieben:
{ "date":1501004700, "high":0.08053391, "low":0.08020004, "open":0.08030001, "close":0.0803542, "volume":48.62169347, "weightedAverage":0.08038445 }
Gesamt: 167 Bytes.
Der Gewinn in der Größe liegt auf der Hand. Und das ist weniger Verkehr, höhere Liefergeschwindigkeit für den Kunden.
Und hier fällt mir natürlich BSON ein. Das Problem der Notwendigkeit eines Backends wird jedoch nicht gelöst, und das Problem wird im Allgemeinen nicht grundlegend gelöst. Darüber hinaus wird es von Browsern nicht nativ unterstützt.
Ich sah weg. Das Netzwerk verfügt über viele Ressourcen, die mit Threads arbeiten. Dies sind Audio- und Videoressourcen. Sie zeigen alle notwendigen Zeichen:
- mit großen Datenmengen arbeiten;
- perfekt mit hohen Belastungen umgehen;
- Sie sind in der Lage, Inhalte online bereitzustellen, ermöglichen jedoch gleichzeitig den Zugriff auf historische Daten.
Ich ging etwas tiefer in das Streaming-Video ein, wodurch ich alle oben genannten Probleme bis zum Marktdatum radikal lösen konnte. Wie sich herausstellte, ist all die Magie in der
Content-Range- Technologie verborgen, die
standardmäßig unterstützt wird, beispielsweise Nginx. Sie können auf jeden Bereich einer statischen Ressource (Datei auf dem Server) zugreifen, ohne ein Backend zu verwenden. Im Allgemeinen geschieht dies wie folgt: Sie verweisen auf die URL, die die Belichtung angibt, die Sie in der Kopfzeile zurückgeben möchten. Zum Beispiel: Bereich: 100-200. Ich werde nicht auf die Feinheiten eingehen, Sie können alle Nuancen der Technologie in Fachartikeln finden. Ich denke, die Essenz ist klar.
Tatsächlich können Sie jetzt auf der Vorderseite einen Aufruf an den erforderlichen Teil der Datei organisieren, der beispielsweise Kerzen enthält. Und da genau bekannt ist, wie viele Bytes eine Kerze benötigt (56 Bytes), können wir den benötigten Offset leicht bestimmen. Es stimmt, wir müssen noch den Zeitpunkt kennen, ab dem der Zeitplan beginnt. Und dies lässt sich sehr einfach lösen, indem der Datei ein Header hinzugefügt wird, dessen Größe ebenfalls eine Konstante ist.
Das heißt, Zunächst greift die Front von der Nullposition auf die Datei zu und empfängt sie
Überschrift. Gleichzeitig gibt nginx die Dateigröße zurück. Dies bestimmt die Gesamtzahl der Kerzen in der Datei und die Startzeit.
Wenn wir nun den Startzeitpunkt kennen und eine klare Vorstellung von der Anzahl der Kerzen haben, können wir jede für einen beliebigen Zeitraum von vorne abrufen, ohne ein Backend zu verwenden.
Ah, ja ... ein weiterer Moment ... wir haben einen Parameter wie die Belichtung der Kerze. Auch hier ist die Lösung einfach: Wir halten mehrere Dateien gleichzeitig für unterschiedliche Belichtungen. Als zusätzlichen kleinen Bonus wird die Größe der Kerzenstruktur um weitere 4 Bytes reduziert.
Im Allgemeinen war die Lösung bereits interessant genug für die Implementierung, aber es stellte sich heraus, dass ich mich nicht schäme zu sagen - sehr coole Gewinne. Tatsache ist, dass Browser die von der Bereichsmethode empfangenen Daten zwischenspeichern können. Das heißt, Wenn dieser Abschnitt der Datei bei der nächsten Frontanforderung an den Server früher vom Browser empfangen wurde, wird er nicht auf Ihren Server übertragen, sondern aus dem Cache entfernt.
Aber auch das ist noch nicht alles. Mit CDN kann das Caching auch über seine Mittel konfiguriert werden. Das heißt, Zusammenfassend lässt sich sagen, dass Sie ein System erhalten können, das in der Lage ist, große Mengen des Marktdatums anzugeben und gleichzeitig die Belastung der Infrastruktur und der Server zu minimieren.
Natürlich gab es keinen Zweifel mehr an der Treue der Idee? Jetzt gibt es wirklich kleine Dinge ... Sie müssen die gleichen Dateien generieren.
Wie oben erwähnt, betreibt die Börse normalerweise zwei Arten der Lieferung des Marktdatums: REST und WEBSocket. Letzterer sendet online das aktuelle Marktdatum. Dies ist normalerweise ein separater Dienst. Wie die Praxis gezeigt hat, ist es nicht schwierig, diesen Dienst so abzuschließen, dass Daten an die erforderlichen Dateien angehängt werden, und wird buchstäblich mit ein paar Stunden Arbeit des Entwicklers gelöst. Wir können sagen, dass er sich gleichzeitig mit dem Newsletter anmeldet.
Das Problem der Übermittlung von Dateien an Knoten ist ein klassisches Problem bei der Synchronisierung des Dateisystems. Das DevOps-Team löst es einfach und natürlich. Zum Beispiel mit rsync.
Jetzt können wir sicher sagen - BINGO!
Vielleicht stellt sich die Frage: Warum funktionieren alle Krypto-Austausche anders? Ich habe keine verlässliche Antwort auf diese Frage. Aber es gibt Gedanken:
- Der Austausch wurde von sympathischen Krypto-Entwicklern erstellt. Vielleicht hatten sie keine Ahnung von der Arbeit des klassischen Austauschs, berücksichtigten ihre Erfahrungen nicht und verwendeten leicht verfügbare Lösungen, um schnelle Ergebnisse zu erzielen. Und dies sind Vorlagenlösungen: das gleiche REST und das dazugehörige JSON;
- wie sie in den Leuten sagen - Funktioniert es? Nicht anfassen. - Weil Technologische Trends wurden bereits von Schlüsselbörsen geschaffen, und neu entstehende Börsen haben sie ausgeliehen.
Wenn das Thema für die Community interessant ist, werde ich mit Artikeln über andere nicht standardmäßige Lösungen fortfahren, die in unserem Projekt implementiert wurden. Wie dies in der Praxis funktioniert, können Sie auf der Austausch-Website sehen (siehe mein Profil). Ich schlage besonders vor, auf die Arbeit des Diagramms zu achten, das alle Gewinne dieser Technologie klar zeigt.