Expérience VonmoTrade. Partie 3: Livre des mandats. Traitement et stockage des informations commerciales

Dans le dernier article du cycle, nous nous sommes familiarisés avec les types d'ordres de change. Aujourd'hui, nous analyserons le livre des commandes, le traitement des demandes et les questions liées à l'organisation du stockage des informations commerciales.

Offre et demande

Vous vous souvenez sûrement de la loi de l'offre et de la demande au cours de l'économie, qui montre la mécanique du marché pour la formation des prix:

La même mécanique travaille sur les échanges.

Le carnet de commandes est une liste dans laquelle les commandes limitées des vendeurs et des acheteurs sont saisies, montrant ainsi l'intérêt actuel pour un instrument financier particulier.

Si vous convertissez le graphique précédent par rapport au carnet de commandes, vous obtenez quelque chose comme ceci:

Nous voyons ici que le prix du marché est obtenu lorsque le prix de demande maximum et le prix d'offre minimum sont égaux. L'écart est la différence entre ces prix. Il s'agit d'un indicateur important, car il est associé à la liquidité de l'instrument. Plus l'écart est petit, plus l'instrument est liquide. Pour assurer la liquidité dans le cadre des échanges, ils imposent souvent une limite à l'écart maximum, au-dessus duquel les échanges peuvent être interrompus.

Création d'applications

Considérez le cycle de vie d'une demande depuis l'admission à l'échange jusqu'à son exécution ou son annulation. Pour simplifier, nous considérerons le cas du marché des changes. Un processus spécial est responsable de la logique de traitement des ordres, appelons-le contrôleur de marché.

Ainsi, le participant crée une application, il arrive à l'échange. Le responsable du traitement doit s'assurer que le participant dispose de suffisamment de liquidités pour créer le type d'ordre demandé. La source d'informations peut être un service de comptabilité interne ou toute API externe.

Pour l'exécution immédiate de cette application, une contre-application dite appariée doit exister sur le marché.

S'il y a un contre-ordre, de la paire trouvée, le plus petit ordre est exécuté en totalité et le plus grand en partie. Bien sûr, si une exécution partielle est autorisée par les instructions de trading de l'application. En l'absence de contre-commande, une nouvelle commande entre dans le carnet de commandes et prend sa place dans la liste des commandes de son type.

Étant donné que seules les commandes en attente entrent dans le carnet de commandes, pour les commandes d'autres types, vous devez sélectionner vos listes.

Dans toutes les listes de commandes, le côté achat doit être trié par ordre décroissant et le côté vente doit être trié par ordre croissant. Le premier élément de la liste des ordres à cours limité pour chaque côté constitue respectivement le meilleur prix de l'offre et de la demande.

Un autre point important est l'ordre d'exécution. Le contrôleur doit implémenter FIFO. Par conséquent, si les prix des deux offres coïncident, l'offre créée précédemment devrait être plus élevée.

Dans l'interface utilisateur, le livre ressemble à un tableau composé d'un ensemble de niveaux de prix, qui présente des ordres à cours limité pour l'achat et la vente.

Pour une distinction visuelle supplémentaire, les demandes de vente et d'achat ont des couleurs différentes.

Agrégation de niveaux

Profondeur du livre - Le nombre de niveaux de prix. Pour les marchés actifs avec un grand nombre d'ordres en attente, séparés par une distance minimale, la profondeur peut être très grande pour être affichée dans le terminal du trader. Pour évaluer l'ensemble du livre, vous avez besoin d'un outil de mise à niveau.

En coupant une décimale et en regroupant les niveaux, nous pouvons réduire leur nombre à chaque étape.

Exécution et annulation des candidatures

Une fois la commande dans le livre exécutée ou annulée, le responsable du traitement doit mettre à jour le livre en supprimant cette commande et en informant toutes les personnes intéressées par les modifications du livre.

Architecture et mise à l'échelle du gestionnaire

Compte tenu des performances et de la fiabilité requises, il est nécessaire de déterminer des approches pour faire évoluer les applications et les systèmes de stockage.

En règle générale, les échanges utilisent une mise à l'échelle verticale. Le code de traitement des applications et des comptes d'utilisateurs est exécuté sur une seule machine dans un seul monolithe. Une telle approche montre de bonnes performances, mais a une limitation importante - dans tous les cas, la mise à l'échelle verticale a une limite, à la fois en termes de puissance du processeur et de capacité de stockage.

Dans le cadre de l'expérience, j'ai décidé que le traitement du marché devrait évoluer horizontalement. Chaque outil individuel est traité par son propre processus. Les processus sont répartis automatiquement entre les nœuds de cluster. En cas d'échec, le marché est transféré vers un autre nœud sans perte de statut.

La formule du système est extrêmement simple: M gestionnaires sont répartis sur K nœuds du cluster et utilisent L stockages de données.
Un schéma similaire vous permet de faire évoluer le système à environ 150 nœuds. Et chaque contrôleur de marché peut gérer environ 30 000 RPS.

Étant donné que le flux d'applications sur tous les marchés est différent et dépend de l'activité des utilisateurs, les marchés peuvent être divisés en plusieurs groupes: petits, moyens et grands. Chaque nœud a des paramètres qui vous permettent de spécifier des limites sur le nombre de marchés qu'il peut traiter. L'assistant répartit automatiquement et uniformément les marchés du même type entre les nœuds de cluster. En cas de modification de la composition des clusters, les marchés sont redistribués. Ainsi, une distribution plus ou moins uniforme de la charge sur le système est obtenue.

Un exemple de vue des nœuds dans l'interface de gestion des échanges:

Stockage de données

Le carnet de commandes est en constante évolution et doit être conservé en mémoire. Pour MVP, j'ai choisi Tarantool avec WAL comme stockage en mémoire. Toutes les données historiques seront enregistrées dans PostgreSQL.

Le schéma de stockage des données actuelles et historiques doit correspondre au schéma sélectionné pour la mise à l'échelle du code des gestionnaires. Chaque marché peut utiliser ses propres postgres et tarantool. Pour ce faire, combinez la paire de postgresql et tarantool en une seule entité - un entrepôt de données de marché.

Lors de la mise en place du marché, l'administrateur a la possibilité de gérer des référentiels. Pour maintenir la flexibilité, au lieu d'accéder à des instances spécifiques de postgresql et tarantool, nous spécifierons un identifiant de pool de connexions unique. L'interface de ces pools est prise en charge par la plateforme. Ainsi, le référentiel dans l'interface d'administration ressemble à ceci:

Lors de la configuration d'un marché, l'administrateur doit spécifier au moins un magasin pour chaque marché. Si vous en spécifiez quelques-uns, vous obtenez un marché avec une réplication logique des données. Cette fonctionnalité vous permet de configurer la fiabilité et les performances d'un schéma de stockage.

Données du carnet de commandes

Tarantool utilise l'espace pour organiser les données stockées. La déclaration des espaces requis pour le carnet de commandes est la suivante:

book = { state = { name = 'book_state', id = 1, }, orders = { limit = { buy_orders = { name = 'limit_buy_orders', id = 10, }, sell_orders = { name = 'limit_sell_orders', id = 20, }, }, market = { buy_orders = { name = 'market_buy_orders', id = 30, }, sell_orders = { name = 'market_sell_orders', id = 40, }, }, ... }, orders_mapping = { name = 'orders_mapping', id = 50, }, } 

Étant donné que plusieurs marchés peuvent stocker leurs données sur une seule instance de tarantool, nous ajouterons un identifiant de marché à toutes les entités. La mise en œuvre actuelle du livre est construite sur le principe de compter une fois, de donner plusieurs fois. Lors des opérations de mise à jour des livres, les regroupements sont automatiquement recomptés. Par exemple, nous ajoutons une commande au marché, la précision des prix est de 6, il existe 6 groupes de prix possibles + une tranche avec les données de commande d'origine qui doivent être mises à jour.

Il existe de nombreuses commandes Orders_Mapping pour émettre des listes de commandes client actives.

Grâce au modèle de données tarantool, utilisant une combinaison d'indices et de divers itérateurs d'échantillonnage, le code lua qui implémente le stockage du carnet de commandes ne prend que 600 lignes (avec l'initialisation).

Données historiques

Les données du marché sont stockées dans des tableaux séparés pour chaque marché. Considérons un ensemble de tables de base.

Historique des candidatures complétées

Pour enregistrer les résultats du traitement des demandes, utilisez la table d'historique. Il comprend les demandes entièrement remplies, ainsi que les demandes annulées, mais partiellement complétées.

 CREATE TABLE public.history ( id uuid NOT NULL, ts timestamp without time zone NOT NULL DEFAULT now(), owner character varying(75) COLLATE pg_catalog."default" NOT NULL, order_type integer NOT NULL, order_side integer NOT NULL, price numeric(64,32) NOT NULL, qty numeric(64,32) NOT NULL, commission numeric(64,32) NOT NULL, opts jsonb NOT NULL, CONSTRAINT history_pkey PRIMARY KEY (id, ts) ) 

Sur sa base, l'émission pour les utilisateurs finaux est basée sur l'historique de leurs offres.

Flux de données historiques

À des fins d'analyse, ainsi que pour la formation d'un flux de données historiques, après chaque transaction, le contrôleur de marché doit enregistrer des informations sur cet événement. Pour corriger les événements de changements du marché, utilisez le tableau des ticks:

 CREATE TABLE public.ticks ( ts timestamp without time zone NOT NULL, bid numeric(64,32) NOT NULL, ask numeric(64,32) NOT NULL, last numeric(64,32) NOT NULL, bid_vol numeric(64,32), ask_vol numeric(64,32), last_vol numeric(64,32), opts jsonb DEFAULT '{}'::jsonb, CONSTRAINT ticks_pk PRIMARY KEY (ts) ) 

Il stocke les prix et les volumes du marché après la transaction, et le champ opts contient des informations de service, telles qu'une description des commandes impliquées dans la transaction.

Flux de données du graphique

Pour construire des graphiques de trading, le tableau des ticks suffit. Il contient ce que l'on appelle le flux brut, mais postgresql possède de puissantes fonctions analytiques et vous permet d'agréger des données à la demande.

Les problèmes commencent lorsqu'il y a trop de données et qu'il n'y a déjà pas assez de puissance. Pour résoudre, créez un tableau avec des données pré-calculées:

 CREATE TABLE public.df ( t timestamp without time zone NOT NULL, r df_resolution NOT NULL DEFAULT '1m'::df_resolution, o numeric(64,32), h numeric(64,32), l numeric(64,32), c numeric(64,32), v numeric(64,32), CONSTRAINT df_pk PRIMARY KEY (t, r) ) 

Nous expliquerons comment travailler avec des séries chronologiques dans Postgresql, préparer des données pour la table df et comment créer des graphiques dans le prochain article.

Résumé

Nous avons compris les principaux points de l'organisation du livre des commandes et du mécanisme de traitement des commandes, ainsi qu'un peu plongé dans la pratique du travail avec les données du marché.

Le schéma de stockage sélectionné vous permet de partir d'un magasin pour tous les marchés et, à mesure que le projet se développe, de répartir les marchés dans différents magasins, en les plaçant le plus près possible des processeurs de marché.