Maison > développement back-end > tutoriel php > 15 questions d'entretien PHP sur la haute concurrence (résumé)

15 questions d'entretien PHP sur la haute concurrence (résumé)

青灯夜游
Libérer: 2023-04-09 10:02:01
avant
11530 Les gens l'ont consulté

15 questions d'entretien PHP sur la haute concurrence (résumé)

Articles connexes recommandés : "Exploration approfondie des solutions et des solutions pour l'accès « à haute concurrence et à trafic important »"

1. Qu'est-ce que Rabbitmq

Une technologie de file d'attente de messages utilisant le protocole avancé de file d'attente de messages AMQP. La plus grande fonctionnalité est que la consommation ne nécessite pas. s'assurer que le fournisseur existe, en atteignant un degré élevé de découplage entre les services

2 Pourquoi utiliser Rabbitmq

  • dans. distribué Le système dispose d'une série de fonctions avancées telles que l'asynchrone, l'écrêtage des pics, l'équilibrage de charge, etc.

  • dispose d'un mécanisme de persistance, et les messages de processus et les informations dans la file d'attente peuvent également être enregistré.

  • Réaliser le découplage entre consommateurs et producteurs.

  • Pour les scénarios à forte concurrence, l'utilisation de files d'attente de messages peut transformer l'accès synchrone en accès série jusqu'à une certaine limite de courant, ce qui est bénéfique pour les opérations de base de données.

  • Vous pouvez utiliser la file d'attente des messages pour obtenir l'effet de commande asynchrone Pendant la file d'attente, les commandes logiques sont passées en arrière-plan.

3. Scénarios utilisant Rabbitmq

  • Communication asynchrone entre les services

  • Consommation séquentielle

  • Tâche chronométrée

  • Demande de coupure de pointe

4. Comment s'assurer que les messages sont envoyés correctement à RabbitMQ ? Comment s'assurer que le destinataire du message consomme le message ?

Mode de confirmation de l'expéditeur

Définissez le canal pour qu'il soit en mode confirmation (mode de confirmation de l'expéditeur), puis tous les messages publiés sur le canal se voit attribuer un identifiant unique.

Une fois le message remis à la file d'attente de destination ou le message écrit sur le disque (message persistant), le canal enverra une confirmation au producteur (contenant l'ID unique du message).

Si une erreur interne se produit dans RabbitMQ et que le message est perdu, un message nack (non reconnu) sera envoyé.

Le mode d'accusé de réception de l'expéditeur est asynchrone et l'application productrice peut continuer à envoyer des messages en attendant l'accusé de réception. Lorsque le message de confirmation atteint l'application producteur, la méthode de rappel de l'application producteur sera déclenchée pour traiter le message de confirmation.

Mécanisme de confirmation du destinataire

Mécanisme de confirmation du message du destinataire

Le consommateur reçoit chaque message Tous les messages doivent être confirmé (la réception du message et la confirmation du message sont deux opérations différentes). Ce n'est que lorsque le consommateur confirme le message que RabbitMQ peut supprimer le message en toute sécurité de la file d'attente.

Aucun mécanisme de délai d'attente n'est utilisé ici. RabbitMQ confirme uniquement si le message doit être renvoyé via l'interruption de la connexion du consommateur. En d’autres termes, tant que la connexion n’est pas interrompue, RabbitMQ donne au Consommateur suffisamment de temps pour traiter le message. Assurer la cohérence ultime des données ;

Voici plusieurs cas particuliers

  • Si le consommateur reçoit le message et se déconnecte avant de confirmer lors de la connexion ou en se désabonnant, RabbitMQ considérera que le message n'a pas été distribué et le redistribuera au prochain consommateur abonné. (Il peut y avoir des dangers cachés de consommation répétée de messages et la duplication doit être supprimée)

  • Si le consommateur reçoit le message mais ne confirme pas le message et que la connexion n'est pas déconnectée, RabbitMQ considère le consommateur occupé. Aucun autre message ne sera distribué à ce consommateur.

5. Comment éviter les livraisons répétées ou la consommation répétée de messages ?

Pendant la production du message, MQ génère en interne un identifiant de message interne pour chaque message envoyé par le producteur, comme base de la déduplication (la livraison du message échoue et est retransmis) pour éviter la duplication. le message entre dans la file d'attente ;

Lors de la consommation de messages, il est nécessaire qu'il y ait un bizId dans le corps du message (globalement unique pour la même entreprise, comme l'identifiant de paiement, l'identifiant de commande, l'identifiant de publication, etc.) comme base de déduplication à éviter Le même message est consommé à plusieurs reprises.

6. Sur quelle base le message est-il transmis ?

En raison de la surcharge importante liée à la création et à la destruction de connexions TCP et du nombre de concurrence limité par les ressources système, cela entraînera un goulot d'étranglement des performances. RabbitMQ utilise des canaux pour transmettre des données. Un canal est une connexion virtuelle établie au sein d'une connexion TCP réelle, et il n'y a pas de limite au nombre de canaux sur chaque connexion TCP.

7. Comment diffuser le message ?

Si la file d'attente a au moins un abonnement consommateur, le message sera envoyé au consommateur de manière circulaire. Chaque message ne sera distribué qu'à un seul consommateur abonné (à condition que le consommateur puisse traiter le message et le confirmer normalement). Plusieurs fonctions de consommation peuvent être réalisées grâce au routage

8. Comment acheminer les messages ?

Fournisseur de messages->Routage->Une à plusieurs files d'attente Lorsqu'un message est publié sur l'échange, le message aura une clé de routage, qui est définie lors de la création du message. Les files d'attente peuvent être liées aux commutateurs via des clés de routage de file d'attente.

Une fois le message arrivé à l'échangeur, RabbitMQ fera correspondre la clé de routage du message avec la clé de routage de la file d'attente (différentes règles de routage pour différents échangeurs

Les échangeurs couramment utilisés sont principalement) ; Il est divisé en trois types :

  • fanout : Si l'échange reçoit un message, il sera diffusé à toutes les files d'attente liées

  • direct : Si les clés de routage correspondent exactement, le message est remis dans la file d'attente correspondante

  • topic : Cela permet aux messages provenant de différentes sources d'atteindre la même file d'attente. Lorsque vous utilisez l'échangeur de sujets, vous pouvez utiliser des caractères génériques

9. Comment s'assurer que les messages ne sont pas perdus ?

Persistance des messages, bien sûr, le principe est que la file d'attente doit être persistante. La façon dont RabbitMQ garantit que les messages persistants peuvent être récupérés après le redémarrage du serveur est de les écrire dans un fichier journal persistant. disk., lors de la publication d'un message persistant sur un échange durable, Rabbit n'enverra pas de réponse tant que le message n'est pas soumis au fichier journal.

Une fois qu'un consommateur consomme un message persistant de la file d'attente persistante, RabbitMQ marquera le message dans le journal de persistance comme en attente de garbage collection. Si RabbitMQ est redémarré avant qu'un message persistant ne soit consommé, Rabbit reconstruira automatiquement l'échange et les files d'attente (et les liaisons) et republiera le message dans le fichier journal de persistance dans la file d'attente appropriée.

10. Quels sont les avantages de l'utilisation de RabbitMQ ?

1. Haut degré de découplage entre les services

2. Hautes performances de communication asynchrone

3. 🎜 >

11. cluster lapinmq

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, et chaque fois que vous écrivez un message dans la file d'attente, le message sera automatiquement envoyé aux files d'attente de plusieurs instances pour la synchronisation des messages.

Ce qui est bien, c'est que si l'une de vos machines tombe en panne, ce n'est pas grave, d'autres machines peuvent être utilisées. Les inconvénients sont, premièrement, une surcharge de performances trop élevée. Les messages sont synchronisés sur toutes les machines, ce qui entraîne une forte pression et une forte consommation de bande passante réseau ! Deuxièmement, si vous jouez comme ça, il n'y a pas d'é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 d'étendre linéairement votre file d'attente

Inconvénients de 12.mq

Disponibilité réduite du système

Plus il y a de dépendances externes introduites dans le système , Plus il est facile de raccrocher, à l'origine vous n'êtes que l'interface du système A pour appeler les trois systèmes BCD et ABCD. Si vous ajoutez MQ, que se passera-t-il si MQ raccroche ? Si MQ raccroche et que tout le système s'effondre, vous êtes condamné.

La complexité du système augmente

Si vous ajoutez MQ brusquement, comment pouvez-vous vous assurer que les messages ne sont pas consommés à plusieurs reprises ? Comment gérer la perte de message ? Comment garantir l’ordre de livraison des messages ? Grosse tête, grosse tête, beaucoup de problèmes, douleur sans fin

13. Problème de cohérence

Une fois le traitement terminé, le système A revient directement pour réussir, les gens tout le monde pensait que votre demande avait abouti ; mais le problème est que si parmi les trois systèmes de BCD et les deux systèmes de BD écrivent avec succès la bibliothèque, mais que le résultat est que le système C ne parvient pas à écrire la bibliothèque, qu'est-ce que faut-il le faire ? Vos données sont incohérentes. La file d'attente des messages est donc en fait une architecture très complexe. Il y a de nombreux avantages à l'introduire, mais vous devez également élaborer diverses solutions techniques et architectures supplémentaires pour éviter les inconvénients qu'elle entraîne. plus tard, vous découvrirez, oh mon dieu, que la complexité du système a augmenté d'un ordre de grandeur, peut-être 10 fois plus compliquée. Mais aux moments critiques, il faut quand même l'utiliser

14. Transactions distribuées

Soumission segmentée. Il y aura un arbitre et enverra ensuite des messages à tous les nœuds. Le succès ne se produira qu’une fois que tous les nœuds auront reçu un accusé de réception. Sinon, vous devez attendre le renvoi.

15. Comment concevoir une situation de trafic soudaine et importante, comme une diffusion en direct.

NGINX plus machine

  • page statique du cache cdn

  • redis File d'attente, laissez les utilisateurs entrer lentement.

  • Ajouter un cache. Mettez en cache les données utilisateur, telles que les informations utilisateur.

  • La base de données utilise maître-esclave

  • Expansion élastique

  • Disjoncteur limiteur de courant

  • Tutoriels associés recommandés : "

    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!

Étiquettes associées:
source:cnblogs.com
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal