Vous souhaitez obtenir une réplication efficace des données ? Paxos n'est pas toujours le meilleur choix !

Les algorithmes typiques de réplication de données sont Paxo et Raft.

1 Stockage des métadonnées de fragment

Dans le système de stockage distribué, après avoir reçu la demande du client, le nœud qui exécute la fonction de routage :

Accédez d'abord aux métadonnées du fragment (métadonnées en abrégé) et déterminez le nœud correspondant du fragment
avant d'accéder aux données réelles

Les métadonnées incluent généralement des informations telles que la plage de données, le volume de données, le trafic de lecture et d'écriture, les nœuds physiques sur lesquels se trouve la copie de la partition et l'état de la copie de la partition.

Du point de vue du stockage, les métadonnées sont également des données, mais la particularité est que chaque demande doit y accéder, de sorte que le stockage des métadonnées peut facilement devenir le goulot d'étranglement des performances de l'ensemble du système et le défaut d'une grande fiabilité. Si le système prend en charge le partitionnement dynamique, les fragments doivent être automatiquement divisés, fusionnés et déplacés entre les nœuds. Les métadonnées changent constamment, ce qui pose le problème de la cohérence multi-copies (Consensus).

Voyons comment différents produits stockent les métadonnées.

1.1 Fragmentation statique

Le cas le plus simple. Le problème des changements de métadonnées peut être ignoré, tant que plusieurs copies de métadonnées sont placées sur les nœuds de travail correspondants, en tenant compte des performances et de la haute fiabilité. TBase suit à peu près cette idée et stocke directement les métadonnées dans le nœud de coordination. Même si le nœud de coordination est un nœud de travail, à mesure que l'échelle du cluster s'étend, il y aura trop de copies de métadonnées.Cependant, étant donné que le partage de hachage est essentiellement un partage statique, il n'est pas nécessaire de prendre en compte la question de la cohérence multicopie.

Cependant, cela n'est évidemment pas adapté à la mise à jour des informations de partition, car il y a trop de copies et le coût de la synchronisation des données est trop élevé. Par conséquent, pour le partitionnement dynamique, les métadonnées ne sont généralement pas stockées sur des nœuds avec des charges de travail.

Comment concevoir ? Créez spécialement des clusters à petite échelle pour les métadonnées et utilisez le protocole Paxos pour répliquer les données. Une grande fiabilité est garantie et le coût de la synchronisation des données est également faible.

TiDB pense à peu près de cette façon.

1.2 TiDB : aucun état de service

Nœud TiKV : le nœud qui stocke réellement les données fragmentées

Nœud de pilote de placement : gérez les métadonnées. Le nom Placement Driver vient du rôle de nœud correspondant dans Spanner, appelé PD.

Lors de la communication entre PD et TiKV, PD est complètement passif :

Les nœuds TiKV signalent régulièrement les battements de cœur aux PD, et les informations de métadonnées des fragments sont signalées avec les battements de cœur.
PD place l'instruction de planification de fragment dans les informations de retour du battement de cœur
Lorsque TiKV signalera le battement de cœur la prochaine fois, le PD pourra connaître l'état d'exécution de la planification

Étant donné que chaque battement de cœur TiKV contient une quantité complète de métadonnées de partition, PD peut même être transformé en un service sans état sans placer de métadonnées de partition. L'avantage est que le nouveau maître élu après la panne du PD n'a pas besoin de gérer la connexion d'état avec l'ancien maître et peut fonctionner après un cycle de pulsation. En termes de mise en œuvre, PD conservera toujours certaines informations, qui peuvent être considérées comme une sorte de cache.

processus de communication

Lorsque les trois nœuds TiKV signalent un battement de cœur à chaque fois, la copie principale (Leader) fournit les métadonnées du fragment, et le PD peut obtenir la quantité complète d'informations sans redondance.

Bien que les services sans état présentent de grands avantages, PD est toujours un point unique, c'est-à-dire que la solution est toujours une idée de conception centralisée et qu'il peut y avoir des problèmes de performances.

Existe-t-il une conception complètement "décentralisée" ? Oui, regardez CockroachDB avec l'architecture P2P.

1.3 CockroachDB : Décentralisé

CockroachDB utilise le protocole Gossip. L'essence du protocole Paxos est un mécanisme de diffusion, où un nœud central envoie des messages à d'autres nœuds. Lorsque le nombre de nœuds est important, le coût de communication est élevé.

CockroachDB adopte l'architecture P2P, et chaque nœud enregistre des métadonnées complètes, donc l'échelle du nœud est très grande, et bien sûr le mécanisme de diffusion n'est pas applicable. Le principe du protocole Gossip est un mécanisme de diffusion de rumeurs, chaque fois qu'une rumeur se propage dans un petit périmètre de quelques personnes, elle finira par devenir une rumeur connue de tous. La cohérence des données ainsi obtenue est la "cohérence finale", c'est-à-dire qu'après l'exécution d'une opération de mise à jour des données, après un certain laps de temps, les données stockées dans chaque nœud du cluster finiront par parvenir à un consensus.

Les bases de données distribuées sont fortement cohérentes, et maintenant nous avons des métadonnées avec une cohérence finale, d'accord ?

CockroachDB est en réalité une base de données distribuée qui implémente une cohérence forte basée sur des métadonnées de "cohérence finale" .

Le nœud A reçoit la requête SQL du client et souhaite interroger les enregistrements de la table de données T1. Selon la plage de clés primaires, il est déterminé que les enregistrements peuvent se trouver sur la partition R1 et les métadonnées locales indiquent que R1 est stocké au nœud B.
Le nœud A envoie une requête au nœud B. Malheureusement, les métadonnées du nœud A sont obsolètes et R1 a été réaffecté au nœud C.
À ce moment, le nœud B répondra au nœud A avec des informations importantes, et R1 sera stocké dans le nœud C
Une fois que le nœud A a obtenu les informations, il envoie à nouveau une demande de requête au nœud C. Cette fois, heureusement, R1 est bien dans le nœud C
Le nœud A reçoit R1 renvoyé par le nœud C.
Le nœud A renvoie l'enregistrement sur R1 au client et met à jour les métadonnées locales en même temps.

CockroachDB mettra à jour en permanence les métadonnées du fragment pendant le processus d'adressage pour faciliter le consensus des métadonnées de chaque nœud.

1.4 Résumé

Le choix du protocole de réplication a beaucoup à voir avec le nombre de copies de données :

Il y a peu de copies et peu de nœuds participants, et des méthodes de diffusion peuvent être utilisées, c'est-à-dire des protocoles tels que Paxos et Raft
S'il y a de nombreuses copies et de nombreux nœuds, il est plus approprié d'adopter le protocole Gossip

2 Efficacité de la réplication

C'est la différence d'efficacité entre Raft et Paxos et l'optimisation de Raft.

Les bases de données distribuées utilisent rarement le protocole Paxos, et le seul produit bien connu est OceanBase, donc l'analyse des différences suivante est basée sur Raft.

2.1 Défauts de performance du Raft

Dans les articles comparant Paxos et Raft, il est mentionné que l'efficacité de réplication de Raft est légèrement inférieure.La raison principale est que Raft doit "voter séquentiellement" et que les trous dans le journal ne sont pas autorisés. Le vote séquentiel est en effet un facteur clé affectant l'efficacité de réplication de l'algorithme Raft.

Pourquoi le "vote séquentiel" a-t-il un si grand impact sur les performances ?

2.2 Processus de réplication du journal Raft

Le leader reçoit la demande du client
Le responsable ajoute (Append) le contenu de la demande (c'est-à-dire l'entrée de journal) au journal local
Le leader envoie une entrée de journal à d'autres suiveurs
Le leader attend le résultat du suiveur. Si la plupart des nœuds soumettent le journal, l'entrée du journal est une entrée validée et le leader peut l'appliquer (appliquer) à la machine d'état locale.
Leader renvoie le client pour qu'il soumette avec succès.
Leader continue de traiter la demande suivante.

Ce qui précède est l'opération d'une seule transaction. Qu'en est-il lorsque plusieurs transactions fonctionnent en parallèle ?

On suppose que ce groupe Raft est composé de 5 nœuds, et T1 à T5 sont 5 opérations transactionnelles qui se sont produites successivement et ont été envoyées à ce groupe Raft.

L'opération de la transaction T1 consiste à définir X sur 1, les 5 nœuds Append avec succès, le nœud Leader Apply à la machine d'état locale et à renvoyer le client pour qu'il se soumette avec succès. Lorsque la transaction T2 est exécutée, bien qu'il y ait un suiveur qui ne réponde pas, il obtient toujours une réponse réussie de la plupart des nœuds, donc il renvoie également le client pour qu'il se soumette avec succès.

Maintenant, c'est au tour de la transaction T3 de s'exécuter, et pas plus de la moitié des réponses ont été reçues. A ce moment, le Leader doit attendre un signal clair d'échec, tel qu'un timeout de communication, avant de terminer l'opération. En raison des règles de vote séquentiel, T3 bloquera la progression des transactions ultérieures. Il est raisonnable que la transaction T4 soit bloquée car elle opère sur le même élément de données que T3, mais l'élément de données à exploiter par T5 n'a rien à voir avec T3 et est également bloqué. Évidemment, ce n'est pas la stratégie optimale de contrôle de la concurrence. .

La même situation se produira également sur le nœud suiveur. Le premier nœud suiveur peut ne pas recevoir le journal de la transaction T2 pour des raisons de réseau. Même s'il reçoit le journal de T3 en premier, il n'effectuera pas l'opération d'ajout, car cela entraînera la bûche semble creuse.

Le vote séquentiel en radeau est un compromis de conception Bien que les performances aient un certain impact, la comparaison des journaux entre les nœuds est simple. Sur deux nœuds, tant qu'un journal est trouvé cohérent, tous les journaux avant ce journal sont cohérents. Cela rend très pratique pour le leader élu de synchroniser les données avec le suiveur, et il est plus facile d'ouvrir l'opération de lecture du suiveur. Les opérations de lecture des suiveurs qui garantissent la cohérence peuvent décharger efficacement la pression d'accès des opérations de lecture.

2.3 Méthode d'optimisation des performances des radeaux (TiDB)

Dans l'implémentation, la copie maîtresse de Raft ne se contente pas de traiter les requêtes une par une, mais est optimisée.

** Opération par lots (Batch). ** Leader met en cache plusieurs demandes de clients, puis envoie ce lot de journaux à Follower par lots. L'avantage de Batch est le coût de communication réduit
**Pipeline. ** Le leader ajoute localement une variable (appelée NextIndex). Après l'envoi de chaque lot, NextIndex est mis à jour pour enregistrer la position du lot suivant, puis le lot suivant est envoyé immédiatement sans attendre le retour du suiveur. S'il y a un problème avec le réseau, le Leader réajuste le NextIndex et envoie à nouveau le Batch. Bien sûr, la prémisse de cette stratégie d'optimisation est que le réseau est fondamentalement stable
** Journal d'ajout parallèle (Append Log Parallelly). **Lorsque le leader envoie le lot au suiveur, il exécute simultanément l'opération Append locale. Étant donné que Append est une opération de disque, la surcharge est relativement élevée. Dans le processus standard, Follower et Leader Append sont exécutés séquentiellement, ce qui prend bien sûr plus de temps. Passer en parallèle peut réduire une partie de la surcharge. Bien sûr, les règles de jugement pour l'entrée engagée doivent également être ajustées à ce moment. En fonctionnement parallèle, même si le leader ne s'ajoute pas avec succès, tant que plus de la moitié des nœuds suiveurs s'ajoutent avec succès, il peut toujours être considéré comme une entrée validée et l'entrée peut être appliquée
** Journal des applications asynchrones (Asynchronous Apply). **Apply n'est pas une condition nécessaire pour une soumission réussie, et toute entrée de journal dans l'état Committed est garantie de ne pas être perdue. Appliquer sert uniquement à s'assurer que l'état pourra être lu correctement la prochaine fois, mais dans la plupart des cas, les données soumises ne seront pas lues immédiatement. Par conséquent, Apply peut être converti en exécution asynchrone et, en même temps, l'opération de lecture coopère avec la transformation.

CockroachDB et certaines bibliothèques Raft effectuent également des optimisations similaires. Par exemple, SOFA-JRaft implémente également l'optimisation Batch et Pipeline.

etcd, la première implémentation open source au niveau de la production du protocole Raft, TiDB et CockroachDB empruntent à sa conception. Ils choisissent Raft car etcd fournit une implémentation technique fiable, tandis que Paxos n'a pas la même implémentation technique fiable. Puisqu'il est open source, pourquoi ne pas l'utiliser directement ? Comme etcd est un seul groupe Raft, les performances d'écriture sont limitées. Par conséquent, TiDB et CockroachDB ont été transformés en groupes multi-Raft, Multi Raft, et toutes les bases de données distribuées utilisant le protocole Raft sont Multi Raft. Cette conception permet à plusieurs groupes de fonctionner en parallèle, évitant dans une certaine mesure les défauts de performance de Raft.

La taille du groupe Raft correspond à la taille de la partition. Plus la partition est petite, plus la probabilité de blocage des transactions est faible. Le sharding par défaut de TiDB est de 96M, et le sharding de CockroachDB ne dépasse pas 512M. Les fragments TiDB plus petits sont de meilleures conceptions ? Pas nécessairement, un fragment trop petit augmentera le coût des opérations de numérisation, ce qui est également un gros compromis.

3 résumé

Le stockage de métadonnées fragmentées est la conception clé des bases de données distribuées, qui doivent répondre à des exigences de performance et de haute fiabilité. Le partitionnement statique est relativement simple et peut être mis en œuvre directement via le déploiement distribué de plusieurs copies.
Le partitionnement dynamique, tout en satisfaisant une fiabilité élevée, doit également tenir compte de la cohérence de plusieurs copies de métadonnées, et un protocole de réplication approprié doit être sélectionné. Si vous créez un cluster de métadonnées indépendant à petite échelle, vous pouvez utiliser des protocoles tels que Paxos ou Raft, et la fonctionnalité de propagation est diffusée. Si les métadonnées existent sur les nœuds de travail et que la quantité est importante, le protocole Gossip peut être envisagé et la caractéristique de propagation est la propagation de rumeurs. Bien que Gossip soit la cohérence finale, grâce à une conception ingénieuse du processus d'adressage, il peut également répondre aux fortes exigences de cohérence des données distribuées.
Paxos et Raft sont des protocoles de réplication largement utilisés, également connus sous le nom d'algorithmes de consensus, qui sélectionnent dynamiquement le maître par vote, ce qui peut garantir une fiabilité et une cohérence élevées entre plusieurs copies. L'algorithme Raft a la contrainte du "vote séquentiel", ce qui peut provoquer un blocage inutile et entraîner des pertes supplémentaires, et ses performances sont légèrement inférieures à celles de Paxos. Cependant, etcd fournit une excellente implémentation technique, qui favorise une utilisation plus large de Raft, et l'émergence d'etcd a des raisons internes pour que l'algorithme Raft soit facile à comprendre.
Les produits de bases de données distribuées ont optimisé Raft dans une certaine mesure. De plus, la conception Multi Raft est utilisée pour réaliser plusieurs groupes de parallélisme, puis en contrôlant la taille des fragments, la probabilité de blocage des transactions est réduite et les performances globales sont améliorées. .

Cela dit, revenons à notre question initiale, pourquoi Paxos n'est-il pas parfois le meilleur choix ? L'une est la raison de la conception de l'architecture.En fonction de l'échelle des nœuds participant à la réplication, si l'échelle est trop grande, il n'est pas approprié d'utiliser Paxos, et il n'est pas non plus adapté à d'autres algorithmes de consensus. La seconde est la raison de la mise en œuvre de l'ingénierie. Dans le scénario où l'algorithme de consensus est applicable, dois-je choisir Raft ou Paxos ? Parce que Paxos n'a pas d'implémentation open source de haute qualité et que Raft a une bonne implémentation technique d'etcd, Raft a été plus largement utilisé. La raison sous-jacente ici est que l'algorithme Paxos lui-même est trop complexe.Jusqu'à présent, il existe de plus en plus de projets open source stables implémentant le protocole Raft que Paxs.

En ce qui concerne le stockage des métadonnées de fragments, à mon avis, TiDB et CockroachDB ont des méthodes de traitement élégantes, mais la solution de TiDB est toujours basée sur le point central de PD. Le déploiement régional a certaines limites.

En ce qui concerne la méthode d'optimisation de Raft, l'idée principale est le parallélisme et l'asynchronisation. En fait, c'est aussi une méthode souvent utilisée dans l'ensemble du système distribué. Nous verrons des cas similaires dans l'optimisation des protocoles atomiques dans la leçon 10.

4 FAQ

Enfin, il est temps pour les questions de réflexion d'aujourd'hui. Nous avons mentionné dans la première conférence que les bases de données distribuées ont des capacités de stockage massives, alors devinez quoi, y a-t-il une limite supérieure à cette quantité massive ? En d'autres termes, selon vous, quels facteurs limiteront la capacité de stockage des bases de données distribuées ? Vous êtes invités à laisser un message dans la zone de commentaires pour discuter avec moi, et je répondrai à cette question dans la section Q&R.

Entendez-vous souvent des amis autour de vous discuter de problèmes liés à la réplication de données, et les conclusions tirées peuvent être erronées ? Si tel est le cas, j'espère que vous pourrez partager la conférence d'aujourd'hui avec lui, afin que nous puissions comprendre correctement ce qu'est la réplication de données dans une base de données distribuée.

Le goulot d'étranglement de la base de données distribuée peut être :

Métadonnées, trop de métadonnées, plusieurs couches de recherche peuvent être nécessaires pour trouver le nœud de données
Paquets de pulsation, s'il y a trop de nœuds dans le réseau, les paquets de pulsation occuperont également une quantité considérable de bande passante, affectant les performances d'E/S

Je pense que la limite supérieure de la capacité est principalement limitée par le scénario d'entreprise.Afin d'améliorer les performances, la fragmentation doit être ajoutée.Cependant, après plus de fragmentation, afin de répondre aux exigences de cohérence, trop de nœuds affecteront le coût de communication et réplication des données Un compromis entre ces deux aspects est Déterminer la limite supérieure de capacité ?

Cette idée est très bonne. L'augmentation de la taille du cluster peut ne pas affecter l'entreprise locale, car la fragmentation et les nœuds de l'entreprise locale peuvent ne pas augmenter. Cependant, toutes les entreprises ont accès aux métadonnées et elles seront affectées par l'augmentation de l'échelle.

Un groupe de radeaux stocke plusieurs copies d'une région. Par exemple, le nombre de copies par défaut de TiDB est 3, donc un groupe Raft a 3 copies. Dans le même temps, un nœud peut avoir des milliers de régions (généralement ces régions ne sont pas des copies les unes des autres), et chaque région appartient à un groupe de radeaux, ce qui signifie que ce nœud peut participer à des milliers de groupes de radeaux. Chaque groupe de radeau élira un nœud en tant que chef de radeau responsable de l'écriture des données.

Fondamentalement correct, permettez-moi de vous le rappeler à nouveau. Les données entre les régions sont différentes, il n'y a donc en aucun cas de relation maître-copie entre les régions.

L'article compare les algorithmes Gossip et Raft/Paxos. Pouvez-vous expliquer si le temps de consensus Gossip est plus court, pourquoi TiDB et d'autres bases de données ne le choisissent pas ? Pourquoi est-ce mieux pour les nœuds multiples ? Est-ce parce qu'il répartit les E/S réseau sur plusieurs nœuds ? Mais cela amène aussi une certaine sérialité !
BTW, Gossip est-il plus rapide que Raft et Paxos pour parvenir à un consensus ?

Gossip n'est pas plus rapide à faire consensus que Raft, CRDB le choisit car ce n'est pas un mécanisme de diffusion. Cependant, l'échelle des nœuds est très grande car le coût de communication du mécanisme de diffusion est trop élevé. Les nœuds de métadonnées de TiDB et d'autres bases de données sont petits, donc Raft convient

Si les informations de fragmentation sont gérées par un seul nœud, cette base de données distribuée aura un goulot d'étranglement, mais ce n'est pas un goulot d'étranglement de stockage (comme bigtable, comme une table de pages à plusieurs niveaux, qui peut stocker jusqu'à 2^61 octets de données) , mais un goulot d'étranglement d'accès (bien sûr, il doit être testé), mais c'est à cause du goulot d'étranglement d'accès que le stockage des données peut avoir une limite supérieure, mais si c'est comme une clé, chaque base de données distribuée est considérée comme un serveur clé , puis une couche est construite, tout comme une zone Pour gérer le serveur clé, puis une autre couche pour gérer la zone, il semble donc qu'elle puisse être étendue à l'infini. Bien sûr, c'est facile à dire, mais c'est trop difficile faire. De plus, pour que les rumeurs diffusent des informations sur la fragmentation du cluster dans l'architecture sans maître, tout comme le cluster Redis, je pense que le goulot d'étranglement est que chaque machine doit stocker toutes les informations de fragmentation. C'est aussi un facteur limitant.

Comment CockroachDB détermine-t-il que les métadonnées du fragment R1 ont expiré ? horodatage global ?

L'horodatage global semble incapable de résoudre ce problème. R1 expire car il ne correspond pas au stockage de données réel, et le nœud qui transportait à l'origine R1 enregistrera les allées et venues de R1 et pourra être acheminé à nouveau

L'emplacement de la table racine de hbase est placé sur zk, la table racine trouve la table méta, puis trouve la table de région. Cette méthode semble être différente de ce que l'enseignant a dit. Hbase n'est pas une base de données distribuée, elle peut donc être implémentée différemment ?

zk est également un petit cluster qui garantit un stockage de données hautement fiable, tout comme etcd.