Wie wir alle wissen, werden Sie beim Entwerfen einer Website auf „Massen-SMS“ an Benutzer, „eine große Anzahl von Protokollen im Bestellsystem“, „Flash-Sale-Design“ usw. stoßen. Der Server kann so etwas plötzlich nicht verarbeiten In dieser Situation ist die Hilfe einer „Nachrichtenwarteschlange“ erforderlich, um die normale und effektive Nutzung des Systems sicherzustellen. In diesem Artikel wird hauptsächlich die Idee der Nachrichtenwarteschlange untersucht.
Verstehen Sie hauptsächlich die folgenden Kenntnisse:
1. Was ist eine Warteschlange und was kann sie?
2. Welche Anwendungsszenarien gibt es für die Ausrichtung?
3. Wie nutzt man Warteschlangen, um Dienste zu entkoppeln?
4. Wie verwende ich die Redis-Warteschlange, um hohen Druck zu beseitigen?
5. Wie verwende ich das professionelle Ausrichtungssystem RabbitMQ?
Die Hauptinhalte sind wie folgt zusammengefasst
@Nachrichtenwarteschlangenkonzepte, Prinzipien und Szenarien
@Entkopplungsfall: Warteschlangenverarbeitungsauftragssystem und Verteilungssystem
@ Traffic-Peak-Cut-Fall: Der Listentyp von Redis realisiert Flash-Sale
@RabbitMQ: Eine professionellere Lösung zur Nachrichtensystemimplementierung
1. Die Nachrichtenwarteschlange verstehen
1.1 Konzept der Nachrichtenwarteschlange
Im Wesentlichen ist die Nachrichtenwarteschlange eine Middleware mit einer Warteschlangenstruktur, was bedeutet, dass die Nachricht direkt nach dem Einfügen in diese Middleware zurückgegeben werden kann und nicht sofort von ihr verarbeitet werden muss Darüber hinaus wird es ein Programm geben, das die Daten liest und sie nacheinander verarbeitet.
Das heißt, wenn Sie auf eine Situation stoßen, in der die Parallelität besonders groß ist und lange dauert und Sie die Verarbeitungsergebnisse nicht sofort zurückgeben müssen, kann die Verwendung von Nachrichtenwarteschlangen solche Probleme lösen.
1.2 Kernstruktur
Stellen Sie die Warteschlange eines Geschäftssystems in die Warteschlange, fügen Sie die Nachrichten einzeln in die Nachrichtenwarteschlange ein und geben Sie anschließend direkt das erfolgreiche Ergebnis zurück Das Einfügen ist erfolgreich. In Zukunft wird es ein Nachrichtenverarbeitungssystem geben, das die Datensätze im Nachrichtensystem einzeln herausnimmt und verarbeitet und so einen Entnahmevorgang abschließt.
1.3 Anwendungsszenarien
Datenredundanz: Beispielsweise erfordert das Bestellsystem in Zukunft eine strikte Datenkonvertierung und -aufzeichnung. Die Nachrichtenwarteschlange kann diese Daten dauerhaft in der Warteschlange speichern, und dann gibt es sie Bestellungen, das nachfolgende Verarbeitungsprogramm erhält es, und nach Abschluss der nachfolgenden Verarbeitung wird der Datensatz gelöscht, um sicherzustellen, dass jeder Datensatz verarbeitet werden kann.
Systementkopplung: Nach der Verwendung des Nachrichtensystems werden das Enqueue-System und das Dequeue-System getrennt, was bedeutet, dass der normale Betrieb des anderen Systems nicht beeinträchtigt wird, solange es eines Tages abstürzt.
Traffic-Spitzenreduzierung: Beispielsweise können wir bei Flash-Sales und Rush-Sales Nachrichtenwarteschlangen in Verbindung mit Caching verwenden, die der Menge an sofortigen Besuchen effektiv standhalten und verhindern können, dass der Server überlastet wird und einen Absturz verursacht.
Asynchrone Kommunikation: Die Nachricht selbst kann direkt nach der Warteschlange zurückgegeben werden.
Skalierbarkeit: Beispielsweise kann die Bestellwarteschlange nicht nur Bestellungen verarbeiten, sondern auch von anderen Unternehmen genutzt werden.
Sortiergarantie: Einige Szenarien müssen in der Reihenfolge der Produkte verarbeitet werden, z. B. Single In und Single Out, um sicherzustellen, dass Daten in einer bestimmten Reihenfolge verarbeitet werden. Es ist möglich, Nachrichtenwarteschlangen zu verwenden.
Die oben genannten sind gängige Verwendungsszenarien der Nachrichtenwarteschlange. Natürlich ist die Nachrichtenwarteschlange nur eine Middleware und kann in Verbindung mit anderen Produkten verwendet werden.
1.4 Allgemeine Vor- und Nachteile der Warteschlangenimplementierung
Warteschlangenmedien
1. Datenbank wie MySQL (hohe Zuverlässigkeit, einfach zu implementieren, langsame Geschwindigkeit)
2, Caching, wie Redis (schnell, geringe Effizienz, wenn ein einzelnes Nachrichtenpaket zu groß ist)
3. Messaging-System, wie RabbitMq (hochprofessionell, zuverlässig, hohe Lernkosten)
Auslösemechanismus für die Nachrichtenverarbeitung
1. Lesen in Endlosschleife: einfach zu implementieren, im Fehlerfall nicht rechtzeitig wiederherstellbar (besser geeignet für Flash-Verkauf, zentralisierter, zentralisierter Betrieb und Wartung)
2. Geplante Aufgaben: Der Druck ist gleichmäßig verteilt, mit einer Verarbeitungsobergrenze; ein derzeit beliebter Verarbeitungsauslösemechanismus. (Der einzige Nachteil besteht darin, dass Sie auf das Intervall und die Daten achten müssen. Warten Sie nicht, bis die vorherige Aufgabe nicht abgeschlossen ist und die nächste Aufgabe erneut beginnt.)
3. Daemon-Prozess: ähnlich wie PHP- fpm und php-cg, erfordert Shell-Grundlagen
2. Entkopplungsfall: Warteschlangenverarbeitung „Bestellsystem“ und „Verteilungssystem"
Lassen Sie uns kurz über die Programmentkopplung sprechen: Mit der Programmentkopplung soll das Problem vermieden werden, wer zuerst gerettet werden soll, wenn Ihre Frau und Ihre Mutter gleichzeitig ins Wasser fallen (lacht)
Für Bestellungen können wir zwei Systeme entwerfen, eines ist das „Bestellsystem“ und das andere ist das „Liefersystem“. Das hätten wir alle beim Online-Einkauf sehen sollen Ich sende eine Bestellung ab, im Hintergrund sehe ich meine Ware in Bearbeitung. Zu diesem Zeitpunkt muss ein „Liefersystem“ einbezogen werden.
Wenn wir bei der Architektur das „Bestellsystem“ und das „Liefersystem“ gemeinsam entwerfen, wird es einige Probleme geben. Erstens wird der Druck auf das System größer sein „Das Vertriebssystem“ muss nicht unbedingt sofort auf diesen Druck reagieren.
Zweitens möchten wir nicht, dass der Ausfall des Bestellsystems zu einem Ausfall des Vertriebssystems führt, was den normalen Betrieb beider Systeme gleichzeitig beeinträchtigen würde. Wir hoffen also, diese beiden Systeme zu entkoppeln. Nachdem die beiden Systeme getrennt wurden, können wir über eine zwischengeschaltete „Warteschlangentabelle“ zwischen den beiden Systemen kommunizieren.
2.1 Architekturdesign
1. Zuerst empfängt das Bestellsystem die Bestellung des Benutzers und verarbeitet die Bestellung dann.
2. Diese Bestellinformationen werden dann in die Warteschlangentabelle geschrieben. Diese Warteschlangentabelle ist der Schlüssel für die Kommunikation zwischen den beiden Systemen.
3. Ein vom Verteilungssystem regelmäßig ausgeführtes Programm liest die Warteschlangentabelle zur Verarbeitung.
4. Nach der Verarbeitung durch das Vertriebssystem werden die verarbeiteten Datensätze markiert.
2.2 Programmablauf
3. Fall der Verkehrsspitzenreduzierung: Der Listentyp von Redis realisiert einen Flash-Sale
redis Basierend auf dem Speicher ist Redis eine sehr gute Ergänzung zur Datenbank, da Redis regelmäßig Daten auf die Festplatte schreibt und daher keine Sorgen über Stromausfälle machen muss hat mehr Vorteile als ein anderer Cache-Memcache. Darüber hinaus bietet Redis fünf Datentypen (String, doppelt verknüpfte Liste, Hash, Set, geordneter Set).
Im Allgemeinen ist Redis für Flash-Verkäufe eine gute Wahl, wenn Fälle, Eilkäufe und Fälle, die eine Warteschlange erfordern, sind sofort höher als bei Ihnen.
3.1 Listentyp im Redis-Datentyp
Die Redis-Liste ist eine doppelt verknüpfte Liste, und Daten können am Kopf oder Ende angehängt werden.
* LPUSH/LPUSHX: Fügen Sie den Wert in den Kopf der (/vorhandenen) Liste ein
* RPUSH/RPUSHX: Fügen Sie den Wert in das Ende der (/vorhandenen) Liste ein
* LPOP: Entfernen und das erste Element der Liste abrufen
* RPOP: Entfernen und das letzte Element der Liste abrufen
* LTRIM: Elemente im angegebenen Bereich behalten
* LLEN: Ermitteln Sie die Länge der Liste
* LSET: Legen Sie den Wert des Listenelements anhand des Index fest
* LINDEX: Ermitteln Sie das Element in der Liste anhand des Index
* LRANGE: Elemente innerhalb des angegebenen Bereichs der Liste abrufen
3.2 Architekturdesign
Ein Flash-Kill-Programmdesign mit einfacher Struktur.
1. Erfassen Sie zunächst, welcher Benutzer am Flash-Sale teilgenommen hat, und notieren Sie seine Zeit.
2. Speichern Sie die Benutzer-ID in der Redis-Liste und lassen Sie sie in die Warteschlange stellen. Wenn festgelegt ist, dass nur die ersten 10 Benutzer erfolgreich teilnehmen können und die Anzahl in der Liste ausreicht, dürfen keine weiteren Daten hinzugefügt werden. Auf diese Weise beträgt die Länge der Redis-Liste nur 10
3. Schreiben Sie schließlich die Daten in Redis langsam in die Datenbank, um den Druck auf die Daten zu verringern
3.3 Codeebene Design
1. Wenn der Benutzer den Flash-Sale startet, schreiben Sie die Anfrage des Flash-Sale-Programms in Redis (uid, time_stamp).
2. Wenn festgelegt ist, dass nur 10 Personen am Flash-Sale teilnehmen können, überprüfen Sie die Länge der in Redis gespeicherten Daten. Wenn sie die Obergrenze überschreitet, bedeutet dies, dass der Flash-Sale erfolgreich ist vollendet.
3. Schließlich werden die 10 in Redis gespeicherten Daten in einer Endlosschleife verarbeitet und dann werden die Daten langsam abgerufen und in der MySQL-Datenbank gespeichert.
Der Flash-Verkaufsbereich übt großen Druck auf die Datenbank aus. Wenn wir nicht über ein solches Design verfügen, führt dies zu einem Schreibengpass in MySQL. Wir verwenden eine Warteschlangenliste in Redis und stellen dann die Flash-Sale-Anfrage in Redis ein. Schließlich schreiben wir die Daten langsam über das Warehousing-Programm in die Datenbank. Auf diese Weise kann der Datenverkehr ausgeglichen werden und es gibt keine Auswirkungen auf MySQL . Zu viel Druck.
4. RabbitMQ
Hier erklären wir einige Verwendungsmöglichkeiten von RabbitMQ. Als wir zuvor über den Flash-Sale-Fall sprachen, erwähnten wir zunächst den Sperrmechanismus zur Verhinderung Wenn unsere Systemarchitektur sehr komplex ist, lesen mehrere Programme eine Warteschlange in Echtzeit oder ich habe mehrere Sendeprogramme, die eine oder mehrere Warteschlangen gleichzeitig bedienen, und ich möchte diese Programme sogar Um sie auf verschiedene Maschinen zu verteilen, ist die Verwendung der Redis-Warteschlange etwas unzureichend. Was ist zu diesem Zeitpunkt zu tun? Wir müssen einige professionellere Nachrichtenwarteschlangensysteme einführen, die das Problem besser lösen können.
4.1 RabbitMQ-Architektur und -Prinzipien
Funktionen: Vollständige Implementierung von AMQP, Cluster-Vereinfachung, Persistenz, plattformübergreifend
RabbitMQS-Nutzung
1. RabbitMQ-Installation (rabbitmq-server, php-amqplib)
2. Produzent sendet Nachricht an Nachrichtenkanal
3. Verbraucherverarbeitungsnachricht
Arbeitswarteschlange
Idee: Der Produzent sendet es an das Nachrichtensystem, und das Nachrichtensystem kapselt die Aufgabe in eine Nachrichtenwarteschlange und verwendet dann dieselbe Warteschlange für mehrere Verbraucher
Dies löst nicht nur die Entkopplung zwischen Produzenten und Verbrauchern, sondern kann auch die gemeinsame Nutzung von Verbrauchern und Aufgaben realisieren, wodurch der Druck auf den Server verringert wird.
5. Zusammenfassung
Das Obige konzentriert sich hauptsächlich auf das Erlernen der Konzepte, Prinzipien und Szenarien von Nachrichtenwarteschlangen. Entkopplungsfälle und Peak-Clipping-Fälle sowie Verständnis der einfachen Verwendung von RabbitMQ.
6. Frage
Was ist der größte Unterschied zwischen Redis und der Auswahl des Nachrichtenservers?
Nach meinem Verständnis ist Redis ein einzelner Thread. Einer ist synchron und der andere ist asynchron, während Redis synchrone Blockierung verwendet Nachrichtenserver Verwenden Sie asynchrone, nicht blockierende Funktionen.
Vor- und Nachteile gängiger Warteschlangenimplementierungen
Warteschlangenmedium:
MySQL: hohe Zuverlässigkeit, einfach zu implementieren, langsame Geschwindigkeit
Redis: hohe Geschwindigkeit, einzelne große Nachricht Paket Geringe Zeiteffizienz
Nachrichtensystem: hochprofessionell, zuverlässig, hoher Lernaufwand (zum Beispiel: RabbtiMQ)
Triggermechanismus für die Nachrichtenverarbeitung:
Endlosschleifenlesen: einfach zu implementieren, Bei einem Ausfall kann keine rechtzeitige Wiederherstellung erfolgen.
Geplante Aufgaben: Druckausgleich mit Obergrenze der Verarbeitungskapazität. (Der größte Fehler: Das Zeitintervall der Positionierungsaufgaben und der verarbeiteten Daten muss genau erfasst werden. Die nächste Aufgabe kann nicht als gestartet betrachtet werden, bevor die vorherige Aufgabe abgeschlossen ist.)
Daemon-Prozess: ähnlich wie PHP -FPM und PHP-CGI, erfordert Shell-Kenntnisse.
Verwandte Empfehlungen:
Implementierung und Anwendung der PHP-Nachrichtenwarteschlange
Wie PHP und Redis die Nachrichtenwarteschlange implementieren
PHP-Implementierung der Instanzfreigabe der Nachrichtenwarteschlangenklasse
Das obige ist der detaillierte Inhalt vonPHP implementiert die Nachrichtenwarteschlange. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
