Analisis ringkas tentang prinsip replikasi tuan-hamba kluster dalam Redis

Artikel ini akan memberi anda pemahaman yang mendalam tentang prinsip replikasi tuan-hamba gugusan Redis. Saya harap ia akan membantu anda!

1. Mula-mula fikirkan soalan, mengapa redis memerlukan penyelesaian teragih apabila prestasinya begitu tinggi?

1 Mencapai prestasi yang lebih tinggi: Aplikasi konkurensi tinggi akan memberi kesan pada prestasi mesin tunggal Lebih banyak pelayan redis diperlukan untuk berkongsi tekanan dan mencapai pengimbangan beban

2. Mencapai ketersediaan tinggi: Jika Mesin Tunggal untuk mengelakkan masa henti/kegagalan perkakasan

3. Mencapai kebolehskalaan: Memori dan perkakasan mesin tunggal adalah terhad, capai pengembangan mendatar

Storan berlebihan atau serpihan untuk mencapai ciri di atas .

2. Konfigurasi replikasi-induk-hamba

Seperti Kafka, Mysql dan Rocketmq, redis menyokong penempatan kelompok terbahagi kepada induk dan hamba nod induk Ia adalah induk, dan nod hamba ialah hamba (yang terbaru dipanggil replika). Redis menyediakan arahan yang sangat mudah untuk membolehkan replikasi tuan-hamba. [Cadangan berkaitan: Tutorial video Redis]

Bagaimana untuk mengkonfigurasi dan mendayakan replikasi tuan-hamba?

Ambil membina gugusan pseudo secara tempatan sebagai contoh Port 6379 ialah nod hamba dan port 6378 ialah nod induk.

1. Konfigurasikan replika masterport dalam redis.conf daripada nod hamba, ia akan menyambung secara automatik ke nod induk dan mula menyegerakkan data 🎜>

Jika nod induk baharu diganti, konfigurasi ini akan ditulis semula. 2. Atau nyatakan

apabila memulakan program pelayan-semula Atau log masuk ke klien dan laksanakan arahan berikut

./redis-server --replicaof masterip masterport

Ambil perhatian bahawa ini. kaedah ialah Pengubahsuaian semasa operasi boleh mencapai failover

Nota: Nod hamba juga boleh menjadi nod induk nod lain, membentuk hubungan replikasi lata. Tetapi nod lain juga menyegerakkan data daripada nod induk peringkat atas.

slaveof masterip masterport

Selepas mengkonfigurasi gugusan, semak status gugusan melalui replikasi maklumat

Gunakan arahan peranan untuk menyemak maklumat peranan nod dalam kelompok

Perhatikan bahawa nod hamba adalah baca sahaja. Ralat akan dilaporkan semasa menulis arahan.

Bagaimana hamba keluar dari kelompok Anda boleh melaksanakan perintah berikut:

3 proses

slaveof no one

1 Mula-mula, replika-replika menyertai kluster

2 sama ada ia mahu bermula dari nod induk secara kerap melalui pemasa Segerakkan data

Perihalan kod sumber:

3 proses - menyokong salinan tanpa cakera atau salinan berterusan rdb

//每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. */
            }
        }
    }
    ...
}

Apabila hamba disambungkan kepada induk, gunakan pync (sebelum ini arahan penyegerakan, yang tidak membenarkan separa penyegerakan semula, jadi sekarang gunakan arahan PSYNC) untuk memulakan replikasi dan menyambungkan nod induk Id replikasi dan ofset maksimum yang diproses dihantar kepada induk. Nod induk mempunyai dua atribut berikut, id replikasi (contoh tanda) dan offset (tanda strim ditulis pada nod hamba)

Jika tidak mencukupi dalam tunggakan penimbal nod induk, atau jika replika merujuk rekod sejarah (ID replikasi) yang tidak diketahui lagi, penyegerakan semula penuh berlaku

Penerangan sumber:

Replication ID, offset

Semasa replikasi , proses peralihan keadaan hamba.

    //没有在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);
        }
    }

4. Dalam peringkat penyebaran arahan, selepas penyegerakan penuh dilakukan, tuan dan hamba akan menyebarkan arahan untuk mencapai konsistensi data.

4. Memahami id replikasi

Setiap kali kejadian dimulakan semula dari awal sebagai contoh utama atau replika dipromosikan kepada contoh utama, ID replikasi baharu akan dijana untuk tika ini. Jika dua replika mempunyai ID replikasi yang sama, mereka mungkin mempunyai data yang sama pada masa yang berbeza Untuk sejarah tertentu (ID replikasi) yang memegang set data terkini, ofset difahami sebagai masa yang logik. Ia perlu dinilai oleh dua data ID Replikasi dan mengimbangi. Digunakan untuk menentukan di mana nod hamba telah menyegerakkan data.

5. Soalan Lazim tentang Replikasi Master-Slave

1.

Hamba mula-mula memadamkan datanya sendiri dan kemudian memuatkannya dengan fail rdb.

2. Semasa proses menjana fail RDB, bagaimana untuk menangani arahan menulis klien?

Simpan ke cache memori, dan hantar ke hamba selepas penghantaran rdb selesai.

3. Bagaimanakah replikasi Redis mengendalikan tamat tempoh kunci?

1. Salinan tidak akan tamat tempoh kunci, tetapi akan menunggu untuk hos tamat tempoh kunci. Apabila induk tamat tempoh kunci (atau mengusirnya kerana LRU), ia mensintesis arahan DEL yang dihantar ke semua replika.

2 Walau bagaimanapun, disebabkan oleh tamat tempoh dipacu hos, kadangkala replika mungkin masih mempunyai kunci memori yang telah tamat tempoh secara logik kerana pelayan induk tidak dapat menyediakan arahan DEL dalam masa yang ditetapkan. Untuk mengendalikan ini, replika menggunakan jam logiknya untuk melaporkan bahawa kunci tidak wujud, hanya untuk operasi baca yang tidak melanggar ketekalan set data (kerana arahan baharu daripada induk akan tiba)

3 . Tamat tempoh kunci tidak dilakukan semasa pelaksanaan skrip Lua. Apabila skrip Lua dijalankan, secara konsepnya masa dibekukan dalam nod induk, jadi kunci yang diberikan akan wujud atau tidak wujud sepanjang masa skrip berjalan. Ini menghalang kunci daripada tamat tempoh di tengah-tengah skrip dan memerlukan kunci untuk menghantar skrip yang sama ke replika dengan cara yang menjamin kesan yang sama dalam set data.

Sebaik sahaja replika dinaikkan ke peringkat utama, ia akan mula tamat tempoh kunci secara bebas dan tanpa sebarang bantuan daripada kunci utama lama.

6. Ringkasan replikasi tuan-hamba

1 masa pemulihan juga panjang

2. Jika tuan tidak normal, anda perlu memilih replika secara manual sebagai tuan

3 Dalam kes 1 tuan dan berbilang hamba, 1 tuan dan 1 hamba, masih terdapat masalah satu mata

4 Redis Versi 2.8.18 dan kemudiannya menyokong replikasi tanpa cakera dengan prestasi yang lebih tinggi.

7. Arahan replikasi

1 Replikasi tak segerak digunakan secara lalai, dan bilangan arahan disegerakkan disahkan oleh tak segerak

2. Satu induk boleh mempunyai berbilang Setiap salinan

3 Salinan juga boleh mempunyai salinannya sendiri Bermula dari redis4.0, salinan akan menerima aliran replikasi yang sama dari nod induk

4. . Replikasi boleh digunakan untuk sifat berskala, dan juga boleh digunakan untuk berbilang salinan pertanyaan baca sahaja

Untuk lebih banyak pengetahuan berkaitan pengaturcaraan, sila lawati: Pengenalan kepada Pengaturcaraan! !

Atas ialah kandungan terperinci Analisis ringkas tentang prinsip replikasi tuan-hamba kluster dalam Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!