Introduction aux nouvelles fonctionnalités de Redis version 6.0

Version stable de Redis 6.0

La version stable de Redis 6.0.0 offre de nombreuses nouvelles fonctionnalités et améliorations fonctionnelles, telles que le nouveau protocole réseau RESP3, nouvel agent de cluster, ACL, etc. Je pense que ce qui préoccupe le plus tout le monde est peut-être encore le "multi-threading". Jetons un coup d'œil aux nouvelles fonctionnalités de la version Redis 6.0.

(Partage vidéo d'apprentissage :tutoriel vidéo Redis)

1. Les versions antérieures à Redis 6.0 sont-elles vraiment mono-thread ?

Lorsque Redis gère les requêtes des clients, y compris l'acquisition (lecture du socket), l'analyse, l'exécution, le retour de contenu (écriture du socket), etc., elles sont toutes traitées par un thread principal séquentiel et série. ce qu'on appelle "Single thread". Mais à proprement parler, il n'est pas monothread depuis Redis 4.0. En plus du thread principal, il dispose également de threads d'arrière-plan qui gèrent certaines opérations plus lentes, telles que le nettoyage des données sales, la libération des connexions inutiles, la suppression de clés volumineuses, etc.

2. Pourquoi le multithreading n'était-il pas utilisé avant Redis6.0 ?

La réponse officielle à une question similaire était la suivante : lors de l'utilisation de Redis, il n'y a presque aucune situation où le processeur devient un goulot d'étranglement. Redis est principalement limité par la mémoire et le réseau. Par exemple, sur un système Linux normal, Redis peut gérer 1 million de requêtes par seconde en utilisant le pipeline, donc si l'application utilise principalement des commandes O(N) ou O(log(N)), elle ne consommera guère beaucoup de CPU.

Après avoir utilisé un seul thread, la maintenabilité est élevée. Bien que le modèle multithread fonctionne bien à certains égards, il introduit une incertitude dans l'ordre d'exécution du programme, entraîne une série de problèmes de lecture et d'écriture simultanées, augmente la complexité du système et peut impliquer un changement de thread ou même un verrouillage. par déverrouillage et impasse. Redis a des performances de traitement très élevées grâce au modèle d'événement AE, au multiplexage d'E/S et à d'autres technologies, il n'est donc pas nécessaire d'utiliser le multithreading. Le mécanisme à thread unique réduit considérablement la complexité de l'implémentation interne de Redis. L'inertie de Hash, Rehash, Lpush et d'autres commandes « thread-unsafe » peuvent être exécutées sans verrous.

3.Pourquoi Redis6.0 introduit-il le multithreading ?

Redis place toutes les données en mémoire. Le temps de réponse de la mémoire est d'environ 100 nanosecondes. Pour les petits paquets de données, le serveur Redis peut gérer 80 000 à 100 000 QPS, ce qui est également la limite du traitement Redis. Pour 80 % des entreprises, un Redis monothread est suffisant.

Mais avec des scénarios commerciaux de plus en plus complexes, certaines entreprises peuvent facilement atteindre des centaines de millions de transactions, elles ont donc besoin de QPS plus importants. Une solution courante consiste à partitionner les données dans une architecture distribuée et à utiliser plusieurs serveurs, mais cette solution présente de très gros inconvénients, comme un trop grand nombre de serveurs Redis à gérer et des coûts de maintenance élevés ; certaines solutions conviennent à un seul serveur Redis. ne fonctionne pas avec les partitions de données ; les partitions de données ne peuvent pas résoudre les problèmes de lecture/écriture des points d'accès ; la réallocation et la mise à l'échelle des données deviennent plus complexes, etc.

Du point de vue de Redis lui-même, étant donné que les appels système de lecture/écriture du réseau de lecture et d'écriture occupent la majeure partie du temps CPU lors de l'exécution de Redis, le goulot d'étranglement réside principalement dans la consommation d'E/S du réseau. Il existe deux directions principales d'optimisation :

• Améliorer les performances des E/S du réseau, implémentations typiques telles que l'utilisation de DPDK pour remplacer la pile réseau du noyau
• Utiliser le multithreading pour utiliser pleinement les multicœurs, implémentations typiques telles que Memcaché.

Cette méthode d'optimisation de la pile de protocoles n'a pas grand-chose à voir avec Redis. La prise en charge du multi-threading est le moyen de fonctionnement le plus efficace et le plus pratique. Donc, en résumé, Redis prend en charge le multithreading pour deux raisons principales :

• Il peut utiliser pleinement les ressources CPU du serveur. Actuellement, le thread principal ne peut utiliser qu'un seul cœur
• Les tâches multithread peuvent le faire. partager la lecture et l'écriture d'E/S synchrones de Redis Load

4. Redis6.0 active-t-il le multithreading par défaut ?

Le multithreading dans Redis 6.0 est désactivé par défaut et seul le thread principal est utilisé. Si vous souhaitez l'activer, vous devez modifier le fichier de configuration redis.conf : io-threads-do-reads yes

5. Lorsque le multi-threading Redis6.0. est activé, comment définir le nombre de threads ?

Après avoir activé le multi-threading, vous devez définir le nombre de threads, sinon cela ne prendra pas effet. Modifiez également le fichier de configuration redis.conf

Concernant le paramétrage du nombre de threads, il existe une suggestion officielle : il est recommandé de régler les machines à 4 cœurs sur 2 ou 3 threads, et 8- Il est recommandé de définir les machines principales sur 6 threads. Le nombre de threads doit être inférieur au nombre de cœurs de machine. Il convient également de noter que plus le nombre de threads est grand, mieux c'est. Les responsables estiment que plus de 8 threads n'ont fondamentalement aucun sens.

6. Après que Redis6.0 ait adopté le multi-threading, quel est l'effet d'amélioration des performances ?

L'auteur de Redis, Antirez, mentionné lors du partage à RedisConf 2019 : La fonctionnalité d'E/S multithread introduite dans Redis 6 peut au moins doubler l'amélioration des performances. Les experts nationaux ont également utilisé la version instable pour effectuer des tests sur Alibaba Cloud esc. Les performances de la commande GET/SET en IO à 4 threads sont presque doublées par rapport à celles d'un seul thread.

Environnement de test:

Serveur Redis : Alibaba Cloud Ubuntu 18.04, 8 CPU 2,5 GHZ, mémoire 8G, modèle hôte ecs.ic5.2xlarge
Client Redis Benchmark : Alibaba Cloud Ubuntu 18.04, 8 CPU 2,5 GHZ, mémoire 8G, hôte Modèle ecs.ic5.2xlarge

Résultats des tests:

Pour plus de détails, veuillez consulter : https://zhuanlan.zhihu. com/p /76788470

Remarque 1 : Ces tests de vérification des performances n'effectuent pas de tests de résistance sur un contrôle strict des délais et différents scénarios de concurrence. Les données sont uniquement à titre de référence de vérification et ne peuvent pas être utilisées comme indicateur en ligne.

Remarque 2 : Si vous activez le multi-threading, il est recommandé d'utiliser au moins une machine à 4 cœurs et l'instance Redis a occupé une quantité considérable de temps CPU. Sinon, cela ne sert à rien d'utiliser le multi. -enfilage. On estime donc que 80 % des développeurs d’entreprises se contenteront d’y jeter un coup d’œil.

7. Quel est le mécanisme d'implémentation du multithread Redis6.0 ?

Le processus est brièvement décrit comme suit:

1 Le thread principal est responsable de la réception de la demande de connexion. , en obtenant le socket et en le plaçant dans la file d'attente globale En attente de traitement de lecture
2. Une fois que le thread principal a traité l'événement de lecture, allouez ces connexions à ces threads IO via RR (Round Robin)
3. Le principal le thread se bloque et attend que le thread IO ait fini de lire le socket
4 , le thread principal exécute la commande de requête de manière monothread et les données demandées sont lues et analysées, mais ne sont pas exécutées
5. Le thread principal se bloque et attend que le thread IO réécrive les données sur le socket
6. Délier, effacer la file d'attente

(Source de l'image : https://ruby-china. org/topics/38957)

La conception présente les caractéristiques suivantes :
1. Thread IO ou lecture ou écriture à partir du socket en même temps, ne pas lire ou écrire en même temps
2 .Le thread IO est uniquement responsable de la lecture et de l'écriture des commandes d'analyse des sockets, et n'est pas responsable du traitement des commandes

8 Après avoir activé le multithread, y a-t-il des problèmes de sécurité de concurrence des threads ?

Comme le montre le mécanisme d'implémentation ci-dessus, la partie multithread de Redis n'est utilisée que pour traiter la lecture et l'écriture des données réseau et l'analyse du protocole, et l'exécution des commandes est toujours unique -exécution séquentielle threadée. Nous n'avons donc pas besoin de prendre en compte les problèmes de concurrence et de sécurité des threads liés au contrôle des clés, de Lua, des transactions, de LPUSH/LPOP, etc.

9. Comment installer Redis 6.0.1 sur environnement Linux (la version officielle de 6.0 est 6.0.1) ?

Ce n'est pas différent de l'installation d'autres versions de Redis. Il n'y a aucun piège dans l'ensemble du processus, donc je ne le décrirai pas ici. La seule chose à noter est que le nombre de multi-threads configurés doit être inférieur au nombre de cœurs du CPU Vérifiez le nombre de cœurs avec la commande :

[root@centos7.5 ~]# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3

Comparez le multi. -modèle de threading de Redis6.0 et modèle multithread Memcached

Au cours des dernières années, memcached était une solution de mise en cache couramment utilisée par les grandes sociétés Internet. Par conséquent, la différence entre redis et memcached s'est réduite. fondamentalement, c'est devenu une question d'entretien incontournable pour les intervieweurs concernant la mise en cache. Ces dernières années, Memcached a été moins utilisé. Cependant, avec l'ajout de fonctionnalités multithread dans Redis 6.0, des problèmes similaires peuvent encore survenir. Nous ne ferons ensuite qu'une brève comparaison des modèles multithread.

Comme le montre l'image ci-dessus : le serveur Memcached fonctionne en mode maître-woker et le serveur utilise socket pour communiquer avec le client. Le thread principal et le thread de travail utilisent des tuyaux pour communiquer. Le thread principal utilise libevent pour surveiller les événements de lecture d'écoute et d'acceptation. Une fois l'événement répondu, il encapsule la structure des données des informations de connexion, sélectionne le thread de travail approprié en fonction de l'algorithme et distribue la tâche de connexion transportant les informations de connexion. Le thread correspondant utilise le descripteur de connexion pour établir et Le socket du client se connecte et effectue les opérations d'accès aux données ultérieures.

Comparaison entre les modèles multithread Redis 6.0 et Memcached :
Similitude : les deux adoptent le modèle de thread maître thread-worker
Différence : Memcached exécute également la logique principale dans le thread de travail et le modèle C'est plus C'est simple, permet d'obtenir une véritable isolation des threads et est conforme à notre compréhension conventionnelle de l'isolation des threads. Redis renvoie la logique de traitement au thread maître. Bien que cela augmente dans une certaine mesure la complexité du modèle, il résout également des problèmes tels que la sécurité de la concurrence des threads.

11. Comment l'auteur de Redis commente-t-il la nouvelle fonctionnalité du « multi-threading » ?

Concernant la fonctionnalité multi-threading, Antirez a expliqué un jour dans 6.0 RC1 :

Il existe deux manières possibles pour Redis de prendre en charge le multi-threading : la première est comme "memcached" De cette façon, une instance Redis ouvre plusieurs threads, augmentant ainsi le nombre d'opérations pouvant être effectuées par seconde dans des commandes simples telles que GET/SET. Cela implique un traitement multithread tel que l'analyse des E/S et des commandes, c'est pourquoi nous l'appelons « threading E/S ». L'autre consiste à permettre l'exécution de commandes plus lentes dans différents threads pour garantir que les autres clients ne soient pas bloqués. Nous appelons ce modèle de thread « Threading de commandes lentes ».

Après mûre réflexion, Redis n'utilisera pas le « threading d'E/S ». Redis est principalement limité par le réseau et la mémoire pendant l'exécution, donc l'amélioration des performances de Redis se fait principalement via plusieurs instances Redis, en particulier les clusters Redis. Ensuite, nous envisagerons principalement d'améliorer deux aspects :
1. Plusieurs instances du cluster Redis peuvent raisonnablement utiliser le disque de l'instance locale via l'orchestration pour éviter de réécrire AOF en même temps.
2. Fournissez un agent de cluster Redis pour permettre aux utilisateurs de faire abstraction d'un cluster lorsqu'il n'existe pas de meilleur client de protocole de cluster.

En remarque, Redis est un système de mémoire comme Memcached, mais différent de Memcached. Le multithreading est complexe et un modèle de données simple doit être pris en compte. Le thread exécutant LPUSH doit prendre en charge les autres threads exécutant LPOP.

Ce que j'attends vraiment, c'est en fait un "threading d'opérations lentes". Dans redis6 ou redis7, un "verrouillage au niveau de la clé" sera fourni afin que les threads puissent prendre pleinement le contrôle de la clé pour gérer les opérations lentes.

Pour plus de détails, voir : http://antirez.com/news/126

12. Le multiplexage IO est souvent mentionné dans les discussions Redis.

Il s'agit d'un type de modèle IO, le modèle de conception classique de Reactor, parfois également appelé IO de blocage asynchrone.

Le multicanal fait référence à plusieurs connexions socket, et la réutilisation fait référence à la réutilisation d'un seul thread. Il existe trois principales technologies de multiplexage : select, poll et epoll. epoll est la dernière et la meilleure technologie de multiplexage disponible. L'utilisation de la technologie de multiplexage d'E/S multicanal permet à un seul thread de gérer efficacement plusieurs demandes de connexion (minimisant la consommation de temps des E/S réseau), et Redis exploite les données en mémoire très rapidement (les opérations en mémoire ne deviendront pas un problème ici ). Goulot d'étranglement des performances), les deux points ci-dessus contribuent principalement au débit élevé de Redis.

13. Connaissez-vous l'œuf de Pâques LOLWUT de Redis ?

Ceci est en fait disponible depuis Redis 5.0, mais pardonnez-moi de le savoir. L'auteur décrit cette fonction comme "LOLWUT : une œuvre d'art dans une commande de base de données", "une œuvre d'art dans une commande de base de données". Vous pouvez appeler cela du sentiment, ou vous pouvez l’appeler un œuf de Pâques, je ne révélerai pas de quoi il s’agit spécifiquement. Les amis qui ne savent pas ce que c'est, comme moi, peuvent se référer à : http://antirez.com/news/123 Il sera généré aléatoirement à chaque exécution.

Recommandations associées :Tutoriel sur la base de données 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!