Cet article a été partagé par Huang Shancheng, ingénieur de développement principal chez Bilibili. Le titre original était « Dix milliers de systèmes de messages à long terme ». Cet article a été rédigé et optimisé dans son contenu.
1. Introduction
À l’ère actuelle du divertissement numérique, les barrages sont devenus l’un des éléments interactifs indispensables sur les plateformes de diffusion en direct.

En envoyant des barrages, en envoyant des cadeaux, etc., les utilisateurs peuvent afficher leurs pensées, leurs commentaires et leur contenu interactif sur l'écran de diffusion en direct en temps réel, enrichissant ainsi l'expérience visuelle de l'utilisateur. Dans ce processus, transmettre des informations interactives au terminal en temps réel nécessite l’utilisation de longues connexions.
Une connexion longue, comme son nom l'indique, est un canal de données réseau maintenu avec le serveur pendant toute la durée de vie de l'application et peut prendre en charge la transmission de données en liaison montante et descendante en duplex intégral. La plus grande différence entre celui-ci et le service de connexion courte en mode réponse à la demande est qu'il peut fournir au serveur la possibilité de transmettre activement des données aux utilisateurs en temps réel.
Cet article présentera la conception architecturale et la pratique des dizaines de millions de systèmes de messagerie en temps réel à connexion longue mis en œuvre par Bilibili sur la base de Golang, y compris la conception du cadre du service de connexion longue, ainsi que les optimisations associées pour la stabilité et la haute performance. débit.


2. Articles connexes
- " L'évolution de la passerelle API basée sur les microservices de Bilibili de 0 à 1 "
- " Graphite Document autonome 500 000 WebSocket longue pratique d'architecture de connexion "
- " Pratique technique du composant de connexion longue prise unifiée Baidu de 0 à 1 "
- " Pratique technologique de connexion longue IM de Tantan : sélection de technologies, conception d'architecture et optimisation des performances "
- " Pratique technologique de passerelle push en temps réel iQiyi WebSocket "
- " Pratique de messagerie instantanée côté Web de LinkedIn : réaliser des centaines de milliers de connexions longues sur une seule machine "
- " Une idée de mise en œuvre de service d'abonnement/push sécurisée et évolutive basée sur des connexions longues "
- " Partage de pratiques techniques de l'architecture Push de messages en temps réel de Meizu avec 25 millions de connexions longues "
- " Entretien exclusif avec l'architecte Meizu : expérience d'un système de transmission de messages en temps réel avec de longues connexions massives "
3. Conception architecturale
3.1 Aperçu
Le service de connexion longue est une connexion longue partagée par plusieurs parties commerciales.
Parce que lors de la conception, il est nécessaire de prendre en compte les demandes des différentes parties commerciales et les différents scénarios commerciaux pour les services de connexion à long terme. Dans le même temps, les limites des services de connexion à long terme doivent également être prises en compte pour éviter d'intervenir dans les affaires. logique et affectant l’itération et le développement ultérieurs des services de connexion à long terme.
Les services de connexion longue distance se divisent principalement en trois aspects :
- 1) Établissement, maintenance et gestion des liaisons longues ;
- 2) transmission de données en liaison descendante ;
- 3) Transfert de données de liaison montante (actuellement uniquement par battement de cœur, aucune exigence réelle de scénario commercial).
3.2 Architecture globale

La structure globale du service de connexion longue est présentée dans la figure ci-dessus. Le service global comprend les parties suivantes.
1) Couche de contrôle : pré-appel pour l'établissement de la connexion, principalement pour la vérification de la légalité de l'accès, la vérification de l'identité et le contrôle du routage.
tâche principale:
- 1) Authentification de l'identité de l'utilisateur ;
- 2) Crypter les données d'assemblage et générer un jeton légal ;
- 3) Planification dynamique et allocation des nœuds d'accès.
2) Couche d'accès : service de base de connexion longue, principalement responsable de la désinstallation des certificats, de l'amarrage du protocole et de la maintenance des connexions longues.
tâche principale:
- 1) Désinstallez les certificats et les protocoles ;
- 2) Responsable de l'établissement et du maintien des connexions avec les clients et de la gestion de la relation de mappage entre l'identifiant de connexion et l'id de chambre ;
- 3) Traitez les messages de liaison montante et descendante.
3) Couche logique : couche d'accès simplifiée, principalement pour les fonctions commerciales de connexion à long terme.
tâche principale:
- 1) Enregistrements de déclaration de numéros en ligne ;
- 2) Enregistrez la relation de mappage entre chaque attribut de l'ID de connexion et chaque nœud.
- 4) Couche de distribution des messages : les messages sont poussés vers la couche d'accès.
tâche principale:
- 1) L'encapsulation, la compression et l'agrégation des messages sont poussées vers les nœuds périphériques correspondants ;
5) Couche de service : couche d'accueil des services métier, fournissant une entrée pour la diffusion de messages en aval.
tâche principale:
- 1) Gérer et contrôler les autorisations push commerciales ;
- 2) Détection et réassemblage des messages ;
- 3) Le flux de messages est limité selon certaines politiques pour protéger son propre système.
3.3 Processus de base

Les connexions longues se composent principalement de trois processus principaux :
- 1) Établissement d'une connexion : initiée par le client, d'abord via la couche de contrôle pour obtenir le jeton légal et la configuration du point d'accès de l'appareil ;
- 2) Maintenir la connexion : principalement le client initie régulièrement des battements de cœur pour s'assurer que la longue connexion est active ;
- 3) Push de liaison descendante : Le push de liaison descendante est initié par le serveur d'entreprise. La couche de service détermine l'identifiant de connexion et le nœud d'accès en fonction de l'identifiant correspondant. Via la couche de distribution de messages, le push est envoyé à la couche d'accès correspondante, écrite dans la couche désignée. connexion, puis distribué au client.
3.4 Liste des fonctions
Combiné avec le scénario commercial de la station B, le push de données descendant fournit les fonctions générales suivantes :
- 1) Messages au niveau de l'utilisateur : désignés pour être envoyés à certains utilisateurs (comme l'envoi de messages d'invitation pk à une certaine ancre) ;
- 2) Messages au niveau de l'appareil : développer et transmettre à certains appareils (par exemple, envoyer des instructions de rapport de journal client pour les appareils non enregistrés) ;
- 3) Messages au niveau de la salle : envoyer des messages aux connexions dans une certaine pièce (par exemple, envoyer des messages de barrage à tous les utilisateurs en ligne dans la salle de diffusion en direct) ;
- 4) Messages de partition : envoyez des messages aux salles d'une certaine partition (par exemple, envoyez une certaine activité de revenus à toutes les salles diffusées dans une certaine partition) ;
- 5) Actualités à l'échelle du district : messages push à tous les utilisateurs de la plateforme (tels que des notifications d'événements push à tous les utilisateurs en ligne).
4. Conception technologique à haut débit
À mesure que l'entreprise se développe et se développe, il y a de plus en plus d'utilisateurs en ligne et la pression sur le système de connexion à long terme augmente, notamment lors de la diffusion en direct d'événements populaires. Par exemple, lors des S-Games, le nombre de personnes en ligne. sur l'ensemble de la plate-forme a atteint des dizaines de millions et le débit des messages a atteint des centaines de millions. Le délai moyen de distribution des messages du système Changlian est d'environ 1 seconde et le taux d'arrivée des messages atteint 99 %. mesures que Changlian a prises.
4.1 Protocole réseau
Le choix du bon protocole réseau est essentiel à la performance d'un système à connexion longue :
- 1) Protocole TCP : il peut fournir une connexion et une transmission de données fiables et convient aux scénarios nécessitant une fiabilité élevée des données ;
- 2) Protocole UDP : Il s'agit d'un protocole peu fiable, mais il a une efficacité de transmission élevée et convient aux scénarios qui ne nécessitent pas une grande fiabilité des données ;
- 3) Protocole WebSocket : Il réalise également une communication bidirectionnelle sans ajouter trop de surcharge et est davantage utilisé du côté Web.
La couche d'accès est divisée en module de protocole et module de connexion :
- 1) Module de protocole : interagit avec des protocoles de couche de communication spécifiques et encapsule l'interface et les différences logiques des différents protocoles de communication.
- 2) Module de connexion : maintient l'état des connexions commerciales de connexion à long terme, prend en charge les demandes de liaison montante, de liaison descendante et d'autres logiques métier, maintient les attributs de la connexion et la relation de liaison avec l'ID de la salle.
Concernant le point 1) ci-dessus , le module de protocole fournit également une interface de données unifiée avec le module de connexion, comprenant l'établissement de la connexion, la lecture des données, l'écriture, etc. Si de nouveaux protocoles sont ajoutés à l'avenir, tant que l'adaptation est effectuée dans le module de protocole, cela n'affectera pas la logique métier à long terme des autres modules.
Avantage de:
- 1) La logique métier et les protocoles de communication sont isolés pour faciliter l'ajout itératif de protocoles de communication et simplifier la difficulté de mise en œuvre de la compatibilité avec plusieurs protocoles de communication ;
- 2) La couche de contrôle peut émettre de meilleurs protocoles de communication en fonction de la situation réelle du client.
4.2 Équilibrage de charge
La technologie d'équilibrage de charge peut être utilisée pour distribuer les requêtes à différents nœuds de serveur pour traitement, évitant ainsi une charge excessive sur un seul nœud et améliorant l'évolutivité et la stabilité du système.
La connexion à long terme ajoute une couche de contrôle pour l'équilibrage de charge. La couche de contrôle fournit une interface de connexion http courte et sélectionne dynamiquement le nœud d'accès approprié en fonction de la situation réelle du client et de chaque nœud périphérique et du principe de proximité.
La couche d'accès prend en charge l'expansion horizontale et la couche de contrôle peut ajouter et réduire des nœuds d'allocation en temps réel. Pendant le jeu S, lorsque le nombre de personnes en ligne approchait des dizaines de millions, chaque nœud d'accès était équilibré et programmé pour garantir que le processeur et la mémoire de chaque nœud se trouvaient dans une plage stable.
4.3 File d'attente des messages
Le lien push du message est le suivant : l'entreprise envoie le push, le pousse vers le nœud périphérique via la couche de service, puis le transmet au client.
La couche de service distribue à chaque nœud périphérique en temps réel. S'il s'agit d'un message de type salle, il doit être transmis à plusieurs nœuds périphériques. La couche de service traite également la logique métier, ce qui affecte considérablement le débit du message.
Par conséquent, la file d'attente des messages et la couche de distribution des messages sont ajoutées. La couche de distribution des messages conserve les informations de chaque nœud périphérique et transmet les messages, ce qui améliore la capacité de traitement simultané et la stabilité du système et évite les problèmes de performances causés par le blocage de la transmission des messages.
4.4 Agrégation des messages
Lorsqu'il y a un événement populaire, le nombre de personnes en ligne en même temps peut atteindre des dizaines de millions, et un message de barrage sera diffusé à des dizaines de millions de terminaux. Si tout le monde en ligne envoie un message chaque seconde, le nombre de messages sera égal à celui-ci. Ce qui doit être envoyé est de 1 kW x 1 kW, ce qui représente une très grande quantité de messages. À ce stade, la couche de distribution des messages et la couche d'accès seront soumises à une forte pression.
L'analyse a révélé que ces messages proviennent tous de la même pièce et appartiennent à des pièces chaudes, comme la salle de jeux S. Le nombre de téléspectateurs ne peut pas être réduit, nous ne pouvons donc que faire des histoires sur le nombre de messages. Le push de messages professionnels ne peut pas être réduit, et le nombre de messages diffusés doit être réduit, c'est pourquoi l'agrégation des messages a été pensée.
Pour les messages de salle, l'agrégation des messages est réalisée selon certaines règles et poussée par lots :

Une fois l'agrégation des messages mise en ligne, le QPS appelé par la couche de distribution de messages vers la couche d'accès est réduit d'environ 60 %, ce qui réduit considérablement la pression sur la couche d'accès et la couche de distribution de messages.
4.5 Algorithme de compression
Après l'agrégation des messages, le nombre de messages est réduit, mais la taille du corps du message est augmentée, ce qui affecte les E/S d'écriture. Si la taille du corps du message doit être réduite, on pense à la compression des messages.
Pour les algorithmes de compression, nous en avons sélectionné deux couramment utilisés sur le marché : zlib et brotli à titre de comparaison.
Nous avons capturé les données poussées par l'activité en ligne, sélectionné le niveau de compression le plus élevé et réussi la vérification de la compression :

On peut voir que brotli présente de grands avantages par rapport à zlib, et l'algorithme de compression brotli a finalement été choisi.
Choisissez d'effectuer une compression des messages au niveau de la couche de distribution des messages pour éviter une compression répétée sur chaque nœud d'accès et un gaspillage de performances. Une fois en ligne, cela améliore non seulement le débit, mais réduit également les coûts d’utilisation du haut débit.
5. Conception technologique de garantie de service
De nos jours, certaines entreprises s'appuient fortement sur les messages push à long terme. La perte de messages affectera au mieux l'expérience utilisateur et, au pire, bloquera les processus métier ultérieurs, affectant ainsi le flux commercial. Afin de garantir la garantie des messages de service à long terme, le travail suivant a été effectué.
5.1 Déploiement multi-actif
Le déploiement multiactif, en déployant la même architecture système et les mêmes services dans différents emplacements géographiques, permet un basculement rapide du système en cas de panne géographique unique, améliorant ainsi la stabilité et la disponibilité du système.

Le déploiement du service à long terme implique principalement les points suivants :
- 1) LongConnect a déployé des points d'accès dans l'est de la Chine, le sud de la Chine et le nord de la Chine, prenant en charge les trois principaux opérateurs. Des points d'accès ont également été déployés dans des salles informatiques auto-construites dans le sud de la Chine et le centre de la Chine pour prendre en charge l'accès indépendant des utilisateurs étrangers ; aux salles informatiques de Singapour a été ajouté un point ;
- 2) Pour différents scénarios commerciaux, basculez entre les nœuds cloud et les nœuds auto-construits en temps réel. Étant donné que les coûts des nœuds cloud et des salles informatiques auto-construites sont différents, les coûts doivent être contrôlés autant que possible tout en garantissant la qualité du service.
Au cours du fonctionnement en ligne actuel, des instabilités du réseau de nœuds uniques ou de salles informatiques sont parfois rencontrées. Grâce à la couche de contrôle, les nœuds problématiques sont supprimés en quelques secondes, ce qui réduit considérablement l'impact sur l'entreprise.
5.2 Canaux de messages hauts et bas
Les messages multiservices accèdent à de longues connexions, mais l'importance des différents messages est différente, comme les messages de barrage et les messages d'invitation pk. La perte de quelques messages de barrage n'aura pas un grand impact sur l'expérience utilisateur, mais si le message d'invitation pk est perdu. , cela empêchera l'entreprise pk de poursuivre les processus ultérieurs.
Pour différents niveaux de messages, des canaux de messages de haute qualité sont utilisés. Les nouvelles importantes sont diffusées sur la chaîne de haute qualité et les informations ordinaires sur la chaîne de mauvaise qualité. De cette manière, les messages importants et ordinaires sont physiquement séparés et la distribution des messages donne la priorité aux messages importants.

Pour les canaux de haute qualité, la double distribution est garantie et la déduplication idempotente est effectuée au niveau de la couche d'accès. Tout d'abord, les messages importants sont destinés au niveau utilisateur et le volume ne sera pas très important, donc la pression sur la couche d'accès n'augmentera pas beaucoup. De plus, les tâches à double livraison sont déployées dans plusieurs salles informatiques, ce qui réduit l'impact de la gigue du réseau dans une seule salle informatique.
Après la mise en ligne des canaux de haute qualité et de mauvaise qualité, nous avons rencontré des fluctuations sortantes de l'intranet. À ce moment-là, les nœuds de travail affiliés à l'intranet poussaient les messages de manière anormale, mais les nœuds de travail de haute qualité sur le cloud pouvaient envoyer des messages normalement, ce qui était normal. assuré l'arrivée de messages de haute qualité et ainsi assuré que les services de haute qualité ne seront pas affectés.
5.3 Fonctions Gundam
Le canal d'optimisation haut-bas résout le lien entre la tâche et la couche d'accès, mais la connexion push de message implique plusieurs liens, tels que la couche de service vers la tâche et la couche d'accès vers le client.
Pour l’ensemble de la liaison, le taux d’arrivée du terminal est assuré par la mise en œuvre du mécanisme must-reach, appelé fonction reach.

Implémentation des fonctions :
- 1) Chaque message introduit msgID et le client effectue une déduplication idempotente et un accusé de réception après avoir reçu le message ;
- 2) Le serveur effectue une détection d'accusé de réception sur msgid, et s'il n'y a pas d'accusé de réception, le serveur réessayera la livraison pendant la période de validité.
Taux d'arrivée final = (1-(1-r)^(n+1)), où : r est le taux d'arrivée unique de la diffusion et n est le nombre maximum de tentatives.
Par exemple : r = 97 %, n=2, alors le taux d'arrivée final peut atteindre (1-(1-0,97)^(2+1)) = 99,9973 %
6. Conception de la garantie de livraison pour les messages entrant et sortant de la « salle »
Certains scénarios commerciaux nécessitent l'utilisation d'informations d'entrée et de sortie de l'utilisateur. Par exemple, lorsque l'utilisateur A entre dans la salle de diffusion en direct, la page affiche un message invitant l'utilisateur A à entrer dans la salle ou à rejoindre la liste en ligne.
1) Les informations d'entrée dans la salle seront perdues et un mécanisme de compensation est nécessaire. Je pensais que le message d'entrée de chambre pouvait être compensé en se connectant au battement de cœur, mais le battement de cœur est continu pendant la période de connexion en ligne, l'entreprise espère recevoir le message d'entrée de chambre une seule fois, le message d'entrée de chambre doit donc avoir un idempotent. mécanisme.
2) Les informations de départ de la chambre seront également perdues. En cas de perte, l'entreprise ne peut pas supprimer les utilisateurs de la liste en ligne. Un mécanisme de compensation est également nécessaire pour le moment. À ce stade, vous devez ajouter une machine d'état pour la connexion et maintenir la machine d'état via les battements de cœur. Lorsque le battement de cœur est perdu, la connexion est considérée comme déconnectée et l'utilisateur se désactive.

7. Planification future
Après plusieurs itérations du service de connexion longue unifié, les fonctions de base sont devenues stables et le service de connexion longue sera amélioré et optimisé à l'avenir.
Concentrez-vous principalement sur les directions suivantes :
- 1) Dataisation : améliorer encore la capacité de collecter des statistiques de données sur la qualité du réseau à liaison complète sur de longues connexions et le suivi des liaisons complètes des messages de grande valeur ;
- 2) Intelligentisation : l'établissement de la connexion sur l'appareil, la sélection du point d'accès, etc. peuvent être automatiquement ajustés en fonction de l'environnement réel ;
- 3) Optimisation des performances : dans le module de connexion de la couche d'accès, les Ctrips qui traitent les messages de liaison montante et descendante sont partagés, réduisant ainsi le nombre de Ctrips au niveau de la couche d'accès et améliorant encore les performances d'une seule machine et le nombre de connexions ;
- 4) Extension des fonctions : ajout d'une fonction de messagerie hors ligne, etc.
8. Documents de référence
[1] Vous apprendre étape par étape comment écrire une longue connexion Socket basée sur TCP
[5] Explication détaillée de TCP/IP - Chapitre 11·UDP : Protocole de datagramme utilisateur
[6] Explication détaillée de TCP/IP - Chapitre 17·TCP : Transmission Control Protocol
[7] Du débutant au compétent en WebSocket, une demi-heure suffit !
[8] Un article suffit pour comprendre rapidement le protocole TCP
[9] Comprenez rapidement les différences entre TCP et UDP
[10] En un seul pipi, vous pouvez rapidement comprendre la différence entre TCP et UDP
[11] Qu'est-ce que Socket exactement ? Comprenez en un seul article !
[12] Lorsque nous lisons et écrivons Socket, que lisons-nous et écrivons-nous exactement ?
[13] Si vous deviez concevoir le protocole TCP, que feriez-vous ?
[14] Approfondissez le système d'exploitation et comprenez ce qu'est Socket dans un article
[15] Il est facile de comprendre comment sont implémentés des serveurs hautes performances.
- Un article d'introduction au développement de la messagerie instantanée mobile : " Un article suffit pour les débutants : Développer la messagerie instantanée mobile à partir de zéro "
- Code source du framework de messagerie instantanée open source : https://github.com/JackJiang2011/MobileIMSDK ( Adresse alternative, cliquez ici )
(Cet article a été publié simultanément sur : http://www.52im.net/thread-4647-1-1.html )