{"id":20492,"date":"2026-08-09T18:19:03","date_gmt":"2026-08-09T16:19:03","guid":{"rendered":"https:\/\/webhosting.de\/redis-eviction-hosting-cache-strategie\/"},"modified":"2026-08-09T18:19:03","modified_gmt":"2026-08-09T16:19:03","slug":"estrategia-de-cache-de-redis-para-el-alojamiento-y-la-expulsion","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/redis-eviction-hosting-cache-strategie\/","title":{"rendered":"Pol\u00edticas de expulsi\u00f3n de Redis para servidores de alojamiento: la estrategia adecuada"},"content":{"rendered":"<p>La funci\u00f3n de expulsi\u00f3n de Redis decide, en los servidores de alojamiento, qu\u00e9 claves se eliminan cuando la memoria es escasa y cu\u00e1les permanecen en la cach\u00e9, para que las solicitudes se procesen de forma r\u00e1pida y fiable. Te mostrar\u00e9 estrategias concretas para elegir la pol\u00edtica adecuada, <strong>configuras<\/strong> y lo garantiza mediante un sistema de seguimiento.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<p>Antes de entrar en detalles, voy a resumir brevemente los aspectos m\u00e1s importantes para que puedas... <strong>Pol\u00edtica<\/strong> puedes establecer r\u00e1pidamente. Los siguientes puntos est\u00e1n dirigidos a administradores de alojamiento, profesionales de DevOps y gestores de sitios web que se centran en el rendimiento. Tengo en cuenta cargas de trabajo t\u00edpicas, desde la cach\u00e9 pura hasta conjuntos de datos mixtos con TTL y claves permanentes. De este modo, mantendr\u00e1s el equilibrio adecuado entre la proporci\u00f3n de cach\u00e9, la seguridad de los datos y la previsibilidad. Con estos puntos clave, tomar\u00e1s una <strong>borrar<\/strong> Elige tu servidor.<\/p>\n<ul>\n  <li><strong>Allkeys-LFU<\/strong>: Para cargas de trabajo de cach\u00e9 de gran volumen con accesos muy desiguales.<\/li>\n  <li><strong>Allkeys-LRU<\/strong>: Para ofrecer contenidos actualizados y un comportamiento f\u00e1cilmente predecible.<\/li>\n  <li><strong>Volatile-LRU\/LFU<\/strong>: Solo borra las claves TTL; protege los datos permanentes.<\/li>\n  <li><strong>Noeviction<\/strong>: Para datos cr\u00edticos; errores de escritura en lugar de p\u00e9rdida de claves.<\/li>\n  <li><strong>Monitoreo<\/strong>: Vigilar constantemente la tasa de aciertos, la memoria y los desalojos.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/servermanagement-strategien-4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00bfQu\u00e9 significa exactamente \u00abeviction\u00bb en Redis?<\/h2>\n\n<p>Por \u00abevicci\u00f3n en Redis\u00bb se entiende la eliminaci\u00f3n de claves tan pronto como se alcance el l\u00edmite establecido <code>memoria m\u00e1xima<\/code> se ha alcanzado y Redis tiene que liberar espacio para que se puedan escribir nuevos datos. Yo controlo este comportamiento mediante el par\u00e1metro <code>pol\u00edtica de memoria m\u00e1xima<\/code>, las opciones como <code>allkeys-lru<\/code>, <code>allkeys-lfu<\/code>, <code>allkeys-random<\/code> o el <code>volatile-*<\/code>-ofrece varias variantes; cada opci\u00f3n da prioridad a unas claves u otras a la hora de eliminarlas. LRU protege las claves utilizadas m\u00e1s recientemente, LFU da prioridad a los datos m\u00e1s utilizados, Random selecciona al azar mediante muestreo, y las pol\u00edticas \u00abvolatile\u00bb solo tienen en cuenta las claves con tiempo de vida (TTL). Importante: Redis toma sus decisiones de eliminaci\u00f3n de forma eficiente mediante muestreo, lo que mantiene baja la latencia y garantiza la fiabilidad del sistema. <strong>controla<\/strong>. La expulsi\u00f3n solo se activa cuando la memoria escasea; hasta entonces, Redis se comporta como un almac\u00e9n de datos en memoria normal con <strong>Cache<\/strong>-Ventajas.<\/p>\n\n<h2>Elecci\u00f3n de la pol\u00edtica adecuada para los servidores de alojamiento<\/h2>\n\n<p>La mejor pol\u00edtica se determina a partir de la pregunta de qu\u00e9 datos deben permanecer en la memoria y cu\u00e1les puede volver a calcular el sistema. Si Redis se utiliza exclusivamente como cach\u00e9, lo m\u00e1s adecuado es una estrategia \u00aballkeys\u00bb, ya que, en caso de duda, cada entrada se vuelve a generar a partir de la fuente original; en ese caso, se obtienen ventajas <strong>allkeys-lfu<\/strong> en caso de accesos desiguales y <strong>allkeys-lru<\/strong> en el caso de contenidos m\u00e1s recientes. Si la instancia contiene datos mixtos, prefiero <strong>volatile-lru<\/strong> o <strong>volatile-lfu<\/strong>, para que solo se eliminen las claves TTL y los datos permanentes permanezcan intactos. Si los datos son cr\u00edticos, opto por <strong>noeviction<\/strong>, pero a cambio acepto que las \u00f3rdenes de escritura fallen cuando la memoria est\u00e9 al m\u00e1ximo de su capacidad y que la aplicaci\u00f3n deba reaccionar correctamente. Esta sencilla l\u00f3gica de decisi\u00f3n hace que el funcionamiento sea predecible, mantiene bajo el riesgo de errores y me proporciona una clara <strong>Barandilla<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis_eviction_meeting_7483.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gu\u00eda pr\u00e1ctica: Cargas de trabajo \u00absolo cach\u00e9\u00bb frente a cargas de trabajo mixtas<\/h2>\n\n<p>Para cargas de trabajo basadas exclusivamente en la cach\u00e9, mi objetivo es conseguir una tasa de aciertos elevada y acepto que las sustituciones apenas supongan un riesgo, ya que los datos se recargan r\u00e1pidamente desde la fuente primaria. En este tipo de entornos, <strong>allkeys-lfu<\/strong> suele ser la mejor soluci\u00f3n, ya que los objetos que se utilizan con frecuencia permanecen mucho tiempo en la memoria, mientras que los datos secundarios se eliminan. Quien busque la actualidad, debe elegir <strong>allkeys-lru<\/strong>, para dar prioridad a las entradas utilizadas m\u00e1s recientemente y mantener fragmentos de p\u00e1gina actualizados. En el caso de conjuntos mixtos, utilizo el TTL en todas las claves de cach\u00e9 y lo combino con <strong>volatile-lru<\/strong> o <strong>volatile-lfu<\/strong>, para que solo se borren los datos \u201etemporales\u201c. Una configuraci\u00f3n adecuada del almacenamiento ayuda a tomar esta decisi\u00f3n; en mi gu\u00eda ofrezco m\u00e1s consejos al respecto <a href=\"https:\/\/webhosting.de\/es\/gestion-de-memoria-de-redis-configuracion-optima-de-la-memoria-rendimiento-cache\/\">Configurar la memoria de forma \u00f3ptima<\/a>, que analiza las reservas y m\u00e9tricas concretas de Maxmemory.<\/p>\n\n<h2>LRU frente a LFU: cu\u00e1ndo es adecuado cada m\u00e9todo<\/h2>\n\n<p>El m\u00e9todo LRU (Least Recently Used) da prioridad a la proximidad temporal del \u00faltimo uso y garantiza que se conserven los contenidos consultados recientemente. El m\u00e9todo LFU (Least Frequently Used) cuenta la frecuencia de acceso y, de este modo, protege los \u201e\u00e9xitos de siempre\u201c, incluso si han estado inactivos durante los \u00faltimos minutos; lo cual resulta muy beneficioso en el caso de accesos muy irregulares. Si el comportamiento de uso cambia r\u00e1pidamente, por ejemplo, en el caso de noticias o campa\u00f1as, el efecto es <strong>allkeys-lru<\/strong> m\u00e1s intuitivo, ya que hace mayor hincapi\u00e9 en la actividad actual. Resulta convincente en el caso de patrones recurrentes y estables, como men\u00fas, widgets de la p\u00e1gina de inicio o datos relacionados con el inicio de sesi\u00f3n. <strong>allkeys-lfu<\/strong>, ya que los contenidos permanecen disponibles de forma continua. Para evitar errores de valoraci\u00f3n, compruebo peri\u00f3dicamente la tasa de aciertos, la tasa de expulsi\u00f3n y los tiempos de respuesta, ya que estas cifras reflejan la situaci\u00f3n real <strong>Utilice<\/strong> de forma fiable.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis-eviction-server-strategies-4287.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ajuste preciso para LRU\/LFU<\/h2>\n\n<p>Para que el LRU y el LFU funcionen con precisi\u00f3n, ajusto tres tornillos de regulaci\u00f3n: <code>maxmemory-samples<\/code>, <code>factor de registro lfu<\/code> y <code>tiempo de decaimiento de lfu<\/code>. Mayor <code>maxmemory-samples<\/code>Los valores (por ejemplo, 10-15 en lugar de los predeterminados) mejoran la calidad de la muestra en los procesos de expulsi\u00f3n y, por lo tanto, aumentan la tasa de acierto de las claves \u201ecorrectas\u201c, pero consumen recursos de la CPU. <code>factor de registro lfu<\/code> determina la rapidez con la que aumenta el contador LFU: los valores bajos reaccionan r\u00e1pidamente (ideal para modas pasajeras), mientras que los valores altos suavizan la curva (mejor para los \u201epesos pesados\u201c duraderos). Con <code>tiempo de decaimiento de lfu<\/code> (en minutos) defino la rapidez con la que \u201ecaduca\u201c la popularidad anterior; los valores m\u00e1s altos son adecuados para patrones diarios, mientras que los m\u00e1s bajos lo son para contenidos que cambian r\u00e1pidamente. Solo modifico un par\u00e1metro por iteraci\u00f3n, observo la tasa de aciertos y vigilo la latencia para no malgastar recursos de la CPU en muestreos innecesarios.<\/p>\n\n<h2>Estrategias TTL con \u00abvolatile-*\u00bb<\/h2>\n\n<p>Pol\u00edticas basadas en TTL, como <strong>volatile-lru<\/strong> y <strong>volatile-lfu<\/strong> limitan las eliminaciones a las claves con tiempo de caducidad y no afectan a las claves \u201epermanentes\u201c. Esto resulta adecuado para configuraciones en las que Redis mantiene juntos datos de cach\u00e9 y datos de larga duraci\u00f3n, como informaci\u00f3n similar a las sesiones junto con cach\u00e9s de consultas. Si establezco TTL de forma sistem\u00e1tica en todas las claves de cach\u00e9, puedo asegurarme de que las expulsiones solo se produzcan donde yo lo haya previsto. Importante: si la base de datos no contiene claves con TTL, las pol\u00edticas \u00abvolatile\u00bb se comportan como <strong>noeviction<\/strong>, es decir, sin borrado y con posibles errores de escritura cuando la memoria est\u00e1 llena. Por eso compruebo peri\u00f3dicamente si todos los objetos de la cach\u00e9 tienen un tiempo de vida razonable y si los intervalos de tiempo hasta la <strong>Actualidad<\/strong> que se ajusten a los contenidos.<\/p>\n\n<p>Como opci\u00f3n complementaria, utilizo, en el caso de contenidos con una vigencia claramente limitada, <strong>volatile-ttl<\/strong>, lo que hace que se eliminen primero las claves con el tiempo de vida restante m\u00e1s corto. Esto resulta \u00fatil cuando todos los objetos de la cach\u00e9 van a renovarse pronto de todos modos y quiero utilizar la fecha de caducidad \u201enatural\u201c como prioridad. Para pruebas o entornos de staging, a veces configuro <strong>vol\u00e1til-aleatorio<\/strong> para minimizar la carga de la CPU; en entornos de producci\u00f3n, evito las variantes aleatorias debido a su menor previsibilidad.<\/p>\n\n<h2>Noeviction para datos cr\u00edticos<\/h2>\n\n<p>En <strong>noeviction<\/strong> Redis no elimina las claves; las operaciones de lectura siguen siendo posibles, mientras que los comandos de escritura pueden fallar en cuanto se alcanza el l\u00edmite de memoria. Esto protege los datos cr\u00edticos contra una eliminaci\u00f3n involuntaria, pero exige que la aplicaci\u00f3n gestione de forma robusta los mensajes de error y, en su caso, la contrapresi\u00f3n. Utilizo \u00abnoeviction\u00bb en aquellos casos en los que la p\u00e9rdida de cach\u00e9 resultar\u00eda m\u00e1s costosa que los errores de escritura temporales, por ejemplo, en configuraciones relevantes para la seguridad o en informaci\u00f3n de sesi\u00f3n altamente sensible. Es importante mantener una planificaci\u00f3n conservadora de la memoria con margen de reserva, para que los picos de carga no provoquen errores de inmediato y la <strong>Aplicaci\u00f3n<\/strong> sigue reaccionando. Adem\u00e1s, env\u00edo alertas de forma activa mediante el sistema de monitorizaci\u00f3n antes de que se alcance el umbral, para poder actuar a tiempo <strong>contrarrestar<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis_strategie_6789.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Persistencia, replicaci\u00f3n y b\u00fafer de memoria<\/h2>\n\n<p>Las decisiones de expulsi\u00f3n siempre deben tomarse teniendo en cuenta la persistencia (RDB\/AOF) y la replicaci\u00f3n. Las instant\u00e1neas de RDB y las reescrituras de AOF utilizan la t\u00e9cnica \u00abcopy-on-write\u00bb; mientras tanto, la memoria RSS crece temporalmente. Por ello, preveo un margen de 25\u201350% por encima del pico observado, para que una reescritura no provoque desalojos involuntarios. La magnitud depende de la tasa de escritura y del tama\u00f1o de los objetos; cuantos m\u00e1s objetos cambien durante la reescritura, mayor ser\u00e1 la necesidad.<\/p>\n\n<p>En la replicaci\u00f3n, tengo en cuenta el <code>tama\u00f1o-de-la-cola-de-respuestas<\/code> as\u00ed como los b\u00faferes de salida para las r\u00e9plicas. Es especialmente importante: en las r\u00e9plicas suelo utilizar <code>replica-ignore-maxmemory yes<\/code> (antes <code>slave-ignore-maxmemory<\/code>), para que el servidor r\u00e9plica no sea expulsado de forma autom\u00e1tica durante los picos de carga mientras sigue al servidor primario. En cambio, en el caso de las r\u00e9plicas de lectura con funci\u00f3n de cach\u00e9, puedo activar deliberadamente una pol\u00edtica de expulsi\u00f3n si necesito limitar estrictamente el espacio de almacenamiento. Para los datos cr\u00edticos, suelo emparejar en las r\u00e9plicas <strong>noeviction<\/strong> con una reserva suficiente para evitar desviaciones en los datos.<\/p>\n\n<h2>Configuraci\u00f3n en redis.conf y en tiempo de ejecuci\u00f3n<\/h2>\n\n<p>Trabajo de forma reproducible con ajustes claros y los guardo de forma permanente:<\/p>\n<pre><code># Ejemplo: Solo cach\u00e9, accesos desiguales\nmaxmemory 4gb\nmaxmemory-policy allkeys-lfu\nmaxmemory-samples 10\nlfu-log-factor 10\nlfu-decay-time 1\n\n# Eliminaciones en segundo plano opcionales (v\u00e9ase Lazyfree)\nlazyfree-lazy-eviction yes\nlazyfree-lazy-expire yes\nlazyfree-lazy-server-del yes\n<\/code><\/pre>\n<p>Durante la ejecuci\u00f3n, pruebo los cambios con <code>CONFIG SET<\/code> y escr\u00edbelas con <code>REESCRITURA DE LA CONFIGURACI\u00d3N<\/code> de forma permanente en el archivo de configuraci\u00f3n. Para cargas de trabajo mixtas, documento las reglas de TTL en el c\u00f3digo y mantengo las instancias de Redis separadas seg\u00fan su finalidad (por ejemplo, cach\u00e9 independiente frente a sesiones), de modo que cada instancia pueda aplicar una pol\u00edtica espec\u00edfica.<\/p>\n\n<h2>Lazyfree: desalojos sin picos de latencia<\/h2>\n\n<p>Las claves grandes o los borrados masivos provocan r\u00e1pidamente picos de latencia de forma sincronizada. Con Lazyfree (<code>lazyfree-lazy-eviction<\/code>, <code>lazyfree-lazy-expire<\/code>, <code>lazyfree-lazy-server-del<\/code>) traslado la liberaci\u00f3n de objetos de gran tama\u00f1o a subprocesos en segundo plano; comandos como <code>UNLINK<\/code> en lugar de <code>DEL<\/code> Tambi\u00e9n lo aprovechan. Resultado: tiempos de respuesta m\u00e1s constantes con las mismas cargas de trabajo. Para ello, vigilo la memoria y la CPU, ya que las liberaciones en segundo plano pueden generar una sobrecarga adicional a corto plazo.<\/p>\n\n<h2>Seguimiento e indicadores: tasa de aciertos, memoria, expulsiones<\/h2>\n\n<p>Una configuraci\u00f3n coherente depende totalmente de la visibilidad: mido la <strong>Tasa de aciertos<\/strong>, la tasa de expulsi\u00f3n, la latencia y la memoria ocupada a lo largo del tiempo. Si la tasa de expulsi\u00f3n aumenta mientras que la tasa de aciertos disminuye, las cifras indican que hay poca memoria, valores de TTL incorrectos o una pol\u00edtica inadecuada. En horas punta, tambi\u00e9n eval\u00fao las tasas de error de las \u00f3rdenes de escritura para detectar directamente los riesgos de \u00abnoeviction\u00bb. Las muestras internas de Redis para LRU\/LFU se pueden consultar a trav\u00e9s de <code>maxmemory-samples<\/code> ajustar; unos valores m\u00e1s altos permiten tomar mejores decisiones, pero consumen algo de CPU. Aumento este valor con moderaci\u00f3n, observo el efecto en los tiempos de respuesta y as\u00ed busco el mejor <strong>Configuraci\u00f3n<\/strong> para la carga de trabajo.<\/p>\n\n<h2>Configuraciones de ejemplo para servidores de alojamiento<\/h2>\n\n<p>Para los casos de alojamiento recurrentes, me ha resultado muy \u00fatil una peque\u00f1a matriz que utilizo como punto de partida y que luego voy perfeccionando a partir de los datos de medici\u00f3n. Siempre preveo una reserva en el <code>memoria m\u00e1xima<\/code>, para amortiguar los picos de carga y garantizar que las expulsiones se produzcan de forma ordenada. Para ello, elijo la pol\u00edtica en funci\u00f3n de la carga de trabajo seg\u00fan la tabla que figura a continuaci\u00f3n y documento claramente las reglas de TTL en la aplicaci\u00f3n. Este procedimiento evita malentendidos entre los equipos de desarrollo y operaciones, y garantiza un comportamiento reproducible en el d\u00eda a d\u00eda. Con esta visi\u00f3n general, mantengo mi <strong>Decisiones<\/strong> transparente y permite recuperarlas m\u00e1s f\u00e1cilmente m\u00e1s adelante <strong>personalizar<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Carga de trabajo<\/th>\n      <th>Pol\u00edtica recomendada<\/th>\n      <th>Ventaja<\/th>\n      <th>Riesgo<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Cach\u00e9 pura, accesos desiguales<\/td>\n      <td>allkeys-lfu<\/td>\n      <td>Los objetos de uso frecuente permanecen<\/td>\n      <td>Las llaves raras se obtienen m\u00e1s r\u00e1pido<\/td>\n      <td>Comprobar la tasa de aciertos, <code>maxmemory-samples<\/code> ajustar con precisi\u00f3n<\/td>\n    <\/tr>\n    <tr>\n      <td>Cach\u00e9 pura, contenidos actualizados<\/td>\n      <td>allkeys-lru<\/td>\n      <td>Se guardan las claves utilizadas m\u00e1s recientemente<\/td>\n      <td>Los favoritos de siempre tienden a caer<\/td>\n      <td>A menudo m\u00e1s adecuado para noticias y campa\u00f1as<\/td>\n    <\/tr>\n    <tr>\n      <td>Datos mixtos con TTL<\/td>\n      <td>volatile-lru\/lfu<\/td>\n      <td>Claves permanentes protegidas<\/td>\n      <td>Sin TTL no hay borrado<\/td>\n      <td>Aplicar y documentar el TTL de forma sistem\u00e1tica<\/td>\n    <\/tr>\n    <tr>\n      <td>Almacenamiento de datos cr\u00edticos<\/td>\n      <td>noeviction<\/td>\n      <td>No se pierden las llaves<\/td>\n      <td>Errores de escritura cuando la RAM est\u00e1 llena<\/td>\n      <td>Garantizar la gesti\u00f3n de errores de la aplicaci\u00f3n<\/td>\n    <\/tr>\n    <tr>\n      <td>Pruebas\/Entorno de pruebas<\/td>\n      <td>allkeys-random<\/td>\n      <td>Consumo de CPU muy reducido<\/td>\n      <td>Desahucios imprevistos<\/td>\n      <td>No utilizar en cach\u00e9s productivos<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/RedisEvictionStrategie3287.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Redis compartido frente a Redis dedicado en el alojamiento web<\/h2>\n\n<p>En entornos compartidos, a menudo te enfrentas a perfiles de carga variables y a reglas de TTL poco claras de otros proyectos, lo que puede hacer que las expulsiones resulten impredecibles. En este caso, prefiero utilizar <strong>volatile-lru<\/strong> o <strong>volatile-lfu<\/strong> y establece TTL breves y claros para todas las claves de cach\u00e9, de modo que solo se eliminen los datos expl\u00edcitamente ef\u00edmeros. En las cach\u00e9s dedicadas de alto rendimiento, esto proporciona <strong>allkeys-lfu<\/strong> a menudo ofrecen mejores \u00edndices de acierto y tiempos de respuesta m\u00e1s estables, ya que los \u201eHeavy-Hitter\u201c permanecen de forma fiable en la RAM. Si a\u00fan tienes dudas a la hora de decidirte, echa un vistazo a mi gu\u00eda sobre <a href=\"https:\/\/webhosting.de\/es\/redis-compartido-frente-a-dedicado-rendimiento-seguridad-cacheboost\/\">Compartido vs. dedicado<\/a>, all\u00ed comparo los efectos en el rendimiento, el aislamiento y los costes. Con esta claridad, reduzco el riesgo de que se produzcan fallos en las p\u00e1ginas y mantengo la <strong>Latencia<\/strong> bajo control.<\/p>\n\n<p>Redis no aplica de forma nativa los l\u00edmites por cliente. Si necesito l\u00edmites de almacenamiento estrictos, inicio instancias independientes o fragmentos de cl\u00faster por proyecto y defino uno propio por cada instancia <code>memoria m\u00e1xima<\/code> junto con la pol\u00edtica correspondiente. De este modo, evito que determinados inquilinos acaparen la memoria compartida y provoquen involuntariamente desalojos en otros.<\/p>\n\n<h2>WordPress y WooCommerce: c\u00f3mo gestionar correctamente la cach\u00e9 de objetos<\/h2>\n\n<p>En las configuraciones de WordPress, los resultados de las consultas, los men\u00fas, los datos de inicio de sesi\u00f3n y los datos transitorios suelen almacenarse en la cach\u00e9 de objetos de Redis; estas claves son ideales para reglas basadas en el TTL. En las p\u00e1ginas din\u00e1micas, establezco TTL cortos para los contenidos ef\u00edmeros, de modo que <strong>volatile-lfu<\/strong> o <strong>volatile-lru<\/strong> crear espacio de forma espec\u00edfica. Si la p\u00e1gina se satura de fragmentos recurrentes, convence <strong>allkeys-lfu<\/strong>, porque los \u201eobjetos persistentes\u201c permanecen en la memoria y la tasa de cach\u00e9 se mantiene alta. Aqu\u00ed explico los errores t\u00edpicos que se producen en la cach\u00e9 de objetos: <a href=\"https:\/\/webhosting.de\/es\/error-de-configuracion-de-la-cache-de-objetos-redis-optimizacion-del-rendimiento-de-wordpress\/\">Error de configuraci\u00f3n en la cach\u00e9 de objetos<\/a>, all\u00ed hablo sobre TTL, espacios de nombres y tama\u00f1o de clave. Con estos ajustes evito fallos innecesarios y mantengo la p\u00e1gina en funcionamiento durante los picos de carga <strong>r\u00e1pido<\/strong>.<\/p>\n\n<p>Pautas pr\u00e1cticas: para fragmentos muy vol\u00e1tiles (por ejemplo, widgets personalizados o fragmentos del carrito de la compra), elijo TTLs que oscilan entre segundos y unos pocos minutos. Para estructuras de men\u00fa, categor\u00edas o widgets de la p\u00e1gina de inicio, conviene utilizar TTL m\u00e1s largos, siempre que un invalidador de cach\u00e9 se active de forma fiable ante cualquier cambio. Los cat\u00e1logos de WooCommerce suelen beneficiarse de tareas de precarga (Cron) que rellenan de forma espec\u00edfica las listas de productos m\u00e1s vendidos tras el vaciado de la cach\u00e9. Aseg\u00farate adem\u00e1s de que los plugins no escriban objetos de tama\u00f1o excesivo en la cach\u00e9 de objetos; si es necesario, fragmenta los datos (varias claves m\u00e1s peque\u00f1as en lugar de un bloque gigantesco) y optimiza los formatos de datos.<\/p>\n\n<h2>Optimizaci\u00f3n del sistema operativo y de los contenedores<\/h2>\n\n<p>Los valores predeterminados del sistema operativo y de los contenedores influyen indirectamente en los desalojos a trav\u00e9s de la disponibilidad de memoria y el comportamiento del RSS. Yo utilizo <code>vm.overcommit_memory=1<\/code>, desactiva las p\u00e1ginas enormes transparentes (THP) y evita el intercambio en las cach\u00e9s de producci\u00f3n para evitar el \u00abOOM-Killer\u00bb y reducir el \u00abRSS-Bloat\u00bb. En los contenedores, configuro el <code>memoria m\u00e1xima<\/code> por debajo del l\u00edmite del cgroup y dejo margen para los picos de RDB\/AOF, el b\u00fafer de replicaci\u00f3n y la fragmentaci\u00f3n. De este modo, evito que el proceso se cierre de forma brusca debido a picos breves, aunque la expulsi\u00f3n por parte de Redis a\u00fan pudiera surtir efecto. En la supervisi\u00f3n, observo, adem\u00e1s de <code>memoria_utilizada<\/code> tambi\u00e9n <code>memoria_utilizada_rss<\/code> y la relaci\u00f3n (<code>relaci\u00f3n_fragmentaci\u00f3n_mem<\/code>), para responder de forma eficaz a los efectos del sistema operativo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis-server-strategien-1794.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Desfragmentaci\u00f3n activa y reservas de memoria<\/h2>\n\n<p>Redis puede fragmentar la memoria internamente, lo que reduce la RAM disponible y provoca expulsiones antes de lo esperado; al activar la desfragmentaci\u00f3n, mitigo este comportamiento. Por lo tanto, preveo un margen por encima del consumo m\u00e1ximo esperado y compruebo peri\u00f3dicamente la <strong>Fragmentaci\u00f3n<\/strong> as\u00ed como el uso real. Los l\u00edmites demasiado estrictos reducen la tasa de aciertos, mientras que los l\u00edmites demasiado generosos conllevan el riesgo de que se produzcan errores tard\u00edos si la opci\u00f3n \u00abnoeviction\u00bb est\u00e1 activa. Peque\u00f1os pasos a la hora de ajustar <code>memoria m\u00e1xima<\/code> me ayudan a mantener los efectos dentro de unos l\u00edmites medibles y a no sobrecompensar a ciegas. De este modo, la planificaci\u00f3n del almacenamiento sigue siendo realista y la <strong>Actuaci\u00f3n<\/strong> constante.<\/p>\n\n<p>Con <code>activedefrag s\u00ed<\/code> y l\u00edmites m\u00e1s precisos (<em>ciclo m\u00ednimo\/m\u00e1ximo<\/em>) Aliso los picos de almacenamiento sin afectar demasiado al rendimiento. Prefiero activar la desfragmentaci\u00f3n fuera de los picos de carga y, a continuaci\u00f3n, eval\u00fao si las expulsiones se producen con menos frecuencia o de forma m\u00e1s ordenada.<\/p>\n\n<h2>Optimizar de forma selectiva las claves grandes y las estructuras de datos<\/h2>\n\n<p>Las claves desproporcionadamente grandes provocan agujeros en la cach\u00e9 y desencadenan expulsiones dr\u00e1sticas. Busco esos valores at\u00edpicos con <code>redis-cli --bigkeys<\/code> o <code>USO DE LA MEMORIA<\/code> por llave y uso <code>ESTAD\u00cdSTICAS DE MEMORIA<\/code>\/<code>MEMORY DOCTOR<\/code> Como primer diagn\u00f3stico. Medidas habituales: dividir los bloques JSON de gran tama\u00f1o, utilizar hash con codificaciones compactas (establecer los umbrales de Listpack\/Ziplist adecuadamente), replantearse la granularidad en los conjuntos y conjuntos ordenados, y eliminar activamente los elementos antiguos. En el caso de los flujos, presto atenci\u00f3n tanto al lado de entrada como al de consumo: con <code>XTRIM<\/code> Limito la longitud y evito que las PEL (entradas pendientes) crezcan indefinidamente procesando los consumidores de forma fiable y sistem\u00e1tica o limpiando los grupos inactivos.<\/p>\n\n<h2>Medidas concretas de ajuste para el d\u00eda a d\u00eda<\/h2>\n\n<p>Empiezo con una pol\u00edtica clara en funci\u00f3n de la carga de trabajo, establezco tiempos de vida (TTL) realistas y observo las tasas de aciertos y de expulsi\u00f3n a lo largo del d\u00eda. A continuaci\u00f3n, ajusto <code>memoria m\u00e1xima<\/code> a pasos moderados y me adapto <code>maxmemory-samples<\/code> para obtener mejores decisiones de LRU\/LFU. Si la tasa de aciertos desciende a pesar de haber aumentado la memoria, el problema suele estar en unos TTL demasiado cortos, en objetos demasiado grandes o en una granularidad de claves incorrecta; en ese caso, optimizo la <strong>Claves<\/strong> y elimino los datos innecesarios. En WordPress, compruebo el tama\u00f1o y el n\u00famero de objetos en la cach\u00e9, as\u00ed como el comportamiento de los plugins que escriben en la cach\u00e9 de forma demasiado agresiva. Con cada iteraci\u00f3n, la tasa de expulsi\u00f3n disminuye, los tiempos de respuesta se estabilizan y la cach\u00e9 asume la <strong>Carga<\/strong> fiable.<\/p>\n\n<h2>Gu\u00eda pr\u00e1ctica: Cuando los desalojos se salen de control<\/h2>\n\n<ul>\n  <li>Validar la alarma: tasa de aciertos\/fallos, expulsiones, mensajes de error (<em>El comando OOM no est\u00e1 permitido<\/em>), comprobar las latencias.<\/li>\n  <li>Medida inmediata: si es posible, de car\u00e1cter temporal <code>memoria m\u00e1xima<\/code> Aumentarlo ligeramente para ganar estabilidad; como alternativa, limitar el tr\u00e1fico (l\u00edmite de tasa\/contrapresi\u00f3n).<\/li>\n  <li>Ajustar la pol\u00edtica: en el caso de \u00abCache-only\u00bb, si es necesario, establecer en <strong>allkeys-lru<\/strong> Cambiar para liberar espacio de forma m\u00e1s agresiva; activar Lazyfree para evitar picos de latencia.<\/li>\n  <li>Limpieza selectiva: espacios de nombres irrelevantes mediante <code>SCAN<\/code> + <code>UNLINK<\/code> borrar; comprobar los TTL y aumentar los tiempos de vida demasiado cortos si la recarga sobrecarga la fuente primaria.<\/li>\n  <li>Identificar a los grandes consumidores: <code>--bigkeys<\/code>, <code>USO DE LA MEMORIA<\/code>, flujos grandes\/conjuntos ordenados; marcar las teclas de acceso r\u00e1pido para el precalentamiento.<\/li>\n  <li>Tener en cuenta la persistencia: \u00bfse est\u00e1 ejecutando una reescritura RDB\/AOF? Asegurarse de que haya suficiente margen o cambiar la ventana.<\/li>\n  <li>Estabilizaci\u00f3n posterior: ajuste preciso de <code>maxmemory-samples<\/code>, par\u00e1metros LFU, desfragmentaci\u00f3n; documentar el efecto de aprendizaje.<\/li>\n  <li>Prevenci\u00f3n a largo plazo: actualizar la planificaci\u00f3n de la capacidad, implantar instancias independientes para las distintas pol\u00edticas y ajustar las alertas de m\u00e9tricas.<\/li>\n<\/ul>\n\n<h2>Resumen final<\/h2>\n\n<p>En la pr\u00e1ctica, para los cach\u00e9s puros suelo recurrir a <strong>allkeys-lfu<\/strong>, para ver contenidos nuevos en <strong>allkeys-lru<\/strong>, para datos mixtos en \u00abvolatile-policies\u00bb y para datos sensibles en \u00abnoeviction\u00bb. Sigue siendo fundamental contar con TTL claros, reservas de memoria bien gestionadas y una supervisi\u00f3n visible, para que las expulsiones se realicen de forma predecible y sin sorpresas. Con esta estructura evito la p\u00e9rdida de datos, mantengo alta la tasa de aciertos y reacciono con tranquilidad ante los picos de carga. La tabla anterior ayuda al principio; despu\u00e9s, las m\u00e9tricas se encargan del ajuste fino. De este modo, cada entorno de alojamiento encuentra una soluci\u00f3n sencilla y resistente <strong>Estrategia<\/strong> para la evacuaci\u00f3n de Redis y ofrece p\u00e1ginas de forma r\u00e1pida y constante <strong>de<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Las pol\u00edticas de expulsi\u00f3n de Redis determinan qu\u00e9 claves se eliminan cuando la memoria est\u00e1 llena. Descubre qu\u00e9 estrategia es la m\u00e1s adecuada para servidores de alojamiento, WordPress y configuraciones de cach\u00e9.<\/p>","protected":false},"author":1,"featured_media":20485,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20492","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"155","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Redis Eviction","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20485","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20492","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=20492"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20492\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20485"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20492"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20492"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20492"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}