Architecture
Clustron Zaris est un moteur de données clé-valeur distribué conçu pour les charges de travail à haut débit et faible latence dans les environnements microservices. Cette page est une visite de haut niveau du moteur — comment un nœud est assemblé et comment les nœuds forment un cluster — afin que vous puissiez raisonner sur l'endroit où vos opérations s'exécutent et sur les raisons du comportement du système.
Cette page visite le moteur à un niveau conceptuel. Pour une couverture riche en schémas et à jour du cluster — le gestionnaire et les nœuds, le partitionnement et la réplication, les modèles de déploiement, la sécurité et le TLS, la montée en charge et la console web — voir la section Architecture et exploitation.
Objectifs de conception
Clustron Zaris est une fondation de données distribuée, pas un simple cache. Sa structure découle d'un petit ensemble d'objectifs qui façonnent chaque couche en dessous :
- Une scalabilité horizontale, de sorte que vous ajoutez de la capacité en ajoutant des nœuds.
- Une séparation claire entre les responsabilités de contrôle et les responsabilités de données.
- Des composants internes du moteur extensibles qui évoluent sans réécriture.
- Des performances prévisibles sous charge.
- Une isolation au niveau de l'instance, de sorte que les instances n'interfèrent pas entre elles.
Architecture de Clustron Zaris
Chaque nœud s'exécute comme un processus indépendant et prend part à la coordination du cluster. Le reste de cette page procède de l'intérieur vers l'extérieur : d'abord la séparation entre contrôle et données, puis les composants à l'intérieur d'un nœud, puis la façon dont les nœuds forment un cluster.
Plan de contrôle et plan de données
Clustron Zaris sépare le travail de service des données du travail de gestion du cluster. Maintenir ces plans distincts est ce qui donne au système à la fois sa clarté opérationnelle et sa marge de montée en charge, car chaque plan peut être raisonné et ajusté de façon indépendante.
Plan de données
Le plan de données gère chaque requête qui touche à vos données. C'est le chemin que votre application sollicite à chaque opération, et il est optimisé pour le débit avant tout.
Il a la charge de :
- Les opérations clé-valeur (Get, Put, Delete)
- Les requêtes par préfixe
- Les abonnements d'observateurs (watch)
- L'application du TTL
- Les recherches dans les index
- L'exécution des requêtes
- Les primitives de bail et de verrouillage
- Les opérations de compteurs
Pour garder ce chemin rapide, le plan de données est optimisé pour le débit, une pression minimale sur le ramasse-miettes (garbage collection), un réseau asynchrone efficace et une sérialisation à faible surcoût.
Plan de contrôle
Le plan de contrôle gère le cluster lui-même plutôt que les données qu'il contient. Il s'exécute lorsque des stores et des instances sont créés, configurés et démantelés — pas à chaque requête.
Il a la charge de :
- La création de stores
- La gestion du cycle de vie des instances
- La configuration du cluster
- La gestion des ports
- L'isolation des instances
- Le démarrage et l'arrêt des nœuds
- Les modèles de configuration
Grâce à cette séparation, chaque instance Zaris s'exécute de façon indépendante, porte sa propre configuration, conserve une journalisation isolée et peut être déployée plusieurs fois par hôte.
À l'intérieur d'un nœud
Un seul nœud Clustron Zaris est construit à partir d'un ensemble de composants de moteur ciblés. Chacun possède une partie distincte du parcours d'une requête, ce qui permet au moteur de rester rapide et d'évoluer pièce par pièce.
Pipeline de requêtes
Le pipeline de requêtes est la porte d'entrée : il reçoit les requêtes des clients et les route vers le bon composant du moteur. Il est conçu pour l'efficacité des entrées/sorties asynchrones, un minimum de changements de contexte, la gestion de la contre-pression (backpressure) et une propagation structurée des erreurs, de sorte que le nœud reste réactif lorsque la charge grimpe.
Segment store
Le segment store est le moteur de stockage en mémoire de base — là où vos clés et valeurs vivent réellement. Il gère le partitionnement des clés, l'accès concurrent, la disposition des données et l'utilisation efficace de la mémoire. Son partitionnement par segments est l'idée clé : le travail est réparti sur des segments de sorte que de nombreuses opérations se déroulent de façon concurrente sans verrou global unique.
Index manager
L'index manager accélère les requêtes afin qu'elles ne retombent pas sur un balayage de chaque clé. Il fournit l'indexation par égalité, l'indexation par plage et des chemins de recherche efficaces, et il maintient ces index aux côtés du stockage primaire afin que les opérations de requête évitent les balayages complets.
Moteur d'expiration
Le moteur d'expiration applique le TTL. Il utilise un modèle inspiré de TimeWheel, qui planifie les expirations en temps O(1) et maintient le coût de nettoyage prévisible au lieu de le faire croître avec le nombre de clés. Cela évite le surcoût d'un minuteur par clé et les balayages coûteux, de sorte que les performances tiennent sous de grosses charges de travail avec TTL.
Moteur d'observateurs
Le moteur d'observateurs (watch) alimente les applications réactives en livrant les changements au fur et à mesure qu'ils surviennent. Il prend en charge les abonnements à des préfixes de clés, livre des événements lors des mutations, offre un instantané suivi d'événements en direct, et propage les événements dans l'ordre — la fondation pour construire des systèmes qui réagissent plutôt que de sonder.
Moteur de baux et de verrous
Le moteur de baux et de verrous fournit les primitives de coordination distribuée : les baux, l'acquisition de verrous, la coordination par expiration et la libération sûre. Ce sont les briques de base à partir desquelles s'assemblent les workflows de plus haut niveau — accès exclusif, élection de leader, présence.
Moteur de compteurs
Le moteur de compteurs maintient des compteurs distribués atomiques avec prise en charge de l'incrémentation, de la décrémentation, de la lecture et du TTL. Il est conçu pour les scénarios de métriques, de limitation de débit (throttling) et de coordination où de nombreux clients mettent à jour le même nombre de façon sûre.
Le modèle de cluster
Les nœuds Clustron Zaris forment un seul cluster logique. Le cluster est conçu de sorte que les opérations restent cohérentes à l'intérieur des frontières de propriété d'un nœud tandis que le système dans son ensemble monte en charge horizontalement.
Ses caractéristiques déterminantes sont :
- Une coordination pair à pair entre les nœuds
- Un routage des requêtes conscient des nœuds
- La détection de défaillances
- Un rééquilibrage à mesure que le cluster grandit ou rétrécit, piloté par la montée en charge élastique (
Add-ZrServer/Remove-ZrServer) - Un comportement de reconnexion configurable basé sur la priorité
Les clients sont des participants actifs de ce modèle. Chaque client maintient une liste de serveurs priorisée, une stratégie de délai de reconnexion et une gestion du basculement, de sorte qu'il puisse continuer à fonctionner à mesure que la disponibilité des nœuds change.
Déploiement multi-instance
Clustron Zaris prend en charge l'exécution de plusieurs instances sur une même machine. Chaque instance s'exécute sur son propre port, conserve une configuration et des journaux isolés, et peut être démarrée ou arrêtée indépendamment. Cela rend pratique le partitionnement des ressources, l'isolation des environnements et l'exécution de déploiements multi-tenants contrôlés sur du matériel partagé.
Réseau
La couche réseau est conçue pour des opérations asynchrones à haut débit, une utilisation efficace des sockets, des cycles de vie de connexion contrôlés et un basculement gracieux. Elle évite délibérément les couches d'abstraction superflues, car chaque couche supplémentaire sur le chemin de requête ajoute un surcoût que le moteur cherche à éliminer.
Philosophie de scalabilité
Clustron Zaris monte en charge horizontalement plutôt que verticalement. Ce choix guide le reste de la conception : conception de client sans état, comportement mémoire prévisible, surcoût de coordination contrôlé et extensibilité modulaire. Le moteur est structuré de sorte que de nouvelles capacités puissent être ajoutées sans retravailler le cœur — les directions prévues incluent des capacités de requête avancées, la recherche vectorielle et par similarité, la planification de travaux distribuée et des primitives distribuées supplémentaires.
Observabilité
Zaris est livré avec l'observabilité intégrée. Des métriques en direct par store et par nœud circulent via Watch-ZrStoreMetrics, le cluster rapporte sa propre santé, et le traçage distribué est disponible par store (New-ZrStore -Tracing) ou à la demande depuis un client (Enable-ZrTrace). Voir Surveillance pour le tableau opérationnel complet.
Principes de conception
L'architecture suit un ensemble cohérent de principes : la performance d'abord, la prévisibilité plutôt que l'abstraction, l'extensibilité sans réécrire le cœur du moteur, une séparation claire des responsabilités, la clarté opérationnelle et une ingénierie des systèmes distribués pragmatique.
État actuel
Clustron Zaris est en développement actif. La stabilisation du cœur du moteur et la documentation sont en cours. Une version publique open-source du cœur du moteur est prévue pour 2026 sous une Business Source License.