Comment garantir la haute disponibilité de la file d'attente des messages ?

La file d'attente de messages est une compétence essentielle dans les scénarios à forte concurrence. Au fur et à mesure que nous l'utilisons, de nombreux problèmes surviennent dans l'environnement de production, tels que : Comment obtenir une haute disponibilité de la file d'attente de messages ?

Il existe de nombreux types de middleware dans les scénarios, nous en préparons ici quelques-uns couramment utilisés pour l'analyse et le traitement.

1. Haute disponibilité de RabbitMQ

RabbitMQ est relativement représentatif car il est basé sur la haute disponibilité maître-esclave (non distribuée), nous utilisons donc RabbitMQ est un exemple pour expliquer comment implémenter la haute disponibilité du premier MQ.

RabbitMQ dispose de trois modes : le mode autonome, le mode cluster normal et le mode cluster miroir.

Mode solo

Le mode autonome est de niveau démo. Généralement, vous pouvez le démarrer localement pour le plaisir. Personne n'utilise le mode autonome pour la production.

Mode cluster normal (pas de haute disponibilité)

Le mode cluster normal signifie démarrer plusieurs instances RabbitMQ sur plusieurs machines, une pour chaque machine. La file d'attente que vous créez ne sera placée que sur une seule instance RabbitMQ, mais chaque instance synchronise les métadonnées de la file d'attente (les métadonnées peuvent être considérées comme des informations de configuration de la file d'attente. Grâce aux métadonnées, vous pouvez trouver l'instance où se trouve la file d'attente) .

Lorsque vous consommez, si vous êtes réellement connecté à une autre instance, alors cette instance extraira les données de l'instance où se trouve la file d'attente.

Cette méthode est vraiment gênante et pas très bonne. Elle n'obtient pas la soi-disant distribution et n'est qu'un cluster ordinaire. Parce que cela conduit le consommateur soit à se connecter de manière aléatoire à une instance à chaque fois et à extraire des données, soit à se connecter de manière fixe à l'instance où se trouve la file d'attente pour consommer des données. Le premier entraîne la surcharge liée à l'extraction de données et le second conduit à une seule instance. goulot d'étranglement des performances de l'instance.

Et si l'instance qui met la file d'attente tombe en panne, les autres instances ne pourront pas extraire de cette instance. Si vous activez la persistance des messages et laissez RabbitMQ stocker les messages, les messages ne seront pas nécessairement perdus, vous l'avez fait. attendre la récupération de cette instance avant de pouvoir continuer à extraire des données de cette file d'attente.

Cette question est donc plus embarrassante. Il n'y a pas de soi-disant haute disponibilité. Cette solution vise principalement à améliorer le débit, c'est-à-dire à permettre à plusieurs nœuds du cluster d'effectuer les opérations de lecture et d'écriture d'un certain. file d'attente. .

Mode cluster miroir (haute disponibilité)

Ce mode est ce qu'on appelle le mode haute disponibilité de RabbitMQ. Ce qui diffère du mode cluster ordinaire, c'est qu'en mode cluster miroir, la file d'attente que vous créez, quelles que soient les métadonnées ou les messages dans la file d'attente, existera sur plusieurs instances, c'est-à-dire que chaque nœud RabbitMQ possède une copie complète de cette file d'attente. La mise en miroir signifie contenir toutes les données de la file d'attente. Ensuite, chaque fois que vous écrivez un message dans la file d'attente, le message sera automatiquement synchronisé avec les files d'attente de plusieurs instances.

Alors comment activer ce mode cluster miroir ? En fait, c'est très simple. RabbitMQ dispose d'une bonne console de gestion, qui consiste à ajouter une politique en arrière-plan. Cette politique est une politique en mode cluster miroir. Lorsqu'elle est spécifiée, vous pouvez exiger que les données soient synchronisées sur tous les nœuds. un nombre spécifié Lorsque le nœud crée à nouveau la file d'attente, l'application de cette stratégie synchronisera automatiquement les données avec les autres nœuds.

Dans ce cas, l'avantage est que si l'une de vos machines tombe en panne, tout ira bien. D'autres machines (nœuds) contiennent toujours les données complètes de cette file d'attente, et d'autres consommateurs peuvent accéder à d'autres nœuds. consommer des données.

Les inconvénients sont, premièrement, la surcharge de performances est trop élevée. Les messages doivent être synchronisés sur toutes les machines, ce qui entraîne une forte pression et une consommation de bande passante réseau !

Deuxièmement, ces jeux ne sont pas distribués et n'ont aucune évolutivité. Si une file d'attente est fortement chargée et que vous ajoutez une machine, la nouvelle machine contiendra également toutes les données de la file d'attente, et il n'y a aucun moyen de le faire. élargissez linéairement votre file d'attente.

2. Haute disponibilité de Kafka

La compréhension architecturale la plus basique de Kafka : il est composé de plusieurs courtiers, chaque courtier est un nœud que vous créez un sujet ; Ce sujet peut être divisé en plusieurs partitions, chaque partition peut exister sur différents courtiers et chaque partition stocke une partie des données.

Il s'agit d'une file d'attente de messages distribuée naturelle, ce qui signifie que les données d'un sujet sont dispersées sur plusieurs machines, et chaque machine stocke une partie des données.

En fait, RabbmitMQ et autres ne sont pas des files d'attente de messages distribuées. Ce sont des files d'attente de messages traditionnelles. Ils fournissent simplement des mécanismes de clustering et HA (High Availability, High Availability), car quelle que soit la façon dont vous jouez, Oui, le les données d'une file d'attente dans RabbitMQ sont placées sur un nœud. Sous le cluster miroir, les données complètes de la file d'attente sont également placées sur chaque nœud.

Avant Kafka 0.8, il n'y avait pas de mécanisme HA. Si un courtier tombait en panne, la partition de ce courtier serait inutile et ne pourrait pas être écrite ou lue. Il n'y avait aucune haute disponibilité.

Par exemple, nous supposons que nous créons un sujet et précisons que le nombre de partitions est de 3, chacune sur trois machines. Cependant, si la deuxième machine tombe en panne, 1/3 des données sur ce sujet seront perdues, elles ne pourront donc pas être hautement disponibles.

Kafka 0.8 et versions ultérieures fournissent un mécanisme HA, qui est un mécanisme de réplique. Les données de chaque partition seront synchronisées avec d'autres machines pour former ses propres répliques multiples. Toutes les répliques éliront un leader, puis la production et la consommation traiteront avec ce leader, et ensuite les autres répliques seront des suiveurs. Lors de l'écriture, le leader sera responsable de la synchronisation des données avec tous les suiveurs. Lors de la lecture, il suffit de lire directement les données sur le leader. Peut-on seulement lire et écrire en tant que leader ?

C'est très simple. Si vous pouvez lire et écrire chaque suiveur à volonté, alors vous devez vous occuper du problème de cohérence des données. La complexité du système est trop élevée et il est facile que des problèmes surviennent. Kafka répartira uniformément toutes les répliques d'une partition sur différentes machines, afin d'améliorer la tolérance aux pannes.

De cette façon, il y a ce qu'on appelle une haute disponibilité, car si un certain courtier tombe en panne, ce sera très bien. Les partitions de ce courtier ont des copies sur d'autres machines. Si le courtier abattu a un chef d'une certaine partition, un nouveau chef sera réélu parmi les partisans et tout le monde pourra continuer à lire et à écrire le nouveau chef. C'est ce qu'on appelle la haute disponibilité.

Lors de l'écriture des données, le producteur écrit au leader, puis le leader écrit les données sur le disque local, puis d'autres suiveurs prennent l'initiative d'extraire les données du leader. Une fois que tous les abonnés ont synchronisé les données, ils enverront des accusés de réception au leader. Une fois que le leader aura reçu les accusés de réception de tous les abonnés, il renverra un message écrit avec succès au producteur. (Bien sûr, ce n'est qu'un des modes, et ce comportement peut être ajusté de manière appropriée)

Lors de la consommation, il ne sera lu que par le leader, mais seulement lorsqu'un message aura été synchronisé par tous les abonnés et renvoyé avec succès, ce message sera lu par les consommateurs.

Pour plus de connaissances sur php, veuillez visiter le tutoriel php !

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!