Quand choisir Redis

1. Pour les structures de données complexes, il est plus approprié de choisir redis

Lorsque la valeur est une structure de données complexe telle qu'un hachage, une liste, un ensemble, un ensemble ordonné, redis sera choisi car mc ne peut pas répondre à ces besoins.

Les scénarios les plus typiques, la liste des commandes des utilisateurs, le message de l'utilisateur, la liste des commentaires postés, etc.

Deuxièmement, la persistance, redis est plus approprié

mc ne peut pas répondre aux besoins de persistance, nous devons donc choisir redis. Cependant, une chose à noter est la suivante : vous êtes-vous vraiment assuré que vous utilisez correctement la fonction de persistance de Redis ?

N'utilisez jamais redis comme base de données :

• Les instantanés réguliers de redis ne peuvent pas garantir que les données ne seront pas perdues ;

• l'AOF de redis réduira l'efficacité et ne pourra pas prendre en charge un trop grand volume de données ; Ne vous attendez pas à ce que Redis fasse un meilleur travail que MySQL dans un stockage solide. Différents outils font ce pour quoi ils sont bons. Utiliser Redis comme base de données est erroné à 80%.

Quels sont les avantages et les inconvénients d'activer la fonction de guérison pour les scénarios de mise en cache ?

S'il s'agit simplement d'un scénario de mise en cache, les données sont stockées dans la base de données et mises en cache dans Redis si la fonction de guérison est activée à ce moment-là. :

L'avantage est que si Redis se bloque puis redémarre, la mémoire peut restaurer rapidement les données chaudes sans exercer instantanément de pression sur la base de données. Il n'y a pas de processus de préchauffage du cache.

L'inconvénient est que pendant le processus de suspension de Redis, s'il y a des modifications de données dans la base de données, cela peut entraîner une incohérence entre la base de données et les données Redis après le redémarrage de Redis.

Par conséquent, pour les scénarios en lecture seule, ou pour autoriser certains scénarios commerciaux incohérents, vous pouvez essayer d'activer la fonction de solidification de redis.

3. Pour une haute disponibilité, il est plus approprié de choisir redis

redis prend naturellement en charge les fonctions de clustering et peut réaliser une réplication active et une séparation de la lecture et de l'écriture. Redis fournit également officiellement un outil de gestion de cluster sentinelle, qui peut réaliser une surveillance des services maître-esclave et un basculement automatique. Tout cela est transparent pour le client, sans modification de programme ni intervention manuelle.

Voiceover : Memcache, pour atteindre une haute disponibilité, nécessite un développement secondaire, comme une double lecture et une double écriture sur le client, ou une synchronisation de cluster sur le serveur.

Cependant, ce que je tiens à vous rappeler ici, c'est que dans la plupart des scénarios commerciaux, le cache doit-il vraiment être hautement disponible

Dans de nombreux cas, les échecs de cache sont autorisés

• Le cache se bloque souvent ? parfois, la base de données lit des données ;

• Nous devons donc analyser attentivement le scénario commercial. La haute disponibilité est-elle vraiment la principale exigence du cache ?

Voix off : Dans le secteur de la messagerie instantanée, le statut en ligne de l'utilisateur est doté d'une haute disponibilité. exigences.

4. Le contenu stocké est relativement volumineux, il est donc plus approprié de choisir redis

La valeur de stockage de memcache peut atteindre 1 Mo. Si la valeur stockée est très grande, seul redis peut être utilisé. Bien sûr, par rapport à Memcache, Redis présente également certains « inconvénients » en raison des différences dans les mécanismes de mise en œuvre sous-jacents.

Scénario 1 : En raison des différences dans les mécanismes d'allocation de mémoire, redis peut provoquer une fragmentation de la mémoire

memcache utilise un pool de mémoire pré-alloué pour gérer la mémoire, ce qui peut économiser du temps d'allocation de mémoire. redis demande temporairement de l'espace, ce qui peut provoquer une fragmentation.

A partir de ce moment, mc sera plus rapide.

Scénario 2 : en raison de la différence d'utilisation de la mémoire virtuelle, Redis peut être vidé et affecter les performances

memcache stocke toutes les données dans la mémoire physique. Redis possède son propre mécanisme de VM, qui peut théoriquement stocker plus de données que la mémoire physique. Lorsque les données sont dépassées, le swap sera déclenché pour vider les données froides sur le disque. À partir de ce point, lorsque la quantité de données est importante, mc sera plus rapide.

Voix off : La nouvelle version de redis a été optimisée.

Cas 3 : En raison des différences dans les modèles de réseau, redis peut affecter la planification des E/S en raison des calculs du processeur

memcache utilise un modèle de multiplexage d'E/S non bloquant, et redis utilise également un modèle de multiplexage d'E/S non bloquant. Mais comme Redis fournit également des fonctions de tri et d'agrégation autres que le stockage KV, lors de l'exécution de ces fonctions, des calculs complexes du processeur bloqueront toute la planification des E/S.

À partir de ce moment, puisque redis fournit plus de fonctions, mc sera plus rapide.

Scénario 4 : En raison des différences dans les modèles de threads, il est difficile pour Redis d'utiliser des effets spéciaux multicœurs pour améliorer les performances

memcache utilise plusieurs threads, le thread principal écoute et les sous-threads de travail acceptent les requêtes et effectuez la lecture et l'écriture. Dans ce processus, il peut y avoir des conflits de verrouillage. Redis utilise un seul thread Bien qu'il n'y ait pas de conflit de verrouillage, il est difficile d'utiliser les caractéristiques du multicœur pour améliorer le débit global.

A partir de ce moment, mc sera plus rapide.

Scénario 5 : En raison de l'absence de partitionnement automatique, Redis ne peut être étendu manuellement que horizontalement

Qu'il s'agisse de Redis ou de Memcache, le cluster de serveurs ne prend naturellement pas en charge l'expansion horizontale et doit être partitionné sur le client. Ce n’est en fait pas bon pour l’appelant. Ce serait plus parfait si le cluster de serveurs pouvait prendre en charge l'expansion horizontale. Enfin, c'est peut-être l'une des raisons pour lesquelles beaucoup de gens aiment Redis : le code source est très lisible et la qualité du code est très élevée.

J'ai vu le code source de Redis et Memcache. En termes de lisibilité, Redis est le logiciel avec le code le plus propre que j'ai jamais vu. Peut-être que la simplicité est l'intention initiale de la conception de Redis. redis. En s'appuyant sur des bibliothèques tierces, une seule marque suffit.

Le code source de Memcache a peut-être pris en compte trop d'évolutivité et de compatibilité multi-systèmes. Le code n'est pas clair et semble laborieux.

Par exemple, pour la partie IO réseau, 1 à 2 fichiers du code source redis peuvent être résolus. MC utilise libevent. Un FD est transmis dans les deux sens, via des tuyaux et des threads, ce qui est particulièrement facile à confondre.

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!