Lors de la refactorisation de notre crypto-échange, il a été décidé de revoir le concept de travailler avec une date de marché. Dans le cas classique, la date de marché est répartie de deux manières:
1. Interface REST;
2. Abonnement à la diffusion WEBSocket.
La méthode REST est souvent utilisée pour obtenir des données historiques, tandis que le WEBSocket envoie des informations en direct en ligne. Dans certains cas, WEBSocket n'est pas utilisé du tout et les mises à jour sont effectuées par des demandes régulières via REST.
Et il semble que tout le monde soit content. Mais, en y regardant de plus près, l'énorme surcharge d'un tel concept devient évidente. Leur gros repose sur REST. Pour assurer le fonctionnement de l'interface REST, nous devons créer un backend qui répond aux exigences des systèmes très chargés. Naturellement, ici, vous pouvez choisir différentes options de solution de PHP au Golang désormais à la mode.
Il est également nécessaire de créer une infrastructure hautement accessible, de mettre en œuvre des bagatelles telles que CI / CD pour les services, de fournir tout cela avec les bons spécialistes pour le développement, la maintenance, etc., etc.
Dans le même temps, c'est la date historique du marché qui occupe la majeure partie de l'espace disque. Il est généralement stocké dans la base de données. D'une part, cela nous permet de résoudre le problème du clustering, mais à des tailles critiques, cela devient une charge insupportable et pose des tâches non triviales pour l'équipe DevOps et les développeurs.
En général ... l'apparente simplicité et la cohérence de ce concept est brisée en une vie dure.
Séparément, vous devez noter la particularité de la date du marché. Il s'accumule toujours (grandit). C'est-à-dire dans la langue du programmeur de base de données, nous insérons et sélectionnons toujours. Mais pas divisible. C'est-à-dire merveilleuse fonctionnalité de base de données pour la systématisation, l'optimisation, etc. Les données stockées ne sont pas réclamées.
Une autre propriété importante d'une date de marché est sa structure clairement définie. Par exemple, une bougie dans un graphique n'a que huit paramètres:
1. Le moment du temps;
2. Exposition;
3. Le prix maximum;
4. Le prix minimum;
5. Prix d'ouverture;
6. cours de clôture;
7. Volume;
8. Prix moyen.
On peut en dire autant des offres.
Sur la base de ces conditions préalables, et également armé d'expérience, je suis rapidement arrivé à la conclusion qu'il est plus correct de considérer la date de marché comme un flux structuré.
Par exemple, un flux avec des bougies peut être considéré comme un tableau de structures binaires:
moment: int32
exposition: int32
min: float64
max: float64
open: float64
close: float64
volume: float64
average: float64Total: 56 octets.
Par exemple, une telle bougie en JSON sera décrite comme suit:
{ "date":1501004700, "high":0.08053391, "low":0.08020004, "open":0.08030001, "close":0.0803542, "volume":48.62169347, "weightedAverage":0.08038445 }
Total: 167 octets.
Le profit en taille est évident. Et c'est moins de trafic, une vitesse de livraison plus élevée pour le client.
Et ici, bien sûr, BSON me vient à l'esprit. Mais cela ne résout pas le problème de la nécessité d'un backend, et en général ne résout pas le problème fondamentalement. De plus, il n'est pas pris en charge nativement par les navigateurs.
J'ai regardé dans l'autre sens. Le réseau a beaucoup de ressources travaillant avec des threads. Ce sont des ressources audio et vidéo. Ils démontrent tous les signes nécessaires:
- travailler avec de grandes quantités de données;
- faire face parfaitement à des charges élevées;
- ils sont capables de fournir du contenu en ligne, mais en même temps ils permettent d'accéder à des données historiques.
Je suis allé un peu plus loin dans la vidéo en streaming, ce qui m'a permis de résoudre radicalement tous les problèmes ci-dessus par date de marché. Toute la magie, comme il s'est avéré, est cachée dans la technologie
Content-Range qui est prise en charge hors de la boîte, par exemple, Nginx. Il vous permet d'accéder à n'importe quelle zone d'une ressource statique (fichier sur le serveur) sans utiliser de backend. En général, cela se produit comme suit: vous vous référez à l'URL indiquant l'exposition que vous souhaitez retourner dans l'en-tête. Par exemple: plage: 100-200. Je ne m'attarderai pas sur les subtilités, vous pouvez trouver toutes les nuances de la technologie dans des articles spécialisés. Je pense que l'essence est claire.
En fait, maintenant, sur la face avant, vous pouvez organiser un appel à la partie nécessaire du dossier, par exemple, contenant des bougies. Et comme on sait exactement combien d'octets une bougie prend (56 octets), nous pouvons facilement déterminer le décalage dont nous avons besoin. Certes, nous avons encore besoin de connaître le moment à partir duquel le calendrier commence. Et cela est très facilement résolu en ajoutant un en-tête au fichier, dont la taille est également une constante.
C'est-à-dire tout d'abord, la face avant accède au fichier à partir de la position zéro et reçoit
titre. En même temps, nginx renverra la taille du fichier. Cela déterminera le nombre total de bougies dans le fichier et l'heure de début.
Maintenant, connaissant le point de départ, ayant une idée claire du nombre de bougies, nous pouvons obtenir n'importe laquelle d'entre elles pour n'importe quelle période de temps de l'avant, sans utiliser de backend.
Ah, oui ... un autre instant ... nous avons un paramètre tel que l'exposition de la bougie. Ici, la solution est également simple - nous conservons plusieurs fichiers à la fois pour différentes expositions. Comme petit bonus supplémentaire, la taille de la structure de la bougie est réduite de 4 octets supplémentaires.
En général, la solution était déjà suffisamment intéressante pour la mise en œuvre, mais elle s'est avérée pour le moment, je n'ai pas honte de le dire - des bénéfices très intéressants. Le fait est que les navigateurs peuvent mettre en cache les données reçues par la méthode range. C'est-à-dire lors de la prochaine demande préalable au serveur, si cette section du fichier a été reçue par le navigateur plus tôt, il n'atteindra pas votre serveur, mais le récupérera du cache.
Mais ce n'est pas tout. En utilisant CDN, la mise en cache peut également être configurée par ses moyens. C'est-à-dire en résumé, vous pouvez obtenir un système capable de fournir de gros volumes de la date du marché tout en minimisant la charge sur l'infrastructure et les serveurs.
Inutile de dire qu'il n'y avait plus de doute sur la fidélité de l'idée? Maintenant, il y a de vraies petites choses ... vous devez faire la génération de ces mêmes fichiers.
Comme mentionné ci-dessus, la bourse utilise généralement deux modes de livraison de la date de marché: REST et WEBSocket. Ce dernier diffuse en ligne la date actuelle du marché. Il s'agit généralement d'un service distinct. Comme la pratique l'a montré, la finalisation de ce service afin qu'il ajoute des données aux fichiers nécessaires n'est pas difficile et est résolue littéralement avec quelques heures de travail du développeur. On peut dire qu'il se connecte en même temps que la newsletter.
Le problème de la livraison de fichiers aux nœuds est un problème classique de synchronisation du système de fichiers. L'équipe DevOps le résout facilement et naturellement. Par exemple, en utilisant rsync.
Maintenant, nous pouvons dire en toute sécurité - BINGO!
Peut-être que la question se posera - pourquoi tous les échanges de crypto font-ils différemment? Je n'ai pas de réponse fiable à cette question. Mais il y a des pensées:
- les échanges ont été créés par des développeurs de crypto sympathiques. Peut-être qu'ils n'avaient aucune idée du travail des échanges classiques, n'ont pas pris en compte leur expérience et ont utilisé des solutions facilement disponibles pour obtenir des résultats rapides. Et ce sont des solutions de modèle: le même REST et le JSON qui l'accompagne;
- comme on dit chez les gens - ça marche? Ne touchez pas. - Parce que les tendances technologiques ont déjà été créées par des bourses clés et les bourses émergentes les ont empruntées.
Si le sujet est intéressant pour la communauté, je vais continuer avec des articles sur d'autres solutions non standard implémentées sur notre projet. Comment cela fonctionne dans la pratique, vous pouvez voir sur le site Web de l'échange (voir mon profil). Je propose surtout de prêter attention au travail de la charte, qui démontre clairement tous les bénéfices de cette technologie.