Maison  >  Article  >  base de données  >  Explication graphique détaillée de la solution haute disponibilité Redis

Explication graphique détaillée de la solution haute disponibilité Redis

尚
avant
2019-12-17 16:42:013418parcourir

Explication graphique détaillée de la solution haute disponibilité Redis

Comprendre et créer un cluster Redis à partir de zéro

Certains développeurs n'utilisent Redis que dans leurs applications, comme la mise en cache des résultats de données. Et maintenant, il existe de nombreux bons outils clients Redis (redisson), qui peuvent essentiellement remplir un nombre considérable de fonctions sans prêter attention à la commande redis. Par conséquent, il se peut que l’on ne prête pas suffisamment d’attention aux questions suivantes :

Comment se remettre d’une catastrophe ? Autrement dit, s'il y a un problème avec un certain nœud Redis, comment assurer la haute disponibilité du service

Comment s'étendre horizontalement ? Lorsque la quantité de données est particulièrement importante, comment résoudre le problème de performances d'un seul redis

Au moins combien de machines sont nécessaires dans le cluster ? Ou quelles technologies et outils sont utilisés pour créer des clusters de plusieurs nœuds Redis

 ?

Comment se remettre d'un sinistre ?

Redis fournit un mécanisme de veille chaude maître-esclave. Les données du serveur maître sont synchronisées avec le serveur esclave. L'état du serveur maître est surveillé en temps réel via Sentry et est responsable de l'élection du serveur maître. . Lorsqu'une anomalie est détectée sur le serveur principal, le serveur principal est réélu selon un certain algorithme et le serveur problématique est supprimé de la liste disponible, et le client est finalement informé. Le maître-esclave est une structure arborescente un-à-plusieurs, comme indiqué ci-dessous :

Explication graphique détaillée de la solution haute disponibilité Redis

Sentinel

Sentinel est le chinois nom de sentinel. Un outil d'architecture haute disponibilité produit par Redis est lui-même un processus indépendant et peut surveiller plusieurs clusters Redis en même temps.

Cluster Sentinel

Sur la base de considérations de haute disponibilité, Sentinel lui-même doit également prendre en charge le clustering. S'il n'y a qu'un seul Sentinel, il y aura un seul point de problème.

Décision Sentinelle

Les sentinelles ont une configuration quantitative. La commutation maître-esclave n'est effectuée que lorsque combien de sentinelles pensent qu'un certain service maître n'est pas disponible en même temps. Par exemple, il y a 5 sentinelles au total, lorsque les trois sentinelles estiment que le service n'est pas disponible, elles décident d'effectuer un changement maître-esclave. Cela peut éviter certaines erreurs de commutation et réduire les coûts de commutation, tels que les anomalies instantanées du réseau.

Comment s'étendre horizontalement ?

Qu'il s'agisse de Redis ou de certains autres produits de base de données, lorsque la capacité de données d'un seul nœud atteint une certaine limite supérieure, la capacité à fournir des services au monde extérieur deviendra de plus en plus faible. Redis fournit redis-trib.rb dans les versions supérieures pour implémenter les fonctions de cluster, et vous pouvez également utiliser l'outil tiers twemproxy.

Décentralisation, chaque nœud est égal

Le cluster Redis n'est pas conçu dans un souci de centralisation, ce qui peut éviter des problèmes tels qu'un point unique dans le nœud central. Chaque nœud peut connaître l'état de l'ensemble du cluster, et tout nœud qui y est connecté peut accéder à toutes les clés, tout comme les Redis à nœud unique.

Diagramme schématique du cluster

Je l'ai dessiné selon ma propre compréhension. Veuillez indiquer s'il y a un malentendu.

Explication graphique détaillée de la solution haute disponibilité Redis

La relation entre la clé et le nœud Redis

Hasy Solt est introduite, qui est comprise comme un emplacement de hachage en chinois. Il y en a 16384 au total. La clé que nous utilisons utilise l'algorithme modulo pour confirmer sur quel emplacement la clé tombe.

HASH_SLOT = CRC16(key) mod 16384

Il existe une certaine relation entre l'emplacement de hachage et le nœud, nous pouvons donc attribuer la clé à un nœud Redis spécifique.

La relation détaillée peut être étudiée à nouveau. Par exemple, le nœud A est responsable des emplacements de hachage numérotés de 0 à 5 000, le nœud B est responsable de 5 001 à 1 000

Construire étape par étape.

Commencez à construire un cluster avec trois maîtres et trois esclaves. Le système est Ubuntu et l'outil de cluster redis-trib.rb fourni par redis est utilisé.

Installez le dernier redis

Créez le répertoire redis_cluster et créez 6 répertoires de 7000 à 7005

Copiez redis.conf dans le répertoire redis dans les 6 répertoires créés ci-dessus Medium

分别修改redis.conf文件,对6个文件做类似的修改。

port  7000                                       //端口7000       
bind  127.0.0.1                                  //默认ip为127.0.0.1 需要改为其他节点机器可访问的ip
daemonize    yes                                 //后台运行
pidfile  /var/run/redis_7000.pid                 //pidfile文件对应7000
cluster-enabled  yes                             //开启集群
cluster-config-file  nodes_7000.conf             //集群的配置
cluster-node-timeout  15000                      //请求超时  默认15秒,可自行设置

bind需要注意的就是需要配置为其它机器可以访问的ip,否则无论是创建集群还是客户端连接都会有问题。

启动6个redis

redis-server redis_cluster/7000/redis.conf
redis-server redis_cluster/7001/redis.conf
redis-server redis_cluster/7002/redis.conf
redis-server redis_cluster/7003/redis.conf
redis-server redis_cluster/7004/redis.conf
redis-server redis_cluster/7005/redis.conf

创建集群
redis的src目录下有个redis-trib.rb,将它复制到/usr/local/bin中,然后执行如下脚本:

redis-trib.rb  create  --replicas  1  127.0.0.1:7000 127.0.0.1:7001  127.0.0.1:7002 127.0.0.1:7003  127.0.0.1:7004  127.0.0.1:7005

--replicas后面的1代表从服务器的个数,上面可以理解为前面3个为主服务器,后面三个分别做为从服务器,即三对主从。

执行过程中会遇到提示需要安装ruby,安装完成之后又会提示安装 gem redis。

安装gem redis,折腾了好久,最终发现是因为在国内访问不了某些网站导致通过apt-get install安装不成功,最后通过下载源码的方式安装成功。

Explication graphique détaillée de la solution haute disponibilité Redis再次执行创建集群的脚本,出现如下提示:

Explication graphique détaillée de la solution haute disponibilité Redis

输入yes,继续

Explication graphique détaillée de la solution haute disponibilité Redis

最少需要多少个主服务器?

可能是基于某些约定,集群约定只有当可用节点数大于半数以上时才具备对外提供服务的能力。首先数量一定是奇数,其实必须大于1,所以最少的主服务器数量为3。

测试集群
连接客户端,由于我的所有节点都是在本地,所以不需要输入ip,但需要加-c的参数。redis-cli -c -p 7000

连接成功后,增加一个key

set mykey 123

有一行提示语,指向到端口7002,这说明虽然我们连接的是7000的实例,但通过hash算法最终会将key分配到7002的实例上。

Explication graphique détaillée de la solution haute disponibilité Redis

再连接7005端口查询下key,测试下是否任意一个实例都可以查询到key

get mykey

显示指向到端口7002

Explication graphique détaillée de la solution haute disponibilité Redis

更多redis知识请关注redis数据库教程栏目。

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!

Déclaration:
Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer