Redis Advanced Learning High Availability Sentinel (partage de résumé)

Cet article vous apporte des connaissances pertinentes sur la sentinelle à haute disponibilité dans Redis, y compris les problèmes liés à l'architecture, au déploiement et à la configuration des fonctions. J'espère qu'il sera utile à tout le monde.

Apprentissage recommandé : Tutoriel vidéo Redis

1. Fonction et architecture

1 Fonction

Avant de présenter Sentinel, passez d'abord en revue les technologies liées à la haute disponibilité de Redis d'un point de vue macro. Ils comprennent : la persistance, la réplication, la sentinelle et le cluster. Leurs principales fonctions et problèmes résolus sont :

• Persistance : la persistance est la méthode de haute disponibilité la plus simple (parfois même pas classée comme méthode de haute disponibilité), principalement la fonction est constituée de données. sauvegarde, c'est-à-dire que les données sont stockées sur le disque dur pour garantir qu'elles ne seront pas perdues en raison de la sortie du processus.
• Réplication : la réplication est la base de Redis à haute disponibilité. Sentinel et Cluster atteignent tous deux une haute disponibilité basée sur la réplication. La réplication implémente principalement la sauvegarde des données sur plusieurs machines, ainsi que l'équilibrage de charge et la récupération simple des pannes pour les opérations de lecture. Défauts : la récupération après panne ne peut pas être automatisée ; les opérations d'écriture ne peuvent pas être équilibrées en charge ; la capacité de stockage est limitée par une seule machine.
• Sentinel : basé sur la réplication, Sentinel implémente une récupération automatique après panne. Inconvénients : les opérations d'écriture ne peuvent pas être équilibrées en charge ; la capacité de stockage est limitée par une seule machine.
• Cluster : grâce au clustering, Redis résout le problème selon lequel les opérations d'écriture ne peuvent pas être équilibrées en charge et la capacité de stockage est limitée par une seule machine, obtenant ainsi une solution de haute disponibilité relativement complète.

Parlons maintenant de la sentinelle.

Redis Sentinel, le Redis Sentinel, a été introduit dans la version 2.8 de Redis. La fonctionnalité principale de Sentinel est le basculement automatique du nœud maître. Ce qui suit est la description de la fonction Sentinel dans le document officiel de Redis :

• Surveillance : Sentinel vérifiera en permanence si le nœud maître et les nœuds esclaves fonctionnent normalement.
• Basculement automatique : lorsque le nœud maître ne peut pas fonctionner correctement, Sentinel lancera une opération de basculement automatique. Il mettra à niveau l'un des nœuds esclaves du nœud maître défaillant vers le nouveau nœud maître et laissera les autres nœuds esclaves passer à Copier le nœud maître. nouveau nœud maître.
• Fournisseur de configuration : lors de l'initialisation, le client obtient l'adresse du nœud maître du service Redis actuel en se connectant à la sentinelle.
• Notification : Sentinel peut envoyer les résultats du basculement au client.

Parmi elles, les fonctions de surveillance et de basculement automatique permettent à Sentinel de détecter les pannes du nœud maître à temps et de terminer le transfert ; tandis que les fonctions de fournisseur de configuration et de notification doivent être reflétées dans l'interaction avec le client.

Voici une explication de l'utilisation du mot « client » dans l'article : Dans l'article précédent, tant que le serveur redis est accessible via l'API, il sera appelé client, y compris redis-cli, client Java Jedis, etc. ; afin de faciliter la différenciation et l'explication, le client dans cet article n'inclut pas redis-cli, mais est plus complexe que redis-cli : redis-cli utilise l'interface sous-jacente fournie par redis, tandis que le client les encapsule. interfaces et fonctions afin de tirer pleinement parti des fournisseurs de configuration et des capacités de notification de Sentinel.

2. Architecture

Le schéma typique de l'architecture Sentinel est le suivant :

Il se compose de deux parties, le nœud sentinelle et le nœud de données :

• Nœud Sentinelle : Le système sentinelle se compose d'une ou plusieurs sentinelles. nœuds, les nœuds Sentinel sont des nœuds Redis spéciaux qui ne stockent pas de données.
• Nœuds de données : les nœuds maîtres et les nœuds esclaves sont tous deux des nœuds de données.

2. Déploiement

Cette partie déployera un système sentinelle simple, comprenant 1 nœud maître, 2 nœuds esclaves et 3 nœuds sentinelles. Pour plus de commodité : tous ces nœuds sont déployés sur une seule machine (LAN IP : 192.168.92.128), distingués par des numéros de port ; la configuration des nœuds est simplifiée au maximum.

1. Déployer des nœuds maître-esclave

Les nœuds maître-esclave du système Sentinel sont les mêmes que les nœuds maître-esclave ordinaires et ne nécessitent aucune configuration supplémentaire. Voici les fichiers de configuration du nœud maître (port=6379) et des deux nœuds esclaves (port=6380/6381). Les configurations sont relativement simples et ne seront pas décrites en détail.

#redis-6379.conf
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
#redis-6380.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
slaveof 192.168.92.128 6379
#redis-6381.conf
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
slaveof 192.168.92.128 6379

redis-server redis-6379.conf
redis-server redis-6380.conf
redis-server redis-6381.conf

Après le démarrage du nœud, connectez-vous au nœud maître pour vérifier si l'état maître-esclave est normal. Une fois la configuration terminée, démarrez le nœud maître et le nœud esclave dans l'ordre :

2 Déployez le nœud sentinelle

Le nœud sentinelle est essentiellement un nœud Redis spécial.

Les configurations des trois nœuds sentinelles sont presque exactement les mêmes. La principale différence est le numéro de port (26379/26380/26381) Ce qui suit utilise le nœud 26379 comme exemple pour présenter la configuration du nœud et la méthode de démarrage ; La partie est aussi simple que possible, plus de configuration sera introduite plus tard.

#sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
sentinel monitor mymaster 192.168.92.128 6379 2

哨兵节点的启动有两种方式，二者作用是完全相同的：其中，sentinel monitor mymaster 192.168.92.128 6379 2 配置的含义是：该哨兵节点监控192.168.92.128:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。

redis-sentinel sentinel-26379.conf
redis-server sentinel-26379.conf --sentinel

3.  总结

按照上述方式配置和启动之后，整个哨兵系统就启动完毕了。可以通过redis-cli连接哨兵节点进行验证

哨兵系统的搭建过程，有几点需要注意：

（1）哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。

（2）哨兵节点本质上是redis节点。

（3）每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。

（4）在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)。

三、客户端访问哨兵系统

上一小节演示了哨兵的两大作用：监控和自动故障转移，本小节则结合客户端演示哨兵的另外两个作用：配置提供者和通知。

1.  代码示例

在介绍客户端的原理之前，先以Java客户端Jedis为例，演示一下使用方法：下面代码可以连接我们刚刚搭建的哨兵系统，并进行各种读写操作（代码中只演示如何连接哨兵，异常处理、资源关闭等未考虑）。

public static void testSentinel() throws Exception {
         String masterName = "mymaster";
         Set<String> sentinels = new HashSet<>();
         sentinels.add("192.168.92.128:26379");
         sentinels.add("192.168.92.128:26380");
         sentinels.add("192.168.92.128:26381");
         JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); //初始化过程做了很多工作
         Jedis jedis = pool.getResource();
         jedis.set("key1", "value1");
         pool.close();
}

Jedis客户端对哨兵提供了很好的支持。如上述代码所示，我们只需要向Jedis提供哨兵节点集合和masterName，构造JedisSentinelPool对象；然后便可以像使用普通redis连接池一样来使用了：通过pool.getResource()获取连接，执行具体的命令。2.  客户端原理

在整个过程中，我们的代码不需要显式的指定主节点的地址，就可以连接到主节点；代码中对故障转移没有任何体现，就可以在哨兵完成故障转移后自动的切换主节点。之所以可以做到这一点，是因为在JedisSentinelPool的构造器中，进行了相关的工作；主要包括以下两点：

（1）遍历哨兵节点，获取主节点信息：遍历哨兵节点，通过其中一个哨兵节点+masterName获得主节点的信息；该功能是通过调用哨兵节点的sentinel get-master-addr-by-name命令实现，该命令示例如下：

一旦获得主节点信息，停止遍历（因此一般来说遍历到第一个哨兵节点，循环就停止了）。

（2）增加对哨兵的监听：这样当发生故障转移时，客户端便可以收到哨兵的通知，从而完成主节点的切换。具体做法是：利用redis提供的发布订阅功能，为每一个哨兵节点开启一个单独的线程，订阅哨兵节点的+switch-master频道，当收到消息时，重新初始化连接池。

3.  总结

通过客户端原理的介绍，可以加深对哨兵功能的理解：

（1）配置提供者：客户端可以通过哨兵节点+masterName获取主节点信息，在这里哨兵起到的作用就是配置提供者。

需要注意的是，哨兵只是配置提供者，而不是代理。二者的区别在于：如果是配置提供者，客户端在通过哨兵获得主节点信息后，会直接建立到主节点的连接，后续的请求(如set/get)会直接发向主节点；如果是代理，客户端的每一次请求都会发向哨兵，哨兵再通过主节点处理请求。

举一个例子可以很好的理解哨兵的作用是配置提供者，而不是代理。在前面部署的哨兵系统中，将哨兵节点的配置文件进行如下修改：

sentinel monitor mymaster 192.168.92.128 6379 2
改为
sentinel monitor mymaster 127.0.0.1 6379 2

（2）通知：哨兵节点在故障转移完成后，会将新的主节点信息发送给客户端，以便客户端及时切换主节点。然后，将前述客户端代码在局域网的另外一台机器上运行，会发现客户端无法连接主节点；这是因为哨兵作为配置提供者，客户端通过它查询到主节点的地址为127.0.0.1:6379，客户端会向127.0.0.1:6379建立redis连接，自然无法连接。如果哨兵是代理，这个问题就不会出现了。

四、基本原理

前面介绍了哨兵部署、使用的基本方法，本部分介绍哨兵实现的基本原理。

1. Commandes prises en charge par le nœud sentinelle

Le nœud sentinelle est un nœud Redis fonctionnant dans un mode spécial, et les commandes qu'il prend en charge sont différentes des nœuds Redis ordinaires. En fonctionnement et en maintenance, nous pouvons interroger ou modifier le système Sentinel via ces commandes ; mais plus important encore, pour que le système Sentinel puisse implémenter diverses fonctions telles que la découverte de pannes et le basculement, il est indissociable de la communication entre les nœuds Sentinel, et la communication est très efficace. La majeure partie de cela est réalisée grâce à des commandes prises en charge par les nœuds sentinelles. Ce qui suit décrit les principales commandes prises en charge par les nœuds sentinelles.

(1) Requête de base : grâce à ces commandes, vous pouvez interroger la topologie, les informations sur les nœuds, les informations de configuration, etc. du système Sentinel.

• info sentinel : obtenez des informations de base sur tous les nœuds maîtres surveillés
• sentinel masters : obtenez des informations détaillées sur tous les nœuds maîtres surveillés
• sentinel master mymaster : obtenez des informations détaillées sur le nœud maître surveillé mymaster
• sentinel slaves mymaster : obtenez les informations détaillées informations du nœud maître surveillé mymaster et du nœud esclave
• sentinel sentinels mymaster : Obtenez les informations détaillées du nœud sentinelle surveillé mymaster
• sentinel get-master-addr-by-name mymaster : Obtenez le nœud maître surveillé mymaster Les informations d'adresse a été introduit avant
• sentinel is-master-down-by-addr : les nœuds Sentinel peuvent utiliser cette commande pour demander si le nœud maître est hors ligne, afin de juger s'il est objectivement hors ligne

(2) Ajouter/supprimer la surveillance du nœud maître

moniteur sentinelle mymaster2 192.168.92.128 16379 2 : La fonction du moniteur sentinelle dans le fichier de configuration est exactement la même que lors du déploiement du nœud sentinelle, et ne sera pas décrite en détail

sentinel supprimer mymaster2 : Annuler le nœud sentinelle actuel Surveillance du nœud maître mymaster2

(3) Basculement forcé

basculement sentinelle mymaster : Cette commande peut forcer un basculement de mymaster même si le nœud maître actuel fonctionne intact par exemple, si le nœud maître actuel Si la machine est sur le point d'être mise au rebut, vous pouvez effectuer un basculement à l'avance via la commande failover.

2. Principes de base

Concernant le principe de sentinelle, la clé est de comprendre les concepts suivants.

(1) Tâches planifiées : Chaque nœud sentinelle maintient 3 tâches planifiées. Les fonctions des tâches planifiées sont les suivantes : obtenir la dernière structure maître-esclave en envoyant la commande d'information au nœud maître-esclave ; obtenir les informations d'autres nœuds sentinelles via la fonction de publication et d'abonnement ; effectuer une détection de battement de cœur en envoyant le ping ; commande à d’autres nœuds pour déterminer s’ils sont hors ligne.

(2) Hors ligne subjectif : dans la tâche planifiée de détection du rythme cardiaque, si d'autres nœuds ne répondent pas pendant un certain temps, le nœud sentinelle les mettra subjectivement hors ligne. Comme son nom l'indique, subjectif hors ligne signifie qu'un nœud sentinelle juge « subjectivement » hors ligne ; la contrepartie du hors ligne subjectif est hors ligne objective.

(3) Objectif hors ligne : une fois que le nœud sentinelle a subjectivement mis hors ligne le nœud maître, il demandera aux autres nœuds sentinelles l'état du nœud maître via la commande sentinel is-master-down-by-addr s'il est déterminé que ; le nœud maître est hors ligne Si le nombre de sentinelles atteint une certaine valeur, le nœud maître sera objectivement hors ligne.

Il est important de noter que l'objectif hors ligne est un concept uniquement pour le nœud maître ; si le nœud esclave et le nœud sentinelle échouent, après avoir été subjectivement hors ligne par la sentinelle, il n'y aura pas d'opérations objectives ultérieures hors ligne et de basculement.

(4) Élire le nœud sentinelle leader : lorsque le nœud maître est jugé objectivement hors ligne, chaque nœud sentinelle négociera pour élire un nœud sentinelle leader, et le nœud leader effectuera des opérations de basculement sur celui-ci.

Toutes les sentinelles surveillant le nœud maître peuvent être élues comme leader. L'algorithme utilisé lors de l'élection est l'algorithme Raft ; l'idée de base de l'algorithme Raft est le premier arrivé, premier servi : c'est-à-dire lors d'un tour d'élection. , la sentinelle A envoie un message à B pour devenir le leader. Pour la candidature du leader, si B n'a pas accepté d'autres sentinelles, elle acceptera que A devienne le leader. Le processus spécifique de l'élection ne sera pas décrit en détail ici. De manière générale, le processus de sélection des sentinelles est très rapide. Celui qui atteint l'objectif hors ligne en premier deviendra généralement le leader.

(5) Basculement : la sentinelle leader élue démarre l'opération de basculement, qui peut être grossièrement divisée en 3 étapes :

Sélectionner un nouveau nœud maître à partir du nœud esclave : le principe de sélection est le suivant : d'abord filtrer les nœuds esclaves en mauvais état ; puis sélectionnez le nœud esclave avec la priorité la plus élevée (spécifié par slave-priority) ; si les priorités ne peuvent pas être distinguées, sélectionnez le nœud esclave avec le plus grand décalage de réplication ; s'il est toujours indiscernable, sélectionnez le nœud esclave avec le plus petit nœud esclave runid ; .
• Mettez à jour le statut maître-esclave : utilisez la commande slaveof no one pour faire du nœud esclave sélectionné le nœud maître ; et utilisez la commande slaveof pour faire des autres nœuds ses nœuds esclaves.
• Définissez le nœud maître hors ligne (c'est-à-dire 6379) comme nœud esclave du nouveau nœud maître. Lorsque 6379 reviendra en ligne, il deviendra le nœud esclave du nouveau nœud maître.

5. Suggestions de configuration et de pratique

1. Configuration

Ce qui suit présente plusieurs configurations liées à Sentinel.

(1) moniteur sentinelle {masterName} {masterIp} {masterPort} {quorum}

Le moniteur sentinelle est la configuration de base de la sentinelle. Cela a déjà été expliqué lors du déploiement du nœud sentinelle. Parmi eux : masterName spécifie le nom du nœud maître, masterIp et masterPort spécifient l'adresse du nœud maître et le quorum est le nombre seuil de sentinelles. pour juger de l'objectif hors ligne du nœud maître. : Lorsque le nombre de sentinelles qui déterminent que le nœud maître est hors ligne atteint le quorum, le nœud maître sera objectivement hors ligne. La valeur recommandée est la moitié du nombre de sentinelles plus 1.

(2) sentinel down-after-milliseconds {masterName} {time}

sentinel down-after-milliseconds est lié au jugement subjectif hors ligne : la sentinel utilise la commande ping pour effectuer une détection de rythme cardiaque sur d'autres nœuds. les nœuds dépassent en panne - S'il n'y a pas de réponse dans le délai configuré après quelques millisecondes, Sentinel l'enregistrera subjectivement hors ligne. Cette configuration est valable pour la détermination subjective hors ligne des nœuds maîtres, des nœuds esclaves et des nœuds sentinelles.

La valeur par défaut de down-after-milliseconds est de 30 000, soit 30 s ; elle peut être ajustée en fonction de différents environnements réseau et exigences d'application : plus la valeur est grande, plus le jugement subjectif hors ligne est lâche, l'avantage est que la possibilité L'erreur de jugement est faible, l'inconvénient est que le temps de découverte des pannes et de basculement devient plus long, et le temps d'attente du client devient également plus long. Par exemple, si l'application a des exigences de haute disponibilité, la valeur peut être réduite de manière appropriée pour terminer le transfert dès que possible en cas de panne ; si l'environnement réseau est relativement médiocre, le seuil peut être augmenté de manière appropriée pour éviter de fréquentes erreurs d'appréciation.

(3) sentinel parallel-syncs {masterName} {number}

sentinel parallel-syncs est lié à la réplication des nœuds esclaves après le basculement : il spécifie le nombre de nœuds esclaves qui lancent à chaque fois des opérations de réplication vers le nouveau nœud maître. . Par exemple, supposons qu'une fois le changement de nœud maître terminé, 3 nœuds esclaves souhaitent lancer la réplication vers le nouveau nœud maître si parallèle-syncs=1, les nœuds esclaves commenceront à se répliquer un par un si parallèle-syncs=3 ; puis 3 nœuds esclaves. Les nœuds commenceront à se répliquer ensemble.

Plus la valeur des synchronisations parallèles est grande, plus la réplication du nœud esclave est rapide, mais plus la pression sur la charge réseau et la charge du disque dur du nœud maître est grande, elle doit être définie en fonction de la situation réelle ; . Par exemple, si la charge sur le nœud maître est faible et que le nœud esclave a des exigences élevées en matière de disponibilité du service, vous pouvez augmenter la valeur des synchronisations parallèles de manière appropriée. La valeur par défaut pour les synchronisations parallèles est 1.

(4) sentinel failover-timeout {masterName} {time}

sentinel failover-timeout est lié au jugement du délai de basculement, mais ce paramètre n'est pas utilisé pour juger du délai d'attente de toute la phase de basculement, mais ses plusieurs sous -phases. Délai d'expiration, par exemple, si le temps nécessaire pour que le nœud maître soit promu au nœud esclave dépasse le délai d'attente, ou le temps nécessaire au nœud esclave pour lancer une opération de réplication vers le nouveau nœud maître (à l'exclusion du temps de copie des données). dépasse le délai d'attente, le basculement expirera.

La valeur par défaut du délai d'attente de basculement est de 180 000, soit 180 s ; en cas d'expiration, la valeur deviendra le double de la valeur d'origine la prochaine fois.

(5) En plus des paramètres ci-dessus, il existe d'autres paramètres, tels que les paramètres liés à la vérification de sécurité, qui ne seront pas présentés ici.

2. Suggestions pratiques

(1) Le nombre de nœuds sentinelles doit être supérieur à un, d'une part, cela augmente la redondance des nœuds sentinelles et empêche les sentinelles elles-mêmes de devenir un goulot d'étranglement de haute disponibilité ; d’un autre côté, cela réduit les erreurs d’évaluation hors ligne. De plus, ces différents nœuds sentinelles doivent être déployés sur différentes machines physiques.

(2) Le nombre de nœuds sentinelles doit être un nombre impair pour permettre aux sentinelles de prendre des « décisions » par le biais du vote : décisions sur l'élection du leader, décisions sur l'objectif hors ligne, etc.

(3) La configuration de chaque nœud sentinelle doit être cohérente, y compris le matériel, les paramètres, etc. De plus, tous les nœuds doivent utiliser ntp ou des services similaires pour garantir une heure précise et cohérente.

(4) Les fonctions de fournisseur de configuration et de client de notification de Sentinel nécessitent la mise en œuvre d'un support client, comme Jedis mentionné ci-dessus ; si la bibliothèque utilisée par le développeur ne fournit pas le support correspondant, le développeur devra peut-être l'implémenter lui-même ;

(5) Lorsque les nœuds du système Sentinel sont déployés dans Docker (ou dans un autre logiciel pouvant effectuer le mappage de ports), une attention particulière doit être accordée au fait que le mappage de ports peut empêcher le système Sentinel de fonctionner correctement, car le Le travail de Sentinel est basé sur la connexion avec d'autres nœuds de communication, et le mappage des ports de Docker peut empêcher Sentinel de se connecter à d'autres nœuds. Par exemple, la découverte les unes des autres par les sentinelles dépend de l'adresse IP et du port qu'elles déclarent au monde extérieur. Si une sentinelle A est déployée dans un docker avec mappage de port, les autres sentinelles ne peuvent pas se connecter à A en utilisant le port déclaré par A.

6. Résumé

Cet article présente d'abord le rôle de Sentinel : surveillance, basculement, fournisseur de configuration et notification ; décrit ensuite la méthode de déploiement du système Sentinel et la méthode d'accès au système Sentinel via le client, puis explique brièvement les principes de base de ; mise en œuvre des sentinelles ; enfin, quelques suggestions sur la pratique des sentinelles sont données.

Basé sur la réplication maître-esclave, Sentinel introduit le basculement automatique du nœud maître, améliorant encore la haute disponibilité de Redis. Cependant, le défaut de Sentinel est également évident : Sentinel ne peut pas effectuer de basculement automatique du nœud esclave, et la lecture est effectuée. séparation d'écriture Dans ce scénario, la défaillance du nœud esclave entraînera l'indisponibilité du service de lecture, ce qui nous obligera à effectuer des opérations de surveillance et de commutation supplémentaires sur le nœud esclave.

De plus, Sentinel n'a toujours pas résolu le problème de l'impossibilité d'équilibrer la charge des opérations d'écriture et de la capacité de stockage limitée par une seule machine. La solution à ces problèmes nécessite l'utilisation de clusters, que je présenterai dans un article ultérieur. bienvenue à faire attention.

Apprentissage recommandé : "Tutoriel vidéo Redis", "Dernières questions et réponses de l'entretien Redis 2022"

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!