Redis におけるクラスターのマスター/スレーブレプリケーションの原理の簡単な分析-Redis-php.cn

この記事では、Redis クラスターのマスター/スレーブレプリケーションの原理について詳しく説明します。お役に立てば幸いです。

Redis におけるクラスターのマスター/スレーブレプリケーションの原理の簡単な分析

# 1. まず最初に、Redis のパフォーマンスが非常に高いのに、なぜ分散ソリューションが必要なのかという疑問について考えてみましょう。

1. より高いパフォーマンスを実現するには: 同時実行性の高いアプリケーションは、単一マシンのパフォーマンスに影響を与えます。負荷を分散し、負荷分散を実現するには、より多くの Redis サーバーが必要です。

2 . 高可用性を達成するには: ダウンタイム/ハードウェア障害を防ぐために単一マシンの場合

#3. スケーラビリティを達成: 単一マシンのメモリとハードウェアには制限があり、水平拡張を実現します。

冗長ストレージまたは共有ストレージを実現して、以上の特徴。

2. マスター/スレーブのレプリケーション構成

Kafka、Mysql、Rocketmq と同様に、redis はクラスターのデプロイメントをサポートしており、クラスターノードはマスターとスレーブに分割されます。マスターノードマスターであり、スレーブノードがスレーブ（最新のものをレプリカと呼びます）であり、スレーブはレプリケーション機構を通じてマスターから最新のデータを同期します。 Redis は、マスター/スレーブレプリケーションを有効にするための非常に便利なコマンドを提供します。 [関連する推奨事項:

Redis ビデオチュートリアル ]

マスター/スレーブレプリケーションを構成して有効にする方法は?

ローカルに疑似クラスターを構築する場合を例に挙げると、ポート 6379 がスレーブノード、ポート 6378 がマスターノードになります。

1. スレーブノードの redis.conf で masterip マスターポートのレプリカを設定します。スレーブノードを起動すると、自動的にマスターノードに接続され、データの同期が開始されます。

Redis におけるクラスターのマスター/スレーブレプリケーションの原理の簡単な分析

新しいマスターノードが置き換えられると、この構成は書き換えられます。

2、または redis-server プログラムの起動時に

./redis-server --replicaof masterip masterport

ログイン後にコピー

3 を指定するか、クライアントにログインして次のコマンドを実行します。

slaveof masterip masterport

ログイン後にコピー

このメソッドは変更されていることに注意してください動作中にフェイルオーバーを実現できます。

注: スレーブノードは、他のノードのマスターノードにもなり、カスケードレプリケーション関係を形成できます。ただし、他のノードもトップレベルのマスターノードからのデータを同期します。

クラスターを構成した後、情報レプリケーションを通じてクラスターのステータスを確認します。

Redis におけるクラスターのマスター/スレーブレプリケーションの原理の簡単な分析

クラスター内のノードのロール情報は、 role command

Redis におけるクラスターのマスター/スレーブレプリケーションの原理の簡単な分析

スレーブノードは読み取り専用であることに注意してください。コマンドの書き込み時にエラーが報告されます。

Redis におけるクラスターのマスター/スレーブレプリケーションの原理の簡単な分析

スレーブはクラスターからどのように終了しますか? 次のコマンドを実行できます:

slaveof no one

ログイン後にコピー

3. マスター/スレーブレプリケーションプロセス

1. まず、レプリカ-レプリカがクラスターに参加します

Redis におけるクラスターのマスター/スレーブレプリケーションの原理の簡単な分析

2. マスターとの接続を確立し、マスターとの接続が確立されているかどうかを確認します。データはタイマーを介してマスターノードから同期する必要があります。

Redis におけるクラスターのマスター/スレーブレプリケーションの原理の簡単な分析

ソースコードの説明:

//每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. フルコピープロセス - ディスクレスをサポートcopy または rdb 永続コピー

Redis におけるクラスターのマスター/スレーブレプリケーションの原理の簡単な分析

スレーブがマスターに接続されているときは、psync (以前は sync コマンドで、部分的な再同期は許可されていないため、現在は代わりに PSYNC を使用してください) コマンドでレプリケーションを初期化し、マスターノードのレプリケーション ID と処理を最大オフセットを超えた後にマスターに送信します。

マスターノードには、レプリケーション ID (マークインスタンス) とオフセット (スレーブノードのストリームに書き込まれるマーク) の 2 つの属性があります。

Replication ID, offset

ログイン後にコピー

バックログが十分でない場合マスターノードのバッファー作業中、またはレプリカが不明になった履歴レコード (レプリケーション ID) を参照している場合、完全な再同期が発生します。

ソースコードの説明:

    //没有在rdb进程，没有aof重写进程
    if (server.rdb_child_pid == -1 && server.aof_child_pid == -1) {
        time_t idle, max_idle = 0;
        int slaves_waiting = 0;
        int mincapa = -1;
        listNode *ln;
        listIter li;

        listRewind(server.slaves,&li);
        while((ln = listNext(&li))) {
            client *slave = ln->value;
            //判断slave是否是等待bgsave状态
            if (slave->replstate == SLAVE_STATE_WAIT_BGSAVE_START) {
            //多久没有发送心跳或查询数据了 空闲时间间隔
                idle = server.unixtime - slave->lastinteraction;
                if (idle > max_idle) max_idle = idle;
                slaves_waiting++;
                mincapa = (mincapa == -1) ? slave->slave_capa :
                                            (mincapa & slave->slave_capa);
            }
        }

        if (slaves_waiting &&
            (!server.repl_diskless_sync ||
             max_idle > server.repl_diskless_sync_delay))
        {
            /* Start the BGSAVE. The called function may start a
             * BGSAVE with socket target or disk target depending on the
             * configuration and slaves capabilities. */
             //bgsave rdb生成
            startBgsaveForReplication(mincapa);
        }
    }

ログイン後にコピー

レプリケーション中にプロセス、スレーブ状態遷移プロセス。

Redis におけるクラスターのマスター/スレーブレプリケーションの原理の簡単な分析

#4. コマンド伝播段階では、完全同期が実行された後、マスターとスレーブはデータの一貫性を達成するためにコマンドを伝播します。

Redis におけるクラスターのマスター/スレーブレプリケーションの原理の簡単な分析

4. レプリケーション ID について

インスタンスがプライマリインスタンスとして最初から再起動されるとき、またはレプリカが昇格されるたびプライマリインスタンスに送信すると、このインスタンス用に新しいレプリケーション ID が生成されます。 2 つのレプリカが同じレプリケーション ID を持つ場合、それらは異なる時点で同じデータを持つ可能性があり、最新のデータセットを保持する特定の履歴 (レプリケーション ID) については、オフセットは論理時間として理解されます。 Replication IDとOffsetの2つのデータで判断する必要があります。スレーブノードがどこにデータを同期しているかを判断するために使用されます。

5. マスター/スレーブレプリケーション FAQ

1. スレーブ自体にデータがある場合はどうなりますか?

slave は最初に自身のデータを削除し、それから rdb ファイルをロードします。

2. rdb ファイルの生成プロセス中に、クライアントがコマンドを記述する場合、どのように対処すればよいでしょうか?

メモリキャッシュに保存し、rdb 送信後にスレーブに送信します。

3. Redis レプリケーションはキーの有効期限をどのように処理しますか?

1. コピーはキーを期限切れにしませんが、ホストがキーを期限切れにするまで待機します。マスターはキーの有効期限が切れる（または LRU によりキーを削除する）と、すべてのレプリカに送信される DEL コマンドを合成します。

2. ただし、ホストドライバーの有効期限が切れるため、マスターサーバーが DEL コマンドを時間内に提供できないため、レプリカに論理的に期限切れのメモリキーがまだ残っている場合があります。これに対処するために、レプリカは論理クロックを使用して、データセットの整合性に違反しない読み取り操作の場合にのみ、キーが存在しないことを報告します (マスターからの新しいコマンドが到着するため)

3 . Lua スクリプトの実行中にキーの有効期限は実行されません。 Lua スクリプトが実行されると、概念的にはマスターノードで時間が固定されるため、スクリプトの実行中は常に特定のキーが存在するか存在しません。これにより、キーがスクリプトの途中で期限切れになり、データセット内で同じ効果が保証される方法で同じスクリプトをレプリカに送信することがキーに要求されることがなくなります。

レプリカがプライマリに昇格すると、キーの期限切れが独立して開始され、古いプライマリからの支援は必要ありません。