Teilen Sie Ideen zur Implementierung der PHP-Flash-Sale-Funktion

Empfehlung: „PHP-Video-Tutorial“

1. Warum ist es schwierig, Flash-Sale-Geschäfte zu tätigen? 1) IM-System wie QQ oder Weibo, Every eins liest sich selbst (Freundesliste, Gruppenliste, persönliche Informationen);

2) Weibo-System, jeder kann die Daten der Personen lesen, denen Sie folgen, Eine Person kann die Daten mehrerer Personen lesen

3) Flash-Sale System, Inventar Es gibt nur eine Kopie, und jeder wird diese Daten gleichzeitig lesen und schreiben.

Mehrere Personen lesen eine Datenmenge.

Zum Beispiel: Xiaomi-Handys haben jeden Dienstag einen Flash-Sale. Es gibt zwar nur 10.000 Handys, aber der momentane Verkehr kann Hunderte oder Dutzende Millionen betragen.

Ein weiteres Beispiel: 12306 schnappt sich Tickets, die Tickets sind begrenzt, es gibt einen Bestand, es gibt viel sofortigen Verkehr und alle lesen den gleichen Bestand. Lese- und Schreibkonflikte, Sperren sind sehr ernst, hier ist das Sofortverkaufsgeschäft schwierig

. Wie optimieren wir also die Struktur des Flash-Sale-Geschäfts?

2. Optimierungsrichtungen

Es gibt zwei Optimierungsrichtungen (über diese beiden Punkte werde ich heute sprechen):

(1) Versuchen Sie, Anfragen vor dem System abzufangen

(lassen Sie keine Sperrkonflikte zu der Datenbank). Der Grund für das Scheitern des herkömmlichen Flash-Sale-Systems liegt darin, dass Anfragen die Back-End-Datenschicht überlasten, Konflikte beim Lesen und Schreiben von Daten schwerwiegend sind, die Parallelität hoch und die Antworten langsam sind und bei fast allen Anfragen eine Zeitüberschreitung auftritt. Der effektive Traffic für erfolgreiche Bestellungen ist sehr gering. Nehmen Sie als Beispiel 12306. Es gibt tatsächlich nur 2.000 Tickets für einen Zug. Wenn 2 Millionen Menschen kommen, um ihn zu kaufen, kann fast niemand ihn erfolgreich kaufen, und die Anforderungseffizienzrate beträgt 0.

(2)

Nützen Sie den Cache voll aus und kaufen Sie Tickets im Handumdrehen. Dies ist ein typisches Anwendungsszenario, bei dem es sich bei den meisten Anfragen um Zugnummernabfrage, Ticketabfrage, Bestellung und Zahlung handelt . Es gibt tatsächlich nur 2.000 Fahrkarten für einen Zug, und 2 Millionen Menschen kommen, um sie zu kaufen. Höchstens 2.000 Personen geben erfolgreich Bestellungen auf, und alle anderen fragen den Bestand ab. Die Schreibquote beträgt nur 0,1 %, und die Lesequote beträgt 99,9 %. Es eignet sich sehr gut zur Caching-Optimierung. Okay, lassen Sie uns später über die Methode „Abfangen von Anfragen so weit wie möglich vor dem System“ und die Methode „Caching“ sprechen und über die Details sprechen.

3. Gemeinsame Flash-Sale-Architektur

Die allgemeine Site-Architektur sieht im Grunde so aus (zeichnen Sie auf keinen Fall das Architekturdiagramm des Betrügertyps)

(1) Die Browserseite, die oberste Ebene, wird ausgeführt etwas JS-Code

(2) Serverseitig greift diese Schicht auf die Back-End-Daten zu und gibt die HTML-Seite an den Browser zurück

(3) Serviceschicht (Webserver), schützt die zugrunde liegenden Datendetails vor dem Upstream und stellt sie bereit Datenzugriff

(4) Datenschicht, das endgültige Inventar wird hier gespeichert, MySQL ist ein typisches Beispiel (natürlich wird es zwischengespeichert)

Obwohl dieses Bild einfach ist, kann es den Flash mit hohem Datenverkehr und hoher Parallelität anschaulich veranschaulichen Verkauf Geschäftsarchitektur Jeder sollte sich an dieses Bild erinnern.

Wie man jedes Level optimiert, wird später im Detail analysiert.

Vier. Optimierungsdetails auf jeder Ebene

Die erste Ebene, wie man den Client optimiert (Browserebene, APP-Ebene)

Eine Frage an alle, jeder hat WeChats Shake gespielt, um sich rote Umschläge zu schnappen, oder? Will Bei jedem Schütteln wird eine Anfrage an das Backend gesendet

? Wenn ich auf die Szene zurückblicke, in der wir eine Bestellung aufgegeben haben, um Tickets zu erhalten, blieb das System hängen, nachdem wir auf die Schaltfläche „Abfrage“ geklickt hatten, und der Fortschrittsbalken stieg langsam an. Als Benutzer klickte ich unbewusst erneut auf „Abfrage“, oder? Klicken Sie weiter, klicken Sie weiter, klicken Sie, klicken Sie. . . Ist es nützlich? Die Systemlast wird ohne Grund erhöht. Ein Benutzer klickt fünfmal und 80 % der Anfragen werden generiert.

(a) Auf der Produktebene ist die Schaltfläche

ausgegraut, nachdem der Benutzer auf „Abfrage“ oder „Tickets kaufen“ geklickt hat, sodass Benutzer keine wiederholten Anfragen stellen können auf nur x Sekunden beschränkt Eine Anfrage senden

Auf APP-Ebene können Sie ähnliche Dinge tun. Obwohl Sie WeChat wie verrückt schütteln, dauert es tatsächlich nur x Sekunden, um eine Anfrage an das Backend zu initiieren. Dies wird als „Abfangen von Anfragen so weit wie möglich stromaufwärts im System“ bezeichnet. Je weiter stromaufwärts, desto besser. Die Browserschicht und die APP-Schicht werden blockiert, sodass mehr als 80 % der Anforderungen blockiert werden können normale Benutzer (aber 99 % der Benutzer sind normale Benutzer) Es gibt keine Möglichkeit, die

High-End-Programmierer in der Gruppe aufzuhalten. Sobald Firebug das Paket erfasst, weiß jeder, wie http aussieht, und kann Programmierer nicht davon abhalten, for-Schleifen zu schreiben und http-Schnittstellen aufzurufen.

Die zweite Ebene: Anforderungsabfangen auf Serverebene

Wie kann man abfangen? Wie kann verhindert werden, dass Programmierer Schleifenaufrufe schreiben? Gibt es eine Grundlage für die Deduplizierung? IP? Cookie-ID? ...Es ist kompliziert. Für diese Art von Geschäft ist eine Anmeldung erforderlich. Verwenden Sie einfach die UID. Auf der serverseitigen Ebene führt Anforderungszählung und Deduplizierung auf der UID durch und muss die Zählung nicht einmal einheitlich speichern, sondern speichert sie direkt im serverseitigen Speicher (diese Zählung ist zwar ungenau, aber am einfachsten). ). Eine UID kann nur eine Anfrage in 5 Sekunden weiterleiten, wodurch 99 % der For-Schleifenanfragen blockiert werden können.

Nur eine Anfrage wird in 5 Sekunden bearbeitet, was ist mit den anderen Anfragen? Cache,

Seiten-Cache, die gleiche UID, die Zugriffshäufigkeit begrenzen, Seiten-Caching durchführen und alle Anfragen, die innerhalb von x Sekunden am Server ankommen, geben dieselbe Seite zurück. Bei Abfragen zum gleichen Element, wie z. B. Zugnummern, wird ein Seiten-Caching durchgeführt und alle Anfragen, die innerhalb von x Sekunden am Server eingehen, geben alle dieselbe Seite zurück. Indem den Datenfluss auf diese Weise begrenzt, kann nicht nur sichergestellt werden, dass Benutzer ein gutes Benutzererlebnis haben (es wird kein 404 zurückgegeben), sondern auch die Robustheit des Systems sichergestellt (unter Verwendung von Seiten-Caching zum Abfangen von Anfragen auf dem Server ).

Seiten-Caching stellt nicht unbedingt sicher, dass alle Server konsistente Seiten zurückgeben. Es kann auch direkt im Speicher jeder Site abgelegt werden. Der Vorteil besteht darin, dass es einfach ist, aber der Nachteil besteht darin, dass HTTP-Anfragen auf verschiedene Server fallen und die zurückgegebenen Ticketdaten unterschiedlich sein können. Dies ist die Anforderungsabfang- und Cache-Optimierung des Servers.

Okay, diese Methode stoppt Programmierer, die for-Schleifen schreiben, um http-Anfragen zu senden. Einige High-End-Programmierer (Hacker) kontrollieren 100.000 Broiler, haben 100.000 UIDs in ihren Händen und senden gleichzeitig Anfragen (abgesehen von der Frage der echten -Name-System, Xiaomi Es ist kein echtes Namenssystem erforderlich, um ein Mobiltelefon zu erhalten. Was soll ich jetzt tun? Der Serverkann es aufgrund des UID-Limits nicht stoppen.

Die dritte Schicht ist die abzufangende Serviceschicht (lassen Sie die Anfrage jedenfalls nicht auf die Datenbank fallen)

Wie fängt man die Serviceschicht ab? Bruder, ich weiß genau, dass Xiaomi nur 10.000 Mobiltelefone hat. Ich weiß, dass es nur 2.000 Tickets für einen Zug gibt. Was bringt es, 100.000 Anfragen an die Datenbank zu stellen? Genau, Anfragewarteschlange!

Erstellen Sie für Schreibanfragen eine Anfragewarteschlange und senden Sie jedes Mal nur eine begrenzte Anzahl von Schreibanfragen an die Datenschicht (geben Sie eine Bestellung auf, zahlen Sie für ein solches Schreibgeschäft).

Bei 1-W-Mobiltelefonen werden nur 10.000 Bestellanfragen gesendet an die Datenbank

3k Für ein Zugticket werden nur 3k Bestellanfragen an die Datenbank gesendet

Wenn alle erfolgreich sind, wird ein weiterer Stapel platziert. Wenn der Bestand nicht ausreicht, werden alle Schreibanfragen in der Warteschlange als „verkauft“ zurückgegeben aus".

Wie optimiert man Leseanfragen? Der Cache-Widerstand, egal ob Memcached oder Redis, sollte kein Problem darstellen, wenn eine einzelne Maschine 10 W pro Sekunde widerstehen kann. Bei einer solchen Strombegrenzung dringen nur sehr wenige Schreibanfragen und sehr wenige Lese-Cache-Fehlanfragen in die Datenschicht ein und 99,9 % der Anfragen werden blockiert.

Natürlich gibt es auch einige Optimierungen bei den Geschäftsregeln. Denken Sie daran, was 12306 getan hat: Ticketverkauf nach Zeit und Abschnitt Früher verkauften sie Tickets um 10 Uhr, aber jetzt verkaufen sie Tickets um 8 Uhr, 8:30 Uhr, 9 Uhr ... und Geben Sie alle halbe Stunde einen Batch frei: Verteilen Sie den Datenverkehr gleichmäßig.

Zweitens Optimierung der Datengranularität: Wenn Sie Tickets kaufen, sind für das verbleibende Ticketanfragegeschäft noch 58 Tickets übrig, also 26. Interessiert es Sie wirklich? ? Wenn der Verkehr stark ist, erstellen Sie einfach einen grobkörnigen „Ticketed“- und „Unticketed“-Cache.

Drittens die Asynchronität mancher Geschäftslogiken: etwa die Trennung von Bestellgeschäft und Zahlungsgeschäft. Diese Optimierungen hängen alle mit dem Geschäft zusammen. Ich habe bereits darauf hingewiesen, dass „alle architektonischen Entwürfe, die vom Geschäft getrennt sind, auch auf das Geschäft ausgerichtet sein müssen.“

Okay, endlich die Datenbankschicht

Der Browser hat 80 % abgefangen, Der Server hat 99,9 % abgefangen und die Serviceschicht hat auch Schreibanforderungswarteschlangen und Daten-Caching durchgeführt, die jedes Mal in die Datenbankschicht eingedrungen sind Anfragen sind kontrollierbar. Es besteht im Grunde kein Druck auf die Datenbank, und Sie können dies auf einer einzigen Maschine erledigen. Auch hier ist der Lagerbestand begrenzt und die Produktionskapazität von Xiaomi ist begrenzt.

Alle werden an die Datenbank übertragen, 1 Million Bestellungen wurden aufgegeben, 0 waren erfolgreich und die Anforderungseffizienz beträgt 0 %. Es wurden 3.000 Daten abgerufen, alle waren erfolgreich und die Anforderungseffizienz betrug 100 %.

5. Zusammenfassung

Die obige Beschreibung sollte sehr klar sein. Es gibt keine Zusammenfassung für das Flash-Sale-System. Ich werde die beiden Architekturoptimierungsideen aus meiner persönlichen Erfahrung wiederholen:

(1)

Versuchen Sie abzufangen die Anfrage im System-Upstream (je mehr Upstream, desto besser);

(2)

Häufig verwendete Caches, die mehr lesen und weniger schreiben (Cache widersteht Lesedruck);

Browser und APPs: Geschwindigkeitsbegrenzung

Server : Geschwindigkeitsbegrenzung gemäß UID, Seiten-Caching durchführen

Serviceschicht (Webserver): Anforderungswarteschlange entsprechend dem Geschäft schreiben, Datenverkehr steuern, Daten-Caching durchführen

Datenschicht: Xiantingxiao

Und: basierend auf dem Geschäft optimieren

6 , Fragen und Antworten

Frage 1. Gemäß Ihrer Architektur ist der Server derjenige mit dem größten Druck. Unter der Annahme, dass die Anzahl der tatsächlichen und effektiven Anforderungen 10 Millionen beträgt, ist es unwahrscheinlich, dass die Anzahl der Anforderungsverbindungen begrenzt wird mit diesem Teil des Drucks?

Antwort: Die Parallelität pro Sekunde beträgt möglicherweise nicht 1 kW. Es gibt zwei Lösungen:

(1) Die Serviceschicht (Webserver) kann durch Hinzufügen von Maschinen erweitert werden.

(2) Wenn nicht genügend Maschinen vorhanden sind, verwerfen Sie die Anfrage und verwerfen Sie 50 % (50 % werden direkt zurückgegeben und es später erneut versucht). Das Prinzip besteht darin, das System zu schützen und nicht alle Benutzer ausfallen zu lassen.

Frage 2. „Kontrollieren Sie 100.000 Broiler, haben Sie 100.000 Uids in der Hand und senden Sie gleichzeitig Anfragen.“

Antwort: Wie oben erwähnt, steuert die Serviceschicht (Webserver) die Schreibanforderungswarteschlange.

Frage 3: Kann der Cache, der die Zugriffshäufigkeit begrenzt, auch für die Suche verwendet werden? Wenn beispielsweise Benutzer A nach „Mobiltelefon“ sucht und Benutzer B nach „Mobiltelefon“ sucht, wird dann zuerst die zwischengespeicherte Seite verwendet, die durch die Suche von A generiert wurde?

Antwort: Diese Methode wird auch häufig bei „dynamischen“ Betriebsaktivitätsseiten verwendet, z. B. beim kurzfristigen Pushen von 4-kW-Benutzer-App-Push-Betriebsaktivitäten und beim Seiten-Caching.

Frage 4: Was tun, wenn die Warteschlangenverarbeitung fehlschlägt? Was soll ich tun, wenn die Masthühner die Warteschlange sprengen?

Antwort: Wenn die Verarbeitung fehlschlägt, wird die Bestellung als fehlgeschlagen zurückgegeben und der Benutzer wird aufgefordert, es erneut zu versuchen. Die Warteschlangenkosten sind sehr niedrig, daher wäre es schwierig, sie zu explodieren. Im schlimmsten Fall, nachdem mehrere Anfragen zwischengespeichert wurden, geben nachfolgende Anfragen direkt „kein Ticket“ zurück (es befinden sich bereits 1 Million Anfragen in der Warteschlange und alle warten, sodass es keinen Sinn macht, weitere Anfragen anzunehmen)

Frage 5: Server Speichern Sie zum Filtern die Anzahl der UID-Anfragen separat im Speicher jeder Site? Wenn dies der Fall ist, wie kann dann mit der Situation umgegangen werden, in der mehrere Servercluster die Antworten desselben Benutzers über den Load Balancer auf verschiedene Server verteilen? Oder sollten wir die Filterung vor dem Lastausgleich auf den Server stellen?

Antwort: Es kann im Speicher abgelegt werden. In diesem Fall scheint ein Server auf eine Anfrage pro 5 Sekunden beschränkt zu sein (vorausgesetzt, es sind 10 Maschinen vorhanden). Lösung:

1) Große Einschränkung hinzufügen (dies ist die empfohlene Lösung, die einfachste)

2) Führen Sie einen 7-Schichten-Balancing auf der Nginx-Schicht durch, damit eine UID-Anfrage möglichst auf derselben Maschine erfolgt

Frage 6: Wenn die Serviceschicht (Webserver) filtert, ist die Warteschlange eine einheitliche Warteschlange der Serviceschicht (Webserver) ? Oder gibt es für jeden Server, der Dienste bereitstellt, eine Warteschlange? Wenn es sich um eine einheitliche Warteschlange handelt, ist es dann erforderlich, eine Sperrenkontrolle durchzuführen, bevor die von jedem Server übermittelten Anforderungen in die Warteschlange gestellt werden?

Antwort: Sie müssen keine Warteschlange vereinheitlichen. In diesem Fall kann jeder Dienst eine geringere Anzahl von Anfragen weitergeben (Gesamtzahl der Stimmen/Anzahl der Dienste). Das Vereinheitlichen einer Warteschlange ist wiederum kompliziert.

Frage 7: Wie kann der verbleibende Lagerbestand rechtzeitig kontrolliert und aktualisiert werden, nachdem die Zahlung nach dem Flash-Sale abgeschlossen ist und der Platzhalter ohne Zahlung storniert wird?

Antwort: Es gibt einen Status in der Datenbank, unbezahlt. Wenn die Zeit beispielsweise 45 Minuten überschreitet, wird der Bestand erneut wiederhergestellt (bekannt als „Rückgabe an das Lager“). Die Inspiration für uns, Tickets zu ergattern, ist, dass wir es nach dem Start des Flash-Verkaufs nach 45 Minuten erneut versuchen, vielleicht dort wird es wieder Tickets geben~

Frage 8: Verschiedene Benutzer durchsuchen das gleiche Produkt und das in verschiedenen Cache-Instanzen angezeigte Inventar ist völlig unterschiedlich. Können Sie mir bitte sagen, wie ich die Cache-Daten konsistent machen oder Dirty Reads zulassen kann?

Antwort: Beim aktuellen Architekturdesign fallen Anfragen auf verschiedene Websites und die Daten sind möglicherweise inkonsistent (der Seitencache ist unterschiedlich). Dieses Geschäftsszenario ist akzeptabel. Aber die echten Daten auf Datenbankebene sind kein Problem.

Frage 9: Auch wenn die Geschäftsoptimierung berücksichtigt „3.000 Bahntickets, nur 3.000 Bestellanfragen gehen an die Datenbank“, führen diese 3.000 Bestellungen nicht zu einer Überlastung?

Antwort: (1) Die Datenbank kann immer noch 3.000 Schreibanfragen aushalten; (2) Daten können aufgeteilt werden; (3) Wenn 3.000 nicht verarbeitet werden können, kann die Serviceschicht (Webserver) die Anzahl der gleichzeitigen Verbindungen steuern. Basierend auf der Stresstestsituation ist 3k nur ein Beispiel;

Frage 10: Wenn die Hintergrundverarbeitung auf dem Server oder der Serviceschicht (Webserver) fehlschlägt, müssen Sie in Betracht ziehen, diesen Stapel fehlgeschlagener Anforderungen erneut abzuspielen? ? Oder einfach wegwerfen?

Antwort: Spielen Sie es nicht erneut ab, wenn die Abfrage fehlschlägt oder die Bestellung fehlschlägt.

Frage 11. Bei Flash-Verkäufen großer Systeme wie 12306 finden gleichzeitig viele Flash-Verkäufe statt.

Antwort: Vertikale Aufteilung

Frage 12. Eine weitere Frage kommt mir in den Sinn. Ist dieser Prozess synchron oder asynchron? Wenn es synchronisiert ist, sollte es eine langsame Rückmeldung geben. Wenn es jedoch asynchron ist, wie kann dann gesteuert werden, ob das Antwortergebnis an den richtigen Anforderer zurückgegeben werden kann?

Antwort: Die Benutzerebene ist definitiv synchron (die HTTP-Anfrage des Benutzers wird unterdrückt), und die Serviceschicht

(Webserver) kann synchron oder asynchron sein.

Frage 13. Flash-Sale-Gruppenfrage: In welchem ​​Stadium sollte der Lagerbestand reduziert werden? Was sollten Sie tun, wenn Sie einen Auftrag zum Sperren von Lagerbeständen erteilen, wenn eine große Anzahl böswilliger Benutzer Aufträge zum Sperren von Lagerbeständen erteilen, ohne dafür zu bezahlen?

Antwort: Die Anzahl der Schreibanfragen auf Datenbankebene ist sehr gering. Warten Sie, bis die Zeit abgelaufen ist, bevor Sie zur Position zurückkehren. Tipps: Dinge, auf die Sie achten sollten Einkaufszentrum nicht zugänglich...)

2. Mehrfachüberwachung, auf Überwachung achten, jemanden finden, den man im Auge behalten kann Wichtige Punkte des Flash-Sales:

1. Hohe Verfügbarkeit: aktiv-aktiv

2 Parallelität: Lastausgleich, Sicherheitsfilterung

Design-Ideen:

1, Statische Seiten: CDN (verwenden Sie vorgefertigte von großen Herstellern), URL-Ausblenden, Seitenkomprimierung, Caching-Mechanismus

2 Dynamische Seiten: Warteschlangen, asynchron, Qualifikationsrausch

Weitere Vorschläge:

1. Baidus Vorschläge: Opcode-Cache, CDN, größere Serverinstanz

2. Alibabas Vorschläge: Cloud-Überwachung, Cloud Shield, ECS, OSS, RDS, CDN

Ideen von CDN verwenden:

1. Verwenden Sie statische Ressourcen (Bilder, JS, CSS usw.) Hochladen auf CDN

2. Bitte beachten Sie, dass die CDN beim Aktualisieren nicht rechtzeitig aktualisiert wird aktuelle Umgebung und Form:

1. Benutzer: extrem große Anzahl, normale/schlechte Leute (CDN-Beschleunigung ist auch eine Art Ablenkung, weil er auf den CDN-Knoten in der Nähe zugreift)

2 1 oder 2 Sekunden reichen nicht aus, da die Verzögerung von 1 Sekunde blitzschnell enden kann und CDN erforderlich ist, damit Benutzer nahegelegene Knoten auswählen können)

3 ,Geschäftsprozess: Produktpräsentation und Registrierung an der Rezeption. Backend-Datenzugriff und Datenverarbeitung

Fügen Sie vor dem Flash-Sale eine Seite hinzu, um andere Produkte umzuleiten und zu bewerben Seite

2. Flash-Sale läuft: Klicken Sie hier, um die Flash-Sale-Seite aufzurufen

3. Flash-Sale-Ende: Meldung, dass die Veranstaltung beendet ist

Neue Idee: Denken Sie über das Problem im Hinblick auf den Zeitplan nach

Angenommen Das, was wir sehen, ist der laufende Flash-Sale, Vorwärtsschieben ist der Countdown, Zurückschieben ist das Ende

Das Bild unten zeigt das Problem aus der Sicht des Benutzers:

Code:

Statische Ressourcen , zur Bereitstellung im OSS gespeichert

Löschen Sie zuerst die Countdown-Seite und kopieren Sie sie sofort auf die Flash-Sale-Seite

Dann verwenden Sie Coretab, um dieses Skript regelmäßig auszuführen

Zusammenfassung:

Vom Countdown bis zum Eilverkauf: Dies erfolgt mithilfe geplanter Linux-Aufgaben und Shell-Skripten.

Der Eilverkauf ist vorbei: PHP wird dafür verwendet und endet, wenn die Tabelle nicht mehr vorhanden ist.

Struktur der Benutzerregistrierungsschicht.

Code : ??

Wie man von Schicht 2 zu Schicht rechnet 3? ?

Wie lang ist die Gesamtverzögerung, die dadurch verursacht wird, dass Schicht 2 Daten an Schicht 3 sendet + Netzwerkübertragungs-DNS-Auflösung und andere Faktoren, damit wir die Anzahl der Server bewerten können, die konfiguriert werden müssen

Zusammenfassung in 2 Sätzen:

1. Wenn der Schlüsselpunkt nicht übergeben wird, kehren Sie direkt zur vorherigen Ebene (Benutzerregistrierungsebene) zurück.

2 Wenn der Schlüsselpunkt übergeben wird, werden andere Ebenen benachrichtigt.

Wirksamkeit: ähnlich der Verschlüsselung und Entschlüsselung von Microsoft-Seriennummern

Warteschlange: Geordnete Sammlung mit Redis

Obergrenze: Technisches Flag-Bit

Datenverarbeitungsschicht

 

 

Das obige ist der detaillierte Inhalt vonTeilen Sie Ideen zur Implementierung der PHP-Flash-Sale-Funktion. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!