Si redis fait déjà partie de la stack, pourquoi Memcached est-il toujours utilisé aux côtés de Redis?

Redis peut faire tout ce que Memcached fournit (cache LRU, expiration d’élément, et désormais clustering en version 3.x +, actuellement en version bêta) ou par des outils tels que twemproxy. La performance est similaire aussi. 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 à d’anciennes réponses qui comparent Redis et Memcache, certaines favorisant Redis en remplacement de Memcache (si elles sont déjà présentes dans la stack):

  • Memcached vs Redis?

  • Est-ce que memcached est un dinosaure par rapport à Redis?

  • Redis et Memcache ou juste Redis?

Malgré cela, en étudiant des stacks de grandes entresockets à l’échelle du Web comme Instagram, Pinterest, Twitter, etc., j’ai constaté qu’elles utilisaient à 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 la mise en cache logique des structures de données.

En 2014, pourquoi memcached vaut-il encore la peine d’être ajouté en tant que composant supplémentaire dans votre stack, alors que vous avez déjà un composant Redis capable de faire tout ce que memcached peut faire? Quels sont les points favorables qui poussent les architectes / ingénieurs à inclure encore memcached en dehors des Redis déjà existants?

Mettre à jour :

Pour nos plates-formes, nous avons complètement éliminé Memcached et utilisons redis pour les exigences de mise en cache simples et logiques. Très performant, flexible et fiable.

Quelques exemples de scénarios:

  • Lister toutes les clés en cache selon un modèle spécifique et lire ou supprimer leurs valeurs. Très facile dans redis, pas faisable (facilement) dans memcached.
  • Stocker une charge utile supérieure à 1 Mo, facile à faire dans Redis, nécessite des réglages de la taille des blocs dans memcached, ce qui a ses propres effets sur les performances.
  • Instantanés faciles du contenu du cache actuel
  • Le cluster Redis est également prêt pour la production, tout comme les pilotes de langage, ce qui facilite également le déploiement en cluster.

La principale raison pour laquelle je vois aujourd’hui comme cas d’utilisation de memcached sur Redis est l’efficacité supérieure de la mémoire que vous devriez pouvoir obtenir avec la mise en cache des fragments HTML simples (ou des applications similaires). Si vous avez besoin de stocker différents champs de vos objects dans différentes clés memcached, les hachages Redis seront plus efficaces en termes de mémoire, mais lorsque vous avez un grand nombre de paires clé -> simple_ssortingng, memcached devrait pouvoir vous donner plus d’éléments par mégaoctet.

Autres choses qui sont de bons points à propos de memcached:

  • C’est un morceau de code très simple, donc si vous avez juste besoin de la fonctionnalité fournie, c’est une alternative raisonnable, mais je ne l’ai jamais utilisée en production.
  • Il est multi-thread, donc si vous devez évoluer dans une configuration à une seule boîte, c’est une bonne chose et vous devez parler avec une seule instance.

Je pense que Redis en tant que cache est de plus en plus logique à mesure que les utilisateurs évoluent 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 Redu LRU et memcached LRU.

Les deux memcached et Redis n’effectuent pas de véritables expulsions LRU, mais seulement une approximation.

L’éviction de Memcache est une classe par taille et dépend des détails d’implémentation de son allocateur de tranche. Par exemple, si vous voulez append un élément qui correspond à une classe de taille donnée, memcached essaiera de supprimer les éléments expirés / non utilisés récemment dans cette classe, au lieu d’essayer de comprendre ce qu’est l’object, quelle que soit sa taille. taille, qui est le meilleur candidat.

Redis essaie plutôt de choisir un bon object comme candidat à l’expulsion lorsque la limite maxmemory est atteinte, en examinant tous les objects, quelle que soit la classe de taille, mais ne peut fournir qu’un object relativement bon, et non le meilleur object temps d’inactivité.

La façon dont Redis fait cela consiste à échantillonner quelques objects, à choisir celui qui était inactif (non consulté) le plus longtemps. Depuis Redis 3.0 (actuellement en version bêta), l’algorithme a été amélioré et prend également un bon nombre de groupes de candidats à travers les expulsions, de sorte que l’approximation a été améliorée. Dans la documentation Redis, vous pouvez trouver une description et des graphiques avec des détails sur son fonctionnement .

Pourquoi memcached a une meilleure empreinte mémoire que Redis pour simple ssortingng -> chaines de mappes.

Redis est un logiciel plus complexe, de sorte que les valeurs de Redis sont stockées de manière plus similaire aux objects dans un langage de programmation de haut niveau: elles 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 correcte et gérable, mais présente une surcharge 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 permettant d’économiser la mémoire. Par exemple, un petit Redis Hash représentant un object est stocké en interne, non pas avec une table de hachage, mais en tant que blob unique binary. Donc, placer plusieurs champs par object dans un hachage est plus efficace que de stocker N clés séparées dans memcached.

Vous pouvez, en fait, stocker un object dans memcached sous la forme d’un seul blob JSON (ou codé binary), mais contrairement à Redis, cela ne vous permettra pas d’extraire 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 pour détruire des objects lorsque le cache est invalidé, pour le recréer ultérieurement dans la firebase database, est une manière primitive d’utiliser Redis.

Par exemple, imaginez que vous deviez mettre en cache les dernières nouvelles N publiées dans Hacker News afin de remplir la section “Plus récent” du site. Ce que vous faites avec Redis est de prendre une liste (limitée aux éléments M) avec les nouvelles les plus récentes insérées. Si vous utilisez un autre magasin pour vos données et Redis en tant que cache, vous devez renseigner à la fois les vues (Redis et la firebase database) lorsqu’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 vide, par exemple après un démarrage, la vue initiale peut être recréée à partir de la firebase database.

En utilisant la mise en cache intelligente, il est possible d’effectuer une mise en cache avec Redis d’une manière plus efficace que celle de 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é:

  1. Legacy – il existe des développeurs qui sont à l’aise et familiarisés avec Memcached, ainsi que des applications qui le prennent en charge. Cela signifie également que c’est une technologie mature et éprouvée.
  2. Mise à l’échelle – Memcached standard est facilement extensible horizontalement, alors que Redis (jusqu’à et à l’exclusion de la v3 à paraître) nécessite plus de travail à cet effet (par exemple, le sharding).

Toutefois:

  1. Ré. inheritance – compte tenu de la robustesse de Redis (structures de données, commandes, persistance …), il est activement développé et les clients dans tous les langages imaginables – de nouvelles applications sont généralement développées avec lui.
  2. Re-scaling: outre la prochaine version 3, il existe des solutions qui facilitent la mise à l’échelle. Par exemple, Redis Cloud offre une évolutivité transparente sans perte de données ni interruption de service. Une autre approche populaire de redimensionnement / partage Redis est twemproxy .