Parlons des solutions haute disponibilité dans Redis !

Quelles sont les solutions haute disponibilité pour redis ? Cet article vous présentera les solutions haute disponibilité dans Redis. J'espère qu'il vous sera utile !

Redis n'est généralement pas déployé individuellement, sinon cela ne provoquera pas de point de défaillance unique. Alors, quelles sont les solutions haute disponibilité pour Redis ?

Réplication maître-esclave

Les utilisateurs peuvent utiliser la commande ou la configuration SLAVEOF pour permettre à un serveur de répliquer un autre serveur. Le serveur répliqué est appelé serveur maître et le serveur de réplication est appelé serveur esclave. De cette façon, vous ajoutez la valeur de la clé sur le serveur maître et la lisez en même temps sur le serveur esclave. [Recommandations associées : Tutoriel vidéo Redis]

Le processus de copie est divisé en deux étapes : la synchronisation et la propagation des commandes.

Synchronisation

La synchronisation mettra à jour l'état de la base de données du serveur vers l'état actuel de la base de données du serveur maître.

Lorsque le client envoie la commande SLAVEOF au serveur esclave, le serveur esclave se synchronisera SYNC命令 avec le serveur maître. Les étapes sont les suivantes :

• Le serveur esclave enverra la commande SYNC au serveur maître.

• Le serveur principal qui reçoit la commande SYNC exécute la commande BGSAVE, génère un fichier RDB en arrière-plan et utilise un tampon pour enregistrer toutes les commandes d'écriture exécutées à partir de maintenant.

• Une fois la commande BGSAVE du serveur maître exécutée, le serveur maître envoie le fichier RDB généré par BGSAVE au serveur esclave. Le serveur esclave reçoit et charge le fichier RDB et met à jour l'état de la base de données du serveur esclave au maître. serveur lorsqu'il exécute la commande BGSAVE. L'état de la base de données

• Le serveur maître envoie toutes les commandes d'écriture dans le tampon au serveur esclave, et le serveur esclave exécute ces commandes d'écriture et met à jour l'état de la base de données avec l'état actuel de la base de données. le serveur maître.

Propagation des commandes

Une fois l'opération de synchronisation terminée, l'état de la base de données du serveur maître et du serveur esclave est cohérent, mais une fois que le serveur maître a reçu la commande d'écriture du client, le maître -slave database L'incohérence des données se produit à nouveau et la cohérence de la base de données est obtenue grâce à la propagation des commandes.

Optimisation de la synchronisation PSYNC

La synchronisation avant 2.8 est une synchronisation complète à chaque fois, et si le serveur est juste déconnecté pendant un moment, en fait, il n'est pas nécessaire de relancer la synchronisation depuis le début, il vous suffit de vous déconnecter et les données seront synchronisées. La version 2.8 a donc commencé à utiliser PSYNC au lieu de la commande SYNC.

PSYNC est divisé en deux situations : la synchronisation complète et la synchronisation partielle consiste à gérer l'état de synchronisation initial, tandis que la synchronisation partielle consiste à gérer la situation de déconnexion et de reconnexion.

Mise en œuvre de la synchronisation partielle

La synchronisation partielle utilise principalement les trois parties suivantes :

• Le décalage de réplication du serveur maître et le décalage de réplication du serveur esclave
• Le tampon du backlog de réplication du serveur maître
• Le ID d'exécution du serveur

Décalage de réplication

Décalage de réplication du serveur maître : Chaque fois que le serveur maître propage N octets de données au serveur esclave, il augmente son propre décalage de réplication de +N Décalage de réplication du serveur esclave : Chaque fois que le serveur esclave recevra N octets de données transmises par le serveur maître, il augmentera son offset de réplication de +N Si les serveurs maître et esclave sont dans un état cohérent, leurs décalages sont toujours les mêmes. Si les décalages ne sont pas égaux, ils sont dans un état incohérent.

Tampon du backlog de copie

Le tampon du backlog de copie est une file d'attente FIFO de longueur fixe maintenue par le serveur principal. La taille par défaut est de 1 Mo. Lorsque la longueur maximale est atteinte, le premier élément mis en file d'attente sera éjecté pour donner. chemin vers les éléments nouvellement mis en file d’attente.
Lorsque la commande redis est propagée, elle sera non seulement envoyée au serveur esclave, mais également au tampon du backlog de réplication.

Lorsque le serveur esclave se reconnecte au serveur maître, le serveur esclave enverra son décalage de réplication au serveur maître via la commande PSYNC. Le serveur maître décide d'utiliser la synchronisation partielle ou la synchronisation complète en fonction du décalage de réplication. Si les données après le décalage sont toujours copiées dans le tampon de backlog, une synchronisation partielle est utilisée, sinon une synchronisation complète est utilisée.
(Le livre ne dit pas comment juger. Je suppose que cela devrait être le décalage de la copie principale moins le décalage de la copie esclave. S'il est supérieur à 1 Mo, cela signifie qu'il y a des données qui ne sont pas dans le backlog du tampon ?)

L'ID courant du serveur

Lorsque le serveur démarre, il générera un caractère aléatoire à 40 chiffres comme ID courant du serveur.

Lorsque le serveur esclave se réplique pour la première fois sur le serveur maître, le serveur maître transmettra son ID d'exécution au serveur esclave, et le serveur esclave enregistrera cet ID d'exécution. Lorsque le serveur esclave est déconnecté et reconnecté, l'ID d'exécution enregistré lui sera envoyé. Si l'ID d'exécution enregistré par le serveur esclave est le même que l'ID d'exécution du serveur maître actuel, une synchronisation partielle sera tentée. différente, une synchronisation complète sera effectuée.

Le processus global de PSYNC

Détection du rythme cardiaque

Dans l'étape de propagation de la commande, le serveur esclave enverra la commande au serveur maître à une fréquence d'une fois par seconde par défaut :
REPLICONF ACK &lt ;replication_offset>REPLICONF ACK <replication_offset></replication_offset>
其中replication_offset就是从服务器当前的复制偏移量。 发送REPLICONF ACK命令对于主从服务器有三个作用：

• 检测主从服务器的网络连接状态。

• 辅助实现min-slaves选项。

• 检测命令丢失。

检测主从服务器的网络连接状态

主从服务器可以通过发送和接收REPLICONF ACK命令来检查两者之间的网络连接是否正常：如果主服务器超过一秒钟没有收到从服务器发来的REPLICONF ACK命令，那么主服务器就知道主从之间出现问题了。

辅助实现min-slaves选项

redis的min-slaves-to-write和min-slaves-max-lagoù replication_offset est le décalage de réplication actuel à partir du serveur. L'envoi de la commande REPLICONF ACK a trois fonctions pour les serveurs maître et esclave :

Détecter l'état de connexion réseau des serveurs maître et esclave.

Implémentation auxiliaire de l'option min-esclaves.

Détecter la perte de commande.

Détectez l'état de la connexion réseau du serveur maître-esclave

Le serveur maître-esclave peut vérifier si la connexion réseau entre les deux est normale en envoyant et en recevant la commande REPLICONF ACK : Si le serveur maître ne le fait pas recevez un message du serveur esclave pendant plus d'une seconde commande REPLICONF ACK envoyée par le serveur, alors le serveur maître sait qu'il y a un problème entre le maître et l'esclave.

Implémentation auxiliaire de l'option min-slaves

Les deux options min-slaves-to-write et min-slaves-max-lag de redis peuvent empêcher le master- slave Le serveur exécute la commande d'écriture de manière non sécurisée.

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

Si configuré comme ci-dessus, cela signifie que si le nombre de serveurs esclaves est inférieur à 3, ou si le délai des 3 serveurs esclaves est supérieur ou égal à 10 secondes, alors le serveur maître refusera d'exécuter la commande d'écriture .

Détecter la perte de commande

• Si la commande d'écriture transmise du serveur maître au serveur esclave est perdue à mi-chemin en raison d'une panne de réseau, alors lorsque le serveur esclave envoie la commande REPLICONF ACK au serveur maître, le serveur maître découvrir le décalage de réplication actuel du serveur esclave Si le décalage est inférieur à son propre décalage, alors le serveur maître peut trouver les données manquantes du serveur esclave dans le tampon de réplication en fonction du décalage de réplication du serveur esclave, réécrire les données et envoyer au serveur esclave.

• Résumé de la réplication maître-esclave

• En fait, la réplication maître-esclave est une copie supplémentaire des données, car même s'il y a RDB et AOF pour la persistance, la machine entière sur le serveur maître peut raccrocher, et la réplication maître-esclave peut Les serveurs maître et esclave sont déployés sur deux machines différentes, de sorte que même si la machine du serveur maître raccroche, vous pouvez basculer manuellement vers le serveur esclave pour continuer le service.

sentinelBien que le maître-esclave implémente la sauvegarde des données, lorsque le serveur maître raccroche, vous devez passer manuellement du serveur esclave au serveur maître. Sentinel peut passer automatiquement du serveur secondaire au serveur principal lorsque le serveur principal raccroche.

Le système sentinelle peut surveiller tous les serveurs maîtres et esclaves, en supposant que le serveur 1 est désormais hors ligne. Lorsque le temps hors ligne du serveur 1 dépasse la limite supérieure du temps hors ligne défini par l'utilisateur, le système sentinelle effectuera un basculement sur le serveur 1 :

Tout d'abord, le système sentinelle sélectionnera l'un des serveurs esclaves sous le serveur 1 et transférera le serveur sélectionné. serveur esclave vers celui-ci. Le serveur est mis à niveau vers le nouveau serveur principal. Après cela, le système sentinelle enverra de nouvelles commandes de réplication à tous les serveurs esclaves sous le serveur 1, leur permettant de devenir des serveurs esclaves du nouveau serveur maître. L'opération de basculement est terminée lorsque tous les serveurs esclaves ont été répliqués sur le nouveau serveur maître.

De plus, sentinel surveillera également le serveur hors ligne1 et, lorsqu'il reviendra en ligne, le définira comme serveur esclave du nouveau serveur maître.

Initialiser l'état sentinelle

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;

🎜Initialiser l'attribut masters de l'état sentinelle🎜🎜🎜🎜masters enregistre les informations pertinentes de tous les serveurs maîtres surveillés par sentinel, où se trouve la clé du dictionnaire le nom du serveur surveillé et la valeur est la structure sentinelRedisInstance correspondant au serveur surveillé. sentinelRedisInstance est une instance surveillée par le serveur sentinelle, qui peut être un serveur maître, un serveur esclave ou d'autres instances sentinelles. 🎜

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;

🎜🎜🎜Créez une connexion réseau au serveur principal 🎜🎜🎜🎜La dernière étape de l'initialisation de Sentinel consiste à créer une connexion réseau au serveur principal surveillé. Deux connexions au serveur principal seront créées. 🎜🎜🎜🎜🎜🎜🎜🎜Connexion de commande🎜 : envoyez spécifiquement des commandes au serveur principal et recevez des réponses aux commandes. 🎜🎜Connexion d'abonnement🎜 : Spécialement utilisée pour s'abonner au canal _sentinel_:hello du serveur principal. 🎜

Obtenir les informations sur le serveur principal

sentinel enverra la commande INFO au serveur principal surveillé via la connexion de commande toutes les 10 secondes par défaut et obtiendra les informations actuelles du serveur principal via la réponse. Répondez pour obtenir les informations suivantes.

• Le run_id du serveur maître
• Les informations de tous les serveurs esclaves sous le serveur maître.

Le dictionnaire de noms et le champ runid sous sentinelRedisInstance peuvent être mis à jour en fonction de ces informations.

Obtenir des informations sur le serveur esclave

sentinel créera également des connexions de commande et des connexions d'abonnement au serveur esclave.

sentinel enverra une commande INFO au serveur esclave via la connexion de commande toutes les 10 secondes par défaut et obtiendra les informations actuelles du serveur esclave via la réponse. La réponse est la suivante :

• L'ID courant du serveur esclave
• Le rôle du serveur esclave
• L'IP et le port du serveur maître
• L'état de connexion du serveur maître master_link_status
• La priorité du serveur esclave slave_priority
• Le serveur esclave La variable de décalage de copie

Selon les informations de réponse d'info, sentinel peut mettre à jour la structure d'instance du serveur esclave.

Envoyer des informations aux connexions d'abonnement des serveurs maître et esclave

Par défaut, Sentinel enverra des commandes aux serveurs maître et esclave surveillés une fois toutes les 2 secondes.

s_ip : adresse IP de Sentinel s_ip:sentinel的ip地址
s_port:sentinel的端口号
s_runid:sentinel的运行id
s_epoch:sentinel当前的配置纪元
m_name:主服务器的名字
m_ip:主服务器的ip地址
m_port:主服务器的端口号
m_epoch:主服务器当前的配置纪元
向sentinel_:hello频道发送信息，也会被监视同一个服务器的其他sentinel监听到（包括自己）。

创建连向其他sentinel的命令连接

sentinel之间会互相创建命令连接。监视同一个嘱咐其的多个sentinel将形成相互连接的网络。

sentinel之间不会创建订阅连接。

检测主观下线状态

sentinel会每秒一次向所有与它创建了命令连接的实例（主服务器、从服务器、其他sentinel）发送ping命令，通过实例的回复来判断实例是否在线。
有效回复：实例返回+PONG、-LOADING、-MASTERDOWN其中一种。
无效回复：以上三种回复之外的其他回复，或者指定时长内没回复。
某个实例在down-after-milliseconds毫秒内，连续向sentinel返回无效回复。那么sentinel就会修改这个实例对应的实例结构，在结构的flags属性中打开SRI_S_DOWN标识，标识该实例进入主观下线状态。（down-after-milliseconds可以在sentinel的配置文件中配置）

检测客观下线状态

当sentinel将一个主服务器判断为主观下线后，为了确认这个主服务器是否真的下线，还会想其他同样监视这个主服务器的其他sentinel询问，看其他sentinel是否也认为该主服务器下线了。超过一定数量就将主服务器判断为客观下线。

询问其他sentinel是否同意该服务器下线

SENTINEL is-master-down-by-addr <ip><port><current_epoch><runid></runid></current_epoch></port></ip>s_port : numéro de port de Sentinel

s_runid : identifiant d'exécution de Sentinel

s_epoch code> : l'époque de configuration actuelle de Sentinel <p><code>m_name : le nom du serveur principal

m_ip : l'adresse IP du serveur principal

m_port : Le numéro de port du serveur principal

m_epoch : L'époque de configuration actuelle du serveur principalL'envoi d'informations au canal sentinel_:hello sera également surveillé par d'autres sentinelles surveillant le même serveur (y compris vous-même).

Créez des connexions de commande avec d'autres sentinelles

Les sentinelles créeront des connexions de commande entre elles. Plusieurs sentinelles surveillant le même commandement formeront un réseau interconnecté.

Aucune connexion d’abonnement ne sera créée entre les sentinelles.

Détecter le statut subjectif hors ligne

🎜🎜sentinel enverra une commande ping à toutes les instances (serveur maître, serveur esclave, autre sentinelle) avec lesquelles elle a créé une connexion de commande une fois par seconde, et jugera l'instance via le réponse de l'instance Est-ce en ligne ? 🎜🎜Réponse valide🎜 : l'instance renvoie l'un des éléments +PONG, -LOADING et -MASTERDOWN. 🎜🎜Réponse invalide🎜 : réponses autres que les trois types de réponses ci-dessus, ou aucune réponse dans le délai imparti. 🎜Une instance renvoie continuellement des réponses invalides à Sentinel dans les down-after-milliseconds millisecondes. Ensuite, Sentinel modifiera la structure de l'instance correspondant à cette instance et activera l'indicateur SRI_S_DOWN dans l'attribut flags de la structure pour indiquer que l'instance est entrée dans l'état subjectif hors ligne. (les temps d'arrêt après millisecondes peuvent être configurés dans le fichier de configuration de Sentinel) 🎜🎜🎜🎜Détecter l'état objectif hors ligne🎜🎜🎜🎜🎜Lorsque Sentinel détermine qu'un serveur principal est subjectivement hors ligne, afin de confirmer si le serveur principal est vraiment hors ligne S'il se déconnecte, il demandera également aux autres sentinelles qui surveillent également le serveur principal de voir si d'autres sentinelles pensent également que le serveur principal est hors ligne. Si le nombre dépasse un certain nombre, le serveur principal sera jugé objectivement hors ligne. 🎜🎜🎜🎜Demandez aux autres sentinelles si elles acceptent que le serveur soit hors ligne🎜🎜🎜SENTINEL is-master-down-by-addr <ip><port><current_epoch><runid></runid></current_epoch></port></ip>🎜 🎜🎜Demander via la commande SENTINEL is-master-down-by-addr La signification des paramètres est la suivante : 🎜🎜🎜🎜🎜🎜🎜Recevoir la commande SENTINEL is-master-down-by-addr 🎜🎜. 🎜Une autre sentinelle reçoit le SENTINEL is - Une fois la commande master-down-by-addr exécutée, elle vérifiera si le serveur maître est hors ligne en fonction de l'adresse IP et du port du serveur maître, puis renverra une réponse multi-bloc contenant trois paramètres. 🎜🎜🎜🎜🎜sentinel compte le nombre d'autres sentinelles qui conviennent que le serveur principal a été hors ligne. Lorsque le nombre configuré est atteint, le drapeau SRI_O_DOWN de l'attribut flags du serveur principal est activé, indiquant que le serveur principal est hors ligne. est entré dans un état objectif hors ligne. 🎜🎜🎜🎜Élire le leader sentinelle🎜🎜🎜

Lorsqu'un serveur maître est jugé objectivement hors ligne, chaque sentinelle surveillant le serveur maître hors ligne négociera pour élire une nouvelle sentinelle leader, et cette sentinelle effectuera des opérations de basculement.

Après avoir confirmé que le serveur maître est entré dans l'état objectif hors ligne, la commande SENTINEL is-master-down-by-addr sera à nouveau envoyée pour élire la sentinelle leader.

Règles d'élection

• Chacune des multiples sentinelles en ligne surveillant le même serveur maître peut devenir la sentinelle leader.
• Après chaque élection de sentinelle de leader, que l'élection soit réussie ou non, les valeurs d'époque de configuration de toutes les sentinelles seront incrémentées d'elles-mêmes. (Une époque de configuration est en fait un compteur)
• Dans une époque de configuration, toutes les sentinelles ont la possibilité de définir une certaine sentinelle comme sentinelle locale. Une fois définie dans cette époque de configuration, elle ne peut pas être modifiée.
• Toutes les sentinelles qui découvrent que le serveur maître est objectivement hors ligne demanderont aux autres sentinelles de se définir comme sentinelle principale locale, c'est-à-dire qu'elles enverront la commande SENTINEL is-master-down-by-addr pour essayer de laisser les autres sentinelles se positionnent comme la principale sentinelle locale.
• Quand une sentinelle envoie la commande SENTINEL is-master-down-by-addr à une autre sentinelle, si la valeur du paramètre runid n'est pas *, mais le runid de la sentinelle source, cela signifie que la sentinelle cible est requise. Définissez-vous comme sentinelle principale. SENTINEL is-master-down-by-addr命令时，如果runid参数的值不是*，而是源sentinel的runid,就表示要目标sentinel将自己设置成领头sentinel。
• sentinel设置局部领头的规则是先到先得
La règle permettant à la sentinelle de désigner le leader local est la suivante : premier arrivé, premier servi. Une fois la première sentinelle désignée comme leader local, toutes les autres demandes seront rejetées.
• Après avoir reçu une commande SENTINEL is-master-down-by-addr, la sentinelle cible renverra une réponse de commande à la sentinelle source. Les paramètres leader_runid et leader_epoch dans la réponse enregistrent respectivement le runid et l'époque de configuration de la sentinelle leader locale de la sentinelle cible.
• Une fois que la sentinelle source a reçu la réponse, elle comparera si l'époque de configuration renvoyée est la même que sa propre époque de configuration. Si tel est le cas, elle continuera à comparer si l'ID d'exécution de la sentinelle principale locale renvoyée est la même que la sienne. runid. S'ils sont cohérents, cela signifie que la sentinelle cible changera son propre runid. Se configure en tant que sentinelle principale locale.
• Si une sentinelle est définie comme sentinelle principale locale par plus de la moitié des sentinelles, alors elle devient la sentinelle principale.
• La sentinelle principale a besoin du soutien de plus de la moitié et ne peut être définie qu'une seule fois à chaque époque de configuration. Ensuite, dans une époque de configuration, une seule sentinelle principale apparaîtra
• Si dans un certain délai, chaque sentinelle est élue. la sentinelle principale (aucune personne n'obtient plus de la moitié des voix), puis chaque sentinelle sera réélue après un certain temps jusqu'à ce que la sentinelle principale soit élue

Failover

Le basculement comprend les éléments suivants trois étapes :

• Une fois hors ligne Parmi tous les serveurs esclaves sous le serveur maître, sélectionnez un serveur esclave et convertissez-le en serveur maître.

• Laissez tous les serveurs esclaves du serveur maître hors ligne être copiés sur le nouveau serveur maître.

• Définissez le serveur maître hors ligne comme serveur esclave du nouveau serveur. Une fois que l'ancien serveur maître est revenu en ligne, il devient le serveur esclave du nouveau serveur maître.

Sélectionnez un nouveau serveur maître

Sélectionnez un serveur esclave parmi tous les serveurs esclaves sous le serveur maître hors ligne et envoyez la commande SLAVEOF no one au serveur esclave pour convertir le serveur esclave Devenez le maître serveur.

Règles de sélection d'un nouveau serveur maître

La sentinelle principale enregistrera tous les serveurs esclaves du serveur maître hors ligne dans une liste, puis filtrera cette liste pour sélectionner un nouveau serveur maître.

• Supprimez tous les serveurs esclaves de la liste qui sont hors ligne ou déconnectés.

• Supprimez tous les serveurs esclaves de la liste qui n'ont pas répondu à la commande INFO de la sentinelle principale au cours des cinq dernières secondes

• Supprimez tous les serveurs qui ont été déconnectés des serveurs hors ligne pendant plus de quelques millisecondes * 10 millisecondes

• Triez ensuite les serveurs esclaves restants dans la liste en fonction de la priorité du serveur esclave, et sélectionnez le serveur avec la priorité la plus élevée.

• S'il existe plusieurs serveurs esclaves avec la même priorité la plus élevée, triez en fonction du décalage de réplication et sélectionnez le serveur esclave avec le décalage le plus élevé (le décalage de réplication le plus élevé signifie également que les données qu'il enregistre sont les dernières)

• Si le décalage de réplication est le même, triez en fonction du runid et sélectionnez le serveur esclave avec le plus petit runid

Après avoir envoyé la commande slaveof no one, la sentinelle principale enverra des informations au serveur esclave mis à niveau une fois par mois. Deuxième commande (généralement une fois toutes les 10 secondes), si le rôle de réponse renvoyé passe de l'esclave d'origine au maître, alors la sentinelle principale saura que le serveur esclave a été mis à niveau vers le serveur maître.

Modifier la cible de réplication du serveur esclave

🎜

通过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不再执行写请求。

主从数据不一致

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

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

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

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!