Estamos utilizando una aplicación web Ruby con el servidor Redis para el almacenamiento en caché. ¿Hay algún punto para probar Memcached en su lugar?

¿Qué nos dará un mejor rendimiento? ¿Hay ventajas o desventajas entre Redis y Memcached?

Puntos a considerar:

• Velocidad de lectura / escritura.
• Uso de memoria.
• Descarga de E / S de disco.
• Escalada.

Resumen (TL; DR)

Actualizado el 3 de junio de 2017

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

Para cualquier cosa nueva, use Redis.

Memcached vs Redis: Comparación directa

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

Puntos a considerar

Cuando se usan para lo mismo, así es como se comparan usando 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 los redis son tan rápidos o casi tan rápidos como memcached. Recomiendo redis, pero no porque memcached es lento. No es.
• Uso de memoria : Redis es mejor.
  • memcached: especifica el tamaño de la memoria caché y, a medida que inserta elementos, el daemon crece rápidamente un poco más que este tamaño. En realidad, nunca hay una manera de reclamar nada de ese espacio, salvo reiniciar memcached. Todas sus claves podrían expirar, podría vaciar la base de datos y aún usaría la porción completa de RAM con la que la configuró.
  • redis: la configuración de un tamaño máximo depende de usted. Redis nunca usará más de lo necesario y le devolverá la memoria que ya no usa.
  • Almacené 100,000 ~ 2KB cadenas (~ 200MB) de oraciones aleatorias en ambos. El uso de RAM de Memcached creció a ~ 225 MB. El uso de Redis RAM aumentó a ~ 228 MB. Después de enjuagar ambos, redis bajó a ~ 29MB y memcached se quedó en ~ 225MB. Son igualmente eficientes en la forma en que almacenan datos, pero solo uno es capaz de recuperarlos.
• Volcado de E / S de disco : una clara victoria para redis, ya que lo hace de forma predeterminada y tiene una persistencia muy configurable. Memcached no tiene mecanismos para descargar en el disco sin herramientas de terceros.
• Escalado : ambos le brindan mucho espacio para la cabeza antes de que necesite más de una instancia como caché. Redis incluye herramientas para ayudarlo a ir más allá, mientras que memcached no.

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 desaparecen. Esto está bien para un caché. No deberías almacenar nada importante allí.

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

redis

Redis puede hacer los mismos trabajos que Memcached, y puede hacerlos mejor.

Redis también puede actuar como caché . También puede almacenar pares clave / valor. En redis incluso pueden tener hasta 512 MB.

Puede desactivar la persistencia y felizmente perderá sus datos al reiniciar también. Si quieres que tu caché sobreviva se reinicia, también te permite hacerlo. De hecho, ese es el valor predeterminado.

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

Si una instancia de redis / memcached no es suficiente rendimiento 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 claro líder en herramientas de terceros. Empresas como Redis Labs, Amazon y otras ofrecen muchas herramientas y servicios de redis útiles. 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 un simple caché de 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. Le permite probar redis en el navegador e incluso le ofrece ejemplos interactivos en vivo con cada comando en los documentos.

Ahora hay dos veces más resultados de stackoverflow para redis que memcached. El doble de resultados de Google. Ejemplos más fácilmente accesibles en más idiomas. Desarrollo más activo. Desarrollo más activo del cliente. Es posible que estas mediciones no signifiquen mucho individualmente, pero en combinación pintan una imagen clara de que el soporte y la documentación para redis es mayor y mucho más actualizado.

Persistencia

De forma predeterminada, redis conserva sus datos en el disco utilizando un mecanismo llamado captura de pantalla. Si tiene suficiente RAM disponible, puede escribir todos sus datos en el disco con casi ninguna degradación del rendimiento. ¡Es casi gratis!

En el modo de instantánea, existe la posibilidad de que un bloqueo repentino pueda provocar una pequeña cantidad de datos perdidos. Si realmente necesita asegurarse de que nunca se pierdan datos, no se preocupe, redis también lo respalda 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 la velocidad con que su disco pueda escribir, 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 servir muchos tipos de datos diferentes. También proporciona los comandos que necesita para aprovechar al máximo esos tipos de datos.

Cadenas ( comandos )

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

Redis le brinda más herramientas para aprovechar este tipo de datos al ofrecer comandos para operaciones bit a bit, manipulación a nivel de bit, soporte de incremento / decremento de coma flotante, consultas de rango y operaciones de teclas múltiples. Memcached no admite 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 ( comandos )

Los hashes son algo así como un 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 campo-> valor utilizando un hash son un poco más eficientes en espacio que los mapas de clave-> valor utilizando cadenas regulares.

Los hashes 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, expirar todos los miembros juntos, eliminar todos los miembros juntos, etc. Excelente para cualquier caso de uso en el que tenga varios pares clave / valor que necesiten agruparse.

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

Listas ( comandos )

Las listas de Redis son colecciones ordenadas de cadenas. Están optimizados para insertar, leer o eliminar valores de la parte superior o inferior (es decir, izquierda o derecha) de la lista.

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

Las listas hacen grandes colas duraderas, atómicas. Estos funcionan muy bien para colas de trabajo, registros, memorias intermedias y muchos otros casos de uso.

Conjuntos ( comandos )

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 (generalmente llamado Conjunto). Esto es así, solo distribuido.

Redis proporciona varios comandos para administrar conjuntos. Los obvios como agregar, eliminar y verificar el conjunto están presentes. Entonces, hay comandos menos obvios como hacer estallar / leer un elemento aleatorio y comandos para realizar uniones e intersecciones con otros conjuntos.

Conjuntos ordenados ( comandos )

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

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

Si agrega usuarios a un conjunto ordenado junto con su puntaje alto, tiene una tabla de clasificación perfecta. A medida que lleguen nuevos puntajes altos, solo agréguelos nuevamente al conjunto con su puntaje alto y reordenará su tabla de clasificación. También es excelente para realizar un seguimiento de la última vez que los usuarios visitaron y quién está activo en su aplicación.

Almacenar valores con el mismo puntaje hace que se ordenen lexicográficamente (piense alfabéticamente). Esto puede ser útil para cosas como funciones de autocompletar.

Muchos de los comandos de conjuntos ordenados son similares a los comandos de conjuntos, a veces con un parámetro de puntuación adicional. También se incluyen comandos para administrar puntajes y consultar por puntaje.

Geo

Redis tiene varios comandos 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 en conjuntos ordenados, por lo que este no es un tipo de datos verdaderamente separado. Es más una extensión sobre conjuntos ordenados.

Mapa de bits e 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 me referí Strings. Este tipo de datos fue el componente básico del reciente proyecto de arte colaborativo de reddit: r / Place .

HyperLogLog le permite usar una cantidad constante de espacio extremadamente pequeño para contar valores únicos casi ilimitados con una precisión impactante. Usando solo ~ 16 KB, podría contar eficientemente 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 se propague ese valor. Técnicamente, memcached también es atómico, pero con redis agregando toda esta funcionalidad más allá de memcached, vale la pena señalar y de alguna manera impresionante que todos estos tipos de datos y características adicionales también sean atómicos.

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

Tubería

Redis proporciona una función llamada ' canalización '. Si tiene muchos comandos de 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 en búfer 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 involucren muchos comandos.

Pub / Sub

Redis tiene comandos dedicados a la funcionalidad pub / sub , lo que permite que redis actúe como un emisor 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 corredores de mensajes dedicados como RabbitMQ pueden tener ventajas en ciertas áreas, pero el hecho de que el mismo servidor también puede brindarle colas duraderas persistentes y otras estructuras de datos que sus cargas de trabajo de pub / sub probablemente necesiten, Redis a menudo demostrará ser la mejor y más simple herramienta para el trabajo.

Lua Scripting

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

Tal vez tenga cálculos complejos que desea que redis realice. Tal vez no pueda permitirse que sus transacciones se reviertan y necesite garantías de que cada paso de un proceso complejo sucederá atómicamente. Estos problemas y muchos más se pueden resolver con scripts de lua.

El script completo se ejecuta atómicamente, por lo que si puede ajustar su lógica en un script lua, a menudo puede evitar meterse con transacciones de bloqueo optimistas.

Escalada

Como se mencionó anteriormente, redis incluye soporte integrado para la agrupación en clúster 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 no usen memcached.

Lo anterior puede parecer que no me gusta memcached. Por el contrario: es una herramienta poderosa, simple, estable, madura y endurecida. Incluso hay algunos casos de uso en los que 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 Memcached hace, a menudo mejor. Cualquier ventaja de rendimiento para memcached es menor y específica para la carga de trabajo. También hay cargas de trabajo para las cuales redis será más rápido, y muchas más cargas de trabajo que redis pueden hacer que memcached simplemente no puede. Las pequeñas diferencias de rendimiento parecen menores ante el abismo gigante en la funcionalidad y el hecho de que ambas herramientas son tan rápidas y eficientes que muy bien pueden ser la última parte de su infraestructura por la que tendrá que preocuparse por escalar.

Solo hay un escenario en el que memcached tiene más sentido: donde memcached ya está en uso como caché. Si ya está almacenando en caché con memcached, siga usándolo, si cumple con sus necesidades. Es probable que no valga la pena el esfuerzo para cambiar a redis y si va a usar redis solo para el almacenamiento en caché, es posible que no ofrezca suficientes beneficios para que valga la pena su tiempo. Si memcached no satisface tus necesidades, entonces probablemente deberías pasar a redis. Esto es cierto tanto si necesita escalar más allá de memcached o si necesita funcionalidad adicional.

Use Redis si

1. Necesita eliminar o caducar elementos de forma selectiva en la memoria caché. (Necesitas esto)

2. Necesita la capacidad de consultar claves de un tipo particular. eq. 'blog1: publicaciones: *', 'blog2: categorías: xyz: publicaciones: *'. ¡Oh si! esto es muy importante. Use esto para invalidar ciertos tipos de elementos almacenados en caché de forma selectiva. También puede usar esto para invalidar caché de fragmentos, caché de página, solo objetos AR de un tipo determinado, etc.

3. Persistencia (también necesitará esto, 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)

Use memcached si

1. Memcached te da dolor de cabeza!
2. umm ... agrupamiento? 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 Memcached

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.

Usamos ambos Memcached se utiliza para almacenar en caché objetos, principalmente reduciendo la carga de lectura en las bases de datos. Redis se usa para cosas como conjuntos ordenados que son útiles para acumular datos de series temporales.

Esto es demasiado largo para ser publicado como un comentario a una respuesta ya aceptada, así que lo puse como una respuesta separada

Una cosa también a considerar es si espera tener un límite superior de memoria rígido en su instancia de caché.

Dado que redis es una base de datos nosql con toneladas de características y el almacenamiento en caché es solo una opción para la que se puede usar, asigna memoria según lo necesite: cuantos más objetos coloque, más memoria usará. La maxmemoryopción no aplica estrictamente el uso del límite de memoria superior. A medida que trabaja con caché, las claves se expulsan y expiran; lo más probable es que sus claves no sean todas del mismo tamaño, por lo que se produce la fragmentación de la memoria interna.

De forma predeterminada, redis usa el asignador de memoria jemalloc , que hace todo lo posible para 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 purgas de objetos que ocurren a una velocidad alta. Debido a esto, en algunos patrones de carga, el proceso de 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 redis conmaxmemory 5Gb con el tiempo usaría más y más memoria, llegando finalmente al límite total de RAM hasta el asesino sin memoria interfiere.

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

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

Memcached es bueno para ser una simple clave / almacén de valores y es bueno para hacer key => STRING. Esto lo hace realmente bueno para el almacenamiento de sesiones.

Redis es bueno haciendo key => SOME_OBJECT.

Realmente depende de lo que vas a poner allí. Tengo entendido que en términos de rendimiento son bastante parejos.

También buena suerte para encontrar puntos de referencia objetivos, si encuentra alguno, por favor envíelos a mi manera.

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

Y ningún enlace de referencia está completo sin confundir un poco las cosas, así que también revise algunas referencias conflictivas en LiveJournal de Dormondo y el Weblog de Antirez .

Editar : como señala Antirez, el análisis de Systoilet está bastante mal concebido. Incluso más allá del déficit de subprocesos simples, gran parte de la disparidad de rendimiento en esos puntos de referencia se puede atribuir a las bibliotecas del cliente en lugar del rendimiento del servidor. Los puntos de referencia en el Weblog de Antirez realmente presentan una comparación mucho más manzanas con manzanas (con la misma boca).

Tuve la oportunidad de usar Memcached y Redis juntos en el proxy de almacenamiento en caché en el que he trabajado, permítanme compartir dónde exactamente he usado qué y por qué detrás de eso ...

Redis>

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

2) Básicamente, es una tienda de clave / valor, por lo que cada vez que en su aplicación tiene algo similar, uno puede usar redis con molestar mucho.

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

Memcache>

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

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

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 es el caso con redis).

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

Además, hay un resultado de evaluación comparativa disponible en este enlace , a continuación se detallan algunos de los mismos,

¡¡Espero que esto ayude!!

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

Con mi compañía actual, Redis se utilizaba como caché principal. Cuando analicé 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, dejó a Redis fuera del agua por completo . Se escaló mucho mejor:

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

Además, en mi opinión, la política de desalojo de Memcached está mucho mejor implementada, lo que resulta en un tiempo de respuesta promedio más estable en general mientras se manejan más datos de los que el caché puede manejar.

Algunos puntos de referencia revelaron que Redis, en nuestro caso, funciona muy mal. Esto creo que tiene que ver con muchas variables:

• tipo de hardware en el que ejecuta Redis
• tipos de datos que almacena
• cantidad de get y sets
• 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 subprocesamiento múltiple.

Otra ventaja es que puede quedar muy claro cómo se 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, también conocido como desalojar los elementos menos utilizados cuando alcanza el máximo capacidad.

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

Aparte de eso, Redis generalmente se considera superior para la mayoría de los casos de uso, ya que tiene más funciones y, por lo tanto, es más flexible.

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

Una prueba muy simple para configurar y obtener 100k claves y valores únicos contra redis-2.2.2 y memcached. Ambos se ejecutan en Linux VM (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 = 18328 ms

Memcached

• El tiempo necesario para 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");

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). Si siempre desea almacenar una clave / valor durante cierto período de tiempo (y nunca desalojarlo debido a la poca memoria), desea utilizar Redis. Por supuesto, también corre el riesgo de quedarse sin memoria ...

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

Redis puede hacer muchas cosas diferentes y un efecto secundario 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 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 no hay realmente ninguna razón convincente para usar Redis sobre Memcached.

Si necesita un caché LRU confiable "nunca se cae" ... Memcached cumplirá los requisitos ya que es imposible que se quede sin memoria por diseño y la funcionalidad de especialización evita que los desarrolladores intenten convertirlo en algo que pueda ponerlo en peligro. Separación simple de preocupaciones.

Memcached será más rápido si está interesado en el rendimiento, incluso 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.

Pensamos en Redis como un despegue de carga para nuestro proyecto en el trabajo. Pensamos que al usar un módulo nginxllamado HttpRedis2Moduleo algo similar tendríamos una velocidad increíble, 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 y era aún más rápido tomar datos con php y luego introducirlos en MongoDB. Estamos usando APC como sistema de almacenamiento en caché y con ese php y MongoDB. Fue mucho más rápido quenginx módulo Redis.

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

Redis es mejor.

Los pros de Redisson,

1. Tiene muchas opciones de almacenamiento de datos como cadenas, conjuntos, conjuntos ordenados, hashes, mapas de bits
2. Disco de persistencia de registros
3. LUASoporte de procedimiento almacenado ( scripting)
4. Puede actuar como intermediario de mensajes utilizando PUB / SUB

Mientras que Memcachees un sistema de tipo de caché de valor clave en memoria.

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

Bueno, usé principalmente mis aplicaciones, Memcache para almacenar en caché las sesiones y redis para objetos de consulta de doctrina / orm. En términos de rendimiento, ambos son casi iguales.

Aquí está el gran artículo / diferencias proporcionadas por Amazon

Redis es un claro ganador en comparación con memcached.

Solo un punto positivo para Memcached es multiproceso y rápido. Redis tiene muchas características excelentes y es muy rápido, pero está limitado a un núcleo.

Grandes puntos sobre Redis, que no son compatibles con Memcached

• Instantáneas: el usuario puede tomar una instantánea de la memoria caché de Redis y conservar el almacenamiento secundario en cualquier momento.
• Soporte incorporado para muchas estructuras de datos como Set, Map, SortedSet, List, BitMaps, etc.
• Soporte para secuencias de comandos Lua en redis