caching - benchmark - Memcached vs Redis?

redis cache (17)

Estamos usando una aplicación web de Ruby con el servidor Redis para el almacenamiento en caché. ¿Hay un punto para probar Memcached lugar?

¿Qué nos dará un mejor rendimiento? ¿Alguna ventaja o desventaja entre Redis y Memcached?

Puntos a considerar:

Velocidad de lectura / escritura.
Uso de memoria.
Volcado de E / S del disco.
Escalada.

Resumen (TL; DR)

Actualizado el 3 de junio de 2017

Redis es más poderoso, más popular y está mejor soportado que memcached. Memcached solo puede hacer una pequeña fracción de lo que puede hacer Redis. Redis es mejor incluso cuando sus características se superponen.

Para cualquier cosa nueva, usa Redis.

Memcached vs Redis: Comparación directa

Ambas herramientas son potentes, rápidas, almacenes de datos en memoria que son útiles como caché. Ambos pueden ayudar a acelerar su aplicación al almacenar en caché los resultados de la base de datos, los fragmentos HTML o cualquier otra cosa que pueda resultar costosa de generar.

Puntos a considerar

Cuando se usan para lo mismo, aquí es cómo se comparan con los "Puntos a considerar" de la pregunta original:

Velocidad de lectura / escritura : Ambos son extremadamente rápidos. Los puntos de referencia varían según la carga de trabajo, las versiones y muchos otros factores, pero generalmente muestran que redis es tan rápido o casi tan rápido como memcached. Recomiendo redis, pero no porque memcached sea lento. No es.
Uso de memoria : Redis es mejor.
- memcached: especifica el tamaño de la memoria caché y al insertar elementos, el demonio crece rápidamente hasta un poco más que este tamaño. Nunca hay realmente una manera de reclamar nada de ese espacio, a menos que se reinicie memcached. Todas las claves podrían estar caducadas, se podría vaciar la base de datos y aún se usaría la porción completa de RAM con la que se configuró.
- redis: establecer un tamaño máximo depende de usted. Redis nunca usará más de lo que debe y le devolverá la memoria que ya no usa.
- Almacené 100,000 ~ 2KB cadenas (~ 200MB) de oraciones al azar en ambos. El uso de memoria RAM Memcached creció a ~ 225MB. El uso de Redis RAM creció a ~ 228MB. Después de vaciar ambos, redis se redujo a ~ 29MB y memcached se mantuvo en ~ 225MB. Son igualmente eficientes en la forma en que almacenan los datos, pero solo uno es capaz de recuperarlos.
Volcado de E / S del disco : una ganancia clara para redis, ya que lo hace de forma predeterminada y tiene una persistencia muy configurable. Memcached no tiene mecanismos para volcar en disco sin herramientas de terceros.
Escalado : ambos le brindan mucho espacio para la cabeza antes de que necesite más de una sola instancia como caché. Redis incluye herramientas para ayudarte a ir más allá de eso, mientras que memcached no lo hace.

memcached

Memcached es un servidor de caché volátil simple. Le permite almacenar pares clave / valor donde el valor se limita a ser una cadena de hasta 1 MB.

Es bueno en esto, pero eso es todo lo que hace. Puede acceder a esos valores por su clave a una velocidad extremadamente alta, a menudo saturando la red disponible o incluso el ancho de banda de la memoria.

Cuando reinicia memcached sus datos se han ido. Esto está bien para un caché. No deberías guardar nada importante allí.

Si necesita un alto rendimiento o una alta disponibilidad, hay herramientas, productos y servicios de terceros disponibles.

Redis

Redis puede hacer los mismos trabajos que memcached, y puede hacerlo mejor.

Redis también puede actuar como caché . Puede almacenar pares clave / valor también. En redis pueden llegar incluso a 512MB.

Puede desactivar la persistencia y, por suerte, también perderá sus datos al reiniciar. Si quieres que tu caché sobreviva al reinicio, también te permite hacerlo. De hecho, ese es el defecto.

También es súper rápido, a menudo limitado por el ancho de banda de la red o de la memoria.

Si una instancia de redis / memcached no es suficiente para su carga de trabajo, redis es la opción clara. Redis incluye soporte de clúster y viene con herramientas de alta disponibilidad ( redis-sentinel ) directamente "en la caja". En los últimos años, redis también se ha convertido en el líder claro en herramientas de terceros. Compañías como Redis Labs, Amazon y otras ofrecen muchas herramientas y servicios útiles para redis. El ecosistema alrededor de redis es mucho más grande. El número de implementaciones a gran escala ahora es probablemente mayor que para memcached.

El Superconjunto Redis

Redis es más que un caché. Es un servidor de estructura de datos en memoria. A continuación, encontrará una descripción general rápida de las cosas que Redis puede hacer más allá de ser una simple caché clave / valor como memcached. La mayoría de las características de redis son cosas que memcached no puede hacer.

Documentación

Redis está mejor documentado que memcached. Si bien esto puede ser subjetivo, parece ser cada vez más cierto todo el tiempo.

redis.io es un recurso fantástico de fácil navegación. Te permite probar redis en el navegador e incluso te da ejemplos interactivos en vivo con cada comando en los documentos.

Ahora hay 2x tantos resultados de para redis como memcached. 2 veces más resultados de Google. Más ejemplos fácilmente accesibles en más idiomas. Desarrollo más activo. Desarrollo de clientes más activo. Es posible que estas medidas no signifiquen mucho de manera individual, pero en combinación pintan una imagen clara de que el soporte y la documentación para el redis es mayor y mucho más actualizado.

Persistence

Por defecto, redis persiste sus datos en el disco utilizando un mecanismo llamado snapshotting. Si tiene suficiente RAM disponible, puede escribir todos sus datos en el disco casi sin degradación del rendimiento. ¡Es casi gratis!

En el modo de instantánea, existe la posibilidad de que una caída repentina pueda ocasionar una pequeña cantidad de datos perdidos. Si necesita asegurarse de que nunca se pierda ningún dato, no se preocupe, redis también está allí con el modo AOF (Anexar solo archivo). En este modo de persistencia, los datos se pueden sincronizar con el disco a medida que se escriben. Esto puede reducir el rendimiento máximo de escritura a lo rápido que puede escribir su disco, pero aún así debería ser bastante rápido.

Hay muchas opciones de configuración para ajustar la persistencia si es necesario, pero los valores predeterminados son muy razonables. Estas opciones facilitan la configuración de redis como un lugar seguro y redundante para almacenar datos. Es una base de datos real .

Muchos tipos de datos

Memcached está limitado a cadenas, pero Redis es un servidor de estructura de datos que puede ofrecer muchos tipos de datos diferentes. También proporciona los comandos que necesita para aprovechar al máximo esos tipos de datos.

Cuerdas ( commands )

Texto simple o valores binarios que pueden tener hasta 512 MB de tamaño. Este es el único tipo de datos redis y memcached share, aunque las cadenas memcached están limitadas a 1MB.

Redis le brinda más herramientas para aprovechar este tipo de datos al ofrecer comandos para operaciones a nivel de bits, manipulación a nivel de bits, soporte de incremento / decremento de punto flotante, consultas de rango y operaciones de varias teclas. Memcached no soporta nada de eso.

Las cadenas son útiles para todo tipo de casos de uso, por lo que memcached es bastante útil solo con este tipo de datos.

Hashes ( commands )

Los hash son una especie de almacén de valores clave dentro de un almacén de valores clave. Se asignan entre campos de cadena y valores de cadena. Los mapas de valor de campo que usan un hash son un poco más eficientes en el espacio que los mapas de valor de clave que usan cadenas regulares.

Los hash son útiles como espacio de nombres, o cuando desea agrupar lógicamente muchas claves. Con un hash, puede capturar a todos los miembros de manera eficiente, vencer a todos los miembros, eliminar a todos los miembros, etc. Ideal para cualquier caso de uso en el que tenga varios pares de clave / valor que deba agrupar.

Un ejemplo de uso de un hash es para almacenar perfiles de usuario entre aplicaciones. Un hash redis almacenado con el ID de usuario como la clave le permitirá almacenar tantos bits de datos sobre un usuario como sea necesario mientras los mantiene almacenados bajo una sola clave. La ventaja de usar un hash en lugar de serializar el perfil en una cadena es que puede tener diferentes aplicaciones de lectura / escritura en diferentes campos dentro del perfil del usuario sin tener que preocuparse por una aplicación que anule los cambios realizados por otros (lo que puede suceder si serializa el pasado). datos).

Listas ( commands )

Las listas redis son colecciones ordenadas de cuerdas. Están optimizados para insertar, leer o eliminar valores de la parte superior o inferior (también conocido como izquierda o derecha) de la lista.

Redis proporciona muchos commands para aprovechar las listas, incluidos los comandos para empujar / abrir elementos, empujar / abrir entre listas, truncar listas, realizar consultas de rango, etc.

Las listas hacen grandes colas duraderas, atómicas. Estos funcionan bien para colas de trabajos, registros, buffers y muchos otros casos de uso.

Conjuntos ( commands )

Los conjuntos son colecciones desordenadas de valores únicos. Están optimizados para permitirle verificar rápidamente si hay un valor en el conjunto, agregar / eliminar valores rápidamente y medir la superposición con otros conjuntos.

Estos son excelentes para cosas como listas de control de acceso, rastreadores de visitantes únicos y muchas otras cosas. La mayoría de los lenguajes de programación tienen algo similar (usualmente llamado Conjunto). Esto es así, solo se distribuye.

Redis proporciona varios commands para gestionar conjuntos. Los obvios como agregar, eliminar y verificar el conjunto están presentes. Por lo tanto, los comandos menos obvios, como hacer estallar / leer un elemento aleatorio y los comandos para realizar uniones e intersecciones con otros conjuntos.

Conjuntos ordenados ( commands )

Los conjuntos ordenados también son colecciones de valores únicos. Estos, como su nombre lo indica, están ordenados. Se ordenan por puntuación, luego lexicográficamente.

Este tipo de datos está optimizado para búsquedas rápidas por puntuación. Obtener el rango de valores más alto, más bajo o cualquier rango intermedio es extremadamente rápido.

Si agrega usuarios a un conjunto ordenado junto con su puntuación más alta, tiene usted mismo una tabla de clasificación perfecta. A medida que ingresan los nuevos puntajes altos, simplemente agréguelos nuevamente al conjunto con su puntaje más alto y reordenará su tabla de líderes. También es ideal para realizar un seguimiento de la última vez que los usuarios visitaron y quién está activo en su aplicación.

El almacenamiento de valores con la misma puntuación hace que se ordenen lexicográficamente (piense alfabéticamente). Esto puede ser útil para cosas como funciones de autocompletar.

Muchos de los commands conjuntos ordenados son similares a los comandos de conjuntos, a veces con un parámetro de puntuación adicional. También se incluyen los comandos para la gestión de puntuaciones y consultas por puntuación.

Geo

Redis tiene varios commands para almacenar, recuperar y medir datos geográficos. Esto incluye consultas de radio y distancias de medición entre puntos.

Técnicamente, los datos geográficos en redis se almacenan dentro de conjuntos ordenados, por lo que este no es un tipo de datos verdaderamente separado. Es más una extensión sobre conjuntos ordenados.

Bitmap y HyperLogLog

Al igual que Geo, estos no son tipos de datos completamente separados. Estos son comandos que le permiten tratar los datos de cadena como si fuera un mapa de bits o un hiperloglog.

Los mapas de bits son para lo que son los operadores de nivel de bits a los que hice referencia en Strings . Este tipo de datos fue el elemento básico para el reciente proyecto de arte colaborativo de reddit: r/Place .

HyperLogLog le permite utilizar una cantidad de espacio constante extremadamente pequeña para contar valores únicos casi ilimitados con una precisión sorprendente. Con solo ~ 16KB, podría contar de manera eficiente el número de visitantes únicos a su sitio, incluso si ese número es de millones.

Transacciones y Atomicidad

Los comandos en redis son atómicos, lo que significa que puede estar seguro de que tan pronto como escriba un valor para redis, ese valor será visible para todos los clientes conectados a redis. No hay que esperar a que ese valor se propague. Técnicamente, memcached también es atómico, pero al volver a agregar toda esta funcionalidad más allá de memcached, vale la pena señalar y, de alguna manera, es impresionante que todos estos tipos de datos y características adicionales también sean atómicos.

Si bien no es exactamente lo mismo que las transacciones en bases de datos relacionales, redis también tiene transactions que usan "bloqueo optimista" ( WATCH / MULTI / EXEC ).

Tubería

Redis proporciona una característica llamada '' pipelining ''. Si tiene muchos comandos redis que desea ejecutar, puede usar la canalización para enviarlos a redis todo a la vez en lugar de uno a la vez.

Normalmente, cuando ejecuta un comando para redis o memcached, cada comando es un ciclo de solicitud / respuesta separado. Con la canalización, redis puede almacenar varios comandos y ejecutarlos todos a la vez, respondiendo con todas las respuestas a todos sus comandos en una sola respuesta.

Esto puede permitirle lograr un rendimiento aún mayor en la importación masiva u otras acciones que involucran muchos comandos.

Pub / Sub

Redis tiene commands dedicados a la funcionalidad pub / sub , lo que permite que redis actúe como un transmisor de mensajes de alta velocidad. Esto permite que un solo cliente publique mensajes a muchos otros clientes conectados a un canal.

Redis hace pub / sub, así como casi cualquier herramienta. Los intermediarios de mensajes dedicados como RabbitMQ pueden tener ventajas en ciertas áreas, pero como el mismo servidor también puede proporcionarle colas duraderas y otras estructuras de datos que probablemente necesite su pub / sub cargas de trabajo, a menudo Redis será la mejor y más sencilla herramienta. para el trabajo.

Lua Scripting

Puede pensar en scripts de lua como los propios procedimientos almacenados o SQL de redis. Es más y menos que eso, pero la analogía en su mayoría funciona.

Tal vez usted tiene cálculos complejos que desea rediscribir. Tal vez no pueda permitirse que sus transacciones se restablezcan y necesite garantías que cada paso de un proceso complejo suceda de forma atómica. Estos problemas y muchos más se pueden resolver con scripts lua.

La secuencia de comandos completa se ejecuta de forma atómica, por lo que si puede ajustar su lógica en una secuencia de comandos lua, a menudo puede evitar entrometerse con transacciones de bloqueo optimistas.

Escalada

Como se mencionó anteriormente, redis incluye soporte integrado para la agrupación en clústeres y se incluye con su propia herramienta de alta disponibilidad llamada redis-sentinel .

Conclusión

Sin dudarlo, recomendaría redis sobre memcached para cualquier proyecto nuevo, o proyectos existentes que aún no usen memcached.

Lo anterior puede parecer que no me gusta memcached. Al contrario: es una herramienta potente, simple, estable, madura y endurecida. Incluso hay algunos casos de uso donde es un poco más rápido que redis. Me encanta memcached Simplemente no creo que tenga mucho sentido para el desarrollo futuro.

Redis hace todo lo que hace memcached, a menudo mejor. Cualquier ventaja de rendimiento para memcached es menor y específica de la carga de trabajo. También hay cargas de trabajo para las que redis será más rápido, y muchas más cargas de trabajo que pueden hacer redis que memcached simplemente no puede. Las pequeñas diferencias de rendimiento parecen ser menores en la funcionalidad de la brecha gigante y el hecho de que ambas herramientas sean tan rápidas y eficientes que muy bien pueden ser la última pieza de su infraestructura, siempre tendrá que preocuparse por la escala.

Solo hay un escenario donde memcached tiene más sentido: donde memcached ya está en uso como caché. Si ya está guardando en caché con memcached, continúe usándolo, si satisface sus necesidades. Es probable que no valga la pena el esfuerzo de pasar a redis y si va a usar redis solo para el almacenamiento en caché, puede que no ofrezca el beneficio suficiente para que valga la pena su tiempo. Si memcached no satisface sus necesidades, entonces probablemente debería pasar a redis. Esto es cierto si necesita escalar más allá de memcached o si necesita funcionalidad adicional.

Bueno, principalmente utilicé ambas aplicaciones con mis aplicaciones, Memcache para almacenar en caché las sesiones y volver a buscar objetos de consultas doctrinales / orm. En términos de rendimiento ambos son casi iguales.

La mayor razón restante es la especialización.

Redis puede hacer muchas cosas diferentes y uno de los efectos secundarios es que los desarrolladores pueden comenzar a usar muchos de esos conjuntos de características diferentes en la misma instancia. Si está utilizando la función LRU de Redis para un caché junto con el almacenamiento de datos de disco duro que NO es LRU, es completamente posible quedarse sin memoria.

Si va a configurar una instancia de Redis dedicada para que se use SOLAMENTE como una instancia de LRU para evitar ese escenario en particular, entonces realmente no hay ninguna razón convincente para usar Redis sobre Memcached.

Si necesita una memoria caché LRU "nunca baja" confiable ... Memcached se ajustará a la cuenta ya que es imposible que se quede sin memoria por diseño y la funcionalidad de especialización evita que los desarrolladores intenten que sea algo que pueda poner en peligro eso. Separación simple de preocupaciones.

Memcached es bueno para ser un simple almacén de clave / valor y es bueno para hacer key => STRING. Esto lo hace realmente bueno para el almacenamiento de sesión.

Redis es bueno haciendo clave => SOME_OBJECT.

Realmente depende de lo que vayas a poner allí. Mi entendimiento es que en términos de rendimiento son bastante parejos.

También buena suerte para encontrar cualquier punto de referencia objetivo, si encuentra alguna amablemente envíenlos a mi manera.

Memcached es multiproceso y rápido.

Redis tiene muchas características y es muy rápido, pero está completamente limitado a un núcleo, ya que se basa en un bucle de eventos.

Utilizamos ambos. Memcached se utiliza para almacenar objetos en caché, principalmente para reducir la carga de lectura en las bases de datos. Redis se utiliza para cosas como conjuntos ordenados que son útiles para enrollar datos de series de tiempo.

Memcached será más rápido si está interesado en el rendimiento, solo porque Redis involucra redes (llamadas TCP). También internamente Memcache es más rápido.

Redis tiene más características, como lo mencionaron otras respuestas.

No estaría mal si decimos que redis es una combinación de (caché + estructura de datos) mientras que memcached es solo un caché.

Otra ventaja es que puede ser muy claro cómo se va a comportar memcache en un escenario de almacenamiento en caché, mientras que redis se usa generalmente como un almacén de datos persistente, aunque se puede configurar para que se comporte como memcached, al mismo tiempo que desaloja los elementos usados menos recientemente cuando alcanza el máximo capacidad.

Algunas aplicaciones en las que he trabajado usan ambas para aclarar cómo pretendemos que se comporten los datos: cosas en memcache, escribimos código para manejar los casos en los que no existen, cosas en redis, confiamos en que estén allí .

Aparte de eso, Redis generalmente se considera superior, ya que la mayoría de los casos de uso son más ricos en características y, por lo tanto, flexibles.

Pensamos en Redis como un despegue de carga para nuestro proyecto en el trabajo. Pensamos que al usar un módulo en nginx llamado HttpRedis2Module o algo similar tendríamos una velocidad asombrosa, pero al probar con la prueba AB, se demuestra que estamos equivocados.

Tal vez el módulo era malo o nuestro diseño, pero era una tarea muy simple e incluso era más rápido tomar datos con php y luego meterlos en MongoDB. Estamos usando APC como sistema de almacenamiento en caché y con ese php y MongoDB. Era mucho más rápido que el módulo Redis de nginx.

Mi consejo es que lo pruebes tú mismo, ya que esto te mostrará los resultados para tu entorno. Decidimos que usar Redis era innecesario en nuestro proyecto ya que no tendría ningún sentido.

Prueba. Ejecutar algunos puntos de referencia simples. Durante mucho tiempo me consideré un rinoceronte de la vieja escuela, ya que usé principalmente memcached y consideré a Redis el nuevo niño.

Con mi empresa actual, Redis fue utilizado como el caché principal. Cuando descubrí algunas estadísticas de rendimiento y simplemente comencé a probar, Redis era, en términos de rendimiento, comparable o mínimamente más lento que MySQL.

Memcached, aunque simplista, sacó del agua a Redis totalmente . Se escala mucho mejor:

para valores mayores (cambio requerido en el tamaño de la losa, pero trabajado)
para múltiples solicitudes concurrentes

Además, en mi opinión, la política de desalojo de memcached se implementa mucho mejor, lo que da como resultado un tiempo de respuesta promedio en general más estable a la vez que se manejan más datos de los que puede manejar la caché.

Algunas evaluaciones comparativas revelaron que Redis, en nuestro caso, se desempeña muy mal. Creo que esto tiene que ver con muchas variables:

tipo de hardware que ejecuta Redis en
tipos de datos que almacena
cantidad de entradas y salidas
¿Qué tan concurrente es tu aplicación?
¿Necesita almacenamiento de estructura de datos?

Personalmente, no comparto la opinión que tienen los autores de Redis sobre la concurrencia y el multihilo.

Redis es mejor Los Pros de Redis son,

1.It has a lot of data storage options such as string , sets , sorted sets , hashes , bitmaps 2.Disk Persistence of records 3.Stored Procedure (LUA acripting) support 4.Can act as a Message Broker using PUB/SUB

Considerando que Memcache es un sistema de tipo de caché de valor de clave en memoria.

No hay soporte para varios almacenes de tipos de datos como listas, conjuntos como en redis.
La mayor desventaja es que Memcache no tiene persistencia de disco.

Si no le molesta un estilo de escritura grosero, vale la pena leer Redis vs Memcached en el blog de Systoilet desde el punto de vista de la usabilidad, pero asegúrese de leer los comentarios y respuestas en los comentarios antes de sacar conclusiones sobre el rendimiento. hay algunos problemas metodológicos (pruebas de bucle de ocupado de un solo hilo), y Redis ha realizado algunas mejoras desde que el artículo también fue escrito.

Y ningún enlace de referencia está completo sin confundir un poco las cosas, así que también revise algunos puntos de referencia conflictivos en el LiveJournal de Dormondo y el blog de Antirez .

Editar - como señala Antirez, el análisis de Systoilet es más bien mal concebido. Incluso más allá del déficit de un solo subproceso, gran parte de la disparidad de rendimiento en esos puntos de referencia puede atribuirse a las bibliotecas cliente en lugar del rendimiento del servidor. Los puntos de referencia de Antirez Weblog presentan, de hecho, una comparación mucho más manzanas con manzanas (con la misma boca).

Tuve la oportunidad de usar tanto memcached como redis juntos en el proxy de almacenamiento en caché en el que he trabajado, permítame compartirle exactamente dónde he usado qué y la razón detrás del mismo ...

Redis>

1) Se utiliza para indexar el contenido de la memoria caché, sobre el clúster. Tengo más de mil millones de claves en grupos redis, los tiempos de respuesta de redis son bastante menos estables.

2) Básicamente, es un almacén de clave / valor, por lo que en cualquier aplicación que tenga algo similar, uno puede usar redis con mucha molestia.

3) Redisar la persistencia, la conmutación por error y la copia de seguridad (AOF) facilitarán su trabajo.

Memcache>

1) sí, una memoria optimizada que puede usarse como caché. Lo utilicé para almacenar el contenido del caché al que se accede con mucha frecuencia (con 50 aciertos / segundo) con un tamaño inferior a 1 MB.

2) Asigné solo 2GB de 16 GB para memcached que también cuando mi tamaño de contenido único era> 1MB.

3) A medida que el contenido crece cerca de los límites, ocasionalmente he observado tiempos de respuesta más altos en las estadísticas (no en el caso de redis).

Si solicita la experiencia general, Redis es mucho más verde, ya que es fácil de configurar, muy flexible y con características robustas y estables.

Además, hay un resultado de evaluación comparativa disponible en este link , a continuación se muestran algunos puntos destacados de la misma,

¡¡Espero que esto ayude!!

Una diferencia importante que no se ha señalado aquí es que Memcache tiene un límite de memoria superior en todo momento, mientras que Redis no lo hace de manera predeterminada (pero se puede configurar para). Si siempre desea almacenar una clave / valor durante un período de tiempo determinado (y nunca desalojarlo debido a la poca memoria) desea ir con Redis. Por supuesto, también corre el riesgo de quedarse sin memoria ...

Una prueba muy simple para establecer y obtener claves y valores únicos de 100 k contra redis-2.2.2 y memcached. Ambos se ejecutan en Linux linux (CentOS) y mi código de cliente (pegado a continuación) se ejecuta en el escritorio de Windows.

Redis

El tiempo necesario para almacenar 100000 valores es = 18954 ms
El tiempo necesario para cargar 100000 valores es = 18328ms.

Memcached

El tiempo que se tarda en almacenar 100000 valores es = 797 ms
El tiempo necesario para recuperar 100000 valores es = 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");

Usa redis si

Necesita eliminar / caducar de forma selectiva los elementos de la memoria caché. (Necesitas esto)
Necesita la capacidad de consultar claves de un tipo particular. eq. ''blog1: mensajes: *'', ''blog2: categorías: xyz: mensajes: *''. ¡Oh si! esto es muy importante. Use esto para invalidar ciertos tipos de elementos almacenados en caché selectivamente. También puede usar esto para invalidar el caché de fragmentos, el caché de páginas, solo objetos AR de un tipo dado, etc.
Persistencia (Necesitará esto también, a menos que esté de acuerdo con que su caché tenga que calentarse después de cada reinicio. Muy esencial para los objetos que rara vez cambian)

Usar memcached si

¡Memcached te da la cabeza!
umm ... ¿agrupación? meh Si vas a llegar tan lejos, usa Varnish y Redis para almacenar en caché fragmentos y objetos AR.

Desde mi experiencia he tenido una estabilidad mucho mejor con Redis que con Memcached.

Esto es demasiado largo para ser publicado como un comentario a una respuesta ya aceptada, así que lo pongo como una respuesta por separado.

Una cosa que también debe considerar es si espera tener un límite de memoria superior dura en su instancia de caché.

Dado que redis es una base de datos nosql con toneladas de funciones y el almacenamiento en caché es solo una de las opciones para las que se puede usar, asigna la memoria a medida que la necesita: cuantos más objetos coloque, más memoria utilizará. La opción maxmemory no impone estrictamente el uso del límite de memoria superior. A medida que trabaja con el caché, las claves se desalojan y caducan; lo más probable es que sus claves no sean todas del mismo tamaño, por lo que se produce una fragmentación de la memoria interna.

De forma predeterminada, redis utiliza el asignador de memoria jemalloc , que hace todo lo posible por ser compacto y rápido, pero es un asignador de memoria de propósito general y no puede mantenerse al día con muchas asignaciones y depuración de objetos que ocurren a una alta velocidad. Debido a esto, en algunos patrones de carga, el proceso redis aparentemente puede perder memoria debido a la fragmentación interna. Por ejemplo, si tiene un servidor con 7 Gb de RAM y desea usar redis como caché LRU no persistente, puede encontrar que el proceso de maxmemory con maxmemory establecido a 5Gb con el tiempo usaría más y más memoria, llegando finalmente al límite de RAM total hasta que el asesino fuera de memoria interfiere.

memcached se adapta mejor al escenario descrito anteriormente, ya que administra su memoria de una manera completamente diferente. memcached asigna una gran parte de la memoria, todo lo que necesitará, y luego administra esta memoria por sí misma, utilizando su propio asignador de losa implementado. Además, memcached se esfuerza por mantener baja la fragmentación interna, ya que en realidad utiliza el algoritmo LRU por bloque , cuando los desalojos de LRU se realizan considerando el tamaño del objeto.

Dicho esto, memcached aún tiene una posición sólida en los entornos, donde el uso de la memoria debe imponerse y / o ser predecible. Hemos intentado usar el último redis estable (2.8.19) como un reemplazo de memcached basado en LRU no persistente en la carga de trabajo de 10-15k op / s, y se perdió mucha memoria; la misma carga de trabajo estaba fallando las instancias de redis de ElastiCache de Amazon en un día más o menos por las mismas razones.