MySQL-Architekturdesign für die Bestellfunktion im E-Commerce-System

Das Grundmodell eines einfachen Bestellgeschäfts besteht aus Benutzern, Produkten (Bestand), Bestellungen und Zahlungen. Hier werden nur Produkte und Bestellungen berücksichtigt. Diese beiden Schritte müssen durchgeführt werden gleichzeitig abgeschlossen und eine Bestellung kann nicht aufgegeben werden. Der Lagerbestand wird nicht reduziert (überverkauft) oder der Lagerbestand wird reduziert, ohne dass eine Bestellung generiert wird (unterverkauft). Händler, die zu viel verkaufen, haben nicht genügend Lagerbestände und Verbraucher können keine Artikel kaufen, wenn sie Bestellungen aufgeben, was zu einer schlechten Erfahrung führt. Händler, die zu wenig verkaufen, haben zu viele Lagerbestände oder müssen Produktinformationen wiederholt ändern, was problematisch ist und die Erfahrung nicht gut ist.

In den frühen Tagen des Systems war der empfangene Datenverkehr gering und viele Unternehmerteams übernahmen ein Ein-Repository-Modell (ja, alle waren zusammen ...). Dieses Modell bietet großen Komfort. Es ist nicht datenbankübergreifend, geschweige denn knotenübergreifend. Es kann problemlos die von der Datenbank bereitgestellten Transaktionen zum Aufgeben von Bestellungen und zum Reduzieren des Lagerbestands verwenden und kann auch verschiedene gemeinsame Tabellen und Unterabfragen ausführen. Operationen (Egal wie ungewöhnlich die Anforderungen von MM sind, was kann ich tun, wenn ich SQL nicht kenne?) Doch gerade diese Vorteile werden bei steigendem Verkehrsaufkommen zum Hemmschuh für den Systemausbau. Gemeinsame Tabellen, Unterabfragen und Transaktionen binden mehrere Tabellen zusammen, was die Auflösung von Datenbanken und Tabellen erschwert.

In der späteren Zeit nimmt der Systemverkehr allmählich zu und die Lese- und Schreibleistung einer einzelnen Datenbank reicht nicht aus. Zu diesem Zeitpunkt wird davon ausgegangen, dass die Datenbank zerlegt und in Tabellen unterteilt wird. Beispielsweise werden Produkte und Bestellungen in zwei Cluster unterteilt, und die Cluster werden entsprechend ihrer jeweiligen Geschäftsdimension in Datenbanken und Tabellen unterteilt. Produkte können nach der Verkäuferdimension unterteilt werden, und Bestellungen werden im Allgemeinen nach der Käuferdimension unterteilt Die Redundanz erfolgt entsprechend der Verkäuferdimension. Das Problem, das zu diesem Zeitpunkt auftritt, ist immer noch ein klassisches Problem: Datenkonsistenz. Nach der Datenaufteilung befinden sich die Produkte und Bestellungen nicht in derselben Datenbank. Wie kann die Konsistenz zwischen den Bestelldaten in der Käuferdimension sichergestellt werden? und die Bestelldaten in der Verkäuferdimension. Es gibt zwei Lösungen:

(1) Verteilte Transaktionen, die klassische basiert auf 2PC. Der Vorteil besteht darin, dass nach einer ausreichenden Verpackung zwar Unterschiede zwischen der Verwendung und einer einzelnen Bibliothek (hauptsächlich komplexe Abfrageanweisungen) bestehen, die Änderungen für das Unternehmen jedoch insgesamt nicht groß sind. Der Nachteil besteht darin, dass die Leistung zu schlecht ist. Die ursprüngliche Einführung verteilter Datenbanken diente hauptsächlich dazu, die Leistung exponentiell zu verbessern. Aufgrund der Einführung verteilter Transaktionen wurde diese Leistungsverbesserung jedoch stark reduziert.

(2) Nachrichten-Middleware, der Protagonist dieses Artikels. Eine der Funktionen der Nachrichten-Middleware besteht darin, für die Kommunikation zwischen verschiedenen Systemen verantwortlich zu sein, was sich hier sehr gut für das Synchronisationsproblem von Waren- und Bestellsystemen eignet. Der Bestellvorgang nach Einführung der Nachrichten-Middleware ist: Nachdem Benutzer A eine Bestellung aufgegeben hat, sendet er eine Nachricht an die Nachrichten-Middleware. Das Produktsystem abonniert die Bestellnachricht und zieht den entsprechenden Bestand ab.

Hier sind einige Punkte zu beachten:

a. Die Übermittlung von Nachrichten dauert, bevor eine Bestellung aufgegeben wird Wenn der Lagerbestand tatsächlich reduziert wird, kann die erfolgreiche Bestellung erst angezeigt werden, nachdem der Lagerbestand erfolgreich reduziert wurde. Das heißt, die Bestellung wird markiert, der Status ist für den Benutzer jedoch nicht sichtbar Das System reduziert den Bestand erfolgreich, das Bestellsystem wird benachrichtigt, um den Status zu aktualisieren (immer noch eine Nachrichten-Middleware-Anwendung).

b Die Zuverlässigkeit der Nachricht ist sehr hoch Die Nachricht wird zugestellt, wenn die Nachricht nicht erfolgreich gesendet werden kann.

c Sie müssen die Nachrichten-ID selbst ausführen, um Duplikate zu entfernen.

d. Front-End-Benutzer möchten so schnell wie möglich über den Erfolg informiert werden Wenn der Bestellbestand nach einer gewissen Zeit nicht erfolgreich abgezogen wurde, sollte der Benutzer zu diesem Zeitpunkt über den Bestellfehler informiert werden, und zwar in diesem Teil Der abgezogene Lagerbestand muss regelmäßig aufgefüllt werden.

Die Einführung von Nachrichten-Middleware kann das Problem der verteilten Datenbankdatensynchronisierung effektiv lösen und verteilte Transaktionen vermeiden. Und der zusätzliche Vorteil besteht darin, dass gleichzeitige Sperrkonflikte bei der Reduzierung des Lagerbestands reduziert werden, was die Leistung verbessert.