Avant de parler de comment choisir une file d'attente de messages ? Tout d'abord, nous devons comprendre une question, à savoir, pourquoi utiliser des files d'attente de messages ? La file d'attente de messages peut-elle être remplacée par d'autres technologies ?
-
Pourquoi utiliser des files d'attente de messages ?
La raison de l'utilisation des files d'attente de messages peut être vue sous trois aspects, c'est-à-dire à partir des trois caractéristiques essentielles des files d'attente de messages : découplage, écrêtage des pics et asynchronie.
découplage
En ce qui concerne le couplage, nous pouvons d'abord regarder un tel exemple : il y a quatre systèmes A, B, C et D, et le système A doit envoyer des messages aux trois systèmes BCD et effectuer les opérations correspondantes. Au début, un tel scénario est acceptable, mais après que le système a fonctionné pendant un certain temps, un nouveau système E est ajouté. Le système E a également besoin du système A pour envoyer des données et utilise l'interface de E. À ce stade , il faut modifier le système A. Code, qui est dédié à l'envoi de données au système E dans le code. Mais après un certain temps, le système D a dit au système A qu'il n'était pas nécessaire que A lui envoie des messages, et le système A est allé commenter ou supprimer la partie du code qui envoie des données à D. Pour le système A, il peut être facile de faire un ou deux changements au début, mais si de plus en plus d'exigences sont requises, il sera très difficile de le modifier à ce moment-là, et le système A est sérieusement couplé à divers systèmes désordonnés. De plus, le système A doit également tenir compte de ce qu'il dit si le système associé est en panne ? Que dois-je faire si l'accès au système D expire ? Avez-vous besoin d'un mécanisme de nouvelle tentative ? Et ainsi de suite. Soit le couplage du système A soit plus élevé, et le traitement est plus lourd.
À ce stade, si MQ est introduit, la situation sera très différente. Dans le même scénario que ci-dessus, le nouveau système E a besoin du message du système A et n'a besoin que de le lire à partir de MQ. Il n'a pas besoin d'informer le système A et laissez-le faire la modification correspondante ; le système D n'a pas besoin du message de A et n'a qu'à annuler l'abonnement au message envoyé par le système A dans MQ. Maintenant, tout le processus devient :
1. Le système A génère une donnée et l'envoie à MQ.
2. Quel système a besoin que les données soient consommées dans MQ par lui-même.
3. Si le nouveau système nécessite que les données soient consommées directement à partir de MQ.
4. Si un système n'a pas besoin de ces données, annulez simplement la consommation des messages MQ.
Avec MQ, le système A n'a pas besoin de se demander à qui envoyer les données, de gérer le code, et n'a pas besoin de se demander si l'appelant réussit à appeler ou échoue à expirer. En bref, grâce à un tel modèle de MQ, publiant et abonnant des messages, le système A est complètement découplé des autres systèmes.
écrêtage de flux
L'écrêtage des pics de trafic, comme son nom l'indique, consiste à coordonner le traitement des pics de trafic, permettant au trafic d'être traité par lots, réduisant ainsi la pression sur le serveur. Une analogie frappante est que les files d'attente de messages sont comme des "réservoirs", stockant les inondations en amont et réduire les pics d'inondation entrant dans le débit des rivières en aval, de manière à atteindre l'objectif de réduction des catastrophes liées aux inondations. Pour l'achat précipité de billets de train pendant la Fête du Printemps, un grand nombre d'utilisateurs se précipitent pour les acheter en même temps.Un autre exemple est la célèbre vente flash Ali Double 11. Des centaines de millions d'utilisateurs ont afflué en un court laps de temps. période de temps, et le trafic a été énorme en un instant.
Utilisez le nombre de requêtes Mysql pour expliquer les avantages de l'écrêtage des pics de trafic. Le nombre de requêtes Mysql est limité, selon le serveur, tout comme mon serveur, la valeur par défaut est de 151 requêtes. Si à un moment donné, deux cents utilisateurs effectuent un grand nombre d'opérations sur mon site en même temps, un grand nombre de requêtes afflueront dans mon système, et la période de pointe peut atteindre trois ou quatre cents requêtes. sur Mysql, donc À l'heure actuelle, il y a trois ou quatre cents opérations SQL effectuées sur Mysql. À l'heure actuelle, il est évident que mon Mysql ne peut pas prendre en charge autant d'opérations, que Mysql ne peut pas fonctionner normalement et que les utilisateurs ne peuvent pas opérer sur mon site Web. Mais généralement, il est impossible d'avoir une si grande quantité de simultanéité, et il n'y a presque aucune pression sur le fonctionnement du système. Bien sûr, ce n'est qu'un exemple, le nombre maximum de requêtes Mysql en ligne ne peut pas être si bas, mais il y aura un tel problème.
Qu'en est-il de la situation après avoir rejoint MQ ? Lorsqu'un grand nombre d'opérations et de requêtes affluent sur le serveur, en supposant qu'il y a 500 requêtes par seconde, et écrivent ces 500 requêtes dans MQ, le système ne peut traiter que 151 requêtes par transaction car le nombre maximal simultané de Mysql est de 151. Le système extrait lentement les requêtes de MQ et il suffit de récupérer les requêtes 151 par seconde.A ce moment, même à l'heure de pointe la plus élevée, le système ne raccroche pas, car toutes les requêtes sont stockées dans MQ et Mysql envoie également des requêtes par seconde. Gère le nombre maximal de requêtes simultanées. Bien que pour MQ, 500 requêtes arrivent par seconde et 151 requêtes sortent, pendant la période de pointe, il peut y avoir un arriéré de milliers de requêtes, mais ce n'est pas un problème, car après la période de pointe, Mysql suivra toujours chaque 151 demandes par seconde sont traitées. Par conséquent, tant que la période de pointe est passée, le système résoudra rapidement l'arriéré d'informations.
traitement asynchrone
Ce qu'on appelle l'asynchronie signifie que le contenu d'une opération de demande est divisé en plusieurs étapes, et ces étapes n'ont pas besoin d'être synchrones. Par exemple, traitez une demande pour un système seckill.
Un seckill passe par de nombreuses étapes, telles que : contrôle des risques, verrouillage des stocks, génération de commandes, notification par SMS et mise à jour des statistiques. Si la file d'attente des messages n'a pas été optimisée, le flux de traitement normal est : l'application envoie une demande via la passerelle, appelle les étapes ci-dessus à tour de rôle, et une fois l'appel terminé, renvoie le résultat à l'application via la passerelle. Pour ces 5 étapes, que le seckill puisse être déterminé comme réussi ou non, en fait, il n'y a que 2 étapes de contrôle des risques et de verrouillage des stocks. Tant que la requête seckill de l'utilisateur passe le contrôle des risques et que l'inventaire est verrouillé côté serveur, le résultat seckill peut être renvoyé à l'utilisateur. Les étapes suivantes telles que la génération de commandes, les notifications par SMS et la mise à jour des statistiques ne doivent pas nécessairement être traité dans la requête seckill Finish.
Par conséquent, lorsque le serveur termine les deux étapes précédentes et détermine le résultat de la requête seckill, il peut immédiatement renvoyer une réponse à l'utilisateur, puis placer les données demandées dans la file d'attente des messages, qui effectuera les opérations suivantes de manière asynchrone.
Le traitement d'une demande seckill est réduit de 5 étapes à 2 étapes, de sorte que non seulement la vitesse de réponse est plus rapide, mais aussi pendant la période seckill, nous pouvons utiliser beaucoup de ressources serveur pour traiter la demande seckill. Une fois le seckill terminé, les ressources sont utilisées pour traiter les étapes suivantes, en utilisant pleinement les ressources limitées du serveur pour traiter davantage de demandes de seckill. À partir de là, nous pouvons voir que l'introduction de la file d'attente de messages peut obtenir le résultat de retour plus rapidement et réduire l'attente, ce qui réalise naturellement la simultanéité entre les étapes et améliore les performances globales du système.
-
Quels sont les avantages et les inconvénients des files d'attente de messages
Les avantages des files d'attente de messages sont également les trois fonctionnalités principales mentionnées ci-dessus. Les inconvénients correspondants sont également causés par les avantages.
Disponibilité réduite du système : plus le système introduit de dépendances externes, plus il est facile de raccrocher. Avant, c'était juste un système A qui appelait l'interface des trois systèmes BCD. Maintenant, un MQ est ajouté. Si le système MQ raccroche , tout le système va s'effondrer. .
La complexité du système augmente: après avoir rejoint le système MQ, il est impossible de garantir si le message sera consommé à plusieurs reprises, comment gérer la perte du message, comment assurer l'ordre de livraison des messages et d'autres problèmes suivront .
Problème de cohérence : Un système renvoie succès après traitement, vous pensez que cette requête est réussie. Mais le problème est que si l'un des trois systèmes BCD tombe en panne, les données ne seront pas cohérentes.
-
sélectionner la file d'attente des messages
Les MQ courants incluent désormais ActiveMQ, RabbitMQ, RocketMQ et Kafka. Chacun des quatre MQ a ses propres avantages et inconvénients.
| caractéristique |
ActiveMQ |
LapinMQ |
RocketMQ |
Kafka |
| Débit autonome |
10 000, le débit est d'un ordre de grandeur inférieur à celui de RocketMQ et Kafka |
10 000, le débit est d'un ordre de grandeur inférieur à celui de RocketMQ et Kafka |
Au niveau 100 000, RocketMQ est également une sorte de MQ qui peut prendre en charge un débit élevé |
100 000 niveaux, c'est le plus gros avantage de Kafka, c'est-à-dire son haut débit.
Coopérer généralement avec les systèmes de mégadonnées pour effectuer le calcul de données en temps réel, la collecte de journaux et d'autres scénarios |
| L'impact du nombre de sujets sur le débit |
|
|
Le sujet peut atteindre des centaines ou des milliers de niveaux, et le débit diminuera légèrement
C'est un avantage majeur de RocketMQ, sous la même machine, il peut supporter un grand nombre de sujets |
Lorsque le sujet va de dizaines à des centaines, le débit chutera considérablement
Par conséquent, sous la même machine, Kafka essaie de s'assurer que le nombre de sujets n'est pas trop grand. Si vous souhaitez prendre en charge des sujets à grande échelle, vous devez ajouter plus de ressources machine |
| Opportunité |
niveau ms |
Niveau microseconde, c'est une caractéristique majeure de rabbitmq, le délai est le plus bas |
niveau ms |
Le retard est dans le niveau de ms |
| disponibilité |
Élevé, basé sur une architecture maître-esclave pour atteindre une haute disponibilité |
Élevé, basé sur une architecture maître-esclave pour atteindre une haute disponibilité |
architecture distribuée très élevée |
Très élevé, Kafka est distribué, plusieurs copies d'une donnée, quelques machines en panne, pas de perte de données, pas d'indisponibilité |
| fiabilité des messages |
La probabilité de perdre des données est plus faible |
|
Après l'optimisation et la configuration des paramètres, aucune perte ne peut être atteinte |
Après la configuration de l'optimisation des paramètres, le message peut atteindre zéro perte |
| prise en charge des fonctions |
Les fonctions dans le domaine MQ sont extrêmement complètes |
Développé sur la base d'erlang, la capacité de simultanéité est donc très forte, les performances sont extrêmement bonnes et le délai est très faible |
La fonction MQ est relativement complète, ou distribuée, et a une bonne évolutivité |
Les fonctions sont relativement simples et prennent principalement en charge des fonctions MQ simples.Le calcul en temps réel et la collecte de journaux dans le domaine des mégadonnées sont utilisés à grande échelle, ce qui est la norme de facto |
| Résumé des avantages et des inconvénients |
Très mature et puissant, il a été appliqué dans un grand nombre d'entreprises et de projets de l'industrie
Faible probabilité occasionnelle de messages manquants
Et maintenant il y a de moins en moins d'applications communautaires et domestiques, la communauté officielle maintient de moins en moins ActiveMQ 5.x, et ne sort une version que dans quelques mois.
Et en effet, il est principalement utilisé sur la base du découplage et de l'asynchronisme, et est rarement utilisé dans des scénarios de débit à grande échelle
|
Développé en langage erlang, les performances sont extrêmement bonnes et le retard est très faible ;
Le débit atteint 10 000 niveaux, et la fonction MQ est relativement complète
Et l'interface de gestion fournie par l'open source est très bonne et facile à utiliser
La communauté est relativement active et plusieurs versions sortent presque tous les mois.
Certaines sociétés Internet nationales ont davantage utilisé rabbitmq ces dernières années
Mais le problème est également évident : RabbitMQ a un débit inférieur car le mécanisme d'implémentation qu'il crée est plus lourd.
Et le développement d'erlang, combien d'entreprises nationales ont la force de faire de la recherche et de la personnalisation au niveau de la source d'erlang ? Si vous n'avez pas cette capacité, vous rencontrerez parfois des problèmes. Il vous est difficile de lire et de comprendre le code source. Le contrôle de votre entreprise sur cette chose est très faible, et les fonctions de base dépendent de la maintenance rapide et des bogues correctifs de la communauté open source.
Et l'expansion dynamique du cluster rabbitmq sera très gênante, mais je pense que ça va. En fait, c'est principalement un problème causé par le langage erlang lui-même. Code source difficile à lire, difficile à personnaliser et à contrôler. |
L'interface est simple et facile à utiliser, et après tout, elle a été appliquée à grande échelle à Ali, et elle est garantie par la marque Ali
Il traite des dizaines de milliards de messages par jour, peut atteindre un débit à grande échelle et offre de très bonnes performances. L'expansion distribuée est également très pratique, la maintenance communautaire est correcte, la fiabilité et la disponibilité sont correctes et il peut prendre en charge un grand nombre de sujets. , prendre en charge des scénarios métier MQ complexes
Et un gros avantage est que les produits d'Ali sont tous basés sur Java, nous pouvons lire le code source par nous-mêmes, personnaliser le MQ de notre entreprise et contrôler
L'activité de la communauté est relativement moyenne, mais ça va. La documentation est relativement simple, et l'interface n'est pas conforme à la spécification JMS standard. Certains systèmes ont besoin de modifier beaucoup de code pour migrer
Il y a aussi la technologie introduite par Ali. Il faut bien faire au cas où cette technologie serait abandonnée et le risque que la communauté devienne jaune. Si votre entreprise a de la force technique, je pense que c'est très bien d'utiliser RocketMQ |
Les caractéristiques de kafka sont en fait très évidentes, c'est-à-dire qu'il ne fournit que moins de fonctions de base, mais il offre un débit ultra-élevé, un délai de niveau ms, une disponibilité et une fiabilité extrêmement élevées, et la distribution peut être étendue de manière arbitraire.
Dans le même temps, il est préférable que Kafka prenne en charge un petit nombre de sujets pour assurer son débit ultra-élevé
De plus, le seul inconvénient de Kafka est la possibilité d'une consommation répétée de messages, ce qui aura un très léger impact sur la précision des données. Dans le domaine du big data et de la collecte de logs, ce léger impact peut être ignoré.
Cette fonctionnalité est naturellement adaptée au calcul en temps réel des mégadonnées et à la collecte de journaux |
因此一般的业务系统要引入MQ,最早的时候都用AactiveMQ。但是现在用的不多，没有经过大规模吞吐量场景的验证，社区也不是很活跃。后来开始使用RabbitMQ,但是由于RabbitMQ是由erlang语言阻止了大梁Java工程师的研究，对公司而言，几乎处于不可控的状态，但是确实是开源的，比较稳定的支持，活跃度也高。另外现在也有越来越多的公司会去使用RocketMQ，但是社区万一突然黄掉的风险，所以自己公司没有实力，就还是使用RabbitMQ。如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄。