Maison > Article > base de données > 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 :
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.
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安装不成功,最后通过下载源码的方式安装成功。
再次执行创建集群的脚本,出现如下提示:
输入yes,继续
最少需要多少个主服务器?
可能是基于某些约定,集群约定只有当可用节点数大于半数以上时才具备对外提供服务的能力。首先数量一定是奇数,其实必须大于1,所以最少的主服务器数量为3。
测试集群
连接客户端,由于我的所有节点都是在本地,所以不需要输入ip,但需要加-c的参数。redis-cli -c -p 7000
连接成功后,增加一个key
set mykey 123
有一行提示语,指向到端口7002,这说明虽然我们连接的是7000的实例,但通过hash算法最终会将key分配到7002的实例上。
再连接7005端口查询下key,测试下是否任意一个实例都可以查询到key
get mykey
显示指向到端口7002
更多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!