{"id":20962,"date":"2026-08-24T15:04:34","date_gmt":"2026-08-24T13:04:34","guid":{"rendered":"https:\/\/webhosting.de\/redis-lfu-vs-lru-eviction-policies-vergleich-cache-optimierung\/"},"modified":"2026-08-24T15:04:34","modified_gmt":"2026-08-24T13:04:34","slug":"comparacao-entre-as-politicas-de-eviccao-lfu-e-lru-do-redis-otimizacao-da-cache","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/redis-lfu-vs-lru-eviction-policies-vergleich-cache-optimierung\/","title":{"rendered":"Redis LFU vs LRU: Qual \u00e9 a pol\u00edtica de evic\u00e7\u00e3o mais adequada?"},"content":{"rendered":"<p>O LFU e o LRU do Redis determinam quais as chaves que s\u00e3o removidas da cache quando os recursos s\u00e3o escassos \u2013 e, assim, decidem sobre <strong>Taxa de acerto<\/strong>, tempo de resposta e consumo de mem\u00f3ria. Vou mostrar-te quando \u00e9 que a pol\u00edtica LFU, orientada para a frequ\u00eancia, ou a pol\u00edtica LRU, orientada para a atualidade, \u00e9 mais adequada, como as configurar e quais os efeitos que as pol\u00edticas \u00aballkeys-lfu\u00bb e \u00aballkeys-lru\u00bb t\u00eam no dia-a-dia; a palavra-chave principal <strong>Redis LFU<\/strong> est\u00e1 no centro desta quest\u00e3o.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>Rec\u00eancia<\/strong> vs. <strong>Frequ\u00eancia<\/strong>: O LRU d\u00e1 prioridade aos acessos mais recentes, enquanto o LFU d\u00e1 prioridade aos acessos mais frequentes.<\/li>\n  <li><strong>Aproxima\u00e7\u00e3o<\/strong> No Redis: ambas as pol\u00edticas funcionam com amostras atrav\u00e9s da vari\u00e1vel `maxmemory-samples`.<\/li>\n  <li><strong>Cargas de trabalho<\/strong> escolher: Sess\u00f5es\/Pain\u00e9is \u2192 LRU, Mais vendidos\/Classifica\u00e7\u00f5es \u2192 LFU.<\/li>\n  <li><strong>Afina\u00e7\u00e3o<\/strong> \u00c9 importante definir corretamente os par\u00e2metros: lfu-decay-time, maxmemory e maxmemory-samples.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong> Necess\u00e1rio: verificar continuamente a taxa de acertos, as expuls\u00f5es por segundo e a lat\u00eancia.<\/li>\n<\/ul>\n\n<h2>Como funciona a evic\u00e7\u00e3o no Redis<\/h2>\n\n<p>O Redis armazena os dados na RAM; se o processo <strong>mem\u00f3ria m\u00e1xima<\/strong>, tem de eliminar chaves. \u00c9 precisamente aqui que entram em a\u00e7\u00e3o pol\u00edticas como a \u00aballkeys-lru\u00bb e a \u00aballkeys-lfu\u00bb, que determinam quais as entradas que t\u00eam de ser eliminadas. Concentro-me nestas duas variantes porque t\u00eam em conta todo o conjunto de dados, e n\u00e3o apenas as chaves com TTL. O Redis seleciona a chave a eliminar atrav\u00e9s de uma amostra, que pode definir com <strong>maxmemory-samples<\/strong> controla; um maior n\u00famero de amostras aumenta a precis\u00e3o, mas consome recursos da CPU. Esta abordagem proporciona bons resultados em grandes espa\u00e7os de chaves, sem tornar a gest\u00e3o demasiado dispendiosa.<\/p>\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\/redis-eviction-policies-9472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Informa\u00e7\u00f5es internas: como o Redis implementa os algoritmos LRU e LFU<\/h2>\n\n<p>Ambas as pol\u00edticas funcionam no Redis <strong>aproximadamente<\/strong>, para manter uma velocidade constante. O LRU armazena, para cada objeto, um registo da data e hora do \u00faltimo acesso. Na evic\u00e7\u00e3o, o Redis faz uma amostragem e descarta o candidato \u201emais antigo\u201c da sele\u00e7\u00e3o. Na pr\u00e1tica, isto \u00e9 extremamente eficiente e suficientemente preciso, desde que se escolha o tamanho da amostra adequado ao espa\u00e7o de chaves.<\/p>\n\n<p><strong>Redis LFU<\/strong> complementa esta ideia com uma <strong>medidor de frequ\u00eancia compacto<\/strong>, que ao longo do tempo <strong>envelhece<\/strong> (Decay). Cada acesso aumenta o contador de utiliza\u00e7\u00f5es de forma n\u00e3o linear, mas sim atenuada, para que as fases de pico isoladas n\u00e3o saturam o contador de forma permanente. Ao mesmo tempo, uma decad\u00eancia temporal garante que a popularidade passada acabe por perder peso. Atrav\u00e9s de par\u00e2metros como <em>lfu-decay-time<\/em> (a que velocidade a hist\u00f3ria fica desatualizada) e um fator de registo interno (em que medida os contadores aumentam a cada acesso) \u00e9 que deves equilibrar <em>rapidez de rea\u00e7\u00e3o<\/em> contra <em>Estabilidade<\/em> da prioriza\u00e7\u00e3o. Regra a reter: valores de decaimento mais baixos \u2192 adapta\u00e7\u00e3o mais r\u00e1pida; valores mais elevados \u2192 prioridades mais lentas, mas mais est\u00e1veis.<\/p>\n\n<h2>LRU no Redis: princ\u00edpio, vantagens, armadilhas<\/h2>\n\n<p>O LRU remove o elemento mais antigo <strong>n\u00e3o utilizados<\/strong> Chaves e, assim, d\u00e1 prioridade \u00e0 atualidade. Esta l\u00f3gica adapta-se a padr\u00f5es com localiza\u00e7\u00e3o temporal, como sess\u00f5es, pain\u00e9is em tempo real ou respostas de API a curto prazo. O Redis utiliza um LRU aproximado: as entradas t\u00eam uma marca temporal e as amostragens selecionam o candidato mais antigo \u2013 de forma r\u00e1pida e compreens\u00edvel. O LRU reage rapidamente \u00e0s altera\u00e7\u00f5es, porque as chaves utilizadas recentemente permanecem no topo e as mais antigas s\u00e3o removidas. Podem tornar-se problem\u00e1ticas as grandes varreduras pontuais, que enchem a cache com valores de curta dura\u00e7\u00e3o e chaves importantes que est\u00e3o temporariamente inativas <strong>reprimir<\/strong>.<\/p>\n\n<p>Dica pr\u00e1tica: se utilizares o LRU e executares regularmente consultas em massa \u201efrias\u201c (por exemplo, relat\u00f3rios de back-office), isola essas cargas de trabalho em <em>separado<\/em> Caches ou planeia-as de forma mais generosa <strong>mem\u00f3ria m\u00e1xima<\/strong>-reservas. Desta forma, evitas a \u00abpolui\u00e7\u00e3o da cache\u00bb, em que dados valiosos, que em breve voltar\u00e3o a ser necess\u00e1rios, s\u00e3o substitu\u00eddos.<\/p>\n\n<h2>LFU no Redis: princ\u00edpio, vantagens e armadilhas<\/h2>\n\n<p>O LFU remove chaves com baixa <strong>Frequ\u00eancia de utiliza\u00e7\u00e3o<\/strong> protegendo assim as \u201eteclas de atalho\u201c a longo prazo. O contador interno cresce de forma logar\u00edtmica e envelhece com o tempo (decad\u00eancia), para que a popularidade antiga n\u00e3o conte para sempre. Isto leva a uma pondera\u00e7\u00e3o equilibradora: os dados utilizados com frequ\u00eancia permanecem armazenados por mais tempo, enquanto valores at\u00edpicos isolados quase n\u00e3o alteram a prioridade. O LFU proporciona frequentemente uma taxa de acertos mais elevada em cat\u00e1logos, classifica\u00e7\u00f5es ou caches de caracter\u00edsticas, uma vez que mant\u00e9m na mem\u00f3ria as chaves comprovadas. No entanto, reage de forma mais lenta a novas tend\u00eancias, raz\u00e3o pela qual o ajuste de <strong>lfu-decay-time<\/strong> continua a ser importante.<\/p>\n\n<p>Para <strong>Tend\u00eancias em alta e em baixa<\/strong> (por exemplo, campanhas de marketing) aplica-se o seguinte: defina o \u00abdecay\u00bb de forma a que uma nova tend\u00eancia tenha um impacto percet\u00edvel, sem que o ru\u00eddo pontual reorganize constantemente a cache. Em muitos projetos, o que tem dado bons resultados \u00e9: come\u00e7ar de forma conservadora e, em seguida, acelerar gradualmente at\u00e9 que a taxa de acertos se mantenha est\u00e1vel sob carga.<\/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_lfu_vs_lru_3948.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compara\u00e7\u00e3o: Rec\u00eancia vs. Frequ\u00eancia no dia-a-dia<\/h2>\n\n<p>No fundo, o LRU distingue \u201equando foi utilizado pela \u00faltima vez\u201c e o LFU \u201equantas vezes foi utilizado\u201c \u2013 eu escolho com base nos dados reais <strong>Cargas de trabalho<\/strong>. No caso de dados vol\u00e1teis e pr\u00f3ximos do utilizador, o LRU costuma funcionar de forma mais natural, uma vez que os acessos recentes antecipam frequentemente os acessos futuros. Para dados de produtos ou configura\u00e7\u00f5es populares, o LFU funciona melhor, porque o que conta \u00e9 a popularidade duradoura. Em cen\u00e1rios mistos, separo as caches por tipos de dados e aplico pol\u00edticas diferentes. A tabela seguinte resume sucintamente as diferen\u00e7as e d\u00e1-te uma vis\u00e3o r\u00e1pida <strong>Apoio \u00e0 decis\u00e3o<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Aspeto<\/th>\n      <th>LRU (allkeys-lru)<\/th>\n      <th>LFU (allkeys-lfu)<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Prioridade<\/td>\n      <td><strong>Atualidade<\/strong> o n\u00famero de visitas<\/td>\n      <td><strong>Frequ\u00eancia<\/strong> o n\u00famero de visitas<\/td>\n    <\/tr>\n    <tr>\n      <td>Rea\u00e7\u00e3o \u00e0 mudan\u00e7a de padr\u00e3o<\/td>\n      <td>Depressa, porque o que conta \u00e9 a \u00faltima utiliza\u00e7\u00e3o<\/td>\n      <td>Moderado, uma vez que o hist\u00f3rico tem influ\u00eancia<\/td>\n    <\/tr>\n    <tr>\n      <td>Cargas de trabalho recomendadas<\/td>\n      <td>Sess\u00f5es, pain\u00e9is de controlo, APIs em tempo real<\/td>\n      <td>Best-sellers, classifica\u00e7\u00f5es, caches em destaque<\/td>\n    <\/tr>\n    <tr>\n      <td>Sensibilidade \u00e0 \u201epolui\u00e7\u00e3o\u201c<\/td>\n      <td>Bastante elevado em digitaliza\u00e7\u00f5es de grande dimens\u00e3o<\/td>\n      <td>Bastante reduzida gra\u00e7as ao contador de frequ\u00eancias<\/td>\n    <\/tr>\n    <tr>\n      <td>Parafusos de ajuste<\/td>\n      <td><strong>maxmemory-samples<\/strong><\/td>\n      <td><strong>lfu-decay-time<\/strong>, maxmemory-samples<\/td>\n    <\/tr>\n    <tr>\n      <td>Explicabilidade<\/td>\n      <td>Muito intuitivo<\/td>\n      <td>Bem, no que diz respeito ao Decay<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Impactos no desempenho na pr\u00e1tica<\/h2>\n\n<p>No caso de pequenos conjuntos de dados, a diferen\u00e7a costuma ser <strong>baixo<\/strong>; \u00e0 medida que o tamanho aumenta, o joio separa-se do trigo. O LRU convence pelo baixo custo de CPU da aproxima\u00e7\u00e3o e por uma causa clara: uma chave \u00e9 eliminada porque foi a \u00faltima a ficar sem ser utilizada. O LFU destaca-se em acessos consistentes, uma vez que as chaves \u00abquentes\u00bb permanecem seguramente na RAM e a taxa de acertos aumenta de forma mensur\u00e1vel. O desafio reside na compreens\u00e3o necess\u00e1ria dos contadores e do decaimento, para que n\u00e3o reajas nem de forma demasiado lenta nem demasiado agressiva. Verifico os efeitos atrav\u00e9s de an\u00e1lise de desempenho e m\u00e9tricas, em vez de me basear apenas na intui\u00e7\u00e3o <strong>decidir<\/strong>.<\/p>\n\n<p>Planeia tamb\u00e9m o <strong>Arranque a frio<\/strong> : Ap\u00f3s rein\u00edcios ou implementa\u00e7\u00f5es, a cache fica vazia ou \u201edesinformada\u201c quanto \u00e0s frequ\u00eancias. A LRU estabiliza-se rapidamente com base na localidade a curto prazo. A LFU, por natureza, necessita de um certo per\u00edodo de aquecimento para identificar as verdadeiras \u00abchaves quentes\u00bb. Estrat\u00e9gias como <em>Pr\u00e9-aquecimento<\/em> (carregar proativamente as chaves importantes) ou um aumento gradual do tr\u00e1fego ajudam a atenuar a lat\u00eancia inicial e as falhas.<\/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-policies-vergleich-4928.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configura\u00e7\u00e3o e ajuste: as op\u00e7\u00f5es mais importantes<\/h2>\n\n<p>Escolho a pol\u00edtica atrav\u00e9s de <strong>pol\u00edtica de mem\u00f3ria m\u00e1xima<\/strong>, normalmente allkeys-lru ou allkeys-lfu, mais raramente variantes vol\u00e1teis com foco no TTL. Com <strong>mem\u00f3ria m\u00e1xima<\/strong> Defino o limite r\u00edgido a partir do qual a evic\u00e7\u00e3o come\u00e7a e dimensiono-o em fun\u00e7\u00e3o do conjunto de dados, acrescido de uma margem de seguran\u00e7a. Controlo a dimens\u00e3o da amostra atrav\u00e9s de <strong>maxmemory-samples<\/strong>; valores mais elevados melhoram a sele\u00e7\u00e3o, mas consomem recursos da CPU. Para o LFU, \u00e9 <strong>lfu-decay-time<\/strong> \u00e9 fundamental, porque determina a rapidez com que os acessos antigos perdem import\u00e2ncia e os novos ganham peso. Podes encontrar aqui um guia detalhado sobre o dimensionamento da mem\u00f3ria: <a href=\"https:\/\/webhosting.de\/pt\/gestao-de-memoria-do-redis-configurar-a-memoria-de-forma-otimizada-desempenho-cache\/\">Configurar a mem\u00f3ria de forma ideal<\/a>.<\/p>\n\n<h3>Sugest\u00f5es concretas para a pr\u00e1tica<\/h3>\n<p>Para um arranque r\u00e1pido, trabalho com predefini\u00e7\u00f5es claras e fa\u00e7o itera\u00e7\u00f5es sob carga:<\/p>\n<ul>\n  <li>allkeys-lru + maxmemory-samples 7\u201310 para dados vol\u00e1teis e pr\u00f3ximos do utilizador<\/li>\n  <li><strong>Redis LFU<\/strong> (allkeys-lfu) + lfu-decay-time conservador (por exemplo, um valor moderado) para cargas de trabalho est\u00e1veis com teclas de atalho<\/li>\n<\/ul>\n<p>Definir a configura\u00e7\u00e3o em tempo de execu\u00e7\u00e3o:<\/p>\n<pre><code>CONFIG SET maxmemory 8gb\nCONFIG SET maxmemory-policy allkeys-lru\nCONFIG SET maxmemory-samples 10\n# Mudan\u00e7a para LFU:\nCONFIG SET maxmemory-policy allkeys-lfu\nCONFIG SET lfu-decay-time 5\n<\/code><\/pre>\n<p>No ficheiro redis.conf, define-se essas mesmas op\u00e7\u00f5es de forma permanente. Eu testo primeiro as altera\u00e7\u00f5es no ambiente de teste com uma carga representativa, antes de as aplicar no ambiente de produ\u00e7\u00e3o.<\/p>\n\n<h3>Selecionar o tamanho da amostra<\/h3>\n<p><strong>maxmemory-samples<\/strong> \u00c9 um par\u00e2metro de ajuste fi\u00e1vel: valores mais elevados melhoram a qualidade dos resultados dos candidatos \u00e0 evic\u00e7\u00e3o, mas consomem CPU. Como regra geral, come\u00e7o com 7\u201310 em espa\u00e7os de chaves grandes e s\u00f3 reduzo se o tempo de CPU estiver escasso. Em espa\u00e7os de chaves pequenos, 5 amostras costumam ser suficientes.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o e m\u00e9tricas: medir em vez de adivinhar<\/h2>\n\n<p>Estou sempre atento <strong>Taxa de acerto<\/strong>, despejos, lat\u00eancias e utiliza\u00e7\u00e3o de mem\u00f3ria, para avaliar a intera\u00e7\u00e3o entre estes fatores. Se as evic\u00e7\u00f5es aumentarem significativamente, verifico as reservas de RAM, as estrat\u00e9gias de TTL e a pol\u00edtica selecionada. Uma taxa de acertos em queda indica frequentemente que mudan\u00e7as nos padr\u00f5es de utiliza\u00e7\u00e3o est\u00e3o a enfraquecer a pol\u00edtica atual ou que os conjuntos de dados n\u00e3o est\u00e3o a ser armazenados em cache de forma suficientemente separada. Os picos de lat\u00eancia indicam, por vezes, que a <strong>Amostras<\/strong> ou a uma evic\u00e7\u00e3o demasiado agressiva. Os testes de carga regulares ajudam-me a encontrar o equil\u00edbrio certo entre a carga da CPU, o limite de mem\u00f3ria e a taxa de acerto.<\/p>\n\n<p>Comandos pr\u00e1ticos para verifica\u00e7\u00f5es r\u00e1pidas:<\/p>\n<pre><code>INFO stats     # keyspace_hits, keyspace_misses, evicted_keys, expired_keys\nINFO memory    # used_memory, fragmentation, allocator_overhead\nLATENCY DOCTOR # Notas sobre picos, por exemplo, bifurca\u00e7\u00e3o ou E\/S<\/code><\/pre>\n<p>O <strong>Taxa de acerto<\/strong> Calculo-o como \u00abacertos \/ (acertos + erros)\u00bb. Uma taxa em queda, acompanhada de um aumento dos despejos, constitui um sinal de alerta. <em>chaves_despejadas<\/em> em rela\u00e7\u00e3o ao tr\u00e1fego e <em>mem\u00f3ria_utilizada<\/em> indica se a pol\u00edtica tem de ser ativada com frequ\u00eancia. Com <em>Chave \u00abMEMORY USAGE\u00bb<\/em> identificas objetos de tamanho excessivo que ocupam uma parte desproporcional da tua cache.<\/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\/tech_office_redis_policy_9123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aspectos relacionados com o alojamento e a escalabilidade: escolher a plataforma de forma consciente<\/h2>\n\n<p>O Redis revela os seus pontos fortes numa <strong>de alto desempenho<\/strong> Plataforma com bastante mem\u00f3ria RAM, baixa lat\u00eancia e liga\u00e7\u00e3o de rede fi\u00e1vel. Em projetos em expans\u00e3o, evito o funcionamento cont\u00ednuo a plena carga, porque isso faz com que a evic\u00e7\u00e3o seja acionada com demasiada frequ\u00eancia e a taxa de acertos seja prejudicada. Uma boa <a href=\"https:\/\/webhosting.de\/pt\/estrategia-de-eviccao-do-cache-de-alojamento-do-redis\/\">Estrat\u00e9gia de alojamento<\/a> garante que as pol\u00edticas sejam aplicadas quando necess\u00e1rio e n\u00e3o funcionem de forma cont\u00ednua. Nas compara\u00e7\u00f5es, aposto em fornecedores premium como o webhoster.de, cuja infraestrutura suporta bem cargas elevadas e permite uma capacidade previs\u00edvel. Assim, a plataforma contribui diretamente para menos evictions e melhor <strong>Tempos de resposta<\/strong> e um desempenho mais constante.<\/p>\n\n<h3>Aspectos relacionados com clusters e r\u00e9plicas<\/h3>\n<p>Em configura\u00e7\u00f5es de sharding (por exemplo, Redis Cluster), as decis\u00f5es de evic\u00e7\u00e3o s\u00e3o aplicadas <strong>por n\u00f3<\/strong>. Ou seja: a margem de seguran\u00e7a, a pol\u00edtica e o ajuste t\u00eam de ser adequados para cada n\u00f3, e n\u00e3o apenas \u201eem m\u00e9dia\u201c. As chaves de acesso r\u00e1pido que est\u00e3o distribu\u00eddas de forma desigual pelos slots podem levar determinados n\u00f3s ao limite mais cedo. Por isso, planeie buffers por fragmento e monitorize as evic\u00e7\u00f5es ao n\u00edvel dos n\u00f3s. As r\u00e9plicas assumem o estado dos dados, incluindo as chaves eliminadas; tenha em conta, nos testes de carga, que a replica\u00e7\u00e3o adicional pode aumentar as lat\u00eancias, sem que a pol\u00edtica em si seja a respons\u00e1vel por isso.<\/p>\n\n<h2>Estrat\u00e9gias TTL e pol\u00edticas mistas<\/h2>\n\n<p>Com o TTL, protejo os de longa dura\u00e7\u00e3o <strong>Configura\u00e7\u00f5es<\/strong> e dou prioridade aos dados sens\u00edveis ao tempo e de curta dura\u00e7\u00e3o. Se utilizar o \u00abvolatile-lru\u00bb ou o \u00abvolatile-lfu\u00bb, o Redis apenas substitui as chaves com tempo de validade \u2013 o que \u00e9 \u00fatil quando o cache e os valores permanentes coexistem. Costumo separar as caches por tipos de dados: sess\u00f5es em LRU, cat\u00e1logos de produtos em LFU, para tirar partido dos respetivos pontos fortes. Uma escolha inteligente do TTL evita que entradas desatualizadas ocupem mem\u00f3ria RAM desnecessariamente e provoquem evic\u00e7\u00f5es. Assim, mantenho a mem\u00f3ria limpa, sem perder dados \u00fateis <strong>Teclas de atalho<\/strong> para perder.<\/p>\n\n<p>Importante: uma pol\u00edtica \u00e9 v\u00e1lida <strong>por inst\u00e2ncia<\/strong>. \u00c9 poss\u00edvel aplicar pol\u00edticas diferentes consoante o tipo de dados de forma fi\u00e1vel, utilizando inst\u00e2ncias Redis separadas ou caches claramente delimitadas. Os namespaces, por si s\u00f3, n\u00e3o alteram a pol\u00edtica; no entanto, ajudam na invalida\u00e7\u00e3o seletiva e na medi\u00e7\u00e3o.<\/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\/entwickler_schreibtisch_6354.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>An\u00e1lise pr\u00e1tica: Come\u00e7ar com LRU, transi\u00e7\u00e3o seletiva para LFU<\/h2>\n\n<p>Costumo come\u00e7ar com <strong>LRU<\/strong>, porque \u00e9 intuitivo e proporciona resultados r\u00e1pidos. Em seguida, identifico as caches com teclas de atalho permanentes e mudo seletivamente para o LFU. Esta abordagem minimiza o risco, porque s\u00f3 se fazem altera\u00e7\u00f5es nos casos em que os padr\u00f5es de dados realmente beneficiam da l\u00f3gica de frequ\u00eancia. Com canaries e testes A\/B, medo a taxa de acertos e a lat\u00eancia antes e depois da mudan\u00e7a. Assim, otimizo passo a passo, em vez de alterar todo o <strong>Plataforma<\/strong> fazer a transi\u00e7\u00e3o de uma s\u00f3 vez.<\/p>\n\n<h3>Um percurso de migra\u00e7\u00e3o comprovado<\/h3>\n<ul>\n  <li>Estabelecer uma linha de base: registar a taxa de acerto atual, as expuls\u00f5es e os percentis 95.\u00ba e 99.\u00ba da lat\u00eancia.<\/li>\n  <li>Selecionar a cache piloto: \u00e1rea est\u00e1vel, com maior volume de leitura e teclas de atalho bem definidas.<\/li>\n  <li>Ativar o LFU, <strong>lfu-decay-time<\/strong> definir de forma conservadora, <strong>maxmemory-samples<\/strong> aumentar.<\/li>\n  <li>Prever uma fase de aquecimento e acompanhar o processo at\u00e9 que os valores se estabilizem.<\/li>\n  <li>Comparar as m\u00e9tricas e s\u00f3 depois proceder ao ajuste, em pequenos passos.<\/li>\n<\/ul>\n\n<h2>Dificuldades frequentes nas aplica\u00e7\u00f5es (por exemplo, o WordPress)<\/h2>\n\n<p>Nos sistemas de conte\u00fado, os TTL incorretos e os <strong>Chaves<\/strong> o que pode rapidamente levar a uma avalanche de \u00abevictions\u00bb. Verifica se as p\u00e1ginas din\u00e2micas est\u00e3o a ser armazenadas em cache sem querer ou se valores demasiado grandes est\u00e3o a esgotar a mem\u00f3ria. Certifica-te de que o comportamento de invalida\u00e7\u00e3o ap\u00f3s as publica\u00e7\u00f5es \u00e9 correto, para que os conte\u00fados desatualizados desapare\u00e7am e se liberte espa\u00e7o. Este guia ajuda-te a identificar erros t\u00edpicos no ambiente do CMS: <a href=\"https:\/\/webhosting.de\/pt\/erro-de-configuracao-do-cache-de-objetos-do-redis-otimizacao-do-desempenho-do-wordpress\/\">Erro no cache de objetos<\/a>. Se invalidares corretamente, definires TTLs realistas e escolheres a pol\u00edtica adequada, a taxa de acertos e <strong>Velocidade<\/strong> mensur\u00e1vel.<\/p>\n\n<p>Outros anti-padr\u00f5es da pr\u00e1tica:<\/p>\n<ul>\n  <li><strong>Grandes im\u00f3veis individuais<\/strong> (por exemplo, blocos enormes de JSON) ocupam o espa\u00e7o de muitas chaves pequenas e \u00fateis. Solu\u00e7\u00e3o: dividir os dados e armazenar em cache apenas os segmentos efetivamente utilizados.<\/li>\n  <li><strong>Fog\u00e3o trovejante<\/strong>: Muitas falhas simult\u00e2neas na mesma chave. Solu\u00e7\u00e3o: aglomera\u00e7\u00e3o de pedidos\/bloqueios, pequenas varia\u00e7\u00f5es nos TTLs, para que as renova\u00e7\u00f5es ocorram de forma distribu\u00edda.<\/li>\n  <li><strong>Polui\u00e7\u00e3o por digitaliza\u00e7\u00e3o<\/strong>: Leituras em lote sem reutiliza\u00e7\u00e3o. Solu\u00e7\u00e3o: Inst\u00e2ncia\/espa\u00e7o de nomes separado, LRU nesse espa\u00e7o com mem\u00f3ria mais generosa ou optar por n\u00e3o armazenar as cargas de trabalho em cache.<\/li>\n  <li><strong>Invalida\u00e7\u00e3o pouco clara<\/strong>: As vers\u00f5es antigas ocupam espa\u00e7o na cache. Solu\u00e7\u00e3o: esquemas de chaves claros (por exemplo, prefixos de vers\u00e3o) e percursos determin\u00edsticos de invalida\u00e7\u00e3o.<\/li>\n<\/ul>\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-eviction-policy-7264.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Resumo: Como fa\u00e7o a escolha<\/h2>\n\n<p>Eu fixo <strong>LRU<\/strong> quando a atualidade constitui a melhor heur\u00edstica para acessos futuros \u2013 por exemplo, no caso de sess\u00f5es, pain\u00e9is e APIs em tempo real. Recorro a isso <strong>LFU<\/strong>, quando existem teclas de atalho claras e permanentes que tamb\u00e9m pretendo proteger em picos de carga. A monitoriza\u00e7\u00e3o mostra-me se as evic\u00e7\u00f5es est\u00e3o a tornar-se excessivas ou se a taxa de acerto est\u00e1 a diminuir; nesse caso, ajusto as amostras, os TTLs e o decaimento. Com uma escolha criteriosa da plataforma, um limite de mem\u00f3ria bem definido e caches separados por tipo de dados, consigo obter sempre o m\u00e1ximo rendimento. Desta forma, o cache mant\u00e9m-se r\u00e1pido, previs\u00edvel e adequado ao padr\u00e3o de acesso \u2013 sem qualquer margem para suposi\u00e7\u00f5es.<\/p>","protected":false},"excerpt":{"rendered":"<p>Para configurar a tua cache da melhor forma, deves compreender como funciona a evic\u00e7\u00e3o do Redis com o Redis LFU e o Redis LRU \u2013 este artigo apresenta-te uma compara\u00e7\u00e3o direta e ajuda-te a escolher a pol\u00edtica adequada.<\/p>","protected":false},"author":1,"featured_media":20955,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20962","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":"143","_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 LFU","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":"20955","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20962","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=20962"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20962\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20955"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20962"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20962"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20962"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}