Sharding Übersicht
Cluster-Konfiguration
Jede laufende Cluster-Instanz unterhält eine lokale Kopie der Cluster-Konfiguration. Diese Kopie enthält Informationen über die bekannten Cluster-Worker und die zugehörige Slot-Zuweisung. Beide Informationen werden mithilfe eines Arrays von Strukturen dargestellt, wie nachstehend gezeigt. Änderungen an der lokalen Kopie werden durch Gossiping an die restlichen Cluster-Knoten kommuniziert.
Beachten Sie, dass Informationen, die sich auf die Knoteneigenschaften beziehen, nur vom Knoten selbst durch Ausstellung der entsprechenden Cluster-Befehle aktualisiert werden können. Beispielsweise kann ein Knoten kein **REPLICA** werden, indem er eine Gossip-Nachricht empfängt. Er kann seine aktuelle Rolle nur ändern, nachdem er eine CLUSTER REPLICATE Anforderung erhalten hat. Wir befolgen diese Einschränkung, um die Behandlung von Cluster-Fehlkonfigurationen bei Netzwerkpartitionen zu vermeiden. Diese Konvention erstreckt sich auch auf die Slot-Zuweisung, die durch direkte Anfragen an Cluster-Instanzen verwaltet wird, die mit den Befehlen CLUSTER [ADDSLOTS|DELSLOTS] und CLUSTER [ADDSLOTSRANGE|DELSLOTSRANGE] erfolgen.
loading...
Anfänglich sind die Cluster-Knoten leer und nehmen die Rolle eines **PRIMARY** ein, mit keinen zugewiesenen Slots und ohne Kenntnis anderer Knoten im Cluster. Der lokale Knoten enthält nur Informationen über sich selbst, die in workers[1] gespeichert sind, während workers[0] für spezielle Zwecke zur Anzeige nicht zugewiesener Slots reserviert ist. Garnet-Cluster-Knoten werden über den Befehl CLUSTER MEET miteinander verbunden, der eine spezielle Art von Gossip-Nachricht generiert. Diese Nachricht zwingt einen entfernten Knoten, den Sender zu seiner Liste vertrauenswürdiger Knoten hinzuzufügen. Entfernte Knoten werden in beliebiger Reihenfolge ab workers[2] gespeichert.
loading...
Informationen über die individuelle Slot-Zuweisung werden im Konfigurationsobjekt mithilfe eines Arrays vom Typ HashSlot-Struktur erfasst. Es enthält Informationen über den Slot-Status und den entsprechenden Eigentümer. Der Slot-Eigentümer wird anhand des Offsets im lokalen Exemplar des Worker-Arrays dargestellt. Der Slot-Status wird verwendet, um zu bestimmen, wie Anfragen für Schlüssel bedient werden, die dem entsprechenden Slot zugeordnet sind.
loading...
Beim Cluster-Start sind die Slots nicht zugewiesen, daher ist ihr Anfangsstatus **OFFLINE** und die workerId 0. Wenn ein Slot einem bestimmten Knoten zugewiesen wird, wird sein Status auf **STABLE** gesetzt und die workerId (aus Sicht der lokalen Konfigurationskopie) auf den entsprechenden Offset des Eigentümerknotens im Worker-Array. Eigentümer eines Slots können Lese-/Schreib- und Migrationsoperationen auf den mit diesem spezifischen Slot verbundenen Daten durchführen. Replikate können nur Leseanfragen für Schlüssel bedienen, die den von ihrem Primärknoten besessenen Slots zugeordnet sind.
loading...
Ausbreitung von Konfigurationsupdates
Ein gegebener Knoten akzeptiert Gossip-Nachrichten von vertrauenswürdigen Knoten. Die Gossip-Nachricht enthält eine serialisierte Byte-Array-Darstellung, die einen Schnappschuss der lokalen Konfiguration des entfernten Knotens darstellt. Der empfangende Knoten versucht, die eingehende Konfiguration atomar mit seiner lokalen Kopie zusammenzuführen, indem er die Konfigurations-Epoche der relevanten Worker vergleicht. Daher können Änderungen an der Cluster-Konfiguration in der Granularität eines einzelnen Workers erfolgen. Wir nutzen diesen Mechanismus, um zu steuern, wann lokale Updates für den Rest des Clusters sichtbar werden. Dies ist äußerst nützlich für Operationen, die über einen langen Zeitraum dauern und aus mehreren Phasen bestehen (z. B. Datenmigration). Solche Operationen sind anfällig für Unterbrechungen und erfordern Schutzmaßnahmen, um eine Kompromittierung der Datenintegrität zu verhindern.
Wie bereits erwähnt, werden lokale Updates durch Gossiping verbreitet, das im Broadcast-Modus oder im Gossip-Sampling-Modus arbeiten kann. Im ersteren Fall senden wir die Konfiguration periodisch an alle Knoten im Cluster, während wir im letzteren Fall zufällig eine Teilmenge von Knoten auswählen, mit denen wir gossippen. Dies kann beim Start des Servers über das Flag --gossip-sp konfiguriert werden.
Slot-Verifizierung
RESP-Datenbefehle arbeiten entweder auf einem einzelnen Schlüssel oder auf einer Sammlung von Schlüsseln. Darüber hinaus können sie entweder als schreibgeschützt (z. B. GET mykey) oder als schreib-/lesbar (z. B. SET mykey foo) klassifiziert werden. Im Cluster-Modus und bevor ein Befehl verarbeitet wird, führt Garnet einen zusätzlichen Schritt zur Slot-Verifizierung durch. Die Slot-Verifizierung umfasst die Inspektion des oder der Schlüssel, die mit einem gegebenen Befehl verbunden sind, und die Validierung, dass sie einem Slot zugeordnet sind, der von dem Knoten bedient werden kann, der die zugehörige Anfrage empfängt. Garnet-Primärknoten können Lese- und Lese-/Schreibanfragen für Slots bedienen, die sie besitzen, während Garnet-Replikatknoten nur Leseanfragen für Slots bedienen können, die ihr Primärknoten besitzt. Bei einem Fehler im Slot-Verifizierungsschritt wird der entsprechende Befehl nicht verarbeitet und die Slot-Verifizierungsmethode schreibt eine Umleitungsnachricht direkt in den Netzwerkpuffer.
loading...
Umleitungsnachrichten
Aus der Sicht eines einzelnen Knotens führen Anfragen für Schlüssel, die auf einen nicht zugewiesenen Slot abgebildet werden, zu einer Nachricht -CLUSTERDOWN Hashlot not served. Für eine einzelne Schlüsselanfrage gilt ein zugewiesener Slot als *LOKAL*, wenn der empfangende Knoten diesen Slot besitzt, andernfalls wird er als *ENTFERNT* klassifiziert, da er einem entfernten Knoten gehört. In der folgenden Tabelle geben wir eine Zusammenfassung der verschiedenen Umleitungsnachrichten, die je nach Slot-Status und Art des ausgeführten Vorgangs generiert werden. Schreibgeschützte und schreib-/lesbare Anfragen für einen bestimmten Schlüssel, der einem *ENTFERNTEN* Slot zugeordnet ist, führen zu einer Umleitungsnachricht -MOVED <slot> <address>:<port>, die auf den Endpunkt verweist, der den Besitz des zugehörigen Slots beansprucht. Ein Slot kann auch einen speziellen Status wie IMPORTING oder MIGRATING haben. Diese Status werden hauptsächlich während der Slot-Migration verwendet, wobei der Status IMPORTING der Slot-Map des Zielknotens und der Status MIGRATING der Slot-Map des Quellknotens zugewiesen wird. Sollte ein Slot den Status MIGRATING haben und der Schlüssel vorhanden sein (d. h. er wurde noch nicht migriert), können Leseanfragen wie gewohnt weiter verarbeitet werden. Andernfalls gibt der empfangende Knoten (sowohl für schreibgeschützte als auch für schreib-/lesbare Anfragen) eine Umleitungsnachricht -ASK <slot> <address>:<port> zurück, die auf den Zielknoten verweist. Beachten Sie, dass schreib-/lesbare Schlüsselanfragen für vorhandene Schlüssel nicht zulässig sind, um die Datenintegrität während der Migration zu gewährleisten.
| Operation/Status | ZUGEWIESEN LOKAL | ZUGEWIESEN ENTFERNT | MIGRATING VORHANDEN | MIGRATING ~VORHANDEN | IMPORTING FRAGT AN | IMPORTING ~FRAGT AN |
|---|---|---|---|---|---|---|
| Nur Lesen | OK | -MOVED | OK | -ASK | OK | -MOVED |
| Lesen/Schreiben | OK | -MOVED | -MIGRATING | -ASK | OK | -MOVED |