J'utilise memcached pour la mise en cache dans mon application Rails 3 via l' Rails.cache
interface simple et j'aimerais maintenant faire un traitement de travail en arrière-plan avec redis et resque.
Je pense qu'ils sont suffisamment différents pour justifier l'utilisation des deux. Sur heroku cependant, il y a des frais distincts pour utiliser à la fois memcached et redis. Est-il judicieux d'utiliser les deux ou devrais-je migrer simplement vers Redis?
J'aime utiliser Memcached pour la mise en cache car les clés les moins récemment utilisées sont automatiquement expulsées du cache et je n'ai pas besoin que les données du cache persistent. Redis est principalement nouveau pour moi, mais je comprends qu'il est persistant par défaut et que les clés n'expirent pas automatiquement du cache.
EDIT: Je voulais juste être plus clair avec ma question. Je sais qu'il est possible d'utiliser uniquement Redis au lieu des deux. Je suppose que je veux juste savoir s'il y a des inconvénients spécifiques à le faire? Compte tenu à la fois de la mise en œuvre et de l'infrastructure, y a-t-il des raisons pour lesquelles je ne devrais pas simplement utiliser Redis? (Ie, Memcached est-il plus rapide pour une simple mise en cache?) Je n'ai rien trouvé de définitif de toute façon.
la source
Réponses:
En supposant que la migration de memcached vers redis pour la mise en cache que vous faites déjà est assez facile, j'opterais avec redis uniquement pour garder les choses simples.
Dans Redis, la persistance est facultative, vous pouvez donc l'utiliser un peu comme Memcached si c'est ce que vous voulez. Vous pouvez même trouver que rendre votre cache persistant est utile pour éviter de nombreux échecs de cache après un redémarrage. L'expiration est également disponible - l'algorithme est un peu différent de memcached, mais pas assez pour avoir de l'importance dans la plupart des cas - voir http://redis.io/commands/expire pour plus de détails.
la source
Je suis l'auteur de redis-store , il n'est pas nécessaire d'utiliser directement les commandes Redis, utilisez simplement l'
:expires_in
option comme celle-ci:ActionController::Base.cache_store = :redis_store, :expires_in => 5.minutes
L'avantage d'utiliser Redis est la solidité, et avec ma gemme, c'est que vous avez déjà des magasins pour
Rack::Cache
,Rails.cache
ouI18n
.la source
:expires_in
. Pouvez-vous m'aider?:expires_in
redis_store, reportez-vous à stackoverflow.com/questions/20907247/…J'ai vu quelques grands sites de rails qui utilisent à la fois Memcached et Redis. Memcached est utilisé pour les choses éphémères qui sont agréables à garder en mémoire mais qui peuvent être perdues / régénérées si nécessaire, et Redis pour le stockage persistant. Les deux sont utilisés pour soulager la base de données principale pour les opérations lourdes de lecture / écriture.
Plus de détails:
Memcached: utilisé pour la mise en cache de page / fragment / réponse et il est possible d'atteindre la limite de mémoire sur Memcached car il LRU (le moins récemment utilisé) expirera les anciens éléments et gardera fréquemment les clés accédées au chaud en mémoire. Il est important que tout ce qui se trouve dans Memcached puisse être recréé à partir de la base de données si nécessaire (ce n'est pas votre seule copie). Mais vous pouvez continuer à y déposer des éléments, et Memcached déterminera ceux qui sont les plus utilisés et les gardera en mémoire. Vous n'avez pas à vous soucier de supprimer des éléments de Memcached.
redis: vous l'utilisez pour des données que vous ne voudriez pas perdre et qui sont suffisamment petites pour tenir en mémoire. Cela inclut généralement les tâches resque / sidekiq, les compteurs de limitation de débit, les résultats de test fractionnés ou tout ce que vous ne voudriez pas perdre / recréer. Vous ne voulez pas dépasser la limite de mémoire ici, vous devez donc faire un peu plus attention à ce que vous stockez et nettoyez plus tard.
Redis commence à souffrir de problèmes de performances une fois qu'il dépasse sa limite de mémoire (corrigez-moi si je me trompe). Il est possible de résoudre ce problème en configurant Redis pour qu'il agisse comme Memcached et LRU expire, afin qu'il n'atteigne jamais sa limite de mémoire. Mais vous ne voudriez pas faire cela avec tout ce que vous gardez dans Redis, comme les emplois de resque. Ainsi, au lieu que les gens conservent souvent la valeur par défaut, Rails.cache est configuré pour utiliser Memcached (en utilisant le
dalli
gem). Et puis ils gardent une variable globale $ redis = ... séparée pour faire des opérations redis.# in config/application.rb config.cache_store = :dalli_store # memcached # in config/initializers/redis.rb $redis = $redis = Redis.connect(url: ENV['REDIS_URL'])
Il pourrait y avoir un moyen simple de faire tout cela dans Redis - peut-être en ayant deux instances Redis distinctes, une avec une limite de mémoire dure LRU, similaire à Memcache, et une autre pour le stockage persistant? Je n'ai pas vu cela utilisé, mais je suppose que ce serait faisable.
la source
J'envisagerais de vérifier ma réponse à ce sujet:
Rails et mise en cache, est-il facile de basculer entre Memcache et Redis?
Essentiellement, grâce à mon expérience, je recommanderais de les garder séparés: memcached pour la mise en cache et redis pour les structures de données et un stockage plus persistant
la source
J'ai demandé à l'équipe de Redis Labs (qui fournit les modules complémentaires Memcached Cloud et Redis Cloud ) quel produit ils recommanderaient pour la mise en cache Rails. Ils ont déclaré qu'en général, ils recommanderaient Redis Cloud, que Memcached Cloud est principalement proposé à des fins héritées, et ont souligné que leur service Memcached Cloud est en fait construit sur Redis Cloud.
la source
Je ne sais pas pour quoi vous les utilisez, mais en fait, utiliser les deux peut vous donner un avantage en termes de performances: Memcached a de bien meilleures performances sur plusieurs cœurs que Redis, donc mettre en cache les données les plus importantes avec Memcached et conserver le reste dans Redis , tirant parti de ses capacités de base de données, pourrait augmenter les performances.
la source