Si redis fait déjà partie de la pile, pourquoi Memcached est-il toujours utilisé aux côtés de Redis?
Redis peut faire tout ce que Memcached fournit (cache LRU, expiration des éléments, et maintenant le clustering dans la version 3.x +, actuellement en version bêta) ou par des outils comme twemproxy. Les performances sont également similaires. De plus, Redis ajoute de la persistance grâce à laquelle vous n'avez pas besoin de chauffer le cache en cas de redémarrage du serveur.
Référence à quelques anciennes réponses qui comparent Redis et Memcache, dont certaines favorisent Redis comme remplacement de Memcache (si déjà présent dans la pile):
Malgré cela, en étudiant des piles de grandes entreprises Web telles qu'Instagram, Pinterest, Twitter, etc., j'ai constaté qu'elles utilisent à la fois Memcached et Redis à des fins différentes, sans utiliser Redis pour la mise en cache principale. Le cache principal est toujours Memcached et Redis est utilisé pour sa mise en cache logique basée sur les structures de données.
Depuis 2014, pourquoi memcached vaut-il toujours la peine d'être ajouté en tant que composant supplémentaire dans votre pile, alors que vous avez déjà un composant Redis qui peut faire tout ce que memcached peut faire? Quels sont les points favorables qui poussent les architectes/ingénieurs à inclure memcached en dehors de Redis déjà existant?
Mise à jour :
Pour nos plates-formes, nous avons complètement supprimé Memcached et utilisons redis pour les exigences de mise en cache simples et logiques. Hautement performant, flexible et fiable.
Quelques exemples de scénarios:
- Répertorier toutes les clés mises en cache selon un modèle spécifique et lire ou supprimer leurs valeurs. Très facile en redis, pas faisable (facilement) en memcached.
- Le stockage d'une charge utile de plus de 1 Mo, facile à faire dans redis, nécessite des ajustements de taille de dalle dans memcached, ce qui a ses propres effets secondaires sur les performances.
- Instantanés faciles du contenu du cache actuel
- Le cluster Redis est également prêt pour la production avec les pilotes de langue, donc le déploiement en cluster est également facile.
La principale raison pour laquelle je vois aujourd'hui un cas d'utilisation pour memcached sur Redis est l'efficacité supérieure de la mémoire que vous devriez pouvoir obtenir avec plain la mise en cache des fragments HTML ( ou applications similaires). Si vous devez stocker différents champs de vos objets dans différentes clés memcached, les hachages Redis vont être plus efficaces en mémoire, mais lorsque vous avez un grand nombre de paires clé -> simple_string, memcached devrait être en mesure de vous donner plus d'éléments par mégaoctet.
D'autres choses qui sont de bons points sur memcached:
- C'est un morceau de code très simple, donc si vous avez juste besoin des fonctionnalités qu'il fournit, c'est une alternative raisonnable, je suppose, mais je ne l'ai jamais utilisé en production.
- Il est multithread, donc si vous devez évoluer dans une configuration à boîte unique, c'est une bonne chose et vous devez parler avec une seule instance.
Je pense que Redis en tant que cache a de plus en plus de sens lorsque les gens s'orientent vers une mise en cache intelligente ou lorsqu'ils essaient de préserver la structure des données mises en cache via les structures de données Redis.
Comparaison entre Redis LRU et memcached LRU.
Memcached et Redis n'effectuent pas de véritables expulsions LRU, mais seulement une approximation de cela.
L'expulsion de Memcache est une classe par taille et dépend des détails d'implémentation de son allocateur de dalles. Par exemple, si vous souhaitez ajouter un élément qui tient dans une classe de taille donnée, memcached essaiera de supprimer les éléments expirés/non récemment utilisés dans cette classe, au lieu de tenter une tentative globale de comprendre ce qu'est l'objet, indépendamment de sa taille, qui est le meilleur candidat.
Redis essaie plutôt de choisir un bon objet en tant que candidat à l'expulsion lorsque la limite maxmemory est atteinte, en regardant tous les objets, quelle que soit la classe de taille, mais ne peut fournir qu'un objet approximativement bon, pas le meilleur objet avec le temps d'inactivité supérieur.
Pour ce faire, Redis procède à l'échantillonnage de quelques objets, en sélectionnant celui qui était inactif (non accessible) le plus longtemps. Depuis Redis 3.0 (actuellement en version bêta), l'algorithme a été amélioré et prend également un bon pool de candidats à travers les expulsions, donc l'approximation a été améliorée. Dans la documentation Redis vous pouvez trouver une description et des graphiques avec des détails sur la façon dont cela fonctionne .
Pourquoi memcached a une meilleure empreinte mémoire que Redis pour une chaîne simple -> des cartes de chaînes.
Redis est un logiciel plus complexe, donc les valeurs dans Redis sont stockées d'une manière plus similaire aux objets dans un langage de programmation de haut niveau: ils ont un type, un codage et un comptage de référence associés pour la gestion de la mémoire. Cela rend la structure interne de Redis bonne et gérable, mais a un surcoût par rapport à memcached qui ne traite que des chaînes.
Quand Redis commence à être plus efficace en mémoire
Redis est capable de stocker de petits types de données agrégées d'une manière spéciale pour économiser de la mémoire. Par exemple, un petit Redis Hash représentant un objet est stocké en interne non pas avec une table de hachage, mais comme un blob unique binaire. Ainsi, la définition de plusieurs champs par objet dans un hachage est plus efficace que le stockage de N clés séparées dans memcached.
Vous pouvez, en fait, stocker un objet dans memcached en tant qu'un blob JSON (ou codé binaire), mais contrairement à Redis, cela ne vous permettra pas de récupérer ou de mettre à jour des champs indépendants.
L'avantage de Redis dans le contexte de la mise en cache intelligente.
En raison des structures de données Redis, le modèle habituel utilisé avec memcached de détruire des objets lorsque le cache est invalidé, pour le recréer à partir de la base de données plus tard, est une manière primitive d'utiliser Redis.
Par exemple, imaginez que vous devez mettre en cache les dernières N nouvelles publiées dans Hacker News afin de remplir la section "Les plus récentes" du site. Ce que vous faites avec Redis, c'est de prendre une liste (limitée aux éléments M) avec les dernières nouvelles insérées. Si vous utilisez un autre magasin pour vos données et Redis comme cache, ce que vous faites est de remplir les deux les vues (Redis et DB) lorsqu'un un nouvel élément est publié. Il n'y a pas d'invalidation du cache.
Cependant, l'application peut toujours avoir une logique de sorte que si la liste Redis est trouvée vide, par exemple après un démarrage, la vue initiale peut être recréée à partir de la base de données.
En utilisant la mise en cache intelligente, il est possible d'effectuer la mise en cache avec Redis de manière plus efficace que Memcached, mais tous les problèmes ne conviennent pas à ce modèle. Par exemple, la mise en cache des fragments HTML peut ne pas bénéficier de cette technique.
Les habitudes sont difficiles a arreter :)
Sérieusement, il y a deux raisons principales - à ma connaissance - pourquoi Memcached est toujours utilisé:
- Héritage - il existe des développeurs qui sont à l'aise et familiers avec Memcached, ainsi que des applications qui le prennent en charge. Cela signifie également qu'il s'agit d'une technologie mature et bien testée.
- Mise à l'échelle - Memcached standard est facilement évolutif horizontalement, tandis que Redis (jusqu'à et à l'exclusion de la prochaine version 3) nécessite plus de travail à cette fin (c'est-à-dire le partage).
Toutefois:
- Ré. héritage - étant donné la robustesse de Redis (structures de données, commandes, persistance ...), étant activement développé et des clients dans tous les langages imaginables - les nouvelles applications sont généralement s'est développé avec.
- Re-scaling - outre la prochaine v3, il existe des solutions qui peuvent rendre le scaling beaucoup plus facile. Par exemple, Redis Cloud offre une mise à l'échelle transparente sans perte de données ni interruption de service. Une autre approche populaire pour redimensionner/partager Redis est twemproxy .