Salut Je suis récemment tombé sur une description assez intéressante de l'architecture des canaux Pusher et j'ai décidé de la traduire pour vous. À mon avis, l'auteur a très facilement décrit les approches de construction d'une architecture hautement chargée et évolutive. Très probablement, l'article sera utile aux débutants, ainsi qu'aux spécialistes de domaines connexes.
Au bureau Pusher, nous avons un petit comptoir avec un nombre toujours croissant. Il indique le nombre de messages remis pour toute l'existence de canaux pousseurs. Vendredi à 22h20 UTC, le nombre a augmenté d'une catégorie pour atteindre 10 000 000 000 000. Il a 13 zéros - 10 billions.
Vous pourriez penser que le nombre total de messages est une métrique gonflée inutile. Mais ce nombre est un indicateur clé du succès de Pusher Channels, notre produit de communication en temps réel. Tout d'abord, ce compteur reflète la confiance que nous accordent les utilisateurs. Deuxièmement, il mesure l'évolutivité de notre système. Afin d'augmenter le nombre, chez Pusher, nous devons nous assurer que les utilisateurs font confiance à l'envoi de messages à notre service, et nous devons être sûrs que notre système est capable de traiter ces messages. Mais que devons-nous délivrer 10 billions de messages? Voyons voir.
Environ 200 000 messages sont envoyés par seconde via les canaux Pusher, et des millions aux heures de pointe. Par exemple, lorsque le New York Times a utilisé le service pour tenir ses lecteurs informés du déroulement de l'élection présidentielle américaine.
Voyons d'abord les canaux Pusher comme une grande boîte noire à travers laquelle passent tous ces messages:
Pusher Channels est un système de type publication-abonnement. Les clients s'abonnent à des canaux (par exemple, "btc-usd" ou "private-user-jim"), tandis que d'autres clients leur envoient des messages. Si un million de personnes sont abonnées au canal "btc-usd" et que quelqu'un y envoie le coût réel du bitcoin, les canaux Pusher devront livrer un million de messages. Nous le faisons en quelques millisecondes.
Un serveur ne peut pas délivrer autant de messages en si peu de temps. Par conséquent, nous utilisons trois techniques éprouvées: le déploiement, le partage et l'équilibrage de charge. Voyons ce qu'il y a dans la boîte noire.
Des millions d'abonnés sont répartis sur environ 170 serveurs Edge puissants, chacun détenant environ 20 000 connexions. Chacun de ces serveurs se souvient de la liste des chaînes qui intéressent ses clients et s'y abonne dans le service central Redis . Même si 2000 clients sont intéressés par «btc-usd» sur le serveur de périphérie, il n'a besoin de s'y abonner qu'une seule fois. Ainsi, lorsqu'un nouveau message arrive sur le canal, Redis envoie 170 messages aux serveurs de périphérie, qui envoient déjà 20 000 messages à leurs abonnés. Cette approche est appelée fan-out.
Mais un simple fan-out ne nous suffit pas, car il reste un composant Redis central par lequel passent tous ceux qui envoient des messages. Cette centralisation limite le nombre de messages envoyés par seconde. Pour contourner cette limitation, le service Redis central se compose de nombreux fragments Redis. Chaque canal, à son tour, est attaché au redécoupage en hachant son nom. Lorsque le client souhaite envoyer un message, il se rend au service de repos. Ce dernier hache le nom du canal et, en fonction du résultat, détermine le fragment Redis nécessaire auquel le message doit être envoyé. Cette approche est appelée sharding.
Il semble que nous passions simplement de la centralisation d'un service Redis à un service de repos. Mais ce n'est pas le cas, car le service de repos lui-même comprend environ 90 serveurs qui effectuent le même travail: ils reçoivent des demandes de publication, calculent des redis-shards et leur envoient des messages. Lorsqu'un éditeur souhaite envoyer un message, il se rend sur l'un des nombreux serveurs de repos. Cette approche est appelée équilibrage de charge.
Ensemble, le déploiement, le partage et l'équilibrage de charge permettent au système d'avoir un composant central. Cette propriété est essentielle pour atteindre l'évolutivité horizontale, qui permet d'envoyer des millions de messages par seconde.
Nous avons examiné les composants centraux du service Pusher Channels, mais il existe d'autres parties, telles que les métriques (comment obtenir ce nombre de 10 billions), les webhooks (comment informer les clients sur les événements intéressants), l'autorisation (restriction d'accès aux canaux), les données sur les actifs utilisateurs, limitation des tarifs (comment s'assurer que nos clients utilisent exactement autant de ressources qu'ils ont payé et qu'ils n'interfèrent pas avec les autres clients). Toutes ces fonctionnalités supplémentaires doivent être mises en œuvre sans sacrifier la bande passante, le délai de livraison des messages et la disponibilité de notre service dans son ensemble.