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
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 :
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 :
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.
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 :
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.
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 :
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)。
上一小节演示了哨兵的两大作用：监控和自动故障转移，本小节则结合客户端演示哨兵的另外两个作用：配置提供者和通知。
在介绍客户端的原理之前，先以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();
}在整个过程中，我们的代码不需要显式的指定主节点的地址，就可以连接到主节点；代码中对故障转移没有任何体现，就可以在哨兵完成故障转移后自动的切换主节点。之所以可以做到这一点，是因为在JedisSentinelPool的构造器中，进行了相关的工作；主要包括以下两点：
（1）遍历哨兵节点，获取主节点信息：遍历哨兵节点，通过其中一个哨兵节点+masterName获得主节点的信息；该功能是通过调用哨兵节点的sentinel get-master-addr-by-name命令实现，该命令示例如下：
一旦获得主节点信息，停止遍历（因此一般来说遍历到第一个哨兵节点，循环就停止了）。
（2）增加对哨兵的监听：这样当发生故障转移时，客户端便可以收到哨兵的通知，从而完成主节点的切换。具体做法是：利用redis提供的发布订阅功能，为每一个哨兵节点开启一个单独的线程，订阅哨兵节点的+switch-master频道，当收到消息时，重新初始化连接池。
通过客户端原理的介绍，可以加深对哨兵功能的理解：
（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连接，自然无法连接。如果哨兵是代理，这个问题就不会出现了。
前面介绍了哨兵部署、使用的基本方法，本部分介绍哨兵实现的基本原理。
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.
(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 :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.
(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.
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!
Logiciel de base de données couramment utilisé
Que sont les bases de données en mémoire ?
Lequel a une vitesse de lecture plus rapide, mongodb ou redis ?
Comment utiliser Redis comme serveur de cache
Comment Redis résout la cohérence des données
Comment MySQL et Redis assurent-ils la cohérence des doubles écritures ?
Quelles données le cache Redis stocke-t-il généralement ?
Quels sont les 8 types de données de Redis
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
