Lösung zum Generieren einer eindeutigen Datenbank-ID in verteilten Situationen

ID als eindeutige Kennung des Unternehmens wird häufig im Datendesign verwendet, zum Beispiel:

•Produkt – Produkt_ID

•Bestellung – Bestell_ID

•Message—— message_id

Diese Bezeichner sind oft der Primärschlüssel der Datenbank. MySQL erstellt einen Clustered-Index für den Primärschlüssel. Im Vergleich zum normalen Index, der auf den Clustered-Index verweist, reduziert er eine Indexabfrage und ist sehr schnell. Unternehmen wie Nachrichten und Bestellungen müssen im Allgemeinen Daten in umgekehrter chronologischer Reihenfolge abfragen. Eine Möglichkeit besteht darin, einen Index für die Zeitspalte zu erstellen. Es ist besser, sich auf die Einfügereihenfolge der ID selbst zu verlassen. Daher muss die verteilte ID zwei Kernbedingungen erfüllen:

• Global eindeutig

• Zeitlicher Trend in der Reihenfolge

Manche Leute sagen vielleicht, dass es nicht möglich ist, MySQLs auto_increment zu verwenden direkt. Reicht das? In der Anfangszeit eines Unternehmens würde ich mich auch für diese Lösung entscheiden. Sie ist einfach, effizient und schnell – Startups müssen immer noch schnell iterieren und Produkte so schnell wie möglich produzieren, und Produkte ändern sich häufig Zeit für die Entwicklung ist möglicherweise nicht sinnvoll. Ja, es wurde wertvolle Zeit verschwendet. Allerdings gibt es bei dieser Lösung einige Probleme:

• Beeinflusst das parallele Einfügen – Datensatz B hängt vom Primärschlüssel von Datensatz A ab. Sie müssen warten, bis Datensatz A erfolgreich eingefügt wurde, und A.id erhalten, bevor Sie können Datensatz B einfügen

•Die Datenwiederherstellung ist schwierig – nachdem die Daten versehentlich gelöscht wurden oder verloren gegangen sind, da im Protokoll keine ID vorhanden ist, kann die Datenkorrelation nicht direkt bestimmt werden

• Betrifft den Sub -Datenbank und Untertabelle – da die ID eingegeben werden muss, um bekannt zu sein, können Datenbanken und Tabellen nicht basierend auf dem Primärschlüssel des Unternehmens aufgeteilt werden

Daher müssen Sie sich Zeit nehmen, nachdem das Unternehmen stabil ist um vorzeitige technische Schulden abzubezahlen.

Gemeinsame Lösungen

Verwenden Sie das Auto_Inkrement der Datenbank, um eine eindeutige ID zu generieren

Vorteile

•Einfach, Nutzung vorhandener Funktionen, geringer Entwicklungsaufwand

•ID-Schrittgröße ist fest

Nachteile

•Einzelner Schreibpunkt, nicht hochverfügbar

•Auch wenn mehrere Hauptbibliotheken entsprechend unterschiedlichem Auto_Inkrement erweitert werden Ausgangspunkte verbessern zwar die Verfügbarkeit, können aber die strikte Reihenfolge der IDs nicht garantieren

• Sie müssen jedes Mal auf die Datenbank zugreifen, wodurch leicht die Leistungsobergrenze erreicht werden kann

IDs stapelweise abrufen und Weisen Sie sie einzeln zu

Diese Art von Die Lösung besteht darin, die ID-Daten in der Datenbank zu speichern. Der ID-Dienst ruft jedes Mal N IDs aus der Datenbank ab und aktualisiert den aktuellen maximalen ID-Wert auf die Originaldaten N. Der ID-Dienst beginnt bei jedem Empfang einer ID-Generierungsanforderung mit diesem N. Die IDs werden der Reihe nach zurückgegeben.

Vorteile

•Batch-Erfassung, nicht jedes Mal auf die Datenbank zugreifen müssen, geringer Datenbankdruck

Nachteile

•Der gesamte Service ist immer noch ein einziger Punkt

•Dienstausfall und Neustart führen zu ID-Unterbrechungen

•Horizontale Erweiterung nicht möglich

Verbesserung

Fügen Sie einen Backup-Dienst hinzu, wenn der Hauptdienst hängt Wenn es aktiviert ist, wird es zum Backup-Dienst weitergeleitet. Sie können vip keepalived verwenden oder einen Proxy hinzufügen.

uuid

Vorteile

•Lokale Generierung von IDs, kein Single Point of Problems, keine Leistungsengpässe

Nachteile

•Inkrement ist nicht garantiert Bestellt

•Die Länge ist zu lang und die Leistung als Primärschlüssel ist gering

Snowflake-ähnlicher Algorithmus

Snowflake ist Twitters Open-Source-Algorithmus zur verteilten ID-Generierung Die Kernidee ist: Eine lange Typ-ID verwendet 41 Bit als Anzahl der Millisekunden, 10 Bit als Maschinennummer und 12 Bit als Seriennummer innerhalb von Millisekunden. Dieser Algorithmus kann theoretisch bis zu 1000 * (2 ^ 12) oder 400 W-IDs pro Sekunde auf einem einzelnen Computer generieren, was den Geschäftsanforderungen vollständig gerecht wird.

Basierend auf den Ideen von Snowflake und der Kombination der Geschäftslogik und Parallelität jedes Unternehmens können Sie Ihren eigenen verteilten ID-Generierungsalgorithmus implementieren.

Vorteile

•Zeit ist auf hohem Niveau, Tendenz steigend

•Einfache Implementierung, nicht auf andere Dienste angewiesen, leicht erweiterbar

Nachteile

•Es gibt keine globale Uhr und eine einzelne Maschine ist absolut in Ordnung, aber aus Sicht des gesamten Clusters ist der Trend in Ordnung

Anmerkungen

•Da die ID häufig als Kennung für Unterdatenbanken und Tabellen verwendet wird, ist es erforderlich, dass diese IDs einen gewissen Grad an Zufälligkeit aufweisen, damit die Daten nach der Aufteilung nicht ungerade sind. Die Sequenznummer darf nicht bei 1 beginnen von jeder Millisekunde. Zweitens kann es von 0 bis 9 beginnen