Mari bercakap tentang penyelesaian ketersediaan tinggi dalam redis!

Apakah penyelesaian ketersediaan tinggi untuk redis? Artikel ini akan memperkenalkan anda kepada penyelesaian ketersediaan tinggi dalam redis. Saya harap ia akan membantu anda!

Redis biasanya tidak digunakan secara individu, jika tidak, ia tidak akan menyebabkan satu titik kegagalan Jadi apakah penyelesaian ketersediaan tinggi untuk redis?

Replikasi tuan-hamba

Pengguna boleh menggunakan perintah atau konfigurasi SLAVEOF untuk membenarkan satu pelayan mereplikasi pelayan lain. Pelayan yang direplikasi dipanggil pelayan induk, dan pelayan yang mereplikasi dipanggil pelayan hamba. Dengan cara ini, anda menambah nilai kunci pada pelayan induk dan membacanya pada pelayan hamba pada masa yang sama. [Cadangan berkaitan: Tutorial video Redis]

Proses replikasi dibahagikan kepada dua langkah: penyegerakan dan penyebaran arahan.

Penyegerakan

Penyegerakan akan mengemas kini status pangkalan data pelayan kepada status pangkalan data semasa pelayan induk.

Apabila pelanggan menghantar arahan SLAVEOF ke pelayan hamba, pelayan hamba akan SYNC命令 menyegerakkan dengan pelayan induk adalah seperti berikut:

• Pelayan hamba akan menyegerakkan dengan pelayan induk Arahan SYNC berlaku pada pelayan induk.

• Pelayan utama yang menerima arahan SYNC melaksanakan arahan BGSAVE, menjana fail RDB di latar belakang dan menggunakan penimbal untuk merekodkan semua arahan tulis yang dilaksanakan mulai sekarang.

• Selepas arahan BGSAVE pelayan induk dilaksanakan, pelayan induk menghantar fail RDB yang dijana oleh BGSAVE ke pelayan hamba menerima dan memuatkan fail RDB dan memperoleh status pangkalan data daripada pelayan Kemas kini kepada status pangkalan data apabila pelayan induk melaksanakan perintah BGSAVE

• Pelayan induk menghantar semua arahan tulis dalam penimbal kepada pelayan hamba dan pelayan hamba melaksanakannya. menulis arahan dan mengemas kini status pangkalan data kepada induk Status pangkalan data semasa pelayan.

Penyebaran arahan

Selepas operasi penyegerakan selesai , induk Status pangkalan data pelayan dan pelayan hamba adalah konsisten, tetapi selepas pelayan induk menerima arahan tulis klien, ketidakkonsistenan data berlaku antara pangkalan data induk dan hamba Pada masa ini, pangkalan data adalah konsisten melalui penyebaran arahan.

Pengoptimuman penyegerakan PSYNC

Penyegerakan sebelum 2.8 ialah penyegerakan penuh setiap kali, dan jika ia daripada pelayan Anda hanya memutuskan sambungan untuk seketika. Sebenarnya, anda tidak perlu menyegerakkan dari awal Anda hanya perlu menyegerakkan data semasa tempoh pemotongan. Jadi versi 2.8 mula menggunakan PSYNC dan bukannya arahan SYNC.

PSYNC terbahagi kepada dua situasi: penyegerakan penuh dan penyegerakan separa Penyegerakan penuh adalah untuk mengendalikan keadaan penyegerakan awal, manakala penyegerakan separa adalah untuk mengendalikan situasi pemotongan dan penyambungan semula.

Pelaksanaan penyegerakan separa

Penyegerakan separa terutamanya menggunakan tiga bahagian berikut:

• Imbangan replikasi pelayan induk dan pelayan hamba Replikasi mengimbangi
• Replikasi penimbal tunggakan induk
• Menjalankan ID pelayan

Replikasi mengimbangi

Imbang replikasi pelayan induk: Setiap kali pelayan induk menghantar N bait data ke pelayan hamba, ia mengimbangi replikasinya sendiri dengan Nmengimbangi replikasi pelayan hamba : Setiap kali pelayan hamba menerima N bait data yang dihantar oleh pelayan induk, ia akan menyalin offsetnya sendiri oleh N Jika pelayan induk dan hamba berada dalam keadaan konsisten, ofset mereka sentiasa sama. Jika offset tidak sama, ia berada dalam keadaan tidak konsisten.

Salin penimbal tunggakan

Penimbal tunggakan salinan ialah baris gilir FIFO panjang tetap yang dikekalkan oleh pelayan utama Saiz lalai ialah 1MB. entri pertama Elemen dalam baris gilir akan dikeluarkan untuk memberi laluan kepada elemen yang baru dicantumkan.
Apabila arahan redis disebarkan, ia bukan sahaja akan dihantar ke pelayan hamba, tetapi juga kepada penimbal tunggakan replikasi.

Apabila pelayan hamba menyambung semula ke pelayan induk, pelayan hamba akan menghantar offset replikasinya sendiri kepada pelayan induk melalui arahan PSYNC, dan pelayan induk akan menyalin offset berdasarkan pada Gunakan jumlah untuk memutuskan sama ada untuk menggunakan penyegerakan separa atau penyegerakan penuh. Jika data selepas offset offset masih disalin ke dalam penimbal tunggakan, penyegerakan separa digunakan, jika tidak, penyegerakan penuh digunakan.
(Buku itu tidak mengatakan cara menilai. Saya rasa ia sepatutnya menjadi salinan induk mengimbangi tolak mengimbangi salinan hamba. Jika ia lebih besar daripada 1MB, bermakna ada data yang tiada dalam tunggakan penimbal?)

ID berjalan pelayan

Apabila pelayan bermula, ia akan menjana aksara rawak 40 digit sebagai ID yang menjalankan pelayan.

Apabila pelayan hamba mereplikasi ke pelayan induk buat kali pertama, pelayan induk akan menghantar ID berjalannya ke pelayan hamba dan pelayan hamba akan menyimpan ID berjalan ini. Apabila pelayan hamba diputuskan sambungan dan disambungkan semula, ID berjalan yang disimpan akan dihantar kepadanya Jika ID berjalan yang disimpan oleh pelayan hamba adalah sama dengan ID berjalan pelayan induk semasa, penyegerakan separa akan dicuba berbeza, penyegerakan penuh akan dilakukan.

Proses keseluruhan PSYNC

Pengesanan degupan jantung

Dalam fasa penyebaran arahan, pelayan hamba akan menghantar arahan kepada pelayan induk pada kekerapan sekali sesaat secara lalai:
REPLICONF ACK <replication_offset></replication_offset>
di mana replication_offset ialah ofset replikasi semasa pelayan hamba. Menghantar arahan REPLICONF ACK mempunyai tiga fungsi untuk pelayan induk dan hamba:

• Kesan status sambungan rangkaian pelayan induk dan hamba.

• Pelaksanaan tambahan pilihan hamba min.

• Arahan pengesanan hilang.

Kesan status sambungan rangkaian pelayan induk dan hamba

Pelayan induk dan hamba boleh menyemak status sambungan rangkaian antara kedua-duanya dengan menghantar dan menerima arahan REPLICONF ACK Sama ada sambungan rangkaian adalah normal: Jika pelayan induk tidak menerima arahan REPLICONF ACK daripada pelayan hamba selama lebih daripada satu saat, maka pelayan induk akan mengetahui bahawa terdapat masalah antara induk dan hamba.

Pelaksanaan tambahan bagi pilihan hamba min

Pilihan min-slaves-to-write dan min-slaves-max-lag Redis boleh menghalang pelayan tuan-hamba daripada melaksanakan arahan tulis dalam situasi tidak selamat .

min-slaves-to-write 3
min-slaves-max-lag 10

Jika dikonfigurasikan seperti di atas, ini bermakna jika bilangan pelayan hamba kurang daripada 3, atau kelewatan semua 3 pelayan hamba lebih besar daripada atau sama dengan 10 saat, maka pelayan induk akan enggan melaksanakan arahan tulis.

Kesan kehilangan arahan

Jika arahan tulis yang disebarkan dari pelayan induk ke pelayan hamba hilang separuh jalan akibat kegagalan rangkaian, maka apabila pelayan hamba menghantar Perintah REPLICONF ACK ke pelayan induk, pelayan induk akan mendapati bahawa replikasi semasa mengimbangi pelayan hamba adalah kurang daripada mengimbanginya sendiri, maka pelayan induk boleh mencari data yang hilang dari pelayan hamba dalam penimbal replikasi berdasarkan replikasi mengimbangi pelayan hamba, dan memulihkan data ini. Tulisan dihantar ke pelayan hamba.

Ringkasan replikasi tuan-hamba

Malah, replikasi tuan-hamba adalah salinan tambahan data, kerana walaupun terdapat RDB dan AOF untuk kegigihan, replikasi induk-hamba mungkin Jika seluruh mesin pada pelayan ditutup, replikasi induk-hamba boleh menggunakan pelayan induk dan hamba pada dua mesin yang berbeza, walaupun mesin pelayan induk ditutup, anda boleh secara manual beralih ke pelayan hamba untuk meneruskan perkhidmatan.

sentinel

Walaupun master-slave melaksanakan sandaran data, apabila pelayan master ditutup, anda perlu menukar secara manual daripada pelayan slave kepada pelayan induk. Sentinel boleh bertukar secara automatik daripada pelayan kedua kepada pelayan utama apabila pelayan utama ditutup.

Sistem sentinel boleh memantau semua pelayan induk dan hamba, dengan mengandaikan pelayan1 berada di luar talian sekarang. Apabila masa luar talian pelayan1 melebihi had atas masa luar talian yang ditetapkan oleh pengguna, sistem sentinel akan melakukan failover untuk pelayan1:

• Pertama, sistem sentinel akan memilih salah satu hamba di bawah pelayan1 dan tingkatkan pelayan hamba yang dipilih kepada pelayan induk baharu.

• Selepas itu, sistem sentinel akan menghantar arahan replikasi baharu kepada semua pelayan hamba di bawah pelayan1, membolehkan mereka menjadi pelayan hamba pelayan induk baharu. Operasi failover selesai apabila semua pelayan hamba telah mereplikasi ke pelayan induk baharu.

• Selain itu, sentinel juga akan memantau pelayan luar talian1, dan apabila ia kembali dalam talian, tetapkannya sebagai pelayan hamba pelayan induk baharu.

Memulakan keadaan sentinel

struct sentinelState {
    char myid[CONFIG_RUN_ID_SIZE+1]; 
    // 当前纪元，用于实现故障转移
    uint64_t current_epoch;
    // 保存了所有被这个sentinel监视的主服务器
    // 字典的键是主服务器的名字
    // 字典的值是指向sentinelRedisInstance结构的指针
    dict *masters;
    // 是否进入了TILT模式
    int tilt;         
    // 目前正在执行的脚本数量
    int running_scripts;   
    // 进入TILT模式的时间
    mstime_t tilt_start_time;   
    // 最后一次执行时间处理器的时间
    mstime_t previous_time;     
    // 一个fifo队列，包含了所有需要执行的用户脚本
    list *scripts_queue;            
    char *announce_ip;  
    int announce_port; 
    unsigned long simfailure_flags; 
    int deny_scripts_reconfig;
    char *sentinel_auth_pass;   
    char *sentinel_auth_user;    
    int resolve_hostnames;      
    int announce_hostnames;     
} sentinel;

Memulakan atribut induk bagi keadaan sentinel

master merekodkan maklumat tentang semua pelayan induk yang dipantau oleh sentinel Kunci kamus ialah nama pelayan yang dipantau dan nilainya ialah struktur sentinelRedisInstance yang sepadan dengan pelayan yang dipantau. sentinelRedisInstance ialah tika yang dipantau oleh pelayan sentinel, yang boleh menjadi pelayan induk, pelayan hamba atau tika sentinel lain.

typedef struct sentinelRedisInstance {
    // 标识值，记录实例的类型，以及该实例的当前状态
    int flags;  
    // 实例的名字
    // 主服务器名字在配置文件中设置
    // 从服务器和sentinel名字由sentinel自动设置，格式是ip:port
    char *name; 
    // 运行id
    char *runid;   
    // 配置纪元，用于实现故障转移
    uint64_t config_epoch;  
    // 实例的地址
    sentinelAddr *addr; /* Master host. */
    // 实例无响应多少毫秒之后，判断为主观下线
    mstime_t down_after_period; 
    // 判断这个实例为客观下线所需的支持投票数量
    unsigned int quorum;
    // 执行故障转移，可以同时对新的主服务器进行同步的从服务器数量
    int parallel_syncs; 
    // 刷新故障迁移状态的最大时限
    mstime_t failover_timeout;  
    // 除了自己外，其他监视主服务器的sentinel
    // 键是sentinel的名字，格式是ip:port
    // 值是键对应的sentinel的实例结构
    dict *sentinels;  
    // ...
} sentinelRedisInstance;

Buat sambungan rangkaian ke pelayan induk

Langkah terakhir dalam memulakan sentinel ialah membuat sambungan rangkaian kepada yang dipantau sambungan pelayan induk, dua sambungan ke pelayan utama akan dibuat.

Sambungan arahan : Hantar arahan secara khusus ke pelayan utama dan terima balasan arahan.
Sambungan langganan: digunakan khas untuk melanggan saluran _sentinel_:hello pelayan utama.

Dapatkan maklumat pelayan utama

Sentinel akan menghantar arahan INFO kepada pelayan utama yang dipantau melalui sambungan arahan setiap 10 saat secara lalai, dan dapatkan maklumat semasa pelayan utama melalui jawapannya. Balas untuk mendapatkan maklumat berikut.

• run_id pelayan induk
• Maklumat semua pelayan hamba di bawah pelayan induk.

Kamus nama dan medan runid di bawah sentinelRedisInstance boleh dikemas kini berdasarkan maklumat ini.

Dapatkan maklumat pelayan hamba

sentinel juga akan membuat sambungan arahan dan sambungan langganan ke pelayan hamba.

Secara lalai, sentinel akan menghantar arahan INFO kepada pelayan hamba melalui sambungan arahan setiap 10 saat dan mendapatkan maklumat semasa pelayan hamba melalui balasan. Jawapannya adalah seperti berikut:

• ID berjalan pelayan hamba
• Peranan pelayan hamba
• IP pelayan induk dan port
• Status sambungan pelayan induk master_link_status
• Keutamaan pelayan hamba slave_priority
• Pembolehubah offset replikasi hamba pelayan

Menurut info Berdasarkan maklumat balasan, sentinel boleh mengemas kini struktur instance pelayan hamba.

Hantar maklumat kepada sambungan langganan pelayan induk dan pelayan hamba

Secara lalai, sentinel akan menghantar maklumat kepada pelayan induk dan pelayan hamba yang dipantau sekali setiap 2 saat Pesanan.

s_ip:alamat ip sentinel
s_port:nombor port sentinel
s_runid:id larian sentinel
s_epoch:sentinel's zaman konfigurasi semasa
m_name:nama pelayan utama
m_ip:alamat ip pelayan utama
m_port:nombor port pelayan utama
m_epoch:utama zaman konfigurasi semasa pelayan
menghantar maklumat ke saluran sentinel_:hello, yang juga akan dipantau oleh sentinel lain yang memantau pelayan yang sama (termasuk dirinya sendiri).

Buat sambungan arahan kepada pengawal lain

Sentinel akan membuat sambungan arahan antara satu sama lain. Berbilang pengawal yang memantau arahan yang sama akan membentuk rangkaian yang saling berkaitan.

Tiada sambungan langganan akan dibuat antara pengawal.

Kesan status luar talian subjektif

sentinel akan menghantar mesej kepada semua kejadian yang mana ia telah mencipta sambungan arahan (pelayan utama) sekali setiap saat , dari pelayan, pengawal lain), hantar arahan ping untuk menentukan sama ada tika itu dalam talian melalui balasan tika itu.
Balasan sah: Instance mengembalikan salah satu PONG, -LOADING dan -MASTERDOWN.
Balasan tidak sah: Balas selain daripada tiga jenis balasan di atas, atau tiada balasan dalam masa yang ditetapkan.
Sesuatu kejadian secara berterusan mengembalikan balasan tidak sah kepada sentinel dalam masa down-after-milliseconds milisaat. Kemudian sentinel akan mengubah suai struktur tika yang sepadan dengan tika ini dan menghidupkan bendera SRI_S_DOWN dalam atribut bendera struktur untuk menunjukkan bahawa tika itu telah memasuki keadaan luar talian subjektif. (ke bawah-selepas-milisaat boleh dikonfigurasikan dalam fail konfigurasi sentinel)

Kesan status luar talian objektif

Apabila sentinel akan Selepas pelayan utama dinilai sebagai luar talian secara subjektif, untuk mengesahkan sama ada pelayan utama benar-benar luar talian, pengawal lain yang turut memantau pelayan utama akan diminta untuk melihat sama ada pengawal lain juga berpendapat bahawa pelayan utama berada di luar talian. Jika nombor melebihi nombor tertentu, pelayan utama akan dinilai sebagai luar talian secara objektif.

Tanya pengawal lain jika mereka bersetuju untuk membawa pelayan ke luar talian

SENTINEL dikuasai oleh-addr <ip><port><current_epoch><runid></runid></current_epoch></port></ip>

Pertanyakan melalui arahan SENTINEL is-master-down-by-addr Maksud parameter adalah seperti berikut:

Terima. SENTINEL is-master-down- by-addr command

Selepas sentinel lain menerima arahan SENTINEL is-master-down-by-addr, mereka akan menyemak sama ada pelayan induk berada di luar talian berdasarkan IP dan port pelayan induk, dan kemudian kembalikan mesej yang mengandungi Respons kepada Berbilang Pukal dengan tiga parameter.

sentinel mengira bilangan sentinel lain yang bersetuju bahawa pelayan utama telah berada di luar talian Apabila nombor yang dikonfigurasikan dicapai, bendera SRI_O_DOWN atribut bendera pelayan utama dihidupkan, menunjukkan bahawa pelayan utama telah di luar talian Masukkan keadaan luar talian objektif.

Pilih ketua pengawal

Apabila pelayan induk dinilai sebagai luar talian secara objektif, setiap sentinel yang memantau pelayan induk luar talian akan berunding untuk memilih sentinel ketua baharu, dan sentinel ini akan melakukan operasi failover.

Selepas mengesahkan bahawa pelayan induk telah memasuki keadaan luar talian objektif, arahan SENTINEL is-master-down-by-addr akan dihantar semula untuk memilih ketua sentinel.

Peraturan pilihan raya

• Setiap berbilang pengawal dalam talian yang memantau pelayan induk yang sama boleh menjadi pengawal ketua.
• Selepas setiap pemilihan ketua sentinel, tidak kira sama ada pemilihan itu berjaya atau tidak, nilai era konfigurasi semua sentinel akan dinaikkan. (Zaman konfigurasi sebenarnya ialah kaunter)
• Dalam zaman konfigurasi, semua sentinel mempunyai peluang untuk menetapkan sentinel tertentu sebagai sentinel tempatan Setelah ditetapkan dalam epoch konfigurasi ini, ia tidak boleh diubah.
• Semua sentinel yang mendapati pelayan induk berada di luar talian secara objektif akan meminta sentinel lain untuk menetapkan diri mereka sebagai sentinel ketua tempatan, iaitu, mereka akan menghantar arahan SENTINEL is-master-down-by-addr untuk mencuba untuk membiarkan sentinel lain menetapkan diri mereka Menjadi sentinel terkemuka tempatan.
• Apabila seorang sentinel menghantar arahan SENTINEL is-master-down-by-addr kepada sentinel lain, jika nilai parameter runid bukan *, tetapi runid sentinel sumber, ini bermakna sentinel sasaran diperlukan untuk menetapkan dirinya sebagai ketua pengawal.
• Peraturan untuk sentinel menetapkan ketua tempatan ialah 先到先得 Selepas sentinel pertama ditetapkan sebagai ketua tempatan, semua permintaan lain akan ditolak.
• Selepas menerima arahan SENTINEL is-master-down-by-addr, sentinel sasaran akan mengembalikan balasan arahan kepada sentinel sumber. Parameter leader_runid dan parameter leader_epoch dalam balasan merekodkan runid dan epok konfigurasi bagi sentinel pemimpin tempatan bagi sentinel sasaran masing-masing.
• Selepas sentinel sumber menerima balasan, ia akan membandingkan sama ada zaman konfigurasi yang dikembalikan adalah sama dengan zaman konfigurasinya sendiri Jika ia adalah sama, ia akan terus membandingkan sama ada runid peneraju tempatan yang dikembalikan sentinel adalah sama dengan runidnya sendiri Jika mereka konsisten, ini bermakna Sentinel sasaran menetapkan dirinya sebagai sentinel pemimpin tempatan.
• Jika sentinel ditetapkan sebagai sentinel terkemuka tempatan oleh lebih separuh daripada sentinel, maka sentinel itu akan menjadi sentinel terkemuka.
• Sentinel terkemuka memerlukan sokongan lebih daripada separuh, dan hanya boleh ditetapkan sekali dalam setiap zaman konfigurasi Kemudian hanya akan ada satu sentinel terkemuka dalam zaman konfigurasi
• Jika dalam tempoh tertentu. had masa, setiap satu Jika sentinel dipilih sebagai ketua sentinel (tiada seorang pun mendapat lebih daripada separuh undi), maka setiap sentinel akan dipilih semula selepas tempoh masa sehingga ketua sentinel

failover

Failover termasuk tiga langkah berikut:

• Di antara semua pelayan hamba di bawah pelayan induk luar talian, pilih pelayan hamba dan menukarnya kepada pelayan Utama.

• Biar semua pelayan hamba di bawah pelayan induk luar talian disalin ke pelayan induk baharu.

• Tetapkan pelayan induk luar talian sebagai pelayan hamba pelayan baharu Selepas pelayan induk lama kembali dalam talian, ia akan menjadi pelayan hamba pelayan induk baharu.

Pilih pelayan induk baharu

Semua pelayan hamba di bawah pelayan induk luar talian , pilih hamba pelayan, hantar arahan SLAVEOF no one kepada pelayan hamba, dan tukar pelayan hamba kepada pelayan induk.

Peraturan untuk memilih pelayan induk baharu

Sentinel terkemuka akan menyimpan semua pelayan hamba pelayan induk luar talian ke dalam senarai, dan kemudian pilih ini Tapis senarai untuk memilih pelayan induk baharu.

• Padam semua pelayan hamba dalam senarai yang di luar talian atau terputus sambungan.

• Padam semua pelayan hamba dalam senarai yang belum membalas arahan INFO pengawal utama dalam lima saat terakhir

• Padam semua pelayan luar talian Pelayan yang sambungannya diputuskan selama lebih daripada berkurangan selepas milisaat * 10 milisaat

• Kemudian susun pelayan hamba yang tinggal dalam senarai mengikut keutamaan pelayan hamba, dan pilih keutamaan antaranya Pelayan tertinggi.

• Jika terdapat berbilang pelayan hamba dengan keutamaan tertinggi yang sama, kemudian susunkannya mengikut ofset replikasi dan pilih pelayan hamba dengan ofset terbesar (offset replikasi terbesar juga Maksudnya bahawa data yang disimpannya adalah yang terkini)

• Jika offset replikasi adalah sama, kemudian susun mengikut runid, dan pilih pelayan hamba dengan runid terkecil

Selepas menghantar arahan slaveof no one, ketua sentinel akan menghantar arahan info kepada pelayan hamba yang dinaik taraf sekali setiap saat (biasanya sekali setiap 10 saat jika peranan balasan yang dikembalikan berubah daripada hamba asal kepada). tuan, maka ketua Sentinel akan tahu bahawa pelayan hamba telah dinaik taraf kepada pelayan tuan.

Ubah suai sasaran replikasi pelayan hamba

通过SLAVEOF命令来使从服务器复制新的主服务器。当sentinel监测到旧的主服务器重新上线后，也会发送SLAVEOF命令使它成为新的主服务器的从服务器。

sentinel总结

sentinel其实就是一个监控系统，，而sentinel监测到主服务器下线后，可以通过选举机制选出一个领头的sentinel，然后由这个领头的sentinel将下线主服务器下的从服务器挑选一个切换成主服务器，而不用人工手动切换。

集群

哨兵模式虽然做到了主从自动切换，但是还是只有一台主服务器进行写操作（当然哨兵模式也可以监视多个主服务器，但需要客户端自己实现负载均衡）。官方也提供了自己的方式实现集群。

节点

每个redis服务实例就是一个节点，多个连接的节点组成一个集群。

CLUSTER MEET <ip><port></port></ip>

向另一个节点发送CLUSTER MEET命令，可以让节点与目标节点进行握手，握手成功就能将该节点加入到当前集群。

启动节点

redis服务器启动时会根据cluster-enabled配置选项是否为yes来决定是否开启服务器集群模式。

集群数据结构

每个节点都会使用一个clusterNode结构记录自己的状态，并为集群中其他节点都创建一个相应的clusterNode结构，记录其他节点状态。

typedef struct clusterNode {
    // 创建节点的时间
    mstime_t ctime; 
    // 节点的名称
    char name[CLUSTER_NAMELEN];
    // 节点标识
    // 各种不同的标识值记录节点的角色（比如主节点或从节点）
    // 以及节点目前所处的状态（在线或者下线）
    int flags;     
    // 节点当前的配置纪元，用于实现故障转移
    uint64_t configEpoch;
    // 节点的ip地址
    char ip[NET_IP_STR_LEN];  
    // 保存建立连接节点的有关信息
    clusterLink *link;          
    
    list *fail_reports;  
    // ...
} clusterNode;

clusterLink保存着连接节点所需的相关信息

typedef struct clusterLink {
    // ...
    // 连接的创建时间
    mstime_t ctime;           
    // 与这个连接相关联的节点，没有就为null
    struct clusterNode *node;   
    // ...
} clusterLink;

每个节点还保存着一个clusterState结构，它记录了在当前节点视角下，集群目前所处的状态，例如集群在线还是下线，集群包含多少个节点等等。

typedef struct clusterState {
    // 指向当前节点clusterNode的指针
    clusterNode *myself;  
    // 集群当前的配置纪元，用于实现故障转移
    uint64_t currentEpoch;
    // 集群当前的状态，上线或者下线
    int state;           
    // 集群中至少处理一个槽的节点数量
    int size;      
    // 集群节点的名单（包括myself节点）
    // 字典的键是节点的名字，字典的值为节点对应的clusterNode结构
    dict *nodes; 
} clusterState;

CLUSTER MEET 命令的实现

CLUSTER MEET <ip><port></port></ip>

• 节点 A 会为节点 B 创建一个clusterNode结构，并将该结构添加到自己的clusterState.nodes 字典里面。

• 之后，节点 A 将根据 CLUSTER MEET 命令给定的 IP 地址和端口号，向节点 B 发送一条 MEET 消息。

• 如果一切顺利，节点 B 将接收到节点 A 发送的 MEET 消息，节点 B 会为节点 A 创建一个clusterNode结构，并将该结构添加到自己的clusterState.nodes字典里面。

• 之后，节点 B 将向节点 A 返回一条 PONG 消息。

• 如果一切顺利，节点 A 将接收到节点 B 返回的 PONG 消息，通过这条 PONG 消息节点 A 可以知道节点 B 已经成功地接收到了自己发送的 MEET 消息。

• 之后，节点 A 将向节点 B 返回一条 PING 消息。

• 如果一切顺利，节点B将接收到节点A返回的PING消息，通过这条PING消息节点B知道节点A已经成功接收到自己返回的PONG消息，握手完成。

槽指派

集群的整个数据库被分为16384个槽，每个键都属于16384个槽的其中一个，集群中每个节点处理0个或16384个槽。当所有的槽都有节点在处理时，集群处于上线状态，否则就是下线状态。

CLUSTER ADDSLOTS

CLUSTER ADDSLOTS <slot>...</slot>
通过CLUSTER ADDSLOTS命令可以将指定槽指派给当前节点负责，例如：CLUSTER ADDSLOTS 0 1 2 3 4 可以将0至4的槽指派给当前节点

记录节点的槽指派信息

clusterNode结构的slots属性和numslot属性记录了节点负责处理哪些槽：

typedef struct clusterNode {
         
    unsigned char slots[CLUSTER_SLOTS/8];
    
    int numslots;
    // ...
} clusterNode;

slots：是一个二进制数组，一共包含16384个二进制位。当二进制位的值是1，代表节点负责处理该槽，如果是0，代表节点不处理该槽numslots：numslots属性则记录节点负责处理槽的数量，也就是slots中值为1的二进制位的数量。

传播节点的槽指派信息

节点除了会将自己负责的槽记录在clusterNode中，还会将slots数组发送给集群中的其他节点，以此告知其他节点自己目前负责处理哪些槽。

typedef struct clusterState {
    clusterNode *slots[CLUSTER_SLOTS];
} clusterState;

slots包含16384个项，每一个数组项都是指向clusterNode的指针，表示被指派给该节点，如果未指派给任何节点，那么指针指向NULL。

CLUSTER ADDSLOTS命令的实现

在集群中执行命令

客户端向节点发送与数据库有关的命令时，接收命令的节点会计算出命令要处理的数据库键属于哪个槽，并检查该槽是否指派给了自己。
如果指派给了自己，那么该节点直接执行该命令。如果没有，那么该节点会向客户端返回一个MOCED的错误，指引客户端转向正确的节点，并再次发送执行的命令。

计算键属于那个槽

CRC16(key)是计算出键key的CRC16的校验和，而 & 16383就是取余，算出0-16383之间的整数作为键的槽号。

判断槽是否由当前节点负责处理

计算出键所属的槽号i后，节点就能判断该槽号是否由自己处理。
如果clusterState.slots[i]等于如果clusterState.myself,那么由自己负责该节点可以直接执行命令。
如果不相等，那么可以获取clusterState.slots[i]指向如果clusterNode的ip和端口，向客户端返回MOVED错误，指引客户端转向负责该槽的节点。

集群模式下不会打印MOVED错误，而是直接自动转向。

重新分片

redis集群重新分配可以将任意数量已经指派给某个节点的槽改为指派给另一个节点，相关槽所属的键值对也会从源节点移动到目标节点。
重新分片操作是在线进行的，在重新分片的过程中，集群不用下线，源节点和目标节点都可以继续处理命令请求。 redis集群的重新分片操作是由redis-trib负责执行。重新分片执行步骤如下：

• redis-trib对目标节点发送CLUSTER SETSLOT <slot> IMPORTING <source_id></source_id></slot>命令，让目标节点准备好从源节点导入槽slot的键值对。

• redis-trib对源节点发送CLUSTER SETSLOT <slot> MIGRTING <target_id></target_id></slot>命令，让源节点准备好将属于槽slot的键值对迁移至目标节点。

• redis-trib向源节点发送CLUSTER GETKEYSINSLOT <slot> <count></count></slot>命令，获取最多count个属于槽的键值对的键名称。

• 对于步骤3获取的每个键名，redis-trib都向源节点发送一个MIGRTING <target_ip> <target_port> <key_name> 0 <timeout></timeout></key_name></target_port></target_ip>命令，将被选中的键值对从源节点迁移至目标节点。

• 重复执行步骤3和步骤4，直到源节点保存的所以属于槽slot的键值对都被迁移至目标节点。

• redis-trib向集群中任何一个节点发送CLUSTER SETSLOT <slot> NODE <target_id></target_id></slot>命令，将槽指派给目标节点。这一信息最终会通过消息发送至整个集群。

CLUSTER SETSLOT IMPORTING 命令实现

typedef struct clusterState {
    // ...
    clusterNode *importing_slots_from[CLUSTER_SLOTS];

} clusterState;

importing_slots_from记录了当前节点正在从其他节点导入的槽。importing_slots_from[i]不为null，则指向CLUSTER SETSLOT <slot> IMPORTING <source_id></source_id></slot>命令，所代表的clusterNode结构。

CLUSTER SETSLOT MIGRTING 命令实现

typedef struct clusterState {
    // ...
    clusterNode *migrating_slots_to[CLUSTER_SLOTS];

} clusterState;

migrating_slots_to记录了当前节点正在迁移至其他节点的槽。migrating_slots_to[i]不为null，则指向迁移至目标节点所代表的clusterNode结构。

ASK错误

在重新分片期间，源节点向目标节点迁移槽的过程中，可能属于这个槽的一部分键值对一部分保存在源节点当中，而另一部分保存在目标节点当中。
客户端向源节点发送一个与数据库键有关的命令，恰好这个槽正在被迁移。
源节点现在自己的数据库中查找指定的键，如果找到，直接执行。
如果没有找到，节点会检查migrating_slots_to[i]查看键是否正在迁移，如果在迁移就返回一个ask错误，引导客户端转向目标节点。

ASKING

客户端收到ask错误之后，会先执行ASKING命令，再向目标节点发送命令。ASKING命令就是打开发送该命令的客户端的REDIS_ASKING标识。一般来说客户端发送的键如果不属于自己负责会返回MOVED错误（槽只迁移部分，这时槽还不属于目标节点负责），但还会检查importing_slots_from[i]，如果显示节点正在导入槽i，并且发送命令的客户端带有REDIS_ASKING标识，那么它就会破例执行一次该命令。

集群的故障转移

集群的故障转移效果和哨兵模式类似，也是将从节点升级成主节点。旧的主节点重新上线后将会成为新主节点的从节点。

故障检测

集群中每个节点会定期的向集群中其他节点发送PING消息，检测对方是否在线，如果指定时间内没有收到PONG消息，那么就将该节点标记为疑似下线。clusterState.nodes字典中找到该节点的clusterNode结构，将flags属性修改成REDIS_NODE_PFAIL标识。
集群中各个节点会互相发送消息来交换集群中各个节点的状态，例如：主节点A得知主节点B认为主节点C进入了疑似下线状态，主节点A会在clusterState.nodes字典中找到节点C的clusterNode结构，并将主节点B的下线报告添加到clusterNode结构的fail_reports链表当中。
每一个下线报告由一个clusterNodeFailReport结构表示

typedef struct clusterNodeFailReport {
    struct clusterNode *node; 
    // 最后一次收到下线报告的时间
    mstime_t time;            
} clusterNodeFailReport;

如果一个集群当中，半数以上负责处理槽的主节点都将某个主节点X报告为疑似下线。那么这个主节点X将被标记为已下线。将主节点X标记成已下线的节点会向集群广播一条关于主节点X的FAIL消息。所有收到这条FAIL消息的节点都会将主节点X标记成已下线。

故障转移

当一个从节点发现自己正在复制的主节点进入了已下线状态，从节点将开始对下线主节点进行故障转移。

• 复制下线主节点的所有从节点，会有一个主节点被选中。

• 被选中的从节点会执行SLAVEOF no one 命令，成为新的主节点。

• 新的主节点会撤销所有对已下线主节点的槽指派，并将这些槽全部指派给自己。

• 新的主节点向集群广播一条PONG消息，这条PONG消息可以让集群中的其他节点立即知道这个节点已经由从节点变成主节点。这个主节点已经接管了已下线节点负责处理的槽。

• 新的主节点开始接收和自己负责处理的槽有关的命令请求，故障转移完成。

选举新的主节点

新的主节点通过选举产生

• 集群的配置纪元是一个自增计数器，它的初始值为0。

• 当集群的某个节点开始一次故障转移操作，集群的配置纪元的值加1。

• 对于每个配置纪元，集群里每个负责处理槽的主节点都有一次投票的机会，第一个想主节点要求投票的从节点将获得主节点的投票。

• 当从节点发现自己正在复制的主节点进入已下线状态时，从节点会向集群广播一条CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST消息，要求所有收到这条消息，并具有投票权的主节点向这个从节点投票。

• 如果一个主节点具有投票权（它正在负责处理槽），并且这个主节点尚未投票给其他从节点，那么主节点将向要求投票的从节点返回一条CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息，表示这个主节点支持从节点成为新的主节点。

• 每个参与选举的从节点都会接收CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息，并根据自己收到了多少条这种消息来统计自己获得了多少主节点的支持。

• 如果集群里有 N 个具有投票权的主节点，那么当一个从节点收集到大于等于 N / 2 + l 张支持票时，这个从节点就会当选为新的主节点。

• 因为在每一个配置纪元里面，每个具有投票权的主节点只能投一次票，所以如果有 N 个主节点进行投票，那么具有大于等于 N / 2 + l 张支持票的从节点只会有一个，这确保了新的主节点只会有一个。

• 如果在一个配置纪元里面没有从节点能收集到足够多的支持票，那么集群进人一个新的配置纪元，并再次进行选举，直到选出新的主节点为止。

主节点选举的过程和选举领头sentinel的过程非常相似。

数据丢失

主从复制数据丢失

主从复制之间是异步执行的，有可能master的部分数据还没来得及同步到从数据库，然后master就挂了，这时这部分未同步的数据就丢失了。

脑裂

脑裂就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着。此时哨兵可能就会认为master 宕机了，然后开启选举，将其他slave切换成了master，这个时候，集群里面就会有2个master，也就是所谓的脑裂。
此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续向旧master的写数据。
master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据将会清空，重新从新的master复制数据，导致数据丢失。

减少数据丢失的配置

min-slaves-to-writ 1
min-slaves-max-lag 10

上述配置表示，如果至少有1个从服务器超过10秒没有给自己ack消息，那么master不再执行写请求。

主从数据不一致

当从数据库因为网络原因或者执行复杂度高命令阻塞导致滞后执行同步命令，导致数据同步延迟，造成了主从数据库不一致。

都看到这了，点个赞再走了吧:)

更多编程相关知识，请访问：编程入门！！

Atas ialah kandungan terperinci Mari bercakap tentang penyelesaian ketersediaan tinggi dalam redis!. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!