Une brève discussion sur trois méthodes permettant à Redis de mettre en œuvre le push d'abonnement en temps réel

Comment plus de 200 000 utilisateurs push peuvent-ils atteindre une concurrence de deuxième niveau ? Cet article vous présentera trois méthodes permettant à Redis d'implémenter le push d'abonnement en temps réel : MQ, les tâches planifiées traditionnelles et la file d'attente SortSet de Redis. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il sera utile à tout le monde.

[Recommandations associées : Tutoriel vidéo Redis]

Il y a quelque temps, nous avons développé un projet pour le centre de coupons de l'entreprise. Le projet est basé sur Redis et est mis en œuvre en tant que technologie clé.

Parlons d'abord du projet de centre de collecte de coupons. Ce projet est similaire au centre de collecte de coupons de l'application JD.com. Bien sûr, la photo est prise de JD.com, pas de celle de l'entreprise. . .

Il existe une fonction appelée abonnement push pour recevoir des coupons.

Qu'est-ce que le push d'abonnement aux coupons ?

signifie que l'utilisateur s'est abonné à la notification push du coupon et que les informations de rappel seront transmises à l'application de l'utilisateur une minute avant de pouvoir les réclamer.

À l'origine, cette fonction d'abonnement était censée être implémentée par le centre de messagerie, mais ils ont dit qu'elle ne pourrait pas être implémentée dans un court laps de temps. Alors moi, la personne en charge des coupons, je l'ai fait -.-!. Le plan spécifique est d'atteindre le moment de transmission spécifique. Le système de coupons appelle l'interface push du centre de messagerie pour diffuser les informations.

Analysons le scénario business de cette fonction. La société compte actuellement plus de 6 000 utilisateurs enregistrés, alors ne demandez pas de qui il s’agit. . . Par exemple, s'il existe un coupon de réduction sans seuil offrant une réduction instantanée de 20 yuans lors de la passation d'une commande, davantage de personnes saisiront ce coupon. Nous estimons prudemment qu'il est à plus de 100 000, et il est difficile de dire si c'est le cas. un million de yuans. Notre objectif initial est de 200 000 personnes, donc ces 200 000 messages push seront diffusés en une minute ! Et un utilisateur peut s'abonner à plusieurs coupons. Nous savons donc qu'il existe deux difficultés majeures avec cette fonction d'abonnement :

• Efficacité du push : si le push est lent, les utilisateurs se plaindront de ne pas être avertis à temps et d'avoir raté l'occasion de commencez à saisir.

• Le volume du push est énorme : un coupon populaire que tout le monde veut récupérer !

Cependant, le volume de poussée affectera l'efficacité de la poussée. C'est vraiment un casse-tête !

Alors résolvons les problèmes un par un !

Problèmes liés à l'efficacité du push : lorsqu'un utilisateur s'abonne à un rappel de collecte de coupons dans le centre de collecte de coupons, un enregistrement de rappel d'abonnement d'un utilisateur sera généré en arrière-plan, qui enregistre le moment auquel il a été donné. à l'utilisateur. La question est donc de savoir comment le système peut sélectionner rapidement les enregistrements à diffuser en temps réel !

Option 1 :

Livraison retardée du MQ. Bien que MQ prenne en charge la livraison différée des messages, l'échelle est trop grande, 1s 5s 10s 30s 1m, et il ne peut pas être utilisé pour une livraison à un moment précis ! Et si l'utilisateur annule l'abonnement après avoir exécuté l'abonnement, l'opération de suppression du message MQ envoyé est un peu lourde et difficile à mettre en œuvre en peu de temps ! Et les utilisateurs peuvent annuler puis s'abonner, ce qui pose encore une fois le problème de la déduplication. Le plan de MQ est donc rejeté.

Option 2 :

Tâches planifiées traditionnelles. C'est relativement simple. Pour utiliser une tâche planifiée, chargez les enregistrements de rappel d'abonnement de l'utilisateur dans la base de données et sélectionnez les enregistrements qui peuvent actuellement être poussés. Mais il y a un dicton qui va bien : toute conception qui s’écarte du business réel est un voyou. Analysons si les tâches planifiées traditionnelles conviennent à notre entreprise !

Peut-il prendre en charge plusieurs machines exécutées en même temps en même temps

Généralement non, il ne peut être exécuté que sur une seule machine à la fois.

能否支持多机同时跑	一般不能，同一时刻只能单机跑。
存储数据源	一般是 mysql 或者其它传统数据库，并且是单表存储
频率	支持秒、分、时、天，一般不能太快

Source de données de stockage

Il s'agit généralement de MySQL ou d'une autre base de données traditionnelle, et il s'agit d'un stockage à table unique

Fréquence

Prend en charge les secondes, minutes, heures et jours, généralement pas trop rapides

Pour résumer, nous savons que les tâches planifiées traditionnelles présentent généralement les défauts suivants :

1. Il n'y a qu'une seule machine de traitement, et elle est incapable de gérer la grande quantité de données !

2. Mauvaise efficacité. La fréquence des tâches planifiées ne peut pas être trop élevée, cela mettra beaucoup de pression sur la base de données métier !

3. Point de défaillance unique.

Si le tapis de course raccroche, alors l'ensemble de l'entreprise sera indisponible -. - C'est une chose terrible ! Par conséquent, les tâches planifiées traditionnelles ne conviennent pas à cette activité. . . Alors, sommes-nous à bout de nerfs ? En fait non ! Il suffit de faire une simple transformation des tâches planifiées traditionnelles ! Vous pouvez le transformer en un cluster de tâches planifiées qui peut s'exécuter sur plusieurs machines en même temps, et l'efficacité peut être précise au deuxième niveau et rejeter les points de défaillance uniques ! Cela nécessite l’aide de notre puissant Redis.

Option 3 :

Cluster de tâches planifiées Nous devons d'abord définir les trois problèmes que le cluster de tâches planifiées doit résoudre !

1. L'efficacité doit être élevée

2. Le débit doit être important

3. .Voici le schéma architectural de l'ensemble du cluster de tâches planifiées.

L'architecture est très simple : nous stockons les enregistrements push d'abonnement de l'utilisateur dans la file d'attente sortedSet du cluster redis, et utilisons l'horodatage de rappel comme valeur de score, puis dans notre personnel Chaque serveur d'entreprise démarre une minuterie avec une fréquence de secondes. Mon paramètre est de 1 s. Ensuite, après l'équilibrage de charge, les enregistrements utilisateur à pousser sont obtenus à partir d'une file d'attente et poussés. Ensuite, nous analysons l’architecture suivante.

1. Performances : à l'exclusion de la bande passante et d'autres facteurs, elles sont essentiellement liées de manière linéaire au nombre de machines. Plus le nombre de machines est grand, plus le débit est élevé. Lorsque le nombre de machines est petit, le débit relatif diminue. ​

2. Efficacité : Il a été amélioré au deuxième niveau et l'effet est acceptable.

3. Point de défaillance unique ? N'existe pas ! Sauf si le cluster Redis ou tous les serveurs sont en panne. . . .

Voici une analyse des raisons pour lesquelles Redis est utilisé ?

Premièrement, Redis peut être utilisé comme base de données de stockage hautes performances. Ses performances sont bien meilleures que celles de MySQL, et il prend en charge la persistance et a une bonne stabilité.

La deuxième file d'attente redis SortedSet prend naturellement en charge le tri basé sur le temps comme condition, ce qui nous satisfait parfaitement dans la sélection des enregistrements à pousser.

ok~ Maintenant que le plan est disponible, comment pouvons-nous le mettre en œuvre en une journée ? Oui, il ne m'a fallu qu'une journée entre la conception de ce plan et la réalisation du codage de base. . . Parce qu'il est trop tard.

Nous utilisons d'abord user_id comme clé, puis modifions le hachage du numéro de file d'attente dans la file d'attente redis SortedSet. Pourquoi ? Parce que si l'utilisateur s'abonne à deux coupons en même temps et que le temps de push est très proche, les deux push peuvent être fusionnés en un seul~, et le hachage est relativement égal. Voici une capture d'écran d'une partie du code :

Ensuite, nous devons décider du nombre de files d'attente. De manière générale, nous définissons autant de files d'attente que nous avons de serveurs de traitement. Étant donné qu'un nombre insuffisant de files d'attente peut entraîner une concurrence dans les files d'attente, un nombre trop élevé peut entraîner un traitement non opportun des enregistrements. Toutefois, la meilleure pratique consiste à ce que le nombre de files d'attente soit configurable de manière dynamique, car le nombre de machines de cluster en ligne change souvent.

Pendant la grande promotion, nous ajouterons plus de machines, n'est-ce pas ? Et à mesure que le volume d'affaires augmente, le nombre de machines augmentera également, n'est-ce pas~. J'ai donc emprunté le diamant de Taobao pour configurer dynamiquement le nombre de files d'attente.

Le nombre d'enregistrements que nous retirons de la file d'attente à chaque fois peuvent également être configurés dynamiquement

De cette façon, nous peut le configurer à tout moment en fonction de la situation de production réelle, ajustant le débit de l'ensemble du cluster ~. Ainsi, notre cluster de tâches planifiées dispose toujours d'une fonctionnalité qui prend en charge l'ajustement dynamique ~. Le dernier élément clé est l’équilibrage de charge. C'est très important !

Car si cela n'est pas bien fait, plusieurs machines peuvent entrer en compétition pour traiter une file d'attente en même temps, affectant l'efficacité de l'ensemble du cluster ! Lorsque le temps était très serré, j'ai utilisé un algorithme simple et pratique qui utilise Redis pour auto-incrémenter la clé, puis modifier le nombre de files d'attente. Cela garantira en grande partie qu'aucune machine ne sera en compétition pour une file d'attente en même temps ~.

Pour plus de connaissances sur la programmation, veuillez visiter : Vidéo de programmation ! !

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!