Nous utilisons une application Web Ruby avec un serveur Redis pour la mise en cache. Y a-t-il un point pour tester Memcached à la place?

Qu'est-ce qui nous donnera de meilleures performances? Des avantages ou des inconvénients entre Redis et Memcached?

Points à considérer:

• Vitesse de lecture / écriture.
• Utilisation de la mémoire.
• Vidage des E / S disque.
• Mise à l'échelle.

Résumé (TL; DR)

Mis à jour le 3 juin 2017

Redis est plus puissant, plus populaire et mieux pris en charge que memcached. Memcached ne peut faire qu'une petite partie des choses que Redis peut faire. Redis est meilleur même lorsque leurs fonctionnalités se chevauchent.

Pour quelque chose de nouveau, utilisez Redis.

Memcached vs Redis: comparaison directe

Les deux outils sont des magasins de données en mémoire puissants et rapides qui sont utiles comme cache. Les deux peuvent aider à accélérer votre application en mettant en cache les résultats de la base de données, les fragments HTML ou tout autre élément qui pourrait coûter cher à générer.

Points à considérer

Lorsqu'ils sont utilisés pour la même chose, voici comment ils se comparent en utilisant les «points à considérer» de la question d'origine:

• Vitesse de lecture / écriture : les deux sont extrêmement rapides. Les repères varient en fonction de la charge de travail, des versions et de nombreux autres facteurs, mais montrent généralement que redis est aussi rapide ou presque aussi rapide que memcached. Je recommande redis, mais pas parce que memcached est lent. Ce n'est pas.
• Utilisation de la mémoire : Redis est meilleur.
  • memcached: vous spécifiez la taille du cache et lorsque vous insérez des éléments, le démon augmente rapidement jusqu'à un peu plus que cette taille. Il n'y a jamais vraiment de moyen de récupérer cet espace, à moins de redémarrer memcached. Toutes vos clés peuvent être expirées, vous pouvez vider la base de données et elle utilisera toujours la totalité de la RAM avec laquelle vous l'avez configurée.
  • redis: La définition d'une taille maximale dépend de vous. Redis n'utilisera jamais plus que nécessaire et vous restituera une mémoire qu'il n'utilise plus.
  • J'ai stocké 100 000 ~ 2 Ko de chaînes (~ 200 Mo) de phrases aléatoires dans les deux. L'utilisation de la mémoire RAM Memcached est passée à ~ 225 Mo. L'utilisation de la RAM Redis est passée à ~ 228 Mo. Après avoir rincé les deux, redis est tombé à ~ 29 Mo et le memcached est resté à ~ 225 Mo. Ils sont également efficaces dans la façon dont ils stockent les données, mais un seul est capable de les récupérer.
• Vidage des E / S disque : une victoire claire pour redis car il le fait par défaut et a une persistance très configurable. Memcached n'a aucun mécanisme de vidage sur disque sans outils tiers.
• Mise à l'échelle : les deux vous offrent des tonnes d'espace libre avant d'avoir besoin de plus d'une seule instance comme cache. Redis inclut des outils pour vous aider à aller au-delà de cela, contrairement à Memcached.

memcached

Memcached est un simple serveur de cache volatile. Il vous permet de stocker des paires clé / valeur où la valeur est limitée à une chaîne jusqu'à 1 Mo.

C'est bon dans ce domaine, mais c'est tout. Vous pouvez accéder à ces valeurs par leur clé à une vitesse extrêmement élevée, saturant souvent le réseau disponible ou même la bande passante mémoire.

Lorsque vous redémarrez memcached, vos données ont disparu. C'est très bien pour un cache. Vous ne devriez pas y stocker quelque chose d'important.

Si vous avez besoin de hautes performances ou d'une haute disponibilité, des outils, produits et services tiers sont disponibles.

redis

Redis peut effectuer les mêmes tâches que Memcached et peut les faire mieux.

Redis peut également servir de cache . Il peut également stocker des paires clé / valeur. En redis, ils peuvent même atteindre 512 Mo.

Vous pouvez désactiver la persistance et il perdra également vos données au redémarrage. Si vous voulez que votre cache survive aux redémarrages, cela vous permet également de le faire. En fait, c'est la valeur par défaut.

C'est aussi très rapide, souvent limité par la bande passante du réseau ou de la mémoire.

Si une instance de redis / memcached n'est pas assez performante pour votre charge de travail, redis est le choix évident. Redis inclut le support de cluster et est livré avec des outils de haute disponibilité ( redis-sentinel ) directement "dans la boîte". Au cours des dernières années, redis est également devenu le leader incontesté de l'outillage tiers. Des entreprises comme Redis Labs, Amazon et d'autres proposent de nombreux outils et services redis utiles. L'écosystème autour de redis est beaucoup plus grand. Le nombre de déploiements à grande échelle est désormais probablement supérieur à celui des memcaches.

The Redis Superset

Redis est plus qu'un cache. Il s'agit d'un serveur de structure de données en mémoire. Ci-dessous, vous trouverez un aperçu rapide des choses que Redis peut faire au-delà d'être un simple cache clé / valeur comme memcached. La plupart des fonctionnalités de redis sont des choses que memcached ne peut pas faire.

Documentation

Redis est mieux documenté que memcached. Bien que cela puisse être subjectif, cela semble être de plus en plus vrai tout le temps.

redis.io est une fantastique ressource facile à naviguer. Il vous permet d' essayer redis dans le navigateur et vous donne même des exemples interactifs en direct avec chaque commande dans les documents.

Il y a maintenant 2x plus de résultats de stackoverflow pour redis que memcached. 2x plus de résultats Google. Des exemples plus facilement accessibles dans plus de langues. Développement plus actif. Développement client plus actif. Ces mesures peuvent ne pas signifier grand-chose individuellement, mais en combinaison, elles brossent un tableau clair que le support et la documentation de redis sont plus importants et plus à jour.

Persistance

Par défaut, redis conserve vos données sur le disque à l'aide d'un mécanisme appelé capture instantanée. Si vous avez suffisamment de RAM disponible, il est capable d'écrire toutes vos données sur le disque sans presque aucune dégradation des performances. C'est presque gratuit!

En mode instantané, il est possible qu'un crash soudain entraîne une petite quantité de données perdues. Si vous devez absolument vous assurer qu'aucune donnée n'est perdue, ne vous inquiétez pas, redis vous soutient également avec le mode AOF (Append Only File). Dans ce mode de persistance, les données peuvent être synchronisées sur le disque au fur et à mesure de leur écriture. Cela peut réduire le débit d'écriture maximal à la vitesse à laquelle votre disque peut écrire, mais devrait toujours être assez rapide.

Il existe de nombreuses options de configuration pour affiner la persistance si vous en avez besoin, mais les valeurs par défaut sont très raisonnables. Ces options facilitent la configuration de redis en tant qu'endroit sûr et redondant pour stocker les données. C'est une vraie base de données.

De nombreux types de données

Memcached est limité aux chaînes, mais Redis est un serveur de structure de données qui peut servir de nombreux types de données différents. Il fournit également les commandes dont vous avez besoin pour tirer le meilleur parti de ces types de données.

Chaînes ( commandes )

Texte simple ou valeurs binaires pouvant atteindre 512 Mo. Il s'agit du seul type de données redis et partage memcached, bien que les chaînes memcached soient limitées à 1 Mo.

Redis vous offre plus d'outils pour tirer parti de ce type de données en proposant des commandes pour les opérations au niveau du bit, la manipulation au niveau du bit, la prise en charge de l'incrémentation / décrémentation en virgule flottante, les requêtes de plage et les opérations à touches multiples. Memcached ne supporte rien de tout cela.

Les chaînes sont utiles pour toutes sortes de cas d'utilisation, c'est pourquoi memcached est assez utile avec ce type de données seul.

Hashs ( commandes )

Les hachages sont un peu comme un magasin de valeurs clés dans un magasin de valeurs clés. Ils mappent entre les champs de chaîne et les valeurs de chaîne. Les mappages de champs-> valeurs utilisant un hachage sont légèrement plus efficaces en espace que les mappages de clés-> valeurs utilisant des chaînes régulières.

Les hachages sont utiles comme espace de noms ou lorsque vous souhaitez regrouper logiquement plusieurs clés. Avec un hachage, vous pouvez récupérer tous les membres efficacement, expirer tous les membres ensemble, supprimer tous les membres ensemble, etc. Idéal pour tout cas d'utilisation où vous avez plusieurs paires clé / valeur qui doivent être regroupées.

Un exemple d'utilisation d'un hachage est pour stocker des profils utilisateur entre les applications. Un hachage redis stocké avec l'ID utilisateur comme clé vous permettra de stocker autant de bits de données sur un utilisateur que nécessaire tout en les stockant sous une seule clé. L'avantage d'utiliser un hachage au lieu de sérialiser le profil en une chaîne est que vous pouvez faire en sorte que différentes applications lisent / écrivent différents champs dans le profil utilisateur sans avoir à se soucier qu'une application écrase les modifications apportées par d'autres (ce qui peut arriver si vous sérialisez périmé Les données).

Listes ( commandes )

Les listes Redis sont des collections ordonnées de chaînes. Ils sont optimisés pour insérer, lire ou supprimer des valeurs en haut ou en bas (aka: gauche ou droite) de la liste.

Redis fournit de nombreuses commandes pour exploiter les listes, y compris les commandes pour pousser / pop les éléments, pousser / pop entre les listes, tronquer les listes, effectuer des requêtes de plage, etc.

Les listes constituent de grandes files d'attente atomiques et durables. Ceux-ci fonctionnent très bien pour les files d'attente de travaux, les journaux, les tampons et de nombreux autres cas d'utilisation.

Ensembles ( commandes )

Les ensembles sont des collections non ordonnées de valeurs uniques. Ils sont optimisés pour vous permettre de vérifier rapidement si une valeur est dans l'ensemble, d'ajouter / supprimer rapidement des valeurs et de mesurer le chevauchement avec d'autres ensembles.

Ils sont parfaits pour des choses comme les listes de contrôle d'accès, les trackers de visiteurs uniques et bien d'autres choses. La plupart des langages de programmation ont quelque chose de similaire (généralement appelé un ensemble). C'est comme ça, seulement distribué.

Redis fournit plusieurs commandes pour gérer les ensembles. Des éléments évidents comme l'ajout, la suppression et la vérification de l'ensemble sont présents. Il en va de même pour les commandes moins évidentes comme le saut / lecture d'un élément aléatoire et les commandes pour effectuer des unions et des intersections avec d'autres ensembles.

Ensembles triés ( commandes )

Les ensembles triés sont également des collections de valeurs uniques. Ceux-ci, comme leur nom l'indique, sont commandés. Ils sont classés par partition, puis lexicographiquement.

Ce type de données est optimisé pour des recherches rapides par score. Il est extrêmement rapide d'obtenir la valeur la plus élevée, la plus basse ou toute plage de valeurs intermédiaires.

Si vous ajoutez des utilisateurs à un ensemble trié avec leur meilleur score, vous avez vous-même un classement parfait. Au fur et à mesure que de nouveaux scores élevés arrivent, ajoutez-les simplement à l'ensemble avec leur score élevé et il réorganisera votre classement. Également idéal pour garder une trace de la dernière fois que les utilisateurs ont visité et qui est actif dans votre application.

Le stockage de valeurs avec le même score entraîne leur classement lexicographique (pensez par ordre alphabétique). Cela peut être utile pour des choses comme les fonctionnalités de saisie semi-automatique.

De nombreuses commandes d' ensemble triées sont similaires aux commandes d'ensembles, avec parfois un paramètre de score supplémentaire. Sont également incluses les commandes de gestion des scores et d'interrogation par score.

Géo

Redis dispose de plusieurs commandes pour stocker, récupérer et mesurer des données géographiques. Cela inclut les requêtes de rayon et la mesure des distances entre les points.

Techniquement, les données géographiques dans redis sont stockées dans des ensembles triés, ce n'est donc pas un type de données vraiment séparé. Il s'agit plutôt d'une extension au-dessus d'ensembles triés.

Bitmap et HyperLogLog

Comme Geo, ce ne sont pas des types de données complètement séparés. Ce sont des commandes qui vous permettent de traiter les données de chaîne comme s'il s'agissait d'un bitmap ou d'un hyperloglog.

Les bitmaps sont destinés aux opérateurs de niveau binaire auxquels j'ai fait référence Strings. Ce type de données était la pierre angulaire du récent projet d'art collaboratif de reddit: r / Place .

HyperLogLog vous permet d'utiliser un espace extrêmement petit constant pour compter des valeurs uniques presque illimitées avec une précision choquante. En utilisant seulement ~ 16 Ko, vous pouvez compter efficacement le nombre de visiteurs uniques sur votre site, même si ce nombre se chiffre en millions.

Transactions et atomicité

Les commandes dans redis sont atomiques, ce qui signifie que vous pouvez être sûr que dès que vous écrivez une valeur dans redis, cette valeur est visible pour tous les clients connectés à redis. Il n'y a pas d'attente pour que cette valeur se propage. Techniquement, memcached est atomique également, mais avec redis ajoutant toutes ces fonctionnalités au-delà de memcached, il convient de noter et quelque peu impressionnant que tous ces types de données et fonctionnalités supplémentaires sont également atomiques.

Bien que ce ne soit pas tout à fait la même chose que les transactions dans les bases de données relationnelles, redis propose également des transactions qui utilisent un «verrouillage optimiste» ( WATCH / MULTI / EXEC ).

Pipelining

Redis fournit une fonctionnalité appelée « pipelining ». Si vous souhaitez exécuter de nombreuses commandes redis, vous pouvez utiliser le pipelining pour les envoyer à redis en une seule fois au lieu d'une à la fois.

Normalement, lorsque vous exécutez une commande sur redis ou memcached, chaque commande est un cycle de demande / réponse distinct. Avec le pipelining, redis peut mettre en mémoire tampon plusieurs commandes et les exécuter toutes en même temps, en répondant avec toutes les réponses à toutes vos commandes en une seule réponse.

Cela peut vous permettre d'atteindre un débit encore plus important lors de l'importation en bloc ou d'autres actions impliquant de nombreuses commandes.

Pub / Sub

Redis a des commandes dédiées à la fonctionnalité pub / sub , permettant à redis d'agir comme un diffuseur de messages à grande vitesse. Cela permet à un seul client de publier des messages sur de nombreux autres clients connectés à un canal.

Redis fait du pub / sub ainsi que presque n'importe quel outil. Les courtiers de messages dédiés comme RabbitMQ peuvent avoir des avantages dans certains domaines, mais le fait que le même serveur puisse également vous fournir des files d'attente durables persistantes et d'autres structures de données dont vos charges de travail de pub / sous-marin ont probablement besoin, Redis s'avérera souvent être l'outil le meilleur et le plus simple Pour le boulot.

Lua Scripting

Vous pouvez penser aux scripts lua comme le propre SQL de redis ou les procédures stockées. C'est à la fois plus et moins que cela, mais l'analogie fonctionne surtout.

Vous avez peut-être des calculs complexes que vous souhaitez que redis effectue. Peut-être que vous ne pouvez pas vous permettre de faire annuler vos transactions et que vous avez besoin de garanties que chaque étape d'un processus complexe se déroulera de manière atomique. Ces problèmes et bien d'autres peuvent être résolus avec les scripts lua.

Le script entier est exécuté de manière atomique, donc si vous pouvez intégrer votre logique dans un script lua, vous pouvez souvent éviter de jouer avec des transactions de verrouillage optimistes.

Mise à l'échelle

Comme mentionné ci-dessus, redis inclut une prise en charge intégrée pour le clustering et est fourni avec son propre outil de haute disponibilité appelé redis-sentinel.

Conclusion

Sans hésitation, je recommanderais redis sur memcached pour tous les nouveaux projets ou les projets existants qui n'utilisent pas déjà memcached.

Ce qui précède peut sembler que je n'aime pas memcached. Au contraire: c'est un outil puissant, simple, stable, mature et durci. Il y a même des cas d'utilisation où c'est un peu plus rapide que redis. J'adore memcached. Je ne pense tout simplement pas que cela ait beaucoup de sens pour le développement futur.

Redis fait tout ce que fait memcached, souvent mieux. Tout avantage de performances pour memcached est mineur et spécifique à la charge de travail. Il existe également des charges de travail pour lesquelles redis sera plus rapide, et de nombreuses autres charges de travail que redis peut faire et que memcached ne peut tout simplement pas. Les différences de performances minuscules semblent mineures face au fossé géant des fonctionnalités et du fait que les deux outils sont si rapides et efficaces qu'ils peuvent très bien être le dernier élément de votre infrastructure que vous aurez à vous soucier de la mise à l'échelle.

Il n'y a qu'un seul scénario où memcached a plus de sens: où memcached est déjà utilisé comme cache. Si vous mettez déjà en cache avec memcached, continuez à l'utiliser, s'il répond à vos besoins. Cela ne vaut probablement pas la peine de passer à redis et si vous allez utiliser redis uniquement pour la mise en cache, cela peut ne pas offrir suffisamment d'avantages pour valoir votre temps. Si memcached ne répond pas à vos besoins, vous devriez probablement passer à redis. Cela est vrai que vous ayez besoin d'évoluer au-delà de memcached ou que vous ayez besoin de fonctionnalités supplémentaires.

Utilisez Redis si

1. Vous devez supprimer / expirer sélectivement les éléments du cache. (Tu en as besoin)

2. Vous devez pouvoir interroger des clés d'un type particulier. eq. 'blog1: posts: *', 'blog2: categories: xyz: posts: *'. Oh oui! c'est très important. Utilisez-le pour invalider certains types d'éléments mis en cache de manière sélective. Vous pouvez également l'utiliser pour invalider le cache de fragments, le cache de pages, uniquement les objets AR d'un type donné, etc.

3. Persistance (Vous en aurez également besoin, sauf si vous êtes d'accord avec votre cache devant se réchauffer après chaque redémarrage. Très essentiel pour les objets qui changent rarement)

Utilisez memcached si

1. Memcached vous donne la tête!
2. euh ... clustering? meh. si vous allez aussi loin, utilisez Varnish et Redis pour mettre en cache des fragments et des objets AR.

D'après mon expérience, j'ai eu une bien meilleure stabilité avec Redis que Memcached

Memcached est multithread et rapide.

Redis a beaucoup de fonctionnalités et est très rapide, mais complètement limité à un cœur car il est basé sur une boucle d'événement.

Nous utilisons les deux. Memcached est utilisé pour mettre en cache des objets, réduisant principalement la charge de lecture sur les bases de données. Redis est utilisé pour des choses comme les ensembles triés, qui sont pratiques pour enrouler des données de séries chronologiques.

C'est trop long pour être posté en tant que commentaire à une réponse déjà acceptée, donc je le mets comme une réponse distincte

Une chose à considérer également est de savoir si vous vous attendez à avoir une limite de mémoire supérieure stricte sur votre instance de cache.

Étant donné que redis est une base de données nosql avec des tonnes de fonctionnalités et que la mise en cache n'est qu'une option pour laquelle elle peut être utilisée, elle alloue de la mémoire selon ses besoins - plus vous y mettez d'objets, plus elle utilise de mémoire. L' maxmemoryoption n'applique pas strictement l'utilisation de la limite de mémoire supérieure. Lorsque vous travaillez avec le cache, les clés sont supprimées et expirées; il est probable que vos clés n'ont pas toutes la même taille, de sorte qu'une fragmentation de la mémoire interne se produit.

Par défaut, redis utilise l' allocateur de mémoire jemalloc , qui fait de son mieux pour être à la fois compact et rapide, mais c'est un allocateur de mémoire à usage général et il ne peut pas suivre de nombreuses allocations et purges d'objets se produisant à un rythme élevé. Pour cette raison, sur certains modèles de charge, le processus redis peut apparemment fuir la mémoire en raison de la fragmentation interne. Par exemple, si vous avez un serveur avec 7 Go de RAM et que vous souhaitez utiliser redis comme cache LRU non persistant, vous constaterez peut-être que le processus redis avec une valeur maxmemoryde 5 Go au fil du temps utiliserait de plus en plus de mémoire, atteignant éventuellement la limite totale de RAM jusqu'à ce que tueur de mémoire interfère.

memcached est mieux adapté au scénario décrit ci-dessus, car il gère sa mémoire d'une manière complètement différente. memcached alloue un gros morceau de mémoire - tout ce dont il aura besoin - puis gère cette mémoire par lui-même, en utilisant son propre allocateur de dalle implémenté . De plus, memcached s'efforce de maintenir une fragmentation interne faible, car il utilise en fait l' algorithme LRU par dalle , lorsque les expulsions LRU sont effectuées avec la taille de l'objet considérée.

Cela dit, memcached a toujours une position forte dans les environnements, où l'utilisation de la mémoire doit être appliquée et / ou prévisible. Nous avons essayé d'utiliser le dernier redis stable (2.8.19) en tant que remplacement memcached basé sur LRU non persistant dans une charge de travail de 10-15k op / s, et il a fuit beaucoup de mémoire; la même charge de travail faisait planter les instances ElastiCache redis d'Amazon en un jour ou deux pour les mêmes raisons.

Memcached est bon pour être un simple magasin clé / valeur et est bon pour faire la clé => STRING. Cela le rend vraiment bon pour le stockage de session.

Redis est bon pour faire la clé => SOME_OBJECT.

Cela dépend vraiment de ce que vous allez y mettre. Ma compréhension est qu'en termes de performances, ils sont assez uniformes.

Bonne chance également pour trouver des repères objectifs, si vous en trouvez, envoyez-les moi à ma façon.

Si vous ne vous occupez pas d'un style d'écriture grossier, Redis vs Memcached sur le blog Systoilet vaut la peine d'être lu du point de vue de l'utilisabilité, mais assurez-vous de lire les allers-retours dans les commentaires avant de tirer des conclusions sur les performances; il y a quelques problèmes méthodologiques (tests de boucle occupée à un seul thread), et Redis a également apporté quelques améliorations depuis la rédaction de l'article.

Et aucun lien de référence n'est complet sans confondre un peu les choses, alors consultez également quelques références contradictoires sur LiveJournal de Dormondo et le blog Antirez .

Edit - comme le souligne Antirez, l'analyse Systoilet est plutôt mal conçue. Même au-delà du manque de thread unique, une grande partie de la disparité des performances dans ces benchmarks peut être attribuée aux bibliothèques clientes plutôt qu'au débit du serveur. Les références du blog Antirez présentent en effet une comparaison beaucoup plus de pommes à pommes (avec la même bouche).

J'ai eu l'occasion d'utiliser à la fois memcached et redis dans le proxy de mise en cache sur lequel j'ai travaillé, permettez-moi de vous expliquer où j'ai exactement utilisé quoi et pourquoi derrière ...

Redis>

1) Utilisé pour indexer le contenu du cache sur le cluster. J'ai plus d'un milliard de clés réparties sur des clusters redis, les temps de réponse redis sont beaucoup moins stables et.

2) Fondamentalement, c'est un magasin de clés / valeurs, donc partout où dans votre application vous avez quelque chose de similaire, on peut utiliser redis avec beaucoup de tracas.

3) La persistance, le basculement et la sauvegarde de Redis (AOF) faciliteront votre travail.

Memcache>

1) oui, une mémoire optimisée pouvant être utilisée comme cache. Je l'ai utilisé pour stocker le contenu du cache auquel on accède très fréquemment (avec 50 hits / seconde) avec une taille inférieure à 1 Mo.

2) Je n'ai alloué que 2 Go sur 16 Go pour Memcached aussi lorsque ma taille de contenu unique était> 1 Mo.

3) Au fur et à mesure que le contenu se rapproche des limites, j'ai parfois observé des temps de réponse plus élevés dans les statistiques (pas le cas avec redis).

Si vous demandez une expérience globale, Redis est beaucoup plus vert car il est facile à configurer, très flexible avec des fonctionnalités robustes stables.

De plus, il existe un résultat d'analyse comparative disponible sur ce lien , ci-dessous quelques exemples de ce même,

J'espère que cela t'aides!!

Tester. Exécutez quelques repères simples. Pendant longtemps, je me considérais comme un rhinocéros de la vieille école depuis que j'utilisais principalement des memcached et considérais Redis comme le nouveau.

Avec mon entreprise actuelle, Redis était utilisé comme cache principal. Lorsque j'ai creusé dans certaines statistiques de performances et simplement commencé à tester, Redis était, en termes de performances, comparable ou minimalement plus lent que MySQL.

Memcached, bien que simpliste, a totalement soufflé Redis hors de l'eau . Il évoluait beaucoup mieux:

• pour des valeurs plus grandes (changement requis de la taille de la dalle, mais travaillé)
• pour plusieurs demandes simultanées

De plus, à mon avis, la politique d'expulsion memcached est beaucoup mieux mise en œuvre, ce qui entraîne un temps de réponse moyen globalement plus stable tout en gérant plus de données que le cache ne peut en gérer.

Certaines analyses comparatives ont révélé que Redis, dans notre cas, fonctionne très mal. Je pense que cela a à voir avec de nombreuses variables:

• type de matériel sur lequel vous exécutez Redis
• types de données que vous stockez
• quantité de gets et sets
• le degré de concurrence de votre application
• avez-vous besoin d'un stockage de structure de données

Personnellement, je ne partage pas le point de vue des auteurs de Redis sur la concurrence et le multithreading.

Un autre avantage est qu'il peut être très clair comment se comportera memcache dans un scénario de mise en cache, tandis que redis est généralement utilisé comme une banque de données persistante, bien qu'il puisse être configuré pour se comporter comme memcached aka expulsant les éléments les moins récemment utilisés lorsqu'il atteint le maximum capacité.

Certaines applications sur lesquelles j'ai travaillé utilisent à la fois juste pour clarifier comment nous voulons que les données se comportent - des trucs dans memcache, nous écrivons du code pour gérer les cas où ils ne sont pas là - des trucs dans redis, nous comptons sur leur présence .

En dehors de cela, Redis est généralement considéré comme supérieur pour la plupart des cas d'utilisation étant plus riche en fonctionnalités et donc flexible.

Ce ne serait pas faux, si nous disons que redis est une combinaison de (cache + structure de données) alors que memcached n'est qu'un cache.

Un test très simple pour définir et obtenir 100k clés et valeurs uniques contre redis-2.2.2 et memcached. Les deux s'exécutent sur Linux VM (CentOS) et mon code client (collé ci-dessous) s'exécute sur le bureau Windows.

Redis

• Le temps nécessaire pour stocker 100 000 valeurs est = 18954 ms

• Le temps nécessaire pour charger 100000 valeurs est = 18328 ms

Memcached

• Le temps nécessaire pour stocker 100 000 valeurs est = 797 ms

• Le temps nécessaire pour récupérer 100 000 valeurs est = 38984 ms

Jedis jed = new Jedis("localhost", 6379);
int count = 100000;
long startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  jed.set("u112-"+i, "v51"+i);
}
long endTime = System.currentTimeMillis();
System.out.println("Time taken to store "+ count + " values is ="+(endTime-startTime)+"ms");

startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  client.get("u112-"+i);
}
endTime = System.currentTimeMillis();
System.out.println("Time taken to retrieve "+ count + " values is ="+(endTime-startTime)+"ms");

Une différence majeure qui n'a pas été soulignée ici est que Memcache a une limite de mémoire supérieure à tout moment, alors que Redis ne l'a pas par défaut (mais peut être configuré pour). Si vous souhaitez toujours stocker une clé / valeur pendant un certain temps (et ne jamais l'expulser en raison d'une mémoire insuffisante), vous souhaitez utiliser Redis. Bien sûr, vous risquez également de manquer de mémoire ...

La principale raison qui reste est la spécialisation.

Redis peut faire beaucoup de choses différentes et un effet secondaire de cela est que les développeurs peuvent commencer à utiliser beaucoup de ces différents jeux de fonctionnalités sur la même instance. Si vous utilisez la fonction LRU de Redis pour un cache avec un stockage de données dur qui n'est PAS LRU, il est tout à fait possible de manquer de mémoire.

Si vous allez configurer une instance Redis dédiée à utiliser UNIQUEMENT en tant qu'instance LRU pour éviter ce scénario particulier, il n'y a pas vraiment de raison impérieuse d'utiliser Redis sur Memcached.

Si vous avez besoin d'un cache LRU fiable "ne tombe jamais en panne" ... Memcached fera l'affaire car il est impossible qu'il manque de mémoire par conception et la fonctionnalité de spécialisation empêche les développeurs d'essayer d'en faire quelque chose qui pourrait mettre cela en danger. Séparation simple des préoccupations.

Memcached sera plus rapide si vous êtes intéressé par les performances, même parce que Redis implique la mise en réseau (appels TCP). En interne, Memcache est plus rapide.

Redis a plus de fonctionnalités comme cela a été mentionné par d'autres réponses.

Nous pensions que Redis était un décollage de charge pour notre projet au travail. Nous pensions qu'en utilisant un module nginxappelé HttpRedis2Moduleou quelque chose de similaire, nous aurions une vitesse impressionnante, mais lorsque nous testons avec AB-test, nous nous trompons.

Peut-être que le module était mauvais ou notre mise en page mais c'était une tâche très simple et c'était encore plus rapide de prendre des données avec php puis de les mettre dans MongoDB. Nous utilisons APC comme système de mise en cache et avec ce php et MongoDB. C'était beaucoup plus rapide que le nginxmodule Redis.

Mon conseil est de le tester vous-même, le faire vous montrera les résultats pour votre environnement. Nous avons décidé que l'utilisation de Redis n'était pas nécessaire dans notre projet car cela n'aurait aucun sens.

Redis est meilleur.

Les avantages de Redissont,

1. Il a beaucoup d'options de stockage de données telles que chaîne, ensembles, ensembles triés, hachages, bitmaps
2. Persistance du disque des enregistrements
3. LUAPrise en charge des procédures stockées ( scripts)
4. Peut agir comme un courtier de messages en utilisant PUB / SUB

Considérant qu'il Memcaches'agit d'un système de type cache de valeur de clé en mémoire.

1. Pas de prise en charge pour différents types de stockage de données comme les listes, les ensembles comme dans redis.
2. Le principal inconvénient est que Memcache n'a aucune persistance de disque.

Eh bien, j'ai surtout utilisé les deux avec mes applications, Memcache pour mettre en cache les sessions et redis pour les objets de requêtes doctrine / orm. En termes de performances, les deux sont presque identiques.

Voici le très bon article / différences fournis par Amazon

Redis est un gagnant clair comparé à memcached.

Un seul point positif pour Memcached Il est multithread et rapide. Redis possède de nombreuses fonctionnalités intéressantes et est très rapide, mais limité à un cœur.

Grands points sur Redis, qui ne sont pas pris en charge dans Memcached

• Instantanés - L'utilisateur peut prendre un instantané du cache Redis et persister sur le stockage secondaire à tout moment.
• Prise en charge intégrée de nombreuses structures de données comme Set, Map, SortedSet, List, BitMaps, etc.
• Prise en charge des scripts Lua dans redis