Les billets d'avion, les billets de train, les billets de bus et les activités hôtelières de Tongcheng Yilong ont été connectés à RocketMQ pour réduire les pics de trafic pendant les pics de trafic afin de réduire la pression en arrière-plan.
Dans le même temps, le système conventionnel est découplé, certains traitements synchrones sont remplacés par des traitements asynchrones et 150 milliards de données sont traitées chaque jour.
Lors du récent Meetup Apache RocketMQ, Cha Jiang, l'architecte de la division des billets de Tongcheng Yilong, a expliqué comment le système de messagerie de Tongcheng Yilong gère 150 milliards de traitements de données par jour.
À travers cet article, vous apprendrez:
Utilisation du système de messagerie Tongcheng Yilong
Scénarios d'application du système de messagerie Tongcheng Yilong
Fosse techniquement étagée
Améliorations basées sur RocketMQ
Utilisation du système de messagerie Tongcheng Yilong
Le cluster RocketMQ est divisé en deux parties: le serveur de noms et le courtier. Le serveur de noms utilise un mode principal double. L'un est pour les performances et l'autre pour la sécurité. Le courtier de données pures est divisé en plusieurs groupes, et chaque groupe est divisé en maître et esclave.
À l'heure actuelle, nos billets d'avion, billets de train, billets de bus et entreprises liées aux hôtels ont été connectés à RocketMQ pour réduire les pics de trafic pendant les pics de trafic afin de réduire la pression du back-end.
Dans le même temps, le système conventionnel est découplé, certains traitements synchrones sont remplacés par des traitements asynchrones et 150 milliards de données sont traitées chaque jour.
Les raisons de choisir RocketMQ sont:
Accès facile, moins de packages Java sont introduits
Développement purement Java, logique de conception claire
La performance globale est relativement stable. Dans le cas d'un grand nombre de sujets, la performance peut être maintenue
Scénarios d'application du système de messagerie Tongcheng Yilong
Système de désabonnement
Ceci est un scénario d'application dans notre système de désinscription. L'utilisateur clique sur le bouton de désabonnement sur le front-end, le système appelle l'interface de désabonnement, puis appelle l'interface de désabonnement du fournisseur pour terminer une fonction de désabonnement.
Si l'interface système du fournisseur n'est pas fiable, l'utilisateur ne pourra pas se désabonner. Si le système est configuré pour synchroniser l'opération, l'utilisateur cliquera à nouveau.
Par conséquent, nous avons introduit RocketMQ pour passer de la synchronisation à l'asynchrone. L'utilisateur final actuel envoie une demande de désabonnement. Une fois que le système de désabonnement a reçu la demande, elle sera enregistrée dans la base de données du système de désabonnement, indiquant que l'utilisateur se désabonne.
En même temps, le message de désabonnement est envoyé au système connecté avec le fournisseur via le moteur de messagerie pour appeler l'interface du fournisseur.
Si l'appel réussit, la base de données sera identifiée, indiquant que l'abonnement a été désabonné avec succès. Dans le même temps, un script de compensation a été ajouté pour récupérer les messages désabonnés de la base de données et se désabonner pour éviter l'échec de désabonnement causé par la perte de message.
Système d'entrepôt
Le deuxième scénario d'application est notre système d'entrepôt. Il s'agit d'un scénario d'utilisation des messages relativement conventionnel. Nous collectons des informations de base et des données détaillées sur l'hôtel auprès du fournisseur, puis nous les connectons au système de messagerie, qui est calculé par le système de distribution principal, le système de prix minimum et le système d'inventaire.
Dans le même temps, lorsque le fournisseur modifie le prix, l'événement de changement de prix sera également transmis à notre système commercial back-end via le système de messagerie pour garantir l'exactitude et l'exactitude des données en temps réel.
Système d'abonnement pour la bibliothèque d'approvisionnement
Le système d'abonnement de la base de données utilise également l'application de messagerie. Dans des circonstances normales, la synchronisation de la base de données est effectuée via binlog pour lire les données à l'intérieur, puis les déplacer vers la base de données.
Pendant le processus de traitement, nous sommes plus préoccupés par l'ordre des données, donc sur la base du mode ligne de la base de données, une nouvelle fonction a été ajoutée pour garantir que l'ordre dans chaque file d'attente est unique.
Bien que l'ordre dans la file d'attente soit naturellement unique, nous avons une fonctionnalité en cours d'utilisation, c'est-à-dire que les messages avec le même ID sont placés dans la même file d'attente.
Par exemple, le message de id1 dans le coin supérieur droit de la figure, le champ principal de la base de données est id1, est unifié dans Queue1, et dans l'ordre.
Dans Queue2, deux id3 sont séparés par deux id2 séquentiels, mais lorsque la consommation réelle est lue, elle sera également séquentielle. Par conséquent, l'ordre de plusieurs files d'attente peut être utilisé pour améliorer la concurrence globale.
Fosse techniquement étagée
Scénario du système fournisseur
Dans la figure ci-dessus, un MQ correspond à deux consommateurs, ils sont dans le même groupe 1. Au début, tout le monde n'a que le thème 1. A ce moment, la consommation est normale.
Cependant, si vous ajoutez un Topic2 au premier consommateur, vous ne pouvez pas consommer ou consommer anormalement pour le moment.
C'est un problème causé par le mécanisme propre de RocketMQ, et Topic2 doit être ajouté au deuxième consommateur pour une consommation normale.
Scénario du système de transaction de paiement
L'autre est un système d'opérations de paiement. Dans ce scénario, il existe également deux applications. Elles appartiennent toutes au même groupe et au même thème. L'une consiste à consommer des données Tag1 et l'autre à consommer des données Tag2.
Dans des circonstances normales, le démarrage ne devrait pas poser de problème, mais un jour, nous avons constaté qu'une application ne peut pas se lever et qu'une autre application ne consomme que les données de Tag2, mais en raison du mécanisme de RocketMQ, les données de Tag1 seront prises en charge. Les données de Tag1 seront supprimées.
Cela entraînera l'échec de l'utilisateur dans le processus de paiement. Pour cela, nous mettons Tag2 dans Group2, et les deux groupes ne consommeront pas le même message.
Je suggère personnellement que RocketMQ puisse implémenter un mécanisme, c'est-à-dire n'accepter que ses propres messages Tag et ne pas recevoir de tags non liés.
Scénarios où une grande quantité d'anciennes données est lue
Dans le scénario de consommation de billets de train, nous avons constaté que 20 milliards de données anciennes n'ont pas été consommées. Lorsque notre consommation commencera, RocketMQ commencera par défaut à lire à partir des données 0. À ce stade, les E / S disque grimpent à 100%, ce qui affecte la lecture d'autres données consommateurs, mais une fois ces anciennes données chargées, cela n'a aucun effet pratique. .
Par conséquent, la meilleure façon de lire une grande quantité d'anciennes données est:
Pour les nouveaux groupes de consommation, la consommation est de LAST_OFFSET par défaut.
Lorsque la pile de sujets unique dans le courtier dépasse 10 millions, la consommation est interdite et l'administrateur doit être contacté pour activer la consommation.
La surveillance doit être en place, et lorsque les pics d'E / S du disque, le consommateur peut être immédiatement contacté pour traitement.
Scène du serveur
①Futex Kernel bug dans CentOS 6.6 provoque le blocage fréquent des processus de serveur de noms et de courtier et ne peut pas fonctionner normalement
Solution: passez à la version 6.7
② Les deux threads côté serveur créeront le même CommitLog et le placeront dans la liste, ce qui entraînera un calcul d'erreur de décalage de message, un échec d'analyse des messages, un échec de consommation et un redémarrage ne résoudra pas le problème.
Solution: problème de sécurité des threads, passage à un thread unique
③ La réinitialisation de la progression de la consommation en mode Pull amène le serveur à remplir une grande quantité de données dans la carte et l'utilisation du processeur du Broker augmente de 100%.
Solution: la scène de variable locale de mappage n'est pas utilisée, supprimez
④Master recommande que lorsque le client consomme dans l'esclave, si les données n'ont pas été synchronisées avec l'esclave, il réinitialise le pullOffset, ce qui entraîne un grand nombre de consommations répétées.
Solution: ne réinitialisez pas le décalage
⑥ Il n'y a pas de MagicCode pour la synchronisation.Lorsque le groupe de sécurité scanne le port de synchronisation, le maître l'analyse de manière incorrecte, ce qui pose des problèmes.
Solution: ajoutez la vérification magicCode lors de la synchronisation
Améliorations basées sur RocketMQ
Nouvelle cliente
Client .net ajouté, développement natif basé sur le code source Java; client HTTP ajouté, implémentation de certaines fonctions et connexion à RocketMQ via Netty Server.
Nouvelle fonction de limite de flux de messages
Si le code client est mal écrit et qu'une boucle infinie est générée, une grande quantité de données dupliquées sera générée. À ce stade, le thread de production sera plein et la file d'attente débordera, ce qui affectera gravement la stabilité de notre cluster MQ et affectera d'autres entreprises.
L'image ci-dessus est un diagramme de modèle de limitation de courant. Nous ajoutons la fonction de limitation de courant avant le sujet. La limite de débit et la limite de taille peuvent être définies via la fonction de limitation de courant.
La limite de débit est implémentée via l'algorithme du compartiment de jetons, c'est-à-dire combien de jetons sont placés dans le compartiment par seconde, et la vitesse est consommée par seconde, ou la quantité de données écrites dans le sujet. Les deux configurations ci-dessus prennent en charge la modification dynamique.
Surveillance d'arrière-plan
Nous avons également créé un arrière-plan de surveillance pour l'ensemble du processus de liaison des messages de surveillance, y compris:
Suivi complet du lien des messages, couvrant tout le cycle de vie de la génération, de la consommation et de l'expiration des messages
Courbe de production et de consommation d'actualités
Alarme anormale de production de message
Les messages s'accumulent pour alerter, notifier quelle adresse IP est trop lente à consommer
Autres fonctions:
Produire et consommer des messages en mode HTTP
Paramètre d'autorisation de consommation de sujet, le sujet ne peut être utilisé que par le groupe désigné pour empêcher l'abonnement désordonné en ligne
Prise en charge des nouveaux groupes de consommateurs à consommer à partir de la dernière position (par défaut, à partir de la première)
Synchronisation de la progression de la consommation en mode diffusion (progression de l'affichage du serveur)
Ce qui précède est la pratique de Tongcheng Yilong dans la construction du système de messagerie.