Eine kurze Diskussion über drei Redis-Methoden zur Implementierung von Abonnement-Push in Echtzeit

Wie können mehr als 200.000 Push-Benutzer Parallelität der zweiten Ebene erreichen? In diesem Artikel werden drei Methoden vorgestellt, mit denen Redis den Abonnement-Push in Echtzeit implementieren kann: MQ, herkömmliche geplante Aufgaben und die SortSet-Warteschlange von Redis. Es hat einen gewissen Referenzwert. Freunde in Not können sich darauf beziehen. Ich hoffe, es wird für alle hilfreich sein.

【Verwandte Empfehlung: Redis-Video-Tutorial】

Vor einiger Zeit haben wir ein Projekt für das Coupon-Center des Unternehmens entwickelt, das mit Redis als Schlüsseltechnologie umgesetzt wird.

Lass uns zuerst über das Coupon-Sammelzentrum-Projekt sprechen. Dieses Projekt ähnelt dem Coupon-Sammelzentrum der JD.com-App. Natürlich stammt das Bild von JD.com, nicht vom Unternehmen. . .

Für den Erhalt von Gutscheinen gibt es eine Funktion namens Abonnement-Push.

Was ist Coupon-Abo-Push?

bedeutet, dass der Benutzer die Push-Benachrichtigung des Gutscheins abonniert hat und die Erinnerungsinformationen eine Minute vor der Inanspruchnahme an die App des Benutzers gesendet werden.

Ursprünglich sollte diese Abonnementfunktion vom Nachrichtencenter implementiert werden, aber es hieß, sie sei nicht in kurzer Zeit umsetzbar. Also habe ich, der Verantwortliche für Gutscheine, es getan -.-!. Der konkrete Plan besteht darin, den bestimmten Push-Zeitpunkt zu erreichen. Das Coupon-System ruft die Push-Schnittstelle des Nachrichtencenters auf, um die Informationen zu verbreiten.

Lassen Sie uns das Geschäftsszenario dieser Funktion analysieren. Das Unternehmen hat derzeit mehr als 6.000 W registrierte Benutzer, fragen Sie also nicht, wer es ist. . . Wenn es beispielsweise einen Rabattgutschein ohne Schwellenwert gibt, der bei der Bestellung einen sofortigen Rabatt von 20 Yuan bietet, werden sich mehr Leute diesen Gutschein schnappen. Wir gehen vorsichtig davon aus, dass der Preis bei 100.000+ liegt, und es ist schwer zu sagen, ob dies der Fall ist liegt im Millionenbereich. Unser ursprüngliches Ziel sind 200.000 Menschen, daher werden diese 200.000 Push-Nachrichten in einer Minute verschickt! Und ein Benutzer kann mehrere Gutscheine abonnieren. Wir wissen also, dass es bei dieser Abo-Funktion zwei herausragende Schwierigkeiten gibt:

• Wirksamkeit von Push: Wenn der Push langsam ist, werden sich Benutzer darüber beschweren, dass sie nicht rechtzeitig benachrichtigt werden und die Möglichkeit verpassen, mit der Vorbestellung zu beginnen.

• Das Volumen des Pushs ist riesig: Die beliebten Coupons, jeder will sie ergattern!

Allerdings beeinflusst die Lautstärke des Pushs die Effektivität des Pushs. Das bereitet wirklich Kopfschmerzen!

Dann lassen Sie uns die Probleme einzeln lösen!

Probleme mit der Wirksamkeit von Push: Wenn sich ein Benutzer im Coupon-Sammelzentrum für eine Coupon-Sammelerinnerung anmeldet, wird im Hintergrund ein Abonnement-Erinnerungsdatensatz eines Benutzers generiert, der den Zeitpunkt aufzeichnet, zu dem Push-Informationen an den Benutzer gesendet werden . Es stellt sich also die Frage, wie das System schnell und in Echtzeit auswählen kann, welche Datensätze übertragen werden sollen!

Option 1:

MQs verspätete Lieferung. Obwohl MQ die verzögerte Zustellung von Nachrichten unterstützt, ist der Maßstab zu groß, 1s 5s 10s 30s 1m, und kann nicht für die Zustellung zu genauen Zeitpunkten verwendet werden! Und wenn der Benutzer das Abonnement nach der Ausführung des Abonnements kündigt, ist das Löschen der gesendeten MQ-Nachricht etwas umständlich und in kurzer Zeit schwer umzusetzen! Und Benutzer können kündigen und dann abonnieren, was wiederum das Problem der Deduplizierung mit sich bringt. Daher wird der Plan von MQ abgelehnt.

Option 2:

Traditionelle geplante Aufgaben. Dies ist relativ einfach. Um eine geplante Aufgabe zu verwenden, laden Sie die Abonnementerinnerungsdatensätze des Benutzers in die Datenbank und wählen Sie die Datensätze aus, die derzeit übertragen werden können. Aber es gibt ein Sprichwort, das gut zutrifft: Jedes Design, das vom eigentlichen Geschäft getrennt ist, ist ein Schurke. Lassen Sie uns analysieren, ob herkömmliche geplante Aufgaben für unser Unternehmen geeignet sind. Kann es die gleichzeitige Ausführung mehrerer Maschinen unterstützen? Im Allgemeinen nicht, kann es nur auf einer einzigen Maschine gleichzeitig ausgeführt werden.

ist normalerweise MySQL oder eine andere herkömmliche Datenbank und ist ein einzelner Tabellenspeicher. Unterstützt Sekunden, Minuten, Stunden und Tage, im Allgemeinen nicht zu schnell

Zusammenfassend wissen wir, dass herkömmliche geplante Aufgaben im Allgemeinen die folgenden Mängel aufweisen:

1. Es gibt nur eine Maschine, die die große Datenmenge nicht verarbeiten kann!

2. Schlechte Wirksamkeit. Die Häufigkeit geplanter Aufgaben darf nicht zu hoch sein. Wenn sie zu hoch ist, wird die Geschäftsdatenbank stark belastet!

3. Single Point of Failure.

Hängt die laufende Maschine, dann ist das gesamte Geschäft nicht erreichbar -. - Das ist eine schreckliche Sache! Daher sind herkömmliche geplante Aufgaben für dieses Unternehmen nicht geeignet. . . Sind wir also am Ende unserer Weisheit? Eigentlich nein! Wir müssen nur eine einfache Transformation der traditionellen geplanten Aufgaben vornehmen! Sie können es in einen geplanten Task-Cluster umwandeln, der auf mehreren Computern gleichzeitig ausgeführt werden kann. Die Effektivität kann bis zur zweiten Ebene genau sein und einzelne Fehlerquellen werden ausgeschlossen! Dies erfordert die Hilfe unseres leistungsstarken Redis.

Option 3:

Cluster für geplante Aufgaben Zuerst müssen wir die drei Probleme definieren, die der Cluster für geplante Aufgaben lösen muss! ​​

1. Die Effektivität muss hoch sein

2 Der Durchsatz muss stabil sein und es darf keinen Single Point of Failure geben Geplanter Aufgabencluster.

Die Architektur ist sehr einfach: Wir speichern die Abonnement-Push-Datensätze des Benutzers in der sortiertSet-Warteschlange des Redis-Clusters, verwenden den Erinnerungszeitstempel als Bewertungswert und richten dann auf jedem unserer Geschäftsserver einen Timer ein Bei einer Frequenz der zweiten Ebene ist meine Einstellung 1s, und nach dem Lastausgleich werden die zu übertragenden Benutzerdatensätze aus einer Warteschlange abgerufen und übertragen. Als nächstes analysieren wir die folgende Architektur. ​

1. Leistung: Ohne Bandbreite und andere Faktoren hängt sie grundsätzlich linear von der Anzahl der Maschinen ab. Je größer die Anzahl der Maschinen, desto größer der Durchsatz. Bei geringerer Anzahl der Maschinen nimmt der relative Durchsatz ab. ​

2. Wirksamkeit: Es wurde auf die zweite Stufe verbessert und die Wirkung ist akzeptabel. ​

3. Single Point of Failure? Existiert nicht! Es sei denn, der Redis-Cluster oder alle Server sind ausgefallen. . . .

Hier ist eine Analyse, warum Redis verwendet wird?

Erstens kann Redis als Hochleistungsspeicherdatenbank verwendet werden. Seine Leistung ist viel besser als die von MySQL, und es unterstützt Persistenz und weist eine gute Stabilität auf.

Die zweite Redis SortedSet-Warteschlange unterstützt natürlich die Sortierung nach Zeit als Bedingung, was uns bei der Auswahl der zu übertragenden Datensätze vollkommen zufriedenstellt.

ok~ Nun, da der Plan verfügbar ist, wie können wir ihn innerhalb eines Tages umsetzen? Ja, ich habe vom Entwurf dieses Plans bis zur Fertigstellung der grundlegenden Codierung nur einen Tag gebraucht. . . Weil die Zeit zu spät ist.

Zuerst verwenden wir user_id als Schlüssel und modifizieren dann den Warteschlangennummern-Hash in die Redis SortedSet-Warteschlange. Warum ist das so? Denn wenn der Benutzer zwei Gutscheine gleichzeitig abonniert und die Push-Zeit sehr nahe beieinander liegt, können die beiden Pushs zu einem zusammengefasst werden, und der Hash ist relativ gleichmäßig. Das Folgende ist ein Screenshot eines Teils des Codes:

Dann müssen wir die Anzahl der Warteschlangen festlegen. Im Allgemeinen definieren wir so viele Warteschlangen, wie wir für die Verarbeitung von Servern haben. Da zu wenige Warteschlangen zu Warteschlangenkonkurrenz führen können, können zu viele dazu führen, dass Datensätze nicht rechtzeitig verarbeitet werden. Die beste Vorgehensweise besteht jedoch darin, dass die Anzahl der Warteschlangen dynamisch konfigurierbar sein sollte, da sich die Anzahl der Online-Cluster-Maschinen häufig ändert.

Wir werden während der großen Aktion weitere Maschinen hinzufügen, oder? Und wenn das Geschäftsvolumen steigt, wird auch die Anzahl der Maschinen steigen, oder? Deshalb habe ich mir den Diamanten von Taobao ausgeliehen, um die Anzahl der Warteschlangen dynamisch zu konfigurieren.

Wie viele Datensätze wir jedes Mal aus der Warteschlange nehmen, kann ebenfalls dynamisch konfiguriert werden

Auf diese Weise kann der Durchsatz des gesamten Clusters jederzeit entsprechend der tatsächlichen Produktionssituation angepasst werden~. Daher verfügt unser Cluster für geplante Aufgaben immer noch über eine Funktion, die dynamische Anpassungen unterstützt ~. Die letzte Schlüsselkomponente ist der Lastausgleich. Das ist sehr wichtig!

Denn wenn dies nicht richtig gemacht wird, kann es dazu führen, dass mehrere Maschinen gleichzeitig um die Verarbeitung einer Warteschlange konkurrieren, was die Effizienz des gesamten Clusters beeinträchtigt! Als die Zeit sehr knapp war, habe ich mithilfe von Redis einen einfachen und praktischen Algorithmus verwendet, um den Schlüssel automatisch zu erhöhen und dann die Anzahl der Warteschlangen zu ändern. Dadurch wird weitgehend sichergestellt, dass nicht zwei Maschinen gleichzeitig um eine Warteschlange konkurrieren.

Weitere Programmierkenntnisse finden Sie unter:

Programmiervideo

! !

Die Speicherdatenquelle
Frequenz

Das obige ist der detaillierte Inhalt vonEine kurze Diskussion über drei Redis-Methoden zur Implementierung von Abonnement-Push in Echtzeit. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!