Résumé et partage de 20 questions d'entretien classiques sur Redis (avec analyse des réponses)

Golden Nine et Silver Ten arrivent bientôt. Cet article partagera avec vous 20 questions d'entretien classiques Redis. J'espère que cela vous sera utile !

1. Qu'est-ce que Redis ? A quoi sert-il principalement ?

Redis, le nom anglais complet est Remote Dictionary Server (Remote Dictionary Service), est une base de données de valeurs-clés de type journal open source écrite en langage ANSI C, prend en charge le réseau, peut être basée sur la mémoire et peut être persistant et fournit une API dans plusieurs langues. [Recommandations associées : Tutoriel vidéo Redis]

Différentes de la base de données MySQL, les données Redis sont stockées en mémoire. Ses vitesses de lecture et d'écriture sont très rapides et peuvent gérer plus de 100 000 opérations de lecture et d'écriture par seconde. Par conséquent, Redis est largement utilisé dans la mise en cache. De plus, Redis est également souvent utilisé pour les verrous distribués. De plus, Redis prend en charge les transactions, la persistance, les scripts LUA, les événements pilotés par LRU et diverses solutions de cluster.

La plupart des amis savent que Redis a les cinq types de base suivants :

• Hash (Hash)
• List (List)
• Set (set)
• zset (ensemble ordonné)
• Il dispose également de trois types de structures de données spéciaux

• Hyperloglog
• Bitmap
• 2.1 Cinq types de données de base de Redis

Chaîne ( string)

• Exemple d'utilisation simple : définir la valeur de la clécode>, <code>get key, etc.
• Scénarios d'application : session partagée, verrouillage distribué, compteur, limite de courant. set key value、get key等
• 应用场景：共享session、分布式锁，计数器、限流。
• 内部编码有3种，int（8字节长整型）/embstr（小于等于39字节字符串）/raw（大于39个字节字符串）

C语言的字符串是char[]实现的，而Redis使用SDS（simple dynamic string） 封装，sds源码如下：

struct sdshdr{
  unsigned int len; // 标记buf的长度
  unsigned int free; //标记buf中未使用的元素个数
  char buf[]; // 存放元素的坑
}

SDS 结构图如下：

Redis为什么选择SDS结构，而C语言原生的 char[]不香吗？

举例其中一点，SDS中，O(1)时间复杂度，就可以获取字符串长度；而C 字符串，需要遍历整个字符串，时间复杂度为O(n)

Hash（哈希）

• 简介：在Redis中，哈希类型是指v（值）本身又是一个键值对（k-v）结构
• 简单使用举例：hset key field value 、hget key field
• 内部编码：ziplist（压缩列表） 、hashtable（哈希表）
• 应用场景：缓存用户信息等。
• 注意点：如果开发使用hgetall，哈希元素比较多的话，可能导致Redis阻塞，可以使用hscan。而如果只是获取部分field，建议使用hmget。

字符串和哈希类型对比如下图：

List（列表）

• 简介：列表（list）类型是用来存储多个有序的字符串，一个列表最多可以存储2^32-1个元素。
• 简单实用举例： lpush key value [value ...] 、lrange key start end
Il existe 3 types d'encodage interne, int (entier long de 8 octets)/embstr (inférieur ou égal à une chaîne de 39 octets)/raw (chaîne supérieure à 39 octets)
• C La chaîne de langage est implémentée par char[], et Redis utilise le package
SDS (simple dynamique chaîne)

zadd user:ranking:2021-03-03 Jay 3

Pourquoi Redis a-t-il choisi la structure

Et le char[] natif du langage C n'est-il pas bon ?

Par exemple, en SDS, la longueur de la chaîne peut être obtenue avec une complexité temporelle O(1) ; tandis que pour les chaînes C, la chaîne entière doit être parcourue et la complexité temporelle est O(n)
< h4 data- id="heading-5">Hash (Hash)
• Introduction : Dans Redis, le type de hachage fait référence à v (valeur) lui-même qui est également une structure de paire clé-valeur (k-v)

Exemple d'utilisation simple : hset key field value, hget key field

Encodage interne : ziplist (liste compressée), hashtable (table de hachage)< /code ></h4><p>Scénarios d'application : mise en cache des informations utilisateur, etc. <img src="https://img.php.cn/upload/image/656/664/457/1631501863989751.png" title="1631501863989751.png" alt="Résumé et partage de 20 questions dentretien classiques sur Redis (avec analyse des réponses)"/></p>🎜Remarque🎜 : Si hgetall est utilisé dans le développement et qu'il existe de nombreux éléments de hachage, cela peut entraîner le blocage de Redis. Vous pouvez utiliser hscan. Si vous souhaitez uniquement obtenir certains champs, il est recommandé d'utiliser hmget. 🎜🎜🎜La comparaison entre les types de chaîne et de hachage est la suivante : 🎜🎜<img src="https://img.php.cn/upload/image/984/524/946/16315018485778Résumé et partage de 20 questions dentretien classiques sur Redis (avec analyse des réponses)" title="1631501848577830 .png " alt="Résumé et partage de 20 questions dentretien classiques sur Redis (avec analyse des réponses)"/>🎜<h4 data-id="heading-6">Liste (liste)🎜🎜🎜Introduction : Le type liste (liste) est utilisé pour stocker plusieurs chaînes ordonnées, une liste peut stocker jusqu'à 2 ^ 32-1 éléments. 🎜🎜Exemples simples et pratiques : <code> lpush key value [value ...], lrange key start end🎜🎜Encodage interne : ziplist (liste compressée), linkedlist (liste chaînée )🎜 🎜Scénarios d'application : file d'attente de messages, liste d'articles, 🎜🎜🎜Une image pour comprendre l'insertion et le pop-up du type de liste : 🎜🎜🎜🎜🎜Les scénarios d'application de liste font référence à ce qui suit : 🎜🎜🎜🎜lpush+lpop= Stack (stack)🎜🎜lpush +rpop=Queue (file d'attente)🎜🎜lpsh+ltrim=Capped Collection (collection limitée)🎜🎜lpush+brpop=Message Queue (file d'attente des messages)🎜🎜🎜🎜Set (set)🎜🎜🎜🎜

• Introduction : Le type set est également utilisé pour enregistrer plusieurs éléments de chaîne, mais les éléments en double ne sont pas autorisés
• Exemple d'utilisation simple : sadd key element [element ...], smembers key sadd key element [element ...]、smembers key
• 内部编码：intset（整数集合）、hashtable（哈希表）
• 注意点：smembers和lrange、hgetall都属于比较重的命令，如果元素过多存在阻塞Redis的可能性，可以使用sscan来完成。
• 应用场景： 用户标签,生成随机数抽奖、社交需求。

有序集合（zset）

• 简介：已排序的字符串集合，同时元素不能重复
• 简单格式举例：zadd key score member [score member ...]，zrank key member
• 底层内部编码：ziplist（压缩列表）、skiplist（跳跃表）
Encodage interne : intset (ensemble d'entiers), hashtable (table de hachage)
Notes : smembers, lrange et hgetall sont des commandes relativement lourdes. S'il y a trop d'éléments et qu'il existe une possibilité de bloquer Redis, vous pouvez utiliser sscan pour le terminer.

Scénarios d'application : tags utilisateur, génération de loterie à nombres aléatoires, besoins sociaux.

Ensemble ordonné (zset)

Introduction : une collection de chaînes triées, et les éléments ne peuvent pas être répétés

Exemple de format simple : zadd key score member [ score membre ...], membre clé zrank

Expiration programmée

Chaque clé avec un délai d'expiration doit créer une minuterie, et la clé sera effacée immédiatement lorsque le délai d'expiration est atteint. Cette stratégie peut immédiatement effacer les données expirées et est très économe en mémoire ; cependant, elle occupera une grande quantité de ressources CPU pour traiter les données expirées, affectant ainsi le temps de réponse et le débit du cache.

Expiration paresseuse

Seulement lors de l'accès à une clé, il sera jugé si la clé a expiré, et elle sera effacée si elle expire. Cette stratégie peut économiser au maximum les ressources du processeur, mais elle est très peu respectueuse de la mémoire. Dans des cas extrêmes, un grand nombre de clés expirées ne seront plus accessibles, ne seront donc pas effacées et occuperont une grande quantité de mémoire.

Expiration périodique

À chaque fois, un certain nombre de clés dans le dictionnaire d'expiration d'un certain nombre de bases de données seront analysées et les clés expirées seront effacées. Cette stratégie est un compromis entre les deux premières. En ajustant l'intervalle de temps des analyses planifiées et la consommation de temps limitée de chaque analyse, l'équilibre optimal entre les ressources CPU et mémoire peut être atteint dans différentes circonstances.

Le dictionnaire expire enregistrera les données d'heure d'expiration de toutes les clés avec une heure d'expiration définie, où clé est un pointeur vers une clé dans l'espace clé et valeur est l'heure d'expiration représentée par l'horodatage UNIX de la clé avec une précision de la milliseconde. L'espace clé fait référence à toutes les clés enregistrées dans le cluster Redis.

Redis utilise à la fois l'expiration paresseuse et l'expiration périodiquedeux stratégies d'expiration.

• Supposons que Redis stocke actuellement 300 000 clés et que toutes aient des délais d'expiration définis. Si vous vérifiez toutes les clés toutes les 100 ms, la charge du processeur sera extrêmement élevée et elle pourrait éventuellement se bloquer.
• Par conséquent, redis utilise une expiration régulière et sélectionne au hasard un certain nombre de clés à vérifier et à supprimer toutes les 100 ms.
• Cependant, il se peut que de nombreuses clés expirées n'aient finalement pas été supprimées. À l'heure actuelle, Redis utilise la suppression différée. Lorsque vous obtenez une clé, redis la vérifiera. Si la clé a un délai d'expiration défini et a expiré, elle sera supprimée à ce moment-là.

Mais si la suppression régulière manque un grand nombre de clés expirées, la suppression paresseuse ne sera pas utilisée. Il y aura beaucoup de clés expirées accumulées dans la mémoire, ce qui provoquera directement l'explosion de la mémoire. Ou parfois, lorsque le volume d'activité augmente, les clés Redis sont beaucoup utilisées, la mémoire n'est tout simplement pas suffisante et le responsable de l'exploitation et de la maintenance oublie d'augmenter la mémoire. Redis pourrait-il raccrocher comme ça ? Non! Redis se protège avec 8 stratégies d'élimination de mémoire ~

6.2 Stratégie d'élimination de mémoire Redis

• volatile-lru : lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, utilisez LRU (la moins récemment utilisée) à partir de la clé avec un délai d'expiration set ) algorithme d'élimination ;
• allkeys-lru : lorsque la mémoire est insuffisante pour accueillir les données nouvellement écrites, l'algorithme LRU (le moins récemment utilisé) est utilisé pour l'élimination de toutes les clés.
• volatile-lfu : nouvellement ajouté dans la version 4.0, lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, l'algorithme LFU est utilisé pour supprimer les clés parmi les clés expirées.
• allkeys-lfu : Nouveau dans la version 4.0, lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, l'algorithme LFU est utilisé pour éliminer de toutes les clés
• volatile-random : Lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites ; données nouvellement écrites, de Dans la clé avec un délai d'expiration défini, les données sont éliminées de manière aléatoire ;.
• allkeys-random : lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, les données sont éliminées de manière aléatoire de toutes les clés.
• volatile-ttl : Lorsque la mémoire n'est pas suffisante pour accueillir les données nouvellement écrites, la clé avec un délai d'expiration défini sera éliminée en fonction du délai d'expiration, et plus la date d'expiration sera éliminée en premier
• noeviction : La stratégie par défaut, lorsque la mémoire est insuffisante Pour accueillir les données nouvellement écrites, la nouvelle opération d'écriture signalera une erreur.

7. Parlons des scénarios d'application courants de Redis

• Cache
• Liste de classement
• Application de compteur
• Session partagée
• Verrouillage distribué
• Réseau social
• File d'attente des messages
• Opération Bit

7.1 Mise en cache

Lorsque nous parlons de Redis, nous pensons naturellement au cache. Les sites Web de taille moyenne et grande au pays et à l'étranger sont indissociables du cache. Une utilisation raisonnable du cache, telle que la mise en cache des données des points d'accès, peut non seulement améliorer la vitesse d'accès du site Web, mais également réduire la pression sur la base de données. De plus, par rapport à Memcached, Redis fournit également des structures de données riches et des mécanismes de persistance tels que RDB et AOF, qui sont parmi les plus puissants.

7.2 Classements

Dans les applications Internet d'aujourd'hui, il existe différents classements, tels que les classements mensuels des ventes des sites de commerce électronique, les classements des cadeaux des applications sociales, les classements des votes des mini-programmes, etc. Le type zsetdata fourni par Redis peut implémenter ces classements complexes.

Par exemple, si les utilisateurs mettent en ligne des vidéos tous les jours, la liste de classement des likes peut être conçue comme ceci :

• 1.用户Jay上传一个视频，获得6个赞，可以酱紫：

zadd user:ranking:2021-03-03 Jay 3

• 2. 过了一段时间，再获得一个赞，可以这样：

zincrby user:ranking:2021-03-03 Jay 1

• 3. 如果某个用户John作弊，需要删除该用户：

zrem user:ranking:2021-03-03 John

• 3. 展示获取赞数最多的3个用户

zrevrangebyrank user:ranking:2021-03-03 0 2

7.3 计数器应用

各大网站、APP应用经常需要计数器的功能，如短视频的播放数、电商网站的浏览数。这些播放数、浏览数一般要求实时的，每一次播放和浏览都要做加1的操作，如果并发量很大对于传统关系型数据的性能是一种挑战。Redis天然支持计数功能而且计数的性能也非常好，可以说是计数器系统的重要选择。

7.4 共享Session

如果一个分布式Web服务将用户的Session信息保存在各自服务器，用户刷新一次可能就需要重新登录了，这样显然有问题。实际上，可以使用Redis将用户的Session进行集中管理，每次用户更新或者查询登录信息都直接从Redis中集中获取。

7.5 分布式锁

几乎每个互联网公司中都使用了分布式部署，分布式服务下，就会遇到对同一个资源的并发访问的技术难题，如秒杀、下单减库存等场景。

• 用synchronize或者reentrantlock本地锁肯定是不行的。
• 如果是并发量不大话，使用数据库的悲观锁、乐观锁来实现没啥问题。
• 但是在并发量高的场合中，利用数据库锁来控制资源的并发访问，会影响数据库的性能。
• 实际上，可以用Redis的setnx来实现分布式的锁。

7.6 社交网络

赞/踩、粉丝、共同好友/喜好、推送、下拉刷新等是社交网站的必备功能，由于社交网站访问量通常比较大，而且传统的关系型数据不太适保存 这种类型的数据，Redis提供的数据结构可以相对比较容易地实现这些功能。

7.7 消息队列

消息队列是大型网站必用中间件，如ActiveMQ、RabbitMQ、Kafka等流行的消息队列中间件，主要用于业务解耦、流量削峰及异步处理实时性低的业务。Redis提供了发布/订阅及阻塞队列功能，能实现一个简单的消息队列系统。另外，这个不能和专业的消息中间件相比。

7.8 位操作

用于数据量上亿的场景下，例如几亿用户系统的签到，去重登录次数统计，某用户是否在线状态等等。腾讯10亿用户，要几个毫秒内查询到某个用户是否在线，能怎么做？千万别说给每个用户建立一个key，然后挨个记（你可以算一下需要的内存会很恐怖，而且这种类似的需求很多。这里要用到位操作——使用setbit、getbit、bitcount命令。原理是：redis内构建一个足够长的数组，每个数组元素只能是0和1两个值，然后这个数组的下标index用来表示用户id（必须是数字哈），那么很显然，这个几亿长的大数组就能通过下标和元素值（0和1）来构建一个记忆系统。

8. Redis 的持久化机制有哪些？优缺点说说

Redis是基于内存的非关系型K-V数据库，既然它是基于内存的，如果Redis服务器挂了，数据就会丢失。为了避免数据丢失了，Redis提供了持久化，即把数据保存到磁盘。

Redis提供了RDB和AOF两种持久化机制，它持久化文件加载流程如下：

8.1 RDB

RDB，就是把内存数据以快照的形式保存到磁盘上。

什么是快照?可以这样理解，给当前时刻的数据，拍一张照片，然后保存下来。

RDB持久化，是指在指定的时间间隔内，执行指定次数的写操作，将内存中的数据集快照写入磁盘中，它是Redis默认的持久化方式。执行完操作后，在指定目录下会生成一个dump.rdb文件，Redis 重启的时候，通过加载dump.rdb文件来恢复数据。RDB触发机制主要有以下几种：

RDB 的优点

• 适合大规模的数据恢复场景，如备份，全量复制等

RDB缺点

• Il n'existe aucun moyen d'obtenir une persistance en temps réel/une persistance de deuxième niveau.
• Les anciennes et nouvelles versions ont des problèmes de compatibilité au format RDB

AOF

AOF (ajouter uniquement le fichier) Persistance, utilisation du formulaire de journal pour enregistrer chaque opération d'écriture, ajouter au fichier et réexécuter le fichier AOF lorsque commande de redémarrage pour récupérer les données. Il résout principalement le problème en temps réel de la persistance des données. La valeur par défaut n'est pas activée.

Le flux de travail d'AOF est le suivant :

Avantages d'AOF

• Cohérence et intégrité des données plus élevées

Inconvénients d'AOF

• Plus il y a de contenu d'enregistrements AOF, meilleur est le fichier En gros, la récupération des données ralentit.

9. Comment atteindre la haute disponibilité de Redis ?

Nous utilisons Redis dans le projet, et nous ne déploierons certainement pas le service Redis à un seul moment. Car une fois le déploiement en point unique interrompu, il n’est plus disponible. Afin d'obtenir une haute disponibilité, une pratique courante consiste à copier plusieurs copies de la base de données et à les déployer sur différents serveurs. Si l'une d'entre elles tombe en panne, elle peut continuer à fournir des services. Redis dispose de trois modes de déploiement pour atteindre une haute disponibilité : Mode maître-esclave, mode sentinelle et mode cluster.

9.1 Mode maître-esclave

En mode maître-esclave, Redis déploie plusieurs machines, avec un nœud maître responsable des opérations de lecture et d'écriture et un nœud esclave responsable uniquement des opérations de lecture. Les données du nœud esclave proviennent du nœud maître. Le principe de mise en œuvre est le mécanisme de réplication maître-esclave

La réplication maître-esclave comprend la réplication complète et la réplication incrémentielle. Généralement, lorsque l'esclave commence à se connecter au maître pour la première fois, ou lorsque l'on considère que c'est la première fois qu'il se connecte, la copie complète est utilisée. Le processus de copie complète est le suivant :

• 1. . L'esclave envoie une commande de synchronisation au maître.
• 2. Après avoir reçu la commande SYNC, le maître exécute la commande bgsave pour générer le fichier RDB complet.
• 3. Le maître utilise un tampon pour enregistrer toutes les commandes d'écriture lors de la génération d'instantanés RDB.
• 4. Une fois que le maître a exécuté bgsave, il envoie des fichiers d'instantanés RDB à tous les esclaves.
• 5. Après avoir reçu le fichier d'instantané RDB, l'esclave charge et analyse l'instantané reçu.
• 6. Le maître utilise un tampon pour enregistrer toutes les commandes écrites générées lors de la synchronisation RDB.
• 7. Une fois l'instantané maître envoyé, il commence à envoyer la commande d'écriture dans le tampon à l'esclave ;
• 8.salve accepte la demande de commande et exécute la commande d'écriture à partir du tampon maître

Après redis2.8. version, il a été utilisé psync pour remplacer sync, car la commande sync consomme des ressources système et psync est plus efficace.

Une fois l'esclave entièrement synchronisé avec le maître, si les données sur le maître sont à nouveau mises à jour, la réplication incrémentielle sera déclenchée.

Lorsque les données augmentent ou diminuent sur le nœud maître, replicationFeedSalves()函数，接下来在 Master节点上调用的每一个命令会使用replicationFeedSlaves() sera déclenché pour se synchroniser avec le nœud esclave. Avant d'exécuter cette fonction, le nœud maître déterminera si la commande exécutée par l'utilisateur a des mises à jour des données. S'il y a une mise à jour des données et que le nœud esclave n'est pas vide, cette fonction sera exécutée. La fonction de cette fonction est : Envoyer la commande exécutée par l'utilisateur à tous les nœuds esclaves, et laisser le nœud esclave l'exécuter. Le processus est le suivant :

9.2 Mode Sentinelle

En mode maître-esclave, une fois que le nœud maître ne peut pas fournir de services en raison d'une panne, il est nécessaire de promouvoir manuellement le nœud esclave en nœud maître, et à en même temps, informez l'application de mettre à jour l'adresse du nœud maître. De toute évidence, cette méthode de gestion des pannes est inacceptable dans la plupart des scénarios commerciaux. Redis a officiellement fourni l'architecture Redis Sentinel depuis la version 2.8 pour résoudre ce problème.

Mode Sentinel, un système Sentinel composé d'une ou plusieurs instances Sentinel, qui peut surveiller tous les nœuds maîtres et nœuds esclaves Redis, et lorsque le nœud maître surveillé entre dans l'état hors ligne, supprime automatiquement le maître hors ligne Un nœud esclave sous le serveur est mis à niveau vers un nouveau nœud maître. Cependant, si un processus sentinelle surveille un nœud Redis, des problèmes peuvent survenir (Problème à point unique). Par conséquent, plusieurs sentinelles peuvent être utilisées pour surveiller les nœuds Redis, et chaque sentinelle se surveillera également mutuellement.

En termes simples, le mode sentinelle a trois fonctions :

• Envoyer des commandes et attendre que le serveur Redis (y compris le serveur maître et le serveur esclave) revienne pour surveiller son état d'exécution ; le nœud maître est en panne, et il basculera automatiquement le nœud esclave vers le nœud maître, puis informera les autres nœuds esclaves via le mode de publication et d'abonnement, modifiera le fichier de configuration et les laissera changer d'hôte
• Les sentinelles les surveilleront également ; autre pour atteindre une haute disponibilité.

Supposons que le serveur principal soit en panne et que Sentinel 1 détecte ce résultat en premier. Le système n'effectuera pas immédiatement le processus de basculement. C'est simplement que Sentinel 1 croit subjectivement que le serveur principal est indisponible. Lorsque les sentinelles suivantes détectent également que le serveur principal est indisponible et que le nombre atteint une certaine valeur, un vote aura lieu entre les sentinelles. Le résultat du vote sera initié par une sentinelle pour effectuer une opération de basculement. Une fois le changement réussi, chaque sentinelle utilisera le mode publication-abonnement pour basculer le serveur esclave qu'elle surveille vers l'hôte. Ce processus est appelé objectif hors ligne. De cette façon, tout est transparent pour le client.

Le mode de fonctionnement de Sentinel est le suivant :

• Chaque Sentinel envoie une commande PING au maître, à l'esclave et aux autres instances Sentinel qu'il connaît une fois par seconde.

• Si le temps écoulé depuis la dernière réponse valide à la commande PING dépasse la valeur spécifiée par l'option down-after-milliseconds, l'instance sera marquée comme subjectivement hors ligne par Sentinel.

• Si un Maître est marqué comme subjectif hors ligne, toutes les Sentinelles qui surveillent ce Maître doivent confirmer une fois par seconde que le Maître est effectivement entré dans l'état subjectif hors ligne.

• Lorsqu'un nombre suffisant de Sentinelles (supérieur ou égal à la valeur spécifiée dans le fichier de configuration) confirment que le Maître est effectivement entré dans un état subjectif hors ligne dans la plage de temps spécifiée, le Maître sera marqué comme objectivement hors ligne.

• Dans des circonstances normales, chaque Sentinelle enverra des commandes INFO à tous les maîtres et esclaves qu'elle connaît une fois toutes les 10 secondes.

• Lorsque le maître est marqué comme objectivement hors ligne par Sentinel, la fréquence à laquelle Sentinel envoie des commandes INFO à tous les esclaves du maître hors ligne passera d'une fois toutes les 10 secondes à une fois toutes les secondes

• S'il n'y en a pas assez Sentinelles doivent accepter Si le maître est hors ligne, le statut hors ligne objectif du maître sera supprimé ; si le maître renvoie à nouveau une réponse valide à la commande PING de Sentinel, le statut hors ligne subjectif du maître sera supprimé.

9.3 Mode cluster cluster

Le mode Sentinelle est basé sur le mode maître-esclave et réalise la séparation en lecture et en écriture. Il peut également basculer automatiquement et la disponibilité du système est plus élevée. Cependant, les données stockées dans chaque nœud sont les mêmes, ce qui gaspille de la mémoire et n'est pas facile à développer en ligne. Par conséquent, le cluster Cluster a vu le jour. Il a été ajouté dans Redis 3.0 et a implémenté le stockage distribué de Redis. Segmentez les données, ce qui signifie stocker différents contenus sur chaque nœud Redis pour résoudre le problème de l'expansion en ligne. De plus, il offre également des capacités de réplication et de basculement.

Communication des nœuds du cluster

Un cluster Redis se compose de plusieurs nœuds Comment chaque nœud communique-t-il entre eux ? Grâce au Protocole Gossip !

Le cluster Redis Cluster communique via le protocole Gossip. Les nœuds échangent en continu des informations, notamment les pannes de nœud, l'adhésion de nouveaux nœuds, les informations de changement de nœud maître-esclave, les informations d'emplacement, etc. Les messages de potins couramment utilisés sont divisés en quatre types : ping, pong, rencontre et échec.

• message de rencontre : notifiez les nouveaux nœuds à rejoindre. L'expéditeur du message informe le destinataire de rejoindre le cluster actuel. Une fois la communication du message de rencontre terminée normalement, le nœud de réception rejoindra le cluster et effectuera des échanges périodiques de messages ping et pong.
• Message Ping : message le plus fréquemment échangé dans le cluster. Chaque nœud du cluster envoie des messages ping à plusieurs autres nœuds chaque seconde, qui sont utilisés pour détecter si les nœuds sont en ligne et échanger des informations d'état entre eux.
• message pong : lors de la réception d'un message ping ou d'une rencontre, il répondra à l'expéditeur sous forme de message de réponse pour confirmer la communication normale du message. Le message pong encapsule en interne ses propres données d'état. Un nœud peut également diffuser son propre message pong au cluster pour demander à l'ensemble du cluster de mettre à jour son propre statut.
• Message d'échec : lorsqu'un nœud détermine qu'un autre nœud du cluster est hors ligne, il diffusera un message d'échec au cluster. Après avoir reçu le message d'échec, les autres nœuds mettront à jour le nœud correspondant vers l'état hors ligne.

Spécialement, chaque nœud communique avec d'autres nœuds via le bus cluster. Lors de la communication, utilisez un numéro de port spécial, c'est-à-dire le numéro de port du service externe plus 10 000. Par exemple, si le numéro de port d'un nœud est 6379, alors le numéro de port qu'il utilise pour communiquer avec d'autres nœuds est 16379. La communication entre les nœuds utilise un protocole binaire spécial.

Algorithme Hash Slot

Puisqu'il s'agit d'un stockage distribué, l'algorithme distribué utilisé par le cluster Cluster est Consistent Hash ? Non, c'est l'algorithme Hash Slot.

Algorithme de slotL'ensemble de la base de données est divisé en 16384 slots (slots). Chaque paire clé-valeur entrant dans Redis est hachée en fonction de la clé et attribuée à l'un de ces 16384 slots. La carte de hachage utilisée est également relativement simple. Elle utilise l'algorithme CRC16 pour calculer une valeur de 16 bits, puis modulo 16384. Chaque clé de la base de données appartient à l'un de ces 16 384 emplacements, et chaque nœud du cluster peut gérer ces 16 384 emplacements.

Chaque nœud du cluster est responsable d'une partie des emplacements de hachage. Par exemple, le cluster actuel a les nœuds A, B et C, et le nombre d'emplacements de hachage sur chaque nœud = 16384/3, alors il y a :

• Le nœud A est responsable des emplacements de hachage 0 ~ 5460
• Le nœud B est responsable des emplacements de hachage 5461 ~ 10922
• Le nœud C est responsable des emplacements de hachage 10923 ~ 16383

Cluster Redis Cluster

Dans le cluster Redis Cluster, il faut s'assurer que 16384 emplacements correspondent. Tous les nœuds fonctionnent normalement. Si un nœud tombe en panne, l'emplacement dont il est responsable deviendra également invalide et l'ensemble du cluster ne fonctionnera pas.

Ainsi, afin d'assurer une haute disponibilité, le cluster Cluster introduit la réplication maître-esclave, et un nœud maître correspond à un ou plusieurs nœuds esclaves. Lorsque d'autres nœuds maîtres envoient une requête ping à un nœud maître A, si plus de la moitié des nœuds maîtres communiquent avec A expirent, alors le nœud maître A est considéré comme étant en panne. Si le nœud maître tombe en panne, le nœud esclave sera activé.

Sur chaque nœud de Redis, il y a deux choses, l'une est l'emplacement et sa plage de valeurs est 016383. L'autre est le cluster, qui peut être compris comme un plug-in de gestion de cluster. Lorsque la clé à laquelle nous accédons arrive, Redis obtiendra une valeur de 16 bits basée sur l'algorithme CRC16, puis prendra le résultat modulo 16384. Chaque clé dans Jiangzi correspond à un emplacement de hachage numéroté entre 016383. Utilisez cette valeur pour trouver le nœud correspondant à l'emplacement correspondant, puis accédez automatiquement au nœud correspondant pour les opérations d'accès.

Bien que les données soient stockées séparément sur différents nœuds, pour le client, l'ensemble du cluster est considéré comme un tout. Le client se connecte à n’importe quel nœud et ressemble à l’exploitation d’une seule instance de Redis. Lorsque la clé actionnée par le client n'est pas affectée au bon nœud, Redis renverra l'instruction de redirection et pointera finalement vers le bon nœud. C'est un peu comme le saut de redirection 302 de la page du navigateur.

Failover

Le cluster Redis atteint une haute disponibilité Lorsqu'un nœud du cluster tombe en panne, failover est utilisé pour garantir que le cluster peut fournir des services externes normaux.

Le cluster Redis réalise la découverte de pannes via des messages ping/pong. Cet environnement comprend subjectif hors ligne et objectif hors ligne.

Hors ligne subjectif : Un nœud pense qu'un autre nœud n'est pas disponible, c'est-à-dire qu'il est dans un état hors ligne. Cet état n'est pas la détermination finale du défaut et ne peut représenter que l'opinion d'un nœud, et il peut y avoir une erreur de jugement.

Objectif hors ligne : Indique qu'un nœud est véritablement hors ligne. Plusieurs nœuds du cluster pensent que le nœud est indisponible, parvenant ainsi à un consensus. Si le nœud maître détenant l'emplacement tombe en panne, un basculement doit être effectué pour le nœud.

• Supposons que le nœud A marque le nœud B comme subjectivement hors ligne. Après un certain temps, le nœud A envoie l'état du nœud B à d'autres nœuds via des messages lorsque le nœud C reçoit le message et analyse le corps du message, si le nœud B est trouvé. Lorsque l'état pfail se produit, le processus objectif hors ligne sera déclenché ;
• Lorsque le nœud maître est hors ligne, le cluster Redis Cluster votera pour le nœud maître détenant l'emplacement de statistiques pour voir si le nombre de votes atteint la moitié. les statistiques du rapport sont supérieures à la moitié, marquées comme statut objectif hors ligne.

Le processus est le suivant :

Récupération après panne : Une fois la panne découverte, si le nœud hors ligne est le nœud maître, vous devez choisir l'un de ses nœuds esclaves pour le remplacer afin d'assurer le niveau élevé disponibilité du cluster. Le processus est le suivant :

• Contrôle de qualification : Vérifiez si le nœud esclave a les conditions pour remplacer le nœud maître défaillant.
• Préparer l'heure des élections : une fois le contrôle de qualification réussi, mettez à jour l'heure des élections en cas d'échec du déclenchement.
• Initier une élection : Lorsque le moment de l'élection de faute arrive, organisez une élection.
• Vote d'élection : Seul le nœud maître détenant le slot dispose de votes. Lorsque les nœuds esclaves collectent suffisamment de votes (plus de la moitié), l'opération de remplacement du nœud maître est déclenchée

10. Verrou distribué Redis ? Quels sont les points auxquels il faut prêter attention ?

Le verrouillage distribué est une implémentation d'un verrou qui contrôle différents processus dans un système distribué pour accéder conjointement aux ressources partagées. Les scénarios commerciaux tels que passer des commandes flash, récupérer des enveloppes rouges, etc. nécessitent tous l'utilisation de verrous distribués. Redis est souvent utilisé comme verrou distribué dans nos projets.

选了Redis分布式锁的几种实现方法，大家来讨论下，看有没有啥问题哈。

• 命令setnx + expire分开写
• setnx + value值是过期时间
• set的扩展命令（set ex px nx）
• set ex px nx + 校验唯一随机值,再删除

10.1 命令setnx + expire分开写

if（jedis.setnx(key,lock_value) == 1）{ //加锁
    expire（key，100）; //设置过期时间
    try {
        do something  //业务请求
    }catch(){
　　}
　　finally {
       jedis.del(key); //释放锁
    }
}

如果执行完setnx加锁，正要执行expire设置过期时间时，进程crash掉或者要重启维护了，那这个锁就“长生不老”了，别的线程永远获取不到锁啦，所以分布式锁不能这么实现。

10.2 setnx + value值是过期时间

long expires = System.currentTimeMillis() + expireTime; //系统时间+设置的过期时间
String expiresStr = String.valueOf(expires);

// 如果当前锁不存在，返回加锁成功
if (jedis.setnx(key, expiresStr) == 1) {
        return true;
} 
// 如果锁已经存在，获取锁的过期时间
String currentValueStr = jedis.get(key);

// 如果获取到的过期时间，小于系统当前时间，表示已经过期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {

     // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间（不了解redis的getSet命令的小伙伴，可以去官网看下哈）
    String oldValueStr = jedis.getSet(key_resource_id, expiresStr);
    
    if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
         // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才可以加锁
         return true;
    }
}
        
//其他情况，均返回加锁失败
return false;
}

笔者看过有开发小伙伴是这么实现分布式锁的，但是这种方案也有这些缺点：

• 过期时间是客户端自己生成的，分布式环境下，每个客户端的时间必须同步。
• 没有保存持有者的唯一标识，可能被别的客户端释放/解锁。
• 锁过期的时候，并发多个客户端同时请求过来，都执行了jedis.getSet()，最终只能有一个客户端加锁成功，但是该客户端锁的过期时间，可能被别的客户端覆盖。

10.3： set的扩展命令（set ex px nx）（注意可能存在的问题）

if（jedis.set(key, lock_value, "NX", "EX", 100s) == 1）{ //加锁
    try {
        do something  //业务处理
    }catch(){
　　}
　　finally {
       jedis.del(key); //释放锁
    }
}

这个方案可能存在这样的问题：

• 锁过期释放了，业务还没执行完。
• 锁被别的线程误删。

10.4 set ex px nx + 校验唯一随机值,再删除

if（jedis.set(key, uni_request_id, "NX", "EX", 100s) == 1）{ //加锁
    try {
        do something  //业务处理
    }catch(){
　　}
　　finally {
       //判断是不是当前线程加的锁,是才释放
       if (uni_request_id.equals(jedis.get(key))) {
        jedis.del(key); //释放锁
        }
    }
}

在这里，判断当前线程加的锁和释放锁是不是一个原子操作。如果调用jedis.del()释放锁的时候，可能这把锁已经不属于当前客户端，会解除他人加的锁。

一般也是用lua脚本代替。lua脚本如下：

if redis.call('get',KEYS[1]) == ARGV[1] then 
   return redis.call('del',KEYS[1]) 
else
   return 0
end;

这种方式比较不错了，一般情况下，已经可以使用这种实现方式。但是存在锁过期释放了，业务还没执行完的问题（实际上，估算个业务处理的时间，一般没啥问题了）。