Eine kurze Analyse des Prinzips der Cluster-Master-Slave-Replikation in Redis

Dieser Artikel vermittelt Ihnen ein tiefgreifendes Verständnis des Master-Slave-Replikationsprinzips des Redis-Clusters. Ich hoffe, er wird Ihnen hilfreich sein!

1. Denken Sie zunächst über eine Frage nach: Warum benötigt Redis eine verteilte Lösung, wenn seine Leistung so hoch ist?

1. Erzielen Sie eine höhere Leistung: Bei Anwendungen mit hoher Parallelität wird die Leistung einer einzelnen Maschine beeinträchtigt, und es sind mehr Redis-Server erforderlich, um den Druck zu verteilen und einen Lastausgleich zu erreichen.

2. Erzielen Sie eine hohe Verfügbarkeit. Ausfallzeiten/Hardwarefehler verhindern

3. Skalierbarkeit erreichen: Der Speicher und die Hardware einer einzelnen Maschine sind begrenzt und eine horizontale Erweiterung ist möglich.

Redundanter oder Sharded-Speicher kann die oben genannten Funktionen erreichen.

2. Master-Slave-Replikationskonfiguration

Wie Kafka, Mysql und Rocketmq unterstützt Redis die Cluster-Bereitstellung. Der Master-Knoten ist der Master und der Slave-Knoten Slave (der neueste wird Replikat genannt). Der Slave synchronisiert die neuesten Daten vom Master über den Replikationsmechanismus. Redis bietet einen sehr praktischen Befehl zum Aktivieren der Master-Slave-Replikation. [Verwandte Empfehlungen: Redis-Video-Tutorial]

Wie konfiguriere und aktiviere ich die Master-Slave-Replikation?

Nehmen Sie als Beispiel den lokalen Aufbau eines Pseudo-Clusters. Port 6379 ist der Slave-Knoten und Port 6378 der Master-Knoten.

1. Konfigurieren Sie die Replik des Master-Knotens in redis.conf. Nach dem Start stellt der Slave-Knoten automatisch eine Verbindung zum Master-Knoten her und beginnt mit der Synchronisierung der Daten. Diese Konfiguration wird neu geschrieben.

2. Oder geben Sie

./redis-server --replicaof masterip masterport

an, wenn Sie das Redis-Server-Programm starten. 3. Oder melden Sie sich beim Client an und führen Sie den folgenden Befehl aus:

slaveof masterip masterport

Beachten Sie, dass diese Methode während des Betriebs geändert wird und ein Failover erfolgen kann Slave-Knoten Es kann auch der Masterknoten anderer Knoten sein, um eine kaskadierte Replikationsbeziehung zu bilden. Aber auch andere Knoten synchronisieren Daten vom Masterknoten der obersten Ebene.

Überprüfen Sie nach der Konfiguration des Clusters den Clusterstatus durch Informationsreplikation.

Verwenden Sie den Rollenbefehl, um die Rolleninformationen des Knotens im Cluster anzuzeigen.

Beachten Sie, dass der Slave-Knoten schreibgeschützt ist . Beim Schreiben des Befehls wird ein Fehler gemeldet.

Wie verlässt der Slave den Cluster? Sie können den folgenden Befehl ausführen:

slaveof no one

3. Master-Slave-Replikationsprozess

1. Zuerst tritt das Replikat-Replikat dem Cluster bei

2. Stellen Sie eine Verbindung zum Master her und prüfen Sie, ob Daten vom Masterknoten über einen Timer synchronisiert werden müssen.

Quellcode-Beschreibung:

//每1s执行这个方法
void replicationCron(void) {
    ...
    //检查是否需要连接到master 如果是REPL_STATE_CONNECT状态，必须连接到master
    //#define REPL_STATE_CONNECT 1  Must connect to master 
    if (server.repl_state == REPL_STATE_CONNECT) {
        serverLog(LL_NOTICE,"Connecting to MASTER %s:%d",
            server.masterhost, server.masterport);
        //和master创建连接    
        if (connectWithMaster() == C_OK) {
            serverLog(LL_NOTICE,"MASTER <-> REPLICA sync started");
        }
    }
    
    //发送ping命令给slave 
    if ((replication_cron_loops % server.repl_ping_slave_period) == 0 &&
        listLength(server.slaves))
    {
        /* Note that we don&#39;t send the PING if the clients are paused during
         * a Redis Cluster manual failover: the PING we send will otherwise
         * alter the replication offsets of master and slave, and will no longer
         * match the one stored into &#39;mf_master_offset&#39; state. */
        int manual_failover_in_progress =
            server.cluster_enabled &&
            server.cluster->mf_end &&
            clientsArePaused();

        if (!manual_failover_in_progress) {
            ping_argv[0] = createStringObject("PING",4);
            replicationFeedSlaves(server.slaves, server.slaveseldb,
                ping_argv, 1);
            decrRefCount(ping_argv[0]);
        }
    }
    
    //发送换行符到所有slave,告诉slave等待接收rdb文件
    listRewind(server.slaves,&li);
    while((ln = listNext(&li))) {
        client *slave = ln->value;

        int is_presync =
            (slave->replstate == SLAVE_STATE_WAIT_BGSAVE_START ||
            (slave->replstate == SLAVE_STATE_WAIT_BGSAVE_END &&
             server.rdb_child_type != RDB_CHILD_TYPE_SOCKET));

        if (is_presync) {
            if (write(slave->fd, "\n", 1) == -1) {
                /* Don&#39;t worry about socket errors, it&#39;s just a ping. */
            }
        }
    }
    ...
}

3. Vollständiger Kopiervorgang – unterstützt plattenloses Kopieren oder persistentes RDB-Kopie

Wenn der Slave verbunden ist: Nachdem Sie den Master erreicht haben, verwenden Sie den Befehl psync (früher der Sync-Befehl, der keine teilweise Neusynchronisierung zulässt, verwenden Sie jetzt stattdessen PSYNC), um die Replikation zu initialisieren, und senden Sie die Master-Knoten-Replikations-ID und maximaler verarbeiteter Offset zum Master.

Der Master-Knoten hat die folgenden zwei Attribute, eine Replikations-ID (Markierungsinstanz) und einen Offset (Markierung, die in den Stream des Slave-Knotens geschrieben wird)

Replication ID, offset

Wenn im Master-Knoten-Puffer nicht genügend Rückstandsarbeit vorhanden ist, oder Wenn es sich bei dem Replikat, auf das verwiesen wird, um einen historischen Datensatz (Replikations-ID) handelt, der nicht mehr bekannt ist, erfolgt eine vollständige Neusynchronisierung.

4. In der Befehlsweitergabephase geben Master und Slave nach der vollständigen Synchronisierung Befehle weiter, um Datenkonsistenz zu erreichen.

4. Replikations-ID verstehen

Jedes Mal, wenn eine Instanz als primäre Instanz von Grund auf neu gestartet wird oder ein Replikat zu einer primären Instanz heraufgestuft wird, wird für diese Instanz eine neue Replikations-ID generiert. Wenn zwei Replikate dieselbe Replikations-ID haben, können sie zu unterschiedlichen Zeiten dieselben Daten haben. Für einen bestimmten Verlauf (Replikations-ID), der den neuesten Datensatz enthält, wird der Offset als logische Zeit verstanden. Es muss anhand der beiden Daten Replikations-ID und Offset beurteilt werden. Wird verwendet, um festzustellen, wo der Slave-Knoten synchronisierte Daten hat.

5. Häufig gestellte Fragen zur Master-Slave-Replikation

1 Was passiert, wenn der Slave selbst über Daten verfügt?

Slave löscht zunächst seine eigenen Daten und lädt sie dann mit einer RDB-Datei.

2. Wie gehe ich beim Generieren von RDB-Dateien mit den Schreibbefehlen des Clients um?

Speichern Sie es im Speichercache und senden Sie es an den Slave, nachdem die RDB gesendet wurde.

3. Wie geht die Redis-Replikation mit dem Ablaufen von Schlüsseln um?

1. Die Kopie lässt den Schlüssel nicht ablaufen, sondern wartet darauf, dass der Host den Schlüssel abläuft. Wenn der Master einen Schlüssel abläuft (oder ihn aufgrund von LRU entfernt), synthetisiert er einen DEL-Befehl, der an alle Replikate übertragen wird.

2. Aufgrund des Ablaufs des Host-Treibers verfügt das Replikat jedoch manchmal immer noch über einen logisch abgelaufenen Speicherschlüssel, da der Master-Server den DEL-Befehl nicht rechtzeitig bereitstellen kann. Um dieses Problem zu lösen, verwendet das Replikat seine logische Uhr, um zu melden, dass ein Schlüssel nicht existiert, und wird nur für Lesevorgänge verwendet, die die Konsistenz des Datensatzes nicht verletzen (da neue Befehle vom Master eintreffen)

3 . Im Lua-Skript ausführen. Während dieses Zeitraums wird kein Schlüsselablauf durchgeführt. Wenn ein Lua-Skript ausgeführt wird, wird die Zeit im Masterknoten konzeptionell eingefroren, sodass ein bestimmter Schlüssel für die gesamte Zeit, in der das Skript ausgeführt wird, vorhanden ist oder nicht. Dadurch wird verhindert, dass der Schlüssel mitten in einem Skript abläuft und der Schlüssel dasselbe Skript auf eine Weise an das Replikat senden muss, die den gleichen Effekt im Datensatz gewährleistet.

Sobald ein Replikat zum primären Replikat hochgestuft wird, beginnt es selbstständig mit dem Ablaufen der Schlüssel und erfordert keine Hilfe vom alten primären Replikat.

6. Zusammenfassung der Master-Slave-Replikation

1 Das Problem der Datensicherung ist gelöst, aber die RDB-Datei ist groß, große Dateien werden übertragen und die Wiederherstellungszeit ist auch lang

2 anormal, das Replikat muss manuell als Master ausgewählt werden

3 Im Fall von 1 Master und mehreren Slaves gibt es immer noch ein Einzelpunktproblem

4 Redis Version 2.8.18 und höher unterstützt die plattenlose Replikation Leistung.

7. Replikationsanweisungen

1. Die Anzahl der synchronisierten Befehle wird durch Asynchronität bestätigt

2. Eine Kopie kann auch eine eigene haben Kopie, von redis4 Ab .0 erhalten Replikate genau den gleichen Replikationsstream vom Masterknoten

4 Die Replikation kann sowohl für die Skalierbarkeit als auch für mehrere Replikate von schreibgeschützten Abfragen verwendet werden

Für weitere programmierbezogene Kenntnisse bitte Besuchen Sie:

Einführung in die Programmierung

! !

Das obige ist der detaillierte Inhalt vonEine kurze Analyse des Prinzips der Cluster-Master-Slave-Replikation in Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!