Was ist Cluster? Warum wird Cluster in Redis benötigt? In diesem Artikel erfahren Sie mehr über den Cluster-Cluster und sprechen über die Datenmenge, die der Cluster-Cluster unterstützen kann. Ich hoffe, dass er für Sie hilfreich ist.

Dieser Artikel bietet eine detaillierte Analyse verschiedener Aspekte des Clusters wie Knoten, Slot-Zuweisung, Befehlsausführung, Re-Sharding, Steuerung, Failover und Nachrichten. [Verwandte Empfehlungen:Redis-Video-Tutorial]

Der Zweck besteht darin, zu beherrschen, was Cluster ist? Cluster-Sharding-Prinzip, Prinzip der Client-Positionierungsdaten, Failover, Master-Auswahl, welche Szenarien für den Cluster verwendet werden sollen, wie der Cluster bereitgestellt wird ... [toc]

Warum brauchen wir Cluster

65 Bruder: Bruder Ma, da ich, wie du erwähnt hast, denSentinel-Cluster zur Realisierung des automatischen Failoversverwendet habe, kann ich endlich mit meiner Freundin zufrieden sein und habe keine Angst vor Redis-Ausfällen . Es ging spät in der Nacht unter.

Aber ich bin kürzlich auf ein schreckliches Problem gestoßen, bei dem Redis 8 Millionen Schlüssel-Wert-Paare speichern muss und 20 GB Speicher belegt.

Ich habe einen 32G-Speicherhost für die Bereitstellung verwendet, aber die Redis-Antwort war manchmal sehr langsam. Ich habe den INFO-Befehl verwendet, um den neuesten_fork_usec-Indikator zu überprüfen (der letzte Fork brauchte Zeit) und stellte fest, dass er besonders hoch war.

Wird hauptsächlich durch den Redis-RDB-Persistenzmechanismus verursacht. Die Zeit, die für die Ausführung des Forks benötigt wird, hängt positiv von der Menge der Redis-Daten ab.

Und wenn Fork ausgeführt wird, blockiert es den Hauptthread. Aufgrund der großen Datenmenge wird der Hauptthread zu lange blockiert, sodass die Reaktion von Redis langsam zu sein scheint.

65 Bruder: Mit der Ausweitung des Geschäftsumfangs wird die Datenmenge immer größer. Es ist schwierig, die Hardware einer einzelnen Instanz zu erweitern, wenn die Master-Slave-Architektur aktualisiert wird, und das Speichern großer Datenmengen führt zu einer langsamen Reaktion. Gibt es eine Möglichkeit, das Problem zu lösen?

Um große Datenmengen zu speichern, können wir neben der Verwendung von Hosts mit großem Speicher auch Slicing-Cluster verwenden. Wie das Sprichwort sagt: „Was jeder hinzufügt, macht die Flammen heller.“ Wenn eine Maschine nicht alle Daten speichern kann, müssen sie von mehreren Maschinen gemeinsam genutzt werden.

Die Verwendung des Redis-Cluster-Clusters löst hauptsächlich verschiedene Langsamkeitsprobleme, die durch großen Datenspeicher verursacht werden, und erleichtert auch die horizontale Erweiterung.

Zwei Lösungen entsprechen den beiden Erweiterungslösungen für die Erhöhung der Redis-Daten:Vertikale Erweiterung (Skalierung nach oben) und horizontale Erweiterung (Skalierung nach außen).

1. Vertikale Erweiterung: Aktualisieren Sie die Hardwarekonfiguration eines einzelnen Redis, z. B. durch Erhöhen der Speicherkapazität, Festplattenkapazität und Verwendung einer leistungsstärkeren CPU.
2. Horizontale Erweiterung: Erhöhen Sie die Anzahl der Redis-Instanzen horizontal, und jeder Knoten ist für einen Teil der Daten verantwortlich.

Wenn Sie beispielsweise eine Serverressource mit 24 GB Speicher und 150 GB Festplatte benötigen, gibt es zwei Möglichkeiten:

Bei Millionen oder mehreren zehn Millionen Benutzern ein horizontal skalierbarer Redis-Slicing-Cluster wird eine sehr gute Wahl sein.

65 Bruder: Was sind die Vor- und Nachteile dieser beiden Optionen?

• Die Bereitstellung einer vertikalen Erweiterung ist einfach, aber wenn die Datenmenge groß ist und RDB zum Erreichen von Persistenz verwendet wird, führt dies zu Blockierungen und langsamen Reaktionen. Darüber hinaus sind aufgrund von Hardware- und Kostenbeschränkungen die Kosten für die Speichererweiterung, beispielsweise die Erweiterung auf 1T-Speicher, zu hoch.
• Horizontale Erweiterung erleichtert die Erweiterung, ohne sich Gedanken über die Hardware- und Kostenbeschränkungen einer einzelnen Instanz machen zu müssen. Das Aufteilen von Clustern bringt jedoch Probleme mit der verteilten Verwaltung mehrerer Instanzen mit sich. Es muss gelöst werden, wie Daten sinnvoll auf verschiedene Instanzen verteilt werden können und gleichzeitig den Clients der korrekte Zugriff auf die Daten auf den Instanzen ermöglicht wird.
Was ist Cluster?

Redis-Cluster ist eine verteilte Datenbanklösung. Der Cluster verwaltet Daten durch Sharding (eine Praxis des „Teile-und-Herrsche-Denkens“) und bietet Replikations- und Failover-Funktionen.

Teilen Sie die Daten in 16384 Slots auf, und jeder Knoten ist für einen Teil der Slots verantwortlich. Slot-Informationen werden in jedem Knoten gespeichert.

Es ist dezentralisiert, der Cluster besteht aus drei Redis-Knoten. Jeder Knoten ist für einen Teil der Daten des gesamten Clusters verantwortlich.

Drei Knoten sind miteinander verbunden, um einen Peer-to-Peer-Cluster zu bilden. Sie tauschen Clusterinformationen untereinander über dasGossip-Protokoll aus. Schließlich speichert jeder Knoten die Slot-Zuweisung anderer Knoten.Gossip协议相互交互集群信息，最后每个节点都保存着其他节点的 slots 分配情况。

开篇寄语

技术不是万能的，程序员也不是最厉害的，一定要搞清楚，不要觉得「老子天下第一」。一旦有了这个意识，可能会耽误我们的成长。

技术是为了解决问题的，如果说一个技术不能解决问题，那这个技术就一文不值。

不要去炫技，没有意义。

集群安装

点击 -> 《Redis 6.X Cluster 集群搭建》查看

一个 Redis 集群通常由多个节点（node）组成，在刚开始的时候，每个节点都是相互独立的，它们都处于一个只包含自己的集群当中，要组建一个真正可工作的集群，我们必须将各个独立的节点连接起来，构成一个包含多个节点的集群。

连接各个节点的工作可以通过CLUSTER MEET命令完成：CLUSTER MEET 。

向一个节点 node 发送CLUSTER MEET

Eröffnungsnachricht

Technologie ist nicht allmächtig und Programmierer sind nicht die Mächtigsten. Sie müssen es klar verstehen und dürfen nicht denken: „Ich bin der Beste auf der Welt.“ . Sobald wir dieses Bewusstsein haben, kann es unser Wachstum verzögern.

Technologie soll Probleme lösen. Wenn eine Technologie keine Probleme lösen kann, dann ist diese Technologie wertlos.

Stellen Sie Ihre Fähigkeiten nicht zur Schau, das ist bedeutungslos.

Cluster-InstallationKlicken Sie auf -> „Redis 6.X-Cluster-Cluster-Konstruktion“ Ansicht

Ein Redis-Cluster besteht normalerweise aus mehreren Knoten Zu Beginn ist jeder Knoten unabhängig voneinander und befindet sich in einem Cluster, der nur sich selbst enthält. Um einen wirklich funktionierenden Cluster zu bilden, müssen wir die unabhängigen Knoten zu einem Cluster verbinden, der mehrere Knoten enthält.

Die Arbeit zum Verbinden verschiedener Knoten kann über den Befehl CLUSTER MEETabgeschlossen werden: CLUSTER MEET .

Durch das Senden des Befehls CLUSTER MEETan einen Knoten kann der Knoten einen Handshake mit der durch IP und Port angegebenen Knoten durchführen Der Knoten wird dem Cluster hinzugefügt, in dem sich der Knoten derzeit befindet.

Redis-Clusters

Lesen Sie den Originaltext

Redis 6.:
• redis.io/topics/ clus…

Cluster-Implementierungsprinzip

• 65 Brother: Nach dem Daten-Slicing müssen die Daten auf verschiedene Instanzen verteilt werden. Wie korrespondieren Daten und Instanzen?

Ab Redis 3.0 wird die offizielle Redis-Cluster-Lösung zur Implementierung von Slicing-Clustern bereitgestellt. Diese Lösung implementiert die Regeln von Daten und Instanzen. Die Redis-Cluster-Lösung verwendet Hash Slot (ich nenne ihn als Nächstes einfach Slot), um die Zuordnungsbeziehung zwischen Daten und Instanzen zu verwalten.

Folgen Sie „Code Byte“, um in die Erkundungsreise der Cluster-Implementierungsprinzipien einzusteigen...

Teilen Sie die Daten in mehrere Teile und speichern Sie sie auf verschiedenen Instanzen

Die gesamte Datenbank des Clusters ist in 16384 Slots (Slots) unterteilt. In der Datenbank gehört jeder Schlüssel zu einem dieser 16384 Slots, und jeder Knoten im Cluster kann 0 oder bis zu 16384 Slots verarbeiten. Der Schlüssel- und Hash-Slot-Mapping-Prozess kann in zwei Hauptschritte unterteilt werden: Verwenden Sie entsprechend dem Schlüssel des Schlüssel-Wert-Paares den CRC16-Algorithmus, um einen 16-Bit-Wert zu berechnen; Paaren Sie die 16 -Bit-Wert bis 16384 Führen Sie Modulo durch und erhalten Sie eine Zahl von 0 bis 16383, die den Hash-Slot darstellt, der dem Schlüssel entspricht. Mit Cluster können Benutzer auch erzwingen, dass ein Schlüssel in einem bestimmten Steckplatz hängt. Durch die Einbettung der Tag-Markierung in die Schlüsselkette kann der Schlüssel dazu gezwungen werden, in dem Steckplatz zu hängen, der dem Steckplatz entspricht, in dem sich der Tag befindet. Hash-Slot und Redis-Instanzzuordnung65 Bruder: Wie wird der Hash-Slot der Redis-Instanz zugeordnet?

Erstellt durchcluster createimCluster-Bereitstellungsbeispiel, verteilt Redis automatisch 16384 Hash-Slots gleichmäßig auf der Cluster-Instanz, z. B. N Knoten, und die Anzahl der Hash-Slots auf jedem Knoten beträgt 16384 /N.cluster create创建，Redis 会自动将 16384 个 哈希槽平均分布在集群实例上，比如 N 个节点，每个节点上的哈希槽数 = 16384 / N 个。

除此之外，可以通过CLUSTER MEET命令将 7000、7001、7002 三个节点连在一个集群，但是集群目前依然处于下线状态，因为三个实例都没有处理任何哈希槽。

可以使用cluster addslots命令，指定每个实例上的哈希槽个数。

65 哥：为啥要手动制定呢？

能者多劳嘛，加入集群中的 Redis 实例配置不一样，如果承担一样的压力，对于垃圾机器来说就太难了，让牛逼的机器多支持一点。

三个实例的集群，通过下面的指令为每个实例分配哈希槽：实例 1负责 0 ～ 5460 哈希槽，实例 2负责 5461~10922 哈希槽，实例 3负责 10923 ～ 16383 哈希槽。

redis-cli -h 172.16.19.1 –p 6379 cluster addslots 0,5460 redis-cli -h 172.16.19.2 –p 6379 cluster addslots 5461,10922 redis-cli -h 172.16.19.3 –p 6379 cluster addslots 10923,16383

键值对数据、哈希槽、Redis 实例之间的映射关系如下：

Redis 键值对的 key 「码哥字节」「牛逼」经过 CRC16 计算后再对哈希槽总个数 16394 取模，模数结果分别映射到实例 1 与实例 2 上。

切记，当 16384 个槽都分配完全，Redis 集群才能正常工作。

复制与故障转移

65 哥：Redis 集群如何实现高可用呢？Master 与 Slave 还是读写分离么？

Master 用于处理槽，Slave 节点则通过《Redis 主从架构数据同步》方式同步主节点数据。

当 Master 下线，Slave 代替主节点继续处理请求。主从节点之间并没有读写分离， Slave 只用作 Master 宕机的高可用备份。

Redis Cluster 可以为每个主节点设置若干个从节点，单主节点故障时，集群会自动将其中某个从节点提升为主节点。

如果某个主节点没有从节点，那么当它发生故障时，集群将完全处于不可用状态。

不过 Redis 也提供了一个参数cluster-require-full-coverage可以允许部分节点故障，其它节点还可以继续提供对外访问。

比如 7000 主节点宕机，作为 slave 的 7003 成为 Master 节点继续提供服务。当下线的节点 7000 重新上线，它将成为当前 70003 的从节点。

故障检测

65 哥：在《Redis 高可用篇：Sentinel 哨兵集群原理》我知道哨兵通过监控、自动切换主库、通知客户端实现故障自动切换，Cluster又如何实现故障自动转移呢？

一个节点认为某个节点失联了并不代表所有的节点都认为它失联了。只有当大多数负责处理 slot 节点都认定了某个节点下线了，集群才认为该节点需要进行主从切换。

Redis 集群节点采用Gossip协议来广播自己的状态以及自己对整个集群认知的改变。比如一个节点发现某个节点失联了 (PFail)，它会将这条信息向整个集群广播，其它节点也就可以收到这点失联信息。

关于GossipDarüber hinaus können Sie mit dem BefehlCLUSTER MEETdie drei Knoten 7000, 7001 und 7002 zu einem Cluster verbinden, der Cluster ist jedoch immer noch offline, da keine der drei Instanzen Hash verarbeitet Slot.

65 Bruder: Warum musst du es manuell formulieren? Wer dazu in der Lage ist, sollte härter arbeiten. Die Konfigurationen der dem Cluster hinzugefügten Redis-Instanzen sind unterschiedlich. Wenn sie den gleichen Druck aushalten, wird es für Müllmaschinen zu schwierig sein, mehr zu unterstützen. Für einen Cluster aus drei Instanzen weisen Sie jeder Instanz mithilfe der folgenden Anweisungen Hash-Slots zu: Instanz 1ist für 0 bis 5460 Hash-Slots verantwortlich, Instanz 2ist dafür verantwortlich 5461–10922 Hash-Slot, Instanz 3ist für die Hash-Slots 10923–16383 verantwortlich.

GET 公众号:码哥字节 (error) MOVED 16330 172.17.18.2:6379

Nach dem Login kopieren

Nach dem Login kopieren

Die Zuordnungsbeziehung zwischen Schlüssel-Wert-Paardaten, Hash-Slots und Redis-Instanzen ist wie folgt: Redis Schlüssel-Wert-Paar Schlüssel "Codebytes" Nach dem Bei der CRC16-Berechnung wird die Gesamtzahl der Hash-Slots 16394 modulo genommen und die Modulus-Ergebnisse werden jeweils Instanz 1 und Instanz 2 zugeordnet. Denken Sie daran: Der Redis-Cluster kann nur dann normal funktionieren, wenn alle 16384 Slots vollständig zugewiesen sind.

Replikation und Failover

65 Brother: Wie erreicht der Redis-Cluster eine hohe Verfügbarkeit? Sind Master und Slave immer noch vom Lesen und Schreiben getrennt? Master wird zum Verarbeiten des Slots verwendet, und der Slave-Knoten übergibt die „ Datensynchronisierung der Redis-Master-Slave-Architektur 》Methode zum Synchronisieren der Masterknotendaten. Wenn der Master offline geht, verarbeitet der Slave weiterhin Anfragen und nicht der Masterknoten. Es gibt keine Lese-/Schreibtrennung zwischen Master- und Slave-Knoten und der Slave wird nur als Hochverfügbarkeits-Backup für den Fall eines Master-Ausfalls verwendet. Redis Cluster kann mehrere Slave-Knoten für jeden Master-Knoten einrichten. Wenn ein einzelner Master-Knoten ausfällt, stuft der Cluster automatisch einen der Slave-Knoten zum Master-Knoten hoch.Wenn ein Master-Knoten keine Slave-Knoten hat, ist der Cluster bei einem Ausfall vollständig nicht verfügbar. Allerdings stellt Redis auch einen Parametercluster-require-full-coveragebereit, der es ermöglicht, dass einige Knoten ausfallen und andere Knoten weiterhin externen Zugriff bereitstellen können. Wenn beispielsweise der Master-Knoten 7000 ausfällt, wird der Slave 7003 zum Master-Knoten und stellt weiterhin Dienste bereit. Wenn der Offline-Knoten 7000 wieder online geht, wird er zum Slave-Knoten des aktuellen 70003.

Fehlererkennung

65 Bruder: In " Redis High Availability Kapitel: Sentinel-Cluster-Prinzip " Ich weiß, dass Sentinel automatisches Failover durch Überwachung, automatisches Umschalten der Hauptdatenbank und Benachrichtigung von Clients realisiert. Wie realisiertClusterautomatisches Failover? Nur weil ein Knoten denkt, dass ein Knoten keinen Kontakt hat, heißt das nicht, dass alle Knoten denken, dass er keinen Kontakt hat. Erst wenn die meisten Knoten, die für die Verarbeitung von Slots verantwortlich sind, feststellen, dass ein Knoten offline ist, geht der Cluster davon aus, dass der Knoten einen Master-Slave-Wechsel durchführen muss. Redis-Clusterknoten verwenden dasGossip-Protokoll, um ihren eigenen Status und Änderungen in ihrem Wissen über den gesamten Cluster zu übertragen. Wenn ein Knoten beispielsweise feststellt, dass ein bestimmter Knoten verloren geht (PFail), sendet er diese Informationen an den gesamten Cluster, und andere Knoten können diese Informationen zum Verbindungsverlust ebenfalls empfangen. Über dasGossip-Protokoll können Sie einen Artikel von Bruder Wukong lesen: „Vireninvasion, alles hängt von der Verteilung ab“Wenn ein Knoten die Anzahl der Verbindungsabbrüche von einem Knoten empfängt (PFail Count ) Sobald Sie den Großteil des Clusters erreicht haben, können Sie den Knoten als bestätigt als offline (Fehlgeschlagen) markieren und ihn dann an den gesamten Cluster senden, wodurch andere Knoten gezwungen werden, ebenfalls die Tatsache zu akzeptieren, dass der Knoten offline war, und dies sofort zu tun Kontrolle über den verlorenen Knoten.

Failover

Wenn ein Slave feststellt, dass sein Masterknoten in den Offline-Zustand übergegangen ist, beginnt der Slave-Knoten mit dem Failover des Offline-Masterknotens.

• Wählen Sie einen Knoten aus der Offline-Master- und Knoten-Slave-Knotenliste aus, um der neue Masterknoten zu werden.

• Der neue Masterknoten widerruft alle Slot-Zuweisungen zum Offline-Masterknoten und weist diese Slots sich selbst zu.

• Der neue Master-Knoten sendet eine PONG-Nachricht an den Cluster. Diese PONG-Nachricht kann andere Knoten im Cluster sofort darüber informieren, dass dieser Knoten von einem Slave-Knoten zu einem Master-Knoten gewechselt ist und dass dieser Master-Knoten die Rolle übernommen hat Aufgabe, die ursprünglich vom Master-Knoten ausgeführt wurde. Der Slot, für dessen Verarbeitung der Offline-Knoten verantwortlich ist.

• Der neue Masterknoten beginnt mit dem Empfang von Befehlsanfragen im Zusammenhang mit dem Verarbeitungssteckplatz und der Failover ist abgeschlossen.

Master-Wahlprozess

65 Bruder: Wie wird der neue Master-Knoten gewählt?

• Die Konfigurationsepoche +1 des Clusters ist ein Selbstzeitzähler mit einem Anfangswert von 0 und wird jedes Mal +1 sein, wenn ein Failover durchgeführt wird.

• Der Slave-Knoten, der erkennt, dass der Master-Knoten offline ist, sendet eineCLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST-Nachricht an den Cluster und fordert alle Master-Knoten, die diese Nachricht empfangen und Stimmrechte haben, auf, für diesen Slave-Knoten zu stimmen.CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST消息，要求所有收到这条消息、并且具有投票权的主节点向这个从节点投票。

• 这个主节点尚未投票给其他从节点，那么主节点将向要求投票的从节点返回一条CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息，表示这个主节点支持从节点成为新的主节点。

• 参与选举的从节点都会接收CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK

• Dieser Master-Knoten hat noch nicht für andere Slave-Knoten gestimmt, dann gibt der Master-Knoten eineCLUSTERMSG_TYPE_FAILOVER_AUTH_ACK-Nachricht an den Slave-Knoten zurück, der eine Abstimmung erfordert, was darauf hinweist, dass dieser Master-Knoten den Slave-Knoten unterstützt wird der neue Masterknoten.

Alle an der Wahl teilnehmenden Slave-Knoten erhalten die NachrichtCLUSTERMSG_TYPE_FAILOVER_AUTH_ACK. Wenn die gesammelten Stimmen >= (N/2) + 1 unterstützen, wird der Slave-Knoten zum neuen Master gewählt Knoten.

Wenn in einer Konfigurationsepoche kein Slave-Knoten genügend Unterstützungsstimmen sammeln kann, tritt der Cluster in eine neue Konfigurationsepoche ein und die Wahl wird erneut abgehalten, bis ein neuer Masterknoten gewählt wird.

Ähnlich wie Sentinel werden beide auf Basis des Raft-Algorithmus implementiert. Der Prozess ist wie in der Abbildung dargestellt:

Ist es möglich, eine Tabelle zum Speichern der Beziehung zwischen Schlüssel-Wert-Paaren und Instanzen zu verwenden?

65 Bruder, ich möchte dich testen: „Die Redis-Cluster-Lösung weist Schlüssel-Wert-Paare verschiedenen Instanzen über Hash-Slots zu. Dieser Prozess erfordert eine CRC-Berechnung des Schlüssels des Schlüssel-Wert-Paares und Modulo der Gesamtzahl der Hashes.“ Slots zur Zuordnung zur Instanz . Wenn Sie eine Tabelle verwenden, um die Entsprechung zwischen Schlüssel-Wert-Paaren und Instanzen direkt aufzuzeichnen (z. B. befindet sich Schlüssel-Wert-Paar 1 auf Instanz 2 und Schlüssel-Wert-Paar 2 auf Instanz 1). Es ist nicht erforderlich, die Entsprechung zwischen Schlüssel und Hash-Slot zu berechnen. Warum führt Redis dies nicht aus? Wenn sich Instanzen ändern (Re-Sharding, Instanzerhöhung oder -verringerung), muss die Oberfläche geändert werden. Wenn es sich um einen Single-Thread-Vorgang handelt, müssen alle Vorgänge serialisiert werden und die Leistung ist zu langsam.

Multithreading beinhaltet das Sperren. Wenn die Menge der Schlüssel-Wert-Paardaten sehr groß ist, ist außerdem auch der zum Speichern der Tabellendaten der Beziehung zwischen Schlüssel-Wert-Paaren und Instanzen erforderliche Speicherplatz sehr groß.

Was die Hash-Slot-Berechnung betrifft, muss zwar auch die Beziehung zwischen Hash-Slots und Instanzzeit aufgezeichnet werden, die Anzahl der Hash-Slots ist jedoch viel kleiner, nur 16384, und der Overhead ist sehr gering.

Wie findet der Client die Instanz, auf der sich die Daten befinden?

65 Brother: Wie ermittelt der Client, auf welche Instanz die abgerufenen Daten verteilt werden?

Die Redis-Instanz sendet ihre Hash-Slot-Informationen über das Gossip-Protokoll an andere Instanzen im Cluster und realisiert so die Verbreitung von Hash-Slot-Zuteilungsinformationen.

Auf diese Weise verfügt jede Instanz im Cluster über Zuordnungsbeziehungsinformationen zwischen allen Hash-Slots und Instanzen.

Beim Slicing von Daten wird der Schlüssel als Wert über CRC16 und dann Modulo 16384 berechnet, um den entsprechenden Slot zu erhalten. Diese Berechnungsaufgabe kann beim Senden einer Anfrage auf dem Client ausgeführt werden.

Nachdem Sie den Steckplatz gefunden haben, müssen Sie jedoch die Redis-Instanz weiter lokalisieren, in der sich der Steckplatz befindet.

Wenn der Client eine Verbindung zu einer Instanz herstellt, antwortet die Instanz dem Client mit der Zuordnungsbeziehung zwischen dem Hash-Slot und der Instanz, und der Client speichert die Zuordnungsinformationen zwischen dem Hash-Slot und der Instanz lokal zwischen.

Wenn der Client eine Anfrage stellt, berechnet er den dem Schlüssel entsprechenden Hash-Slot, lokalisiert die Instanz, in der sich die Daten befinden, anhand der lokal zwischengespeicherten Hash-Slot-Instanzzuordnungsinformationen und sendet dann die Anfrage an die entsprechende Instanz.

Hash-Slots neu verteilen65 Bruder: Was soll ich tun, wenn sich die Zuordnungsbeziehung zwischen Hash-Slots und Instanzen aufgrund neuer Instanzen oder einer Lastausgleichsumverteilung ändert?

集群中的实例通过 Gossip 协议互相传递消息获取最新的哈希槽分配信息，但是，客户端无法感知。

Redis Cluster 提供了重定向机制：客户端将请求发送到实例上，这个实例没有相应的数据，该 Redis 实例会告诉客户端将请求发送到其他的实例上。

65 哥：Redis 如何告知客户端重定向访问新实例呢？

分为两种情况：MOVED 错误、ASK 错误。

MOVED 错误

MOVED错误（负载均衡，数据已经迁移到其他实例上）：当客户端将一个键值对操作请求发送给某个实例，而这个键所在的槽并非由自己负责的时候，该实例会返回一个 MOVED 错误指引转向正在负责该槽的节点。

GET 公众号:码哥字节 (error) MOVED 16330 172.17.18.2:6379

Nach dem Login kopieren

Nach dem Login kopieren

该响应表示客户端请求的键值对所在的哈希槽 16330 迁移到了 172.17.18.2 这个实例上，端口是 6379。这样客户端就与 172.17.18.2:6379 建立连接，并发送 GET 请求。

同时，客户端还会更新本地缓存，将该 slot 与 Redis 实例对应关系更新正确。

ASK 错误

65 哥：如果某个 slot 的数据比较多，部分迁移到新实例，还有一部分没有迁移咋办？

如果请求的 key 在当前节点找到就直接执行命令，否则时候就需要 ASK 错误响应了，槽部分迁移未完成的情况下，如果需要访问的 key 所在 Slot 正在从从 实例 1 迁移到 实例 2，实例 1 会返回客户端一条 ASK 报错信息：客户端请求的 key 所在的哈希槽正在迁移到实例 2 上，你先给实例 2 发送一个 ASKING 命令，接着发发送操作命令。

GET 公众号:码哥字节 (error) ASK 16330 172.17.18.2:6379

Nach dem Login kopieren

比如客户端请求定位到 key = 「公众号:码哥字节」的槽 16330 在实例 172.17.18.1 上，节点 1 如果找得到就直接执行命令，否则响应 ASK 错误信息，并指引客户端转向正在迁移的目标节点 172.17.18.2。

注意：ASK 错误指令并不会更新客户端缓存的哈希槽分配信息。

所以客户端再次请求 Slot 16330 的数据，还是会先给172.17.18.1实例发送请求，只不过节点会响应 ASK 命令让客户端给新实例发送一次请求。

MOVED指令则更新客户端本地缓存，让后续指令都发往新实例。

集群可以设置多大？

65 哥：有了 Redis Cluster，再也不怕大数据量了，我可以无限水平拓展么？

答案是否定的，Redis 官方给的 Redis Cluster 的规模上线是 1000 个实例。

65 哥：到底是什么限制了集群规模呢？

关键在于实例间的通信开销，Cluster 集群中的每个实例都保存所有哈希槽与实例对应关系信息（Slot 映射到节点的表），以及自身的状态信息。

在集群之间每个实例通过Gossip协议传播节点的数据，Gossip协议工作原理大概如下：

1. 从集群中随机选择一些实例按照一定的频率发送PING消息发送给挑选出来的实例，用于检测实例状态以及交换彼此的信息。PING消息中封装了发送者自身的状态信息、部分其他实例的状态信息、Slot 与实例映射表信息。
2. 实例接收到PING消息后，响应PONG消息，消息包含的信息跟PING消息一样。

集群之间通过Gossip协议可以在一段时间之后每个实例都能获取其他所有实例的状态信息。

所以在有新节点加入，节点故障，Slot 映射变更都可以通过PING，PONG的消息传播完成集群状态在每个实例的传播同步。

Gossip 消息

发送的消息结构是clusterMsgDataGossip结构体组成：

typedef struct { char nodename[CLUSTER_NAMELEN]; //40字节 uint32_t ping_sent; //4字节 uint32_t pong_received; //4字节 char ip[NET_IP_STR_LEN]; //46字节 uint16_t port; //2字节 uint16_t cport; //2字节 uint16_t flags; //2字节 uint32_t notused1; //4字节 } clusterMsgDataGossip;

Nach dem Login kopieren

所以每个实例发送一个Gossip消息，就需要发送 104 字节。如果集群是 1000 个实例，那么每个实例发送一个PING消息则会占用 大约 10KB。

除此之外，实例间在传播 Slot 映射表的时候，每个消息还包含了 一个长度为 16384 bit 的Bitmap。

Jedes Bit entspricht einem Slot. Wenn der Wert = 1 ist, bedeutet dies, dass dieser Slot zur aktuellen Instanz gehört, sodass einePING-Nachricht etwa 12 KB groß ist.PING消息大约 12KB。

PONG与PING消息一样，一发一回两个消息加起来就是 24 KB。集群规模的增加，心跳消息越来越多就会占据集群的网络通信带宽，降低了集群吞吐量。

实例的通信频率

65 哥：码哥，发送 PING 消息的频率也会影响集群带宽吧？

Redis Cluster 的实例启动后，默认会每秒从本地的实例列表中随机选出 5 个实例，再从这 5 个实例中找出一个最久没有收到 PING 消息的实例，把 PING 消息发送给该实例。

65 哥：随机选择 5 个，但是无法保证选中的是整个集群最久没有收到 PING 通信的实例，有的实例可能一直没有收到消息，导致他们维护的集群信息早就过期了，咋办呢？

这个问题问的好，Redis Cluster 的实例每 100 ms 就会扫描本地实例列表，当发现有实例最近一次收到PONG消息的时间 >cluster-node-timeout / 2。那么就立刻给这个实例发送PING消息，更新这个节点的集群状态信息。

当集群规模变大，就会进一步导致实例间网络通信延迟怎加。可能会引起更多的 PING 消息频繁发送。

降低实例间的通信开销

• 每个实例每秒发送一条PING消息，降低这个频率可能会导致集群每个实例的状态信息无法及时传播。
• 每 100 ms 检测实例PONG消息接收是否超过cluster-node-timeout / 2，这个是 Redis 实例默认的周期性检测任务频率，我们不会轻易修改。

所以，只能修改cluster-node-timeout的值：集群中判断实例是否故障的心跳时间，默认 15 S。

所以，为了避免过多的心跳消息占用集群宽带，将cluster-node-timeout调成 20 秒或者 30 秒，这样PONG消息接收超时的情况就会缓解。

但是，也不能设置的太大。都则就会导致实例发生故障了，却要等待cluster-node-timeout时长才能检测出这个故障，影响集群正常服务、

总结

• 哨兵集群实现故障自动转移，但是当数据量过大导致生成 RDB 时间过长。而 Fork 执行的时候会阻塞主线程，由于数据量过大导致阻塞主线程过长，所以出现了 Redis 响应慢的表象。
• 使用 Redis Cluster 集群，主要解决了大数据量存储导致的各种慢问题，同时也便于横向拓展。在面向百万、千万级别的用户规模时，横向扩展的 Redis 切片集群会是一个非常好的选择。
• 集群的整个数据库被分为 16384 个槽（slot），数据库中的每个键都属于这 16384 个槽的其中一个，集群中的每个节点可以处理 0 个或最多 16384 个槽。
• Redis 集群节点采用 Gossip 协议来广播自己的状态以及自己对整个集群认知的改变。
• 客户端连接到集群候任何一个实例后，实例会将哈希槽与实例映射信息发送给客户端，客户端将信息保存，用于将 key 定位到对应的节点。
• 集群并不能无限增加，由于集群通过Gossip协议传播集群实例信息，所以通信频率是限制集群大小的主要原因，主要可以通过修改cluster-node-timeout
PONGist dasselbe wie die PING-Nachricht. Die Summe der beiden gesendeten und zurückgegebenen Nachrichten beträgt 24 KB. Mit zunehmender Clustergröße belegen immer mehr Heartbeat-Nachrichten die Netzwerkkommunikationsbandbreite des Clusters und verringern den Cluster-Durchsatz.

Instanzkommunikationsfrequenz

65 Bruder: Bruder Ma, die Häufigkeit des Sendens von PING-Nachrichten wirkt sich auch auf die Clusterbandbreite aus, oder?

Nachdem die Instanz des Redis-Clusters gestartet wurde, werden standardmäßig jede Sekunde 5 Instanzen zufällig aus der lokalen Instanzliste ausgewählt, und dann wird die Instanz gefunden, die die PING-Nachricht am längsten nicht erhalten hat Diese 5 Instanzen senden eine PING-Nachricht an diese Instanz.

65 Brother: Wählen Sie zufällig 5 aus, es gibt jedoch keine Garantie dafür, dass die ausgewählte Instanz die Instanz ist, die im gesamten Cluster am längsten keine PING-Kommunikation erhalten hat Die Cluster-Informationen, die sie verwalten, sind schon vor langer Zeit abgelaufen. Okay, was tun?

Das ist eine gute Frage. Redis-Cluster-Instanzen scannen alle 100 ms die lokale Instanzliste > Cluster-Node-Timeout/2. Senden Sie dann sofort eine PING-Nachricht an diese Instanz, um die Cluster-Statusinformationen dieses Knotens zu aktualisieren. Wenn die Clustergröße zunimmt, erhöht sich die Netzwerkkommunikationsverzögerung zwischen Instanzen weiter. Kann dazu führen, dass häufiger PING-Nachrichten gesendet werden.

Reduzieren Sie den Kommunikationsaufwand zwischen Instanzen

• Jede Instanz sendet jede Sekunde einePING-Nachricht, wodurch diese Häufigkeit verringert werden kann Dies führt dazu, dass die Statusinformationen jeder Instanz des Clusters nicht rechtzeitig weitergegeben werden können.
• Überprüfen Sie alle 100 ms, ob derPONG-Nachrichtenempfang der Instanzcluster-node-timeout / 2überschreitet. Dies ist die Standardfrequenz der periodischen Erkennungsaufgabe der Redis-Instanz. Wir lassen uns nicht leicht ändern. Sie können also nur den Wert voncluster-node-timeoutändern: die Heartbeat-Zeit im Cluster, um festzustellen, ob eine Instanz fehlerhaft ist. Der Standardwert ist 15 S. Um also zu vermeiden, dass zu viele Heartbeat-Nachrichten die Clusterbandbreite belegen, passen Siecluster-node-timeoutauf 20 Sekunden oder 30 Sekunden an, sodassPONGNachrichten werden empfangen. Die Timeout-Situation wird gemildert. Allerdings darf es nicht zu groß eingestellt werden. Andernfalls schlägt die Instanz fehl, Sie müssen jedoch aufcluster-node-timeoutwarten, um diesen Fehler zu erkennen, der sich auf den normalen Dienst des Clusters auswirkt

  Zusammenfassung

  • Der Sentinel-Cluster implementiert automatisches Failover, aber wenn der Betrag Wenn die Datenmenge zu groß ist, dauert die RDB-Generierung zu lange. Wenn Fork ausgeführt wird, wird der Hauptthread aufgrund der großen Datenmenge blockiert, sodass Redis langsam reagiert.
  • Die Verwendung des Redis-Cluster-Clusters löst hauptsächlich verschiedene Langsamkeitsprobleme, die durch großen Datenspeicher verursacht werden, und erleichtert auch die horizontale Erweiterung.Wenn es Millionen oder Dutzende Millionen Benutzer gibt, sind horizontal skalierbare Redis-Slicing-Cluster eine sehr gute Wahl.
  • Die gesamte Datenbank des Clusters ist in 16384 Slots unterteilt. Jeder Schlüssel in der Datenbank gehört zu einem dieser 16384 Slots. Jeder Knoten im Cluster kann 0 oder höchstens 16384 Slots verarbeiten.
  • Redis-Clusterknoten verwenden das Gossip-Protokoll, um ihren Status und Änderungen in ihrem Wissen über den gesamten Cluster zu übertragen.
  • Nachdem der Client eine Verbindung zu einer beliebigen Instanz im Cluster hergestellt hat, sendet die Instanz den Hash-Slot und die Instanzzuordnungsinformationen an den Client, und der Client speichert die Informationen und verwendet sie, um den Schlüssel zum entsprechenden Knoten zu finden.
  • Der Cluster kann nicht unbegrenzt vergrößert werden. Da der Cluster Cluster-Instanzinformationen über dasGossip-Protokoll weitergibt, ist die Kommunikationshäufigkeit der Hauptgrund für die Begrenzung der Clustergröße. Dies kann hauptsächlich durch Modifizieren erfolgen Dascluster-node-timeoutPassen Sie die Häufigkeit an. Weitere Programmierkenntnisse finden Sie unter: Programmiervideo! !

Das obige ist der detaillierte Inhalt vonWas ist ein Cluster? Warum wird Cluster in Redis benötigt?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!