Redis est-il multithread ?

Redis est monothread signifie que le module de requête réseau utilise un seul thread (il n'est donc pas nécessaire de prendre en compte la sécurité de la concurrence). , c'est-à-dire qu'un thread gère toutes les requêtes réseau et que les autres modules utilisent toujours plusieurs threads.

Les raisons pour lesquelles Redis peut s'exécuter rapidement :

(1) La plupart des requêtes sont des opérations de mémoire pure (très rapides)
(2) Utiliser un seul thread pour éviter Élimine le contexte inutile Conditions de commutation et de concurrence
(3) Multiplexage IO-IO non bloquant (Que signifie le multiplexage IO ?)

Il existe trois méthodes dans le multiplexage IO ：select,poll,epoll. Il convient de noter que select et poll ne sont pas sécurisés pour les threads, tandis qu'epoll est sécurisé pour les threads

L'implémentation interne de Redis utilise epoll, en utilisant epoll + un cadre d'événements simple implémenté par lui-même. Lire, écrire, fermer et se connecter dans epoll sont tous convertis en événements, puis utiliser la fonction de multiplexage d'epoll pour ne jamais perdre de temps sur io. Ces trois conditions ne sont pas indépendantes les unes des autres, notamment la première, si la demande est faite. Tous prennent du temps, et le débit et les performances de l'utilisation d'un seul thread peuvent être imaginés. Il faut dire que redis a choisi la solution technique adaptée à des scénarios particuliers.

Implémentation interne de redis :

L'implémentation interne utilise epoll, en utilisant epoll + un framework d'événements simple implémenté par lui-même. Lire, écrire, fermer et se connecter dans epoll sont tous convertis en événements, puis utiliser la fonction de multiplexage d'epoll pour ne jamais perdre de temps sur io. Ces trois conditions ne sont pas indépendantes les unes des autres, notamment la première, si la demande est faite. Ils prennent tous du temps, et le débit et les performances de l'utilisation d'un seul thread peuvent être imaginés. Il faut dire que redis a choisi la solution technique adaptée à des scénarios particuliers.

Redis sur les problèmes de sécurité des threads :

Redis adopte en fait le concept de fermeture de thread, fermant les tâches dans un seul thread, ce qui évite naturellement les problèmes de sécurité des threads, mais pour ceux qui ont besoin de s'appuyer sur plusieurs redis Pour les opérations composites, des verrous sont toujours requis et il peut s'agir de verrous distribués.

Quels sont les avantages de l'utilisation de Redis ?

(1) C'est rapide car les données sont stockées en mémoire, similaire à HashMap. L'avantage de HashMap est que la complexité temporelle de la recherche et de l'opération est O(1)

(2. ) Prise en charge riche Type de données, prend en charge la chaîne, la liste, l'ensemble, l'ensemble trié, le hachage

(3) Prend en charge les transactions, les opérations sont toutes atomiques. La soi-disant atomicité signifie que toutes les modifications apportées aux données sont soit exécutées, soit. pas exécuté du tout

(4) Fonctionnalités riches : peut être utilisé pour la mise en cache, la messagerie, la définition du délai d'expiration par clé, il sera automatiquement supprimé après l'expiration

Problèmes de performances courants de Redis et solutions :

(1) Il est préférable que le maître n'effectue aucun travail de persistance, tel que les instantanés de mémoire RDB et les fichiers journaux AOF (le maître écrit des instantanés de mémoire et la commande save planifie la fonction rdbSave, ce qui bloquera le travail de le thread principal Lorsque l'instantané est relativement volumineux, l'impact sur les performances est le suivant : Si les données sont très volumineuses, le service sera suspendu par intermittence, il est donc préférable de ne pas écrire d'instantanés de mémoire sur le maître si le fichier AOF l'est trop ; grand, cela affectera la vitesse de récupération du redémarrage du maître)

(2) Si les données sont importantes, un esclave doit activer la sauvegarde AOF des données, la politique est définie pour se synchroniser une fois par seconde

(3) Pour la vitesse de réplication maître-esclave et la stabilité de la connexion, il est préférable que le maître et l'esclave soient dans le même LAN

(4) Essayez d'éviter d'ajouter des bibliothèques esclaves au maître bibliothèque sous forte pression

(5) N'utilisez pas de structure graphique pour la réplication maître-esclave. Il est plus stable d'utiliser une structure de liste chaînée unidirectionnelle, c'est-à-dire : Maître <- Esclave1 <. ;- Slave2 <- Slave3...; Cette structure facilite la résolution du problème du point de défaillance unique et la réalisation du remplacement du maître par l'esclave. Si le maître raccroche, vous pouvez immédiatement activer Slave1 en tant que maître, laissant tout le reste inchangé.

Pour plus de connaissances sur Redis, veuillez visiter la colonne Tutoriel d'utilisation de 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!