Cet article vous apporte une introduction détaillée (images et textes) sur le journal de base du système distribué. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.
Qu'est-ce qu'un journal ?
Un journal est une séquence d'enregistrements complètement ordonnée ajoutée par ordre chronologique. Il s'agit en fait d'un format de fichier spécial. Le fichier est une section de mots. tableau, et le journal ici est un enregistrement de données, mais par rapport au fichier, chaque enregistrement ici est classé par ordre relatif de temps. On peut dire que le journal est le modèle de stockage le plus simple, et la lecture se fait généralement de gauche à droite. à droite, comme une file d'attente de messages, le fichier journal est généralement écrit de manière linéaire et le consommateur lit séquentiellement à partir du décalage.
En raison des caractéristiques inhérentes du journal lui-même, les enregistrements sont insérés séquentiellement de gauche à droite, ce qui signifie que les enregistrements de gauche sont "plus anciens" que les enregistrements de droite, ce qui signifie que nous n'avons pas besoin Pour s'appuyer sur l'horloge système, cette fonctionnalité est très importante pour les systèmes distribués.
Application du journal
Application de la base de données de connexion
Le journal est Impossible de savoir quand il apparaîtra. Il se peut que le concept soit trop simple. Dans le domaine de la base de données, les journaux sont davantage utilisés pour synchroniser les données et les index lorsque le système tombe en panne, comme le journal redo dans MySQL. Le journal redo est une structure de données basée sur le disque utilisée pour garantir l'exactitude et l'exhaustivité des données lorsque le système se bloque. Le système est également appelé journaux à écriture anticipée. Par exemple, lors de l'exécution d'une chose, le journal redo sera écrit en premier, puis les modifications réelles seront appliquées de cette façon, lorsque le système récupère après un crash. réécrit en fonction du journal redo. Remettez-le pour restaurer les données (pendant le processus d'initialisation, il n'y aura pas de connexion client pour le moment). Le journal peut également être utilisé pour la synchronisation entre le maître et l'esclave de la base de données, car essentiellement, tous les enregistrements d'opérations de la base de données ont été écrits dans le journal. Il nous suffit de synchroniser le journal avec l'esclave et de le relire sur l'esclave pour devenir maître. -synchronisation esclave. De nombreux autres composants requis peuvent également être implémentés ici. Nous pouvons obtenir toutes les modifications dans la base de données en nous abonnant au redo log, implémentant ainsi une logique métier personnalisée, telle que l'audit, la synchronisation du cache, etc.
Application des journaux dans les systèmes distribués
Les services de système distribué concernent essentiellement l'état. Les changements ici peuvent être compris comme des machines à états. Deux processus indépendants (ne dépendant pas de l'environnement externe, tel que les horloges système, les interfaces externes, etc.) avec des entrées cohérentes produiront des sorties cohérentes et maintiendront finalement un état cohérent, et le journal parce que sa séquentialité inhérente ne le fait pas. Dépend de l'horloge système, il peut être utilisé pour résoudre le problème de l'ordre des changements.
Nous utilisons cette fonctionnalité pour résoudre de nombreux problèmes rencontrés dans les systèmes distribués. Par exemple, dans le nœud de veille de RocketMQ, le courtier principal reçoit la demande du client et enregistre le journal, puis le synchronise avec l'esclave en temps réel. L'esclave le relit localement. Lorsque le maître raccroche, l'esclave peut continuer à le faire. traiter la demande, par exemple en rejetant la demande d'écriture et en continuant à gérer les demandes de lecture. Le journal peut non seulement enregistrer des données, mais également enregistrer directement des opérations, telles que des instructions SQL.
Le journal est une structure de données clé pour résoudre le problème de cohérence. Le journal est comme une séquence d'opérations. Chaque enregistrement représente une instruction, comme le Paxos et largement utilisé. Protocoles Raft. Il s'agit d'un protocole de cohérence construit sur la base de journaux.
Application des journaux dans Message Queue
Les journaux peuvent être facilement utilisés pour traiter les entrées et les sorties de données, et chaque source de données peut générer votre propre journal . Les sources de données ici peuvent provenir de divers aspects, tels qu'un certain flux d'événements (clic sur une page, rappel d'actualisation du cache, modification du journal binaire de la base de données). Nous pouvons stocker les journaux de manière centralisée dans un cluster et les abonnés peuvent lire les journaux en fonction du décalage. Pour chaque enregistrement, appliquez vos propres modifications en fonction des données et des opérations de chaque enregistrement.
Le journal ici peut être compris comme une file d'attente de messages, et la file d'attente de messages peut jouer le rôle de découplage asynchrone et de limitation de courant. Pourquoi parle-t-on de découplage ? Parce que pour les consommateurs et les producteurs, les responsabilités des deux rôles sont très claires, ils sont responsables de produire des messages et de consommer des messages, sans se soucier de qui est en aval ou en amont, qu'il s'agisse du journal des modifications de la base de données ou d'un certain événement. Je n'ai pas du tout besoin de me soucier d'une certaine partie. Je dois seulement faire attention aux journaux qui m'intéressent et à chaque enregistrement dans les journaux.
Nous savons que le QPS de la base de données est certain et que les applications de couche supérieure peuvent généralement se développer horizontalement. À ce stade, s'il y a un scénario de demande soudaine comme Double 11, la base de données sera submergée, nous pouvons alors introduire un message. files d'attente et ajouter chaque base de données d'équipe Les opérations sont écrites dans le journal et une autre application est chargée de consommer ces enregistrements de journal et de les appliquer à la base de données Même si la base de données se bloque, le traitement peut continuer à partir de la position du dernier message lors de la récupération ( RocketMQ et Kafka prennent en charge la sémantique Exactly Once), ici même si la vitesse du producteur est différente de celle du consommateur, il n'y aura aucun impact ici. Il peut stocker tous les enregistrements dans le fichier. se connecte et se synchronise régulièrement avec le nœud esclave, de sorte que la capacité du backlog des messages puisse être considérablement améliorée car l'écriture des journaux est traitée par le nœud maître. Les demandes de lecture sont divisées en deux types, l'un est à lecture finale, ce qui signifie que la vitesse de consommation. peut suivre la vitesse d'écriture. Un type de lecture peut aller directement au cache, tandis que l'autre type est un consommateur en retard sur la demande d'écriture. Ce type peut être lu à partir du nœud esclave, de sorte que via l'isolation des E/S et certains. les politiques de fichiers fournies avec le système d'exploitation, telles que le cache de pages, la pré-lecture du cache, etc., les performances peuvent être considérablement améliorées.
L'évolutivité horizontale est une fonctionnalité très importante dans un système distribué. Les problèmes qui peuvent être résolus en ajoutant des machines ne sont pas un problème. Alors, comment implémenter une file d'attente de messages capable de réaliser une expansion horizontale ? Si nous avons une file d'attente de messages autonome, à mesure que le nombre de sujets augmente, les E/S, le processeur, la bande passante, etc. comment procéder ici ? Qu'en est-il de l'optimisation des performances ?
1. Partage de sujet/journal Essentiellement, les messages écrits par sujet sont des enregistrements de journal. À mesure que le nombre d'écritures augmente, une seule machine deviendra lentement un goulot d'étranglement. À l'heure actuelle, nous pouvons diviser un seul sujet en plusieurs sous-thèmes et attribuer chaque sujet à une machine différente. De cette manière, les sujets contenant une grande quantité de messages peuvent être résolus en ajoutant des machines, tandis que certains sujets contenant une petite quantité de messages. peut être résolu en ajoutant des machines. peut être attribué à la même machine ou non partitionné
2.commit de groupe, par exemple, le client producteur de Kafka, lors de l'écriture d'un message, l'écrit d'abord dans une file d'attente de la mémoire locale, et puis écrit le message en fonction de chaque partition et nœuds sont résumés et soumis par lots. Pour le côté serveur ou côté courtier, cette méthode peut également être utilisée, en écrivant d'abord dans le cache de page, puis en vidant le disque régulièrement. déterminé en fonction de l'entreprise. Par exemple, les services financiers peuvent utiliser la synchronisation. La façon de brosser le disque.
3. Évitez les copies de données inutiles
4. Isolation des E/S
Conclusion
Connexions dans les systèmes distribués Ça joue un rôle très important et constitue la clé pour comprendre les différents composants du système distribué. À mesure que notre compréhension s'approfondit, nous constatons que de nombreux middleware distribués sont construits sur la base de journaux, tels que Zookeeper, HDFS, Kafka, RocketMQ et Google Spanner. , même pour les bases de données, telles que Redis, MySQL, etc., leur maître-esclave est basé sur la synchronisation des journaux. En s'appuyant sur le système de journaux partagés, nous pouvons implémenter de nombreux systèmes : synchronisation des données entre les nœuds, problèmes d'ordre des données de mise à jour simultanées (stabilité cohérente). problèmes), la persistance (lorsque le système tombe en panne, il peut continuer à fournir des services via d'autres nœuds), les services de verrouillage distribués, etc. Je crois qu'avec la pratique et la lecture de nombreux articles, vous aurez une compréhension plus profonde.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!