Une brève analyse des raisons pour lesquelles Redis est rapide ? Où es-tu bientôt ?

Pourquoi Redis est-il rapide ? Où est Redis ? L'article suivant vous aidera à analyser les raisons pour lesquelles Redis est si rapide. J'espère qu'il vous sera utile !

Redis est une base de données NoSQL basée sur des paires clé-valeur. La valeur de Redis peut être composée de diverses structures de données et algorithmes tels que String, hash, list, set, zset, Bitmaps, HyperLogLog, etc. Redis fournit également l'expiration des clés, la publication et l'abonnement, les transactions, les scripts Lua, les sentinelles, le cluster et d'autres fonctions. [Recommandations associées : Tutoriel vidéo Redis]

Redis exécute les commandes très rapidement et, selon les performances officielles, il peut atteindre 10w+qps. Cet article présente donc principalement où Redis est rapide. Les points principaux sont les suivants :

1. Langage de développement

Maintenant, nous utilisons tous des langages de haut niveau pour la programmation, tels que Java, python, etc. Vous pensez peut-être que le langage C est très ancien, mais il est vraiment utile. Après tout, le système Unix est implémenté en C, le langage C est donc un langage très proche du système d'exploitation. Redis est développé en langage C, l'exécution sera donc plus rapide.

De plus, si les étudiants apprennent bien le C, cela vous aidera à mieux comprendre les systèmes d'exploitation informatiques. Ne pensez pas qu'après avoir appris une langue de haut niveau, vous n'avez pas à faire attention à la couche inférieure. La dette que vous devez devra toujours être remboursée. Voici un livre plus difficile à recommander, "Compréhension approfondie des systèmes informatiques".

2. Accès à la mémoire pure

Redis met toutes les données en mémoire. La synchronisation sans données fonctionne normalement. Il n'est pas nécessaire de lire les données du disque, 0 fois IO. Le temps de réponse de la mémoire est d'environ 100 nanosecondes, ce qui constitue une base importante pour la vitesse rapide de Redis. Jetons d'abord un coup d'œil à la vitesse du processeur :

Prenons mon ordinateur comme exemple. La fréquence principale est de 3,1G, ce qui signifie qu'il peut exécuter 3,1*10^9 instructions par seconde. Ainsi, le processeur voit le monde très, très lentement, la mémoire est cent fois plus lente qu'elle et le disque est un million de fois plus lent qu'elle. Pensez-vous qu'elle est plus rapide ou non ?

J'ai emprunté une image de "Compréhension approfondie des systèmes informatiques", qui montre une hiérarchie de mémoire typique au niveau de la couche L0, le processeur peut y accéder en un cycle d'horloge. Le cache basé sur SRAM peut être renouvelé en plusieurs accès. dans les cycles d'horloge du processeur, puis dans la mémoire principale basée sur la DRAM, ils sont accessibles en dizaines, voire centaines de cycles d'horloge.

3. Thread unique

Premièrement, un seul thread simplifie la mise en œuvre des algorithmes. Il est non seulement difficile d'implémenter des structures de données concurrentes, mais également difficile à tester. Deuxièmement, un seul thread évite la consommation causée par le changement de thread et le verrouillage et la libération des verrous. Pour le développement côté serveur, les verrous et le changement de thread nuisent généralement aux performances. Bien entendu, le single threading aura aussi ses défauts, ce qui est aussi le cauchemar de Redis : le blocage. Si l'exécution d'une commande est trop longue, d'autres commandes seront bloquées, ce qui est très fatal pour Redis, Redis est donc une base de données pour des scénarios d'exécution rapides.

En plus de Redis, Node.js est également monothread, et Nginx est également monothread, mais ce sont tous deux des modèles de serveurs hautes performances.

4. Mécanisme de multiplexage d'E/S multicanal non bloquant

Avant cela, parlons du fonctionnement des E/S bloquantes traditionnelles : lors de l'utilisation de la lecture ou de l'écriture sur un certain descripteur de fichier (File Descriptor FD) lors de la lecture et de l'écriture, si les données ne sont pas reçues, le thread sera suspendu jusqu'à ce que les données soient reçues.

Bien que le modèle de blocage soit facile à comprendre, il ne sera pas utilisé lorsque plusieurs tâches client doivent être traitées.

Le multiplexage E/S signifie en fait que la gestion de plusieurs connexions peut se faire dans le même processus. Le multicanal fait référence aux connexions réseau et le multiplexage n’est qu’un seul et même fil. Dans les services réseau, le rôle du multiplexage d'E/S est de notifier simultanément le code métier de plusieurs événements de connexion. La méthode de traitement est déterminée par le code métier.

Dans le modèle de multiplexage d'E/S, l'appel de fonction le plus important est la fonction de multiplexage d'E/S. Cette méthode peut surveiller la lecture et l'écriture de plusieurs descripteurs de fichiers (fd) en même temps. peut être lu/écrit, cette méthode renverra le nombre de fds lisibles/inscriptibles.

Redis utilise epoll comme implémentation de la technologie de multiplexage d'E/S, et le propre modèle de traitement d'événements de Redis convertit les lectures, écritures, fermetures, etc. d'epoll en événements, sans perdre trop de temps d'E/S réseau. Réalisez la surveillance de plusieurs lectures et écritures FD pour améliorer les performances.

Donnons un exemple frappant. Par exemple, un serveur TCP gère 20 sockets clients.

Plan A : Traitement séquentiel. Si la première socket est lente à lire les données à cause de la carte réseau, une fois bloquée, le reste sera gâché.

Plan B : créer un sous-processus de clonage pour gérer chaque demande de socket. Sans oublier que chaque processus consomme beaucoup de ressources système et que le changement de processus à lui seul suffit à fatiguer le système d'exploitation.

Schéma C (modèle de multiplexage E/S, epoll) : Enregistrez le fd correspondant au socket utilisateur dans epoll (en fait, ce qui est transmis entre le serveur et le système d'exploitation n'est pas le fd du socket mais la structure de données de fd_set) , puis epoll indique uniquement quelles sockets doivent être lues/écrites, et ne doit gérer que les sockets fd actives et changeantes.

De cette façon, l'ensemble du processus ne sera bloqué que lorsque epoll est appelé, et l'envoi et la réception de messages clients ne seront pas bloqués.

Pour plus de connaissances sur la programmation, veuillez visiter : Introduction à la programmation ! !

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!