Pourquoi le processus unique Redis est-il rapide ?

Redis utilise une base de données KV basée sur la mémoire qui utilise un modèle mono-processus et monothread et est écrite en langage C. Les données officielles fournies indiquent qu'il peut atteindre plus de 100 000 qps. Ces données ne sont pas pires que Memcached, la même base de données KV basée sur la mémoire qui utilise un processus unique et multithread.

La principale raison pour laquelle Redis est rapide est : (Apprentissage recommandé : Tutoriel vidéo Redis)

Entièrement basé sur la mémoire

Structure des données Données simples et faciles à exploiter

Utiliser un modèle de multiplexage d'E/S multicanal

Je n'entrerai pas dans les détails sur le premier et le deuxième points, mais principalement Concentrez-vous sur le troisième point de l'utilisation de la technologie de réutilisation des E/S multicanaux pour se développer.

Le modèle de multiplexage d'E/S multicanal utilise select, poll et epoll pour surveiller les événements d'E/S de plusieurs flux en même temps. Lorsqu'il est inactif, le thread actuel sera bloqué. Lorsqu'un ou plusieurs flux ont des événements d'E/S, ils sortiront de l'état de blocage, de sorte que le programme interrogera tous les flux (epoll interroge uniquement les flux qui ont réellement émis des événements), et uniquement dans l'ordre. Traitement des flux prêts, cette approche évite beaucoup d'opérations inutiles.

Ici, « multiple » fait référence à plusieurs connexions réseau, et « réutilisation » fait référence à la réutilisation du même fil. 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.

Contrairement à Memcached, Redis n'utilise pas Libevent directement, mais complète une implémentation très légère d'interfaces courantes telles que select, epoll, evport et kqueue.

Choisissez les interfaces appropriées pour les différents appels système. La valeur par défaut est epoll sous Linux. Parce que Libevent est relativement lourd et polyvalent, la quantité de code est très importante et il possède de nombreuses fonctions que Redis ne peut pas utiliser. Afin de rechercher la « légèreté » et de supprimer les dépendances, Redis a choisi de l'encapsuler lui-même.

Avantages d'un processus unique et d'un thread unique

Le code est plus clair et la logique de traitement est plus simple

Il n'est pas nécessaire de prendre en compte divers problèmes de verrouillage , il n'y a pas de verrouillage. Libérez l'opération de verrouillage, il n'y a pas de consommation de performances causée par un éventuel blocage

Il n'y a pas de commutation causée par un multi-processus ou un multi-thread qui consomme les performances du processeur

Les inconvénients d'un processus unique et d'un thread unique

Impossible de profiter des performances du processeur multicœur, mais cela peut être amélioré en ouvrant plusieurs instances Redis sur une seule machine ;

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!