{"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-eviccao-do-cache-de-alojamento-do-redis","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/redis-eviction-hosting-cache-strategie\/","title":{"rendered":"Pol\u00edticas de evic\u00e7\u00e3o do Redis para servidores de alojamento: a estrat\u00e9gia certa"},"content":{"rendered":"<p>A fun\u00e7\u00e3o de evic\u00e7\u00e3o do Redis determina, nos servidores de alojamento, quais as chaves que devem ser removidas quando a mem\u00f3ria est\u00e1 escassa e quais as que permanecem na cache, para que as consultas sejam respondidas de forma r\u00e1pida e fi\u00e1vel. Vou mostrar-te estrat\u00e9gias concretas para escolheres a pol\u00edtica adequada, <strong>configuras<\/strong> e assegura isso atrav\u00e9s da monitoriza\u00e7\u00e3o.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<p>Antes de entrar em pormenores, vou resumir brevemente as decis\u00f5es mais importantes, para que possas <strong>Pol\u00edtica<\/strong> podes definir rapidamente. Os pontos que se seguem destinam-se a administradores de alojamento, profissionais de DevOps e gestores de sites com foco no desempenho. Tenho em conta cargas de trabalho t\u00edpicas, desde o cache puro at\u00e9 conjuntos de dados mistos com TTL e chaves permanentes. Desta forma, mant\u00e9ns o equil\u00edbrio certo entre a quota de cache, a seguran\u00e7a dos dados e a previsibilidade. Com estes pontos-chave, poder\u00e1s tomar uma <strong>claro<\/strong> Escolha o teu servidor.<\/p>\n<ul>\n  <li><strong>Allkeys-LFU<\/strong>: Para cargas de trabalho de cache de grande volume com acessos distribu\u00eddos de forma muito desigual.<\/li>\n  <li><strong>Allkeys-LRU<\/strong>: Para conte\u00fados atualizados e um comportamento bem previs\u00edvel.<\/li>\n  <li><strong>Volatile-LRU\/LFU<\/strong>: Elimina apenas as chaves TTL, protegendo os dados permanentes.<\/li>\n  <li><strong>Noeviction<\/strong>: Para dados cr\u00edticos; erros de escrita em vez de perda de chaves.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong>: Acompanhar constantemente a taxa de acertos, a mem\u00f3ria e as evacua\u00e7\u00f5es.<\/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>O que significa, concretamente, a \u00abevic\u00e7\u00e3o\u00bb no Redis?<\/h2>\n\n<p>Por \u00abevic\u00e7\u00e3o no Redis\u00bb entende-se a remo\u00e7\u00e3o de chaves assim que o limite definido <code>mem\u00f3ria m\u00e1xima<\/code> foi atingido e o Redis tem de libertar espa\u00e7o para que possam ser gravados novos dados. Eu controlo esse comportamento atrav\u00e9s da configura\u00e7\u00e3o <code>pol\u00edtica de mem\u00f3ria m\u00e1xima<\/code>, as op\u00e7\u00f5es como <code>allkeys-lru<\/code>, <code>allkeys-lfu<\/code>, <code>allkeys-random<\/code> ou o <code>volatile-*<\/code>-oferece v\u00e1rias variantes; cada op\u00e7\u00e3o d\u00e1 prioridade a chaves diferentes na remo\u00e7\u00e3o. O LRU protege as chaves utilizadas mais recentemente, o LFU d\u00e1 prefer\u00eancia aos dados utilizados com frequ\u00eancia, o Random seleciona aleatoriamente por amostragem e as pol\u00edticas \u00abvolatile\u00bb consideram apenas as chaves com tempo de validade (TTL). Importante: o Redis toma as suas decis\u00f5es de elimina\u00e7\u00e3o de forma eficiente atrav\u00e9s de amostragem, o que mant\u00e9m a lat\u00eancia baixa e garante a fiabilidade do sistema <strong>controlos<\/strong>. S\u00f3 quando a mem\u00f3ria come\u00e7a a escassear \u00e9 que a evic\u00e7\u00e3o entra em a\u00e7\u00e3o; at\u00e9 l\u00e1, o Redis comporta-se como um armazenamento de dados em mem\u00f3ria normal, com <strong>Cache<\/strong>-vantagens.<\/p>\n\n<h2>Escolha da pol\u00edtica adequada para servidores de alojamento<\/h2>\n\n<p>A melhor pol\u00edtica resulta da quest\u00e3o de saber quais os dados que t\u00eam de permanecer na mem\u00f3ria e quais os que o sistema pode recalcular. Se o Redis servir exclusivamente como cache, uma estrat\u00e9gia \u00aballkeys\u00bb \u00e9 adequada, porque, em caso de d\u00favida, cada entrada \u00e9 recriada a partir da fonte original; nesse caso, ganha pontos <strong>allkeys-lfu<\/strong> em caso de acessos desiguais e <strong>allkeys-lru<\/strong> no caso de conte\u00fados mais recentes. Se a inst\u00e2ncia contiver dados mistos, prefiro <strong>vol\u00e1til-lru<\/strong> ou <strong>volatile-lfu<\/strong>, para que apenas as chaves TTL sejam eliminadas e os dados permanentes permane\u00e7am inalterados. Se os dados forem cr\u00edticos, opto por <strong>noeviction<\/strong>, mas aceito que os comandos de grava\u00e7\u00e3o falhem quando a mem\u00f3ria estiver totalmente ocupada e que a aplica\u00e7\u00e3o tenha de reagir corretamente. Esta l\u00f3gica de decis\u00e3o simples torna o funcionamento previs\u00edvel, mant\u00e9m o risco de erros baixo e proporciona-me uma vis\u00e3o clara <strong>Guarda-corpos<\/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>Guia pr\u00e1tico: Cargas de trabalho exclusivamente em cache vs. cargas de trabalho mistas<\/h2>\n\n<p>Para cargas de trabalho exclusivamente de cache, procuro obter uma elevada taxa de acertos e aceito que as substitui\u00e7\u00f5es representem um risco m\u00ednimo, uma vez que os dados s\u00e3o rapidamente recarregados a partir da fonte prim\u00e1ria. Em tais ambientes, o <strong>allkeys-lfu<\/strong> \u00e9 frequentemente o melhor compromisso, uma vez que os objetos utilizados com frequ\u00eancia permanecem na mem\u00f3ria durante muito tempo, enquanto os dados secund\u00e1rios s\u00e3o eliminados. Quem procura a atualidade, opta por <strong>allkeys-lru<\/strong>, para dar prioridade \u00e0s entradas utilizadas mais recentemente e manter fragmentos de p\u00e1ginas atualizados. No caso de conjuntos mistos, utilizo o TTL em todas as chaves de cache e combino isso com <strong>vol\u00e1til-lru<\/strong> ou <strong>volatile-lfu<\/strong>, para que apenas os dados claramente \u201etempor\u00e1rios\u201c sejam eliminados. Uma configura\u00e7\u00e3o adequada do espa\u00e7o de armazenamento ajuda nesta escolha; dou mais dicas no meu guia <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>, que analisa as reservas e m\u00e9tricas concretas do Maxmemory.<\/p>\n\n<h2>LRU vs. LFU: Quando utilizar cada m\u00e9todo<\/h2>\n\n<p>O LRU (Least Recently Used) d\u00e1 prioridade \u00e0 proximidade temporal da \u00faltima utiliza\u00e7\u00e3o e garante que os conte\u00fados consultados recentemente sejam mantidos. O LFU (Least Frequently Used) contabiliza a frequ\u00eancia de acesso e, assim, protege os \u201esucessos duradouros\u201c, mesmo que tenham estado inativos nos \u00faltimos minutos; o que compensa visivelmente em casos de acessos muito irregulares. Se o comportamento de utiliza\u00e7\u00e3o mudar rapidamente, por exemplo, no caso de not\u00edcias ou campanhas, o efeito \u00e9 <strong>allkeys-lru<\/strong> mais intuitivo, uma vez que d\u00e1 maior destaque \u00e0 atividade atual. Em padr\u00f5es recorrentes e est\u00e1veis, como menus, widgets da p\u00e1gina inicial ou dados relacionados com o in\u00edcio de sess\u00e3o, \u00e9 convincente <strong>allkeys-lfu<\/strong>, porque os conte\u00fados permanecem sempre dispon\u00edveis. Para evitar erros de avalia\u00e7\u00e3o, verifico regularmente a taxa de acertos, a taxa de exclus\u00e3o e os tempos de resposta, pois estes n\u00fameros refletem a situa\u00e7\u00e3o real <strong>Use<\/strong> demonstra ser fi\u00e1vel.<\/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 fino para LRU\/LFU<\/h2>\n\n<p>Para que o LRU\/LFU funcionem com precis\u00e3o, ajusto tr\u00eas parafusos de regula\u00e7\u00e3o: <code>maxmemory-samples<\/code>, <code>lfu-log-factor<\/code> e <code>lfu-decay-time<\/code>. Mais elevadas <code>maxmemory-samples<\/code>-Os valores (por exemplo, 10\u201315 em vez do padr\u00e3o) melhoram a qualidade da amostragem nas evic\u00e7\u00f5es e, assim, aumentam a taxa de acerto das chaves \u201ecorretas\u201c, mas consomem recursos da CPU. <code>lfu-log-factor<\/code> determina a rapidez com que o contador LFU aumenta: valores baixos reagem rapidamente (ideal para tend\u00eancias ef\u00e9meras), valores elevados suavizam a curva (melhor para \u201egrandes nomes\u201c duradouros). Com <code>lfu-decay-time<\/code> (em minutos) defino a rapidez com que a popularidade anterior \u201edecai\u201c; valores mais elevados s\u00e3o adequados para padr\u00f5es di\u00e1rios, enquanto valores mais baixos s\u00e3o adequados para conte\u00fados que mudam rapidamente. Alterarei sempre apenas um par\u00e2metro por itera\u00e7\u00e3o, observarei a taxa de acertos e estarei atento \u00e0 lat\u00eancia, para n\u00e3o sobrecarregar desnecessariamente a CPU nas amostragens.<\/p>\n\n<h2>Estrat\u00e9gias TTL com `volatile-*`<\/h2>\n\n<p>Pol\u00edticas baseadas em TTL, tais como <strong>vol\u00e1til-lru<\/strong> e <strong>volatile-lfu<\/strong> limitam as elimina\u00e7\u00f5es \u00e0s chaves com prazo de validade e n\u00e3o afetam as chaves \u201epermanentes\u201c. Isto \u00e9 adequado para configura\u00e7\u00f5es em que o Redis mant\u00e9m em conjunto dados de cache e dados de longa dura\u00e7\u00e3o, como, por exemplo, informa\u00e7\u00f5es semelhantes a sess\u00f5es juntamente com caches de consultas. Se definir TTLs de forma consistente em todas as chaves de cache, posso garantir que as evic\u00e7\u00f5es s\u00f3 ocorram onde pretendo. Importante: se a base de dados n\u00e3o contiver chaves com TTL, as pol\u00edticas \u00abvolatile\u00bb comportam-se como <strong>noeviction<\/strong>, ou seja, sem limpeza e com poss\u00edveis erros de grava\u00e7\u00e3o quando a mem\u00f3ria est\u00e1 cheia. Por isso, verifico regularmente se todos os objetos da cache t\u00eam um tempo de vida \u00fatil razo\u00e1vel e se os intervalos de tempo at\u00e9 \u00e0 <strong>Atualidade<\/strong> que se adequem aos conte\u00fados.<\/p>\n\n<p>Como op\u00e7\u00e3o complementar, utilizo-a no caso de conte\u00fados com um prazo de validade claramente definido <strong>vol\u00e1til-ttl<\/strong>, o que faz com que as chaves com o prazo de validade restante mais curto sejam eliminadas em primeiro lugar. Isto \u00e9 \u00fatil quando todos os objetos da cache v\u00e3o, de qualquer forma, ser renovados em breve e eu pretendo utilizar a data de validade \u201enatural\u201c como prioridade. Para testes ou ambientes de staging, por vezes defino <strong>vol\u00e1til-aleat\u00f3rio<\/strong> para minimizar a carga da CPU; em ambiente de produ\u00e7\u00e3o, evito as variantes aleat\u00f3rias devido \u00e0 sua menor previsibilidade.<\/p>\n\n<h2>Noeviction para dados cr\u00edticos<\/h2>\n\n<p>Em <strong>noeviction<\/strong> O Redis n\u00e3o elimina chaves; os acessos de leitura continuam poss\u00edveis, enquanto os comandos de escrita podem falhar assim que o limite de mem\u00f3ria for atingido. Isto protege os dados cr\u00edticos contra a elimina\u00e7\u00e3o indesejada, mas exige que a aplica\u00e7\u00e3o lide de forma robusta com mensagens de erro e, se necess\u00e1rio, com contrapress\u00e3o. Utilizo o \u00abnoeviction\u00bb nos casos em que as perdas de cache seriam mais dispendiosas do que erros de grava\u00e7\u00e3o tempor\u00e1rios, por exemplo, em configura\u00e7\u00f5es relevantes para a seguran\u00e7a ou em informa\u00e7\u00f5es de sess\u00e3o altamente sens\u00edveis. \u00c9 importante manter um planeamento conservador da mem\u00f3ria com margem de reserva, para que os picos de tr\u00e1fego n\u00e3o provoquem erros imediatos e para que a <strong>Aplica\u00e7\u00e3o<\/strong> continua a reagir. Al\u00e9m disso, emito um aviso ativo atrav\u00e9s do monitoriza\u00e7\u00e3o antes de o limiar ser atingido, para que se possa agir atempadamente <strong>contrariar<\/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>Persist\u00eancia, replica\u00e7\u00e3o e buffer de mem\u00f3ria<\/h2>\n\n<p>As decis\u00f5es de evic\u00e7\u00e3o devem ser sempre tomadas no contexto da persist\u00eancia (RDB\/AOF) e da replica\u00e7\u00e3o. Os instant\u00e2neos RDB e as reescritas AOF utilizam o \u00abCopy-on-Write\u00bb; entretanto, a mem\u00f3ria RSS aumenta temporariamente. Por isso, prevejo uma margem de 25\u201350% acima do pico observado, para que uma reescrita n\u00e3o provoque evic\u00e7\u00f5es indesejadas. A ordem de grandeza depende da taxa de grava\u00e7\u00e3o e do tamanho dos objetos; quanto mais objetos forem alterados durante a reescrita, maior ser\u00e1 a necessidade.<\/p>\n\n<p>Na replica\u00e7\u00e3o, tenho em conta o <code>tamanho-da-filha-de-respostas<\/code> bem como os buffers de sa\u00edda para as r\u00e9plicas. \u00c9 particularmente importante: nas r\u00e9plicas, costumo definir <code>replica-ignore-maxmemory yes<\/code> (anteriormente <code>slave-ignore-maxmemory<\/code>), para que o servidor de r\u00e9plicas n\u00e3o seja evicto automaticamente durante picos de carga, enquanto acompanha o servidor prim\u00e1rio. No caso de r\u00e9plicas de leitura com car\u00e1ter de cache, posso, por outro lado, ativar deliberadamente uma pol\u00edtica de evic\u00e7\u00e3o, caso precise limitar rigorosamente a mem\u00f3ria. Para dados cr\u00edticos, costumo emparelhar nas r\u00e9plicas <strong>noeviction<\/strong> com uma margem suficiente para evitar discrep\u00e2ncias nos dados.<\/p>\n\n<h2>Configura\u00e7\u00e3o no ficheiro redis.conf e em tempo de execu\u00e7\u00e3o<\/h2>\n\n<p>Trabalho de forma reproduz\u00edvel, com defini\u00e7\u00f5es claras, e guardo-as de forma permanente:<\/p>\n<pre><code># Exemplo: Apenas cache, acessos desiguais\nmaxmemory 4gb\nmaxmemory-policy allkeys-lfu\nmaxmemory-samples 10\nlfu-log-factor 10\nlfu-decay-time 1\n\n# Elimina\u00e7\u00f5es opcionais em segundo plano (ver Lazyfree)\nlazyfree-lazy-eviction yes\nlazyfree-lazy-expire yes\nlazyfree-lazy-server-del yes\n<\/code><\/pre>\n<p>Durante a execu\u00e7\u00e3o, testo as altera\u00e7\u00f5es com <code>CONFIG SET<\/code> e escreve-as com <code>REESCREVER CONFIGURA\u00c7\u00c3O<\/code> de forma permanente no ficheiro de configura\u00e7\u00e3o. Para cargas de trabalho mistas, documento as regras de TTL no c\u00f3digo e mantenho as inst\u00e2ncias do Redis separadas por finalidade (por exemplo, cache separado vs. sess\u00f5es), para que cada inst\u00e2ncia possa aplicar uma pol\u00edtica espec\u00edfica.<\/p>\n\n<h2>Lazyfree: Desocupa\u00e7\u00f5es sem picos de lat\u00eancia<\/h2>\n\n<p>Chaves grandes ou elimina\u00e7\u00f5es em massa provocam rapidamente picos de lat\u00eancia de forma sincronizada. Com o Lazyfree (<code>evic\u00e7\u00e3o pregui\u00e7osa-pregui\u00e7osa<\/code>, <code>lazyfree-lazy-expire<\/code>, <code>servidor-lazyfree-lazy-del<\/code>) transfiro a liberta\u00e7\u00e3o de objetos de grande dimens\u00e3o para threads em segundo plano; comandos como <code>DESLIGAR<\/code> em vez de <code>DEL<\/code> Tamb\u00e9m utilizo isso. Resultado: tempos de resposta mais constantes com as mesmas cargas de trabalho. Estou atento \u00e0 mem\u00f3ria e \u00e0 CPU, pois as liberta\u00e7\u00f5es em segundo plano podem gerar uma sobrecarga adicional a curto prazo.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o e indicadores: taxa de acertos, mem\u00f3ria, evic\u00e7\u00f5es<\/h2>\n\n<p>Uma configura\u00e7\u00e3o harmoniosa depende inteiramente da visibilidade: eu avalio a <strong>Taxa de acerto<\/strong>, a taxa de evic\u00e7\u00e3o, a lat\u00eancia e a mem\u00f3ria ocupada ao longo do tempo. Se a taxa de evic\u00e7\u00e3o aumentar enquanto a taxa de acertos diminui, os n\u00fameros indicam mem\u00f3ria insuficiente, TTLs incorretos ou uma pol\u00edtica inadequada. Em per\u00edodos de pico, avalio tamb\u00e9m as taxas de erro dos comandos de grava\u00e7\u00e3o, para identificar diretamente os riscos de \u00abnoeviction\u00bb. As amostras internas do Redis para LRU\/LFU podem ser obtidas atrav\u00e9s de <code>maxmemory-samples<\/code> ajustar; valores mais elevados proporcionam melhores decis\u00f5es, mas consomem algum recurso da CPU. Aumento este valor de forma moderada, observo o impacto nos tempos de resposta e procuro assim o melhor <strong>Defini\u00e7\u00e3o<\/strong> para a carga de trabalho.<\/p>\n\n<h2>Configura\u00e7\u00f5es de exemplo para servidores de alojamento<\/h2>\n\n<p>Para cen\u00e1rios de alojamento recorrentes, tem-se revelado \u00fatil uma pequena matriz que utilizo como ponto de partida e que, posteriormente, aperfei\u00e7oo com base em medi\u00e7\u00f5es. Planeio sempre uma reserva no <code>mem\u00f3ria m\u00e1xima<\/code>, para amortecer os picos de carga e garantir que as evic\u00e7\u00f5es ocorram de forma ordenada. Para tal, seleciono a pol\u00edtica com base na carga de trabalho, de acordo com a tabela abaixo, e documento claramente as regras de TTL na aplica\u00e7\u00e3o. Esta abordagem evita mal-entendidos entre as equipas de desenvolvimento e de opera\u00e7\u00f5es e garante um comportamento reprodut\u00edvel no dia-a-dia. Com esta vis\u00e3o geral, mantenho a minha <strong>Decis\u00f5es<\/strong> transparente e permite-lhe mais facilmente <strong>personalizar<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Carga de trabalho<\/th>\n      <th>Pol\u00edtica recomendada<\/th>\n      <th>Vantagem<\/th>\n      <th>Risco<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Cache puro, acessos desiguais<\/td>\n      <td>allkeys-lfu<\/td>\n      <td>Os objetos utilizados com frequ\u00eancia permanecem<\/td>\n      <td>As chaves raras aparecem mais depressa<\/td>\n      <td>Verificar a taxa de acertos, <code>maxmemory-samples<\/code> ajustar com precis\u00e3o<\/td>\n    <\/tr>\n    <tr>\n      <td>Cache puro, conte\u00fados atualizados<\/td>\n      <td>allkeys-lru<\/td>\n      <td>As chaves utilizadas mais recentemente permanecem<\/td>\n      <td>Os favoritos de longa data tendem a cair<\/td>\n      <td>Muitas vezes mais adequado para not\u00edcias\/campanhas<\/td>\n    <\/tr>\n    <tr>\n      <td>Dados mistos com TTL<\/td>\n      <td>volatile-lru\/lfu<\/td>\n      <td>Chaves permanentes protegidas<\/td>\n      <td>Sem TTL, n\u00e3o h\u00e1 elimina\u00e7\u00e3o<\/td>\n      <td>Aplicar e documentar o TTL de forma coerente<\/td>\n    <\/tr>\n    <tr>\n      <td>Armazenamento de dados cr\u00edticos<\/td>\n      <td>noeviction<\/td>\n      <td>Sem perda de chaves<\/td>\n      <td>Erros de escrita com a RAM cheia<\/td>\n      <td>Garantir o tratamento de erros na aplica\u00e7\u00e3o<\/td>\n    <\/tr>\n    <tr>\n      <td>Teste\/Prepara\u00e7\u00e3o<\/td>\n      <td>allkeys-random<\/td>\n      <td>Custos de CPU muito baixos<\/td>\n      <td>Despejos imprevis\u00edveis<\/td>\n      <td>N\u00e3o utilizar em caches produtivas<\/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 partilhado vs. Redis dedicado na hospedagem<\/h2>\n\n<p>Em ambientes partilhados, \u00e9 mais frequente teres de lidar com perfis de carga vari\u00e1veis e regras de TTL pouco claras de outros projetos, o que pode tornar as evic\u00e7\u00f5es imprevis\u00edveis. Nesse caso, prefiro utilizar <strong>vol\u00e1til-lru<\/strong> ou <strong>volatile-lfu<\/strong> e defina TTLs curtas e claras para todas as chaves da cache, de modo a que apenas os dados explicitamente tempor\u00e1rios sejam eliminados. Em caches dedicadas de alto desempenho, isto proporciona <strong>allkeys-lfu<\/strong> muitas vezes apresentam melhores taxas de acerto e tempos de resposta mais est\u00e1veis, porque os \u201eHeavy-Hitters\u201c permanecem de forma fi\u00e1vel na RAM. Quem ainda tiver d\u00favidas sobre esta quest\u00e3o, pode consultar o meu guia sobre <a href=\"https:\/\/webhosting.de\/pt\/redis-partilhado-vs-dedicado-desempenho-seguranca-cacheboost\/\">Partilhado vs. dedicado<\/a>, onde comparo os efeitos no desempenho, no isolamento e nos custos. Com esta clareza, reduzo o risco de desmoronamentos laterais e mantenho a <strong>Lat\u00eancia<\/strong> sob controlo.<\/p>\n\n<p>O Redis n\u00e3o aplica limites por cliente de forma nativa. Se precisar de limites r\u00edgidos de mem\u00f3ria, inicio inst\u00e2ncias separadas ou fragmentos de cluster por projeto e defino um limite espec\u00edfico por inst\u00e2ncia <code>mem\u00f3ria m\u00e1xima<\/code> juntamente com a pol\u00edtica adequada. Desta forma, evito que determinados inquilinos dominem a mem\u00f3ria partilhada e provoquem, inadvertidamente, evic\u00e7\u00f5es noutros.<\/p>\n\n<h2>WordPress e WooCommerce: como gerir corretamente a cache de objetos<\/h2>\n\n<p>Nas configura\u00e7\u00f5es do WordPress, os resultados das consultas, os menus, as informa\u00e7\u00f5es de in\u00edcio de sess\u00e3o e os dados transit\u00f3rios acabam frequentemente no cache de objetos do Redis; estas chaves s\u00e3o ideais para regras baseadas em TTL. Nas p\u00e1ginas din\u00e2micas, defino TTLs curtos para conte\u00fados transit\u00f3rios, para que <strong>volatile-lfu<\/strong> ou <strong>vol\u00e1til-lru<\/strong> criar espa\u00e7o de forma espec\u00edfica. Se a p\u00e1gina estiver sobrecarregada com fragmentos recorrentes, convence <strong>allkeys-lfu<\/strong>, porque os \u201ecorredores de longa dist\u00e2ncia\u201c permanecem na mem\u00f3ria e a taxa de cache mant\u00e9m-se elevada. Explico aqui os erros t\u00edpicos no cache de objetos: <a href=\"https:\/\/webhosting.de\/pt\/erro-de-configuracao-do-cache-de-objetos-do-redis-otimizacao-do-desempenho-do-wordpress\/\">Erro de configura\u00e7\u00e3o na cache de objetos<\/a>, onde abordo os temas TTL, namespaces e tamanho da chave. Com estes ajustes, evito falhas desnecess\u00e1rias e mantenho o site a funcionar durante os picos de tr\u00e1fego <strong>r\u00e1pido<\/strong>.<\/p>\n\n<p>Orienta\u00e7\u00f5es pr\u00e1ticas: Para fragmentos altamente vol\u00e1teis (por exemplo, widgets personalizados, snippets do carrinho de compras), opto por TTLs na ordem dos segundos a alguns minutos. Para estruturas de menus, categorias ou widgets da p\u00e1gina inicial, faz sentido utilizar TTLs mais longos, desde que um invalidador de cache seja acionado de forma fi\u00e1vel sempre que houver altera\u00e7\u00f5es. Os cat\u00e1logos do WooCommerce beneficiam frequentemente de tarefas de pr\u00e9-aquecimento (Cron), que preenchem de forma espec\u00edfica as listas de produtos mais populares ap\u00f3s a limpeza da cache. Certifica-te tamb\u00e9m de que os plugins n\u00e3o gravam objetos de tamanho excessivo na cache de objetos; se necess\u00e1rio, fragmenta-os (v\u00e1rias chaves mais pequenas em vez de um blob gigantesco) e simplifica os formatos de dados.<\/p>\n\n<h2>Otimiza\u00e7\u00e3o do sistema operativo e dos contentores<\/h2>\n\n<p>As predefini\u00e7\u00f5es do sistema operativo e dos contentores influenciam as evic\u00e7\u00f5es indiretamente, atrav\u00e9s da disponibilidade de mem\u00f3ria e do comportamento do RSS. Eu defino <code>vm.overcommit_memory=1<\/code>, desative as Transparent Huge Pages (THP) e evite o swap nos caches de produ\u00e7\u00e3o, para impedir o OOM-Killer e reduzir o incha\u00e7o do RSS. Nos contentores, configuro o <code>mem\u00f3ria m\u00e1xima<\/code> abaixo do limite do cgroup e deixo margem para picos de RDB\/AOF, buffer de replica\u00e7\u00e3o e fragmenta\u00e7\u00e3o. Desta forma, evito que o processo seja encerrado abruptamente devido a picos de curta dura\u00e7\u00e3o, embora a evic\u00e7\u00e3o do lado do Redis ainda possa entrar em a\u00e7\u00e3o. Na monitoriza\u00e7\u00e3o, observo, al\u00e9m de <code>mem\u00f3ria_utilizada<\/code> tamb\u00e9m <code>mem\u00f3ria_usada_rss<\/code> e a rela\u00e7\u00e3o (<code>r\u00e1cio_de_fragmenta\u00e7\u00e3o_de_mem\u00f3ria<\/code>), para reagir de forma eficaz aos efeitos do 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>Desfragmenta\u00e7\u00e3o ativa e reservas de mem\u00f3ria<\/h2>\n\n<p>O Redis pode fragmentar a mem\u00f3ria internamente, o que reduz a RAM dispon\u00edvel e provoca evic\u00e7\u00f5es mais cedo do que o esperado; com a desfragmenta\u00e7\u00e3o ativa, atenuo este comportamento. Por isso, prevejo uma margem acima do consumo m\u00e1ximo esperado e verifico regularmente a <strong>Fragmenta\u00e7\u00e3o<\/strong> bem como a utiliza\u00e7\u00e3o efetiva. Limites demasiado restritivos reduzem a taxa de acerto, enquanto limites demasiado generosos acarretam o risco de erros tardios, caso a op\u00e7\u00e3o \u00abnoeviction\u00bb esteja ativada. Pequenos passos no ajuste de <code>mem\u00f3ria m\u00e1xima<\/code> ajudam-me a manter os impactos mensur\u00e1veis e a n\u00e3o tomar medidas excessivas de forma cega. Desta forma, o planeamento do armazenamento mant\u00e9m-se realista e o <strong>Desempenho<\/strong> constante.<\/p>\n\n<p>Com <code>activedefrag sim<\/code> e limites mais precisos (<em>ciclo-m\u00edn.\/m\u00e1x.<\/em>) Suavizo os picos de mem\u00f3ria sem afetar demasiado o d\u00e9bito. Prefiro ativar a desfragmenta\u00e7\u00e3o fora dos picos de carga e, em seguida, avalio se as evic\u00e7\u00f5es ocorrem com menos frequ\u00eancia ou de forma mais ordenada.<\/p>\n\n<h2>Simplificar de forma seletiva as \u00abBig Keys\u00bb e as estruturas de dados<\/h2>\n\n<p>Chaves desproporcionalmente grandes criam lacunas na cache e provocam evacua\u00e7\u00f5es dr\u00e1sticas. Procuro esses valores at\u00edpicos com <code>redis-cli --bigkeys<\/code> ou <code>UTILIZA\u00c7\u00c3O DA MEM\u00d3RIA<\/code> por chave e utiliza\u00e7\u00e3o <code>ESTAT\u00cdSTICAS DE MEM\u00d3RIA<\/code>\/<code>MEMORY DOCTOR<\/code> como primeiro diagn\u00f3stico. Medidas frequentes: dividir grandes blobs JSON, utilizar hashes com codifica\u00e7\u00f5es compactas (definir adequadamente os limiares de Listpack\/Ziplist), reavaliar a granularidade em conjuntos\/conjuntos ordenados e eliminar ativamente os membros antigos. No que diz respeito aos fluxos, tenho em aten\u00e7\u00e3o tanto o lado da entrada como o do consumidor: com <code>XTRIM<\/code> Limito o comprimento e evito que as PELs (Pending Entries) cres\u00e7am infinitamente, processando os consumidores de forma fi\u00e1vel e sistem\u00e1tica ou limpando os grupos inativos.<\/p>\n\n<h2>Medidas concretas de afina\u00e7\u00e3o para o dia a dia<\/h2>\n\n<p>Come\u00e7o por definir uma pol\u00edtica clara de acordo com a carga de trabalho, defino TTLs realistas e acompanho as taxas de acertos e de evic\u00e7\u00e3o ao longo do dia. Depois, ajusto <code>mem\u00f3ria m\u00e1xima<\/code> aos poucos e com cuidado <code>maxmemory-samples<\/code> para obter melhores decis\u00f5es de LRU\/LFU. Se a taxa de acertos diminuir apesar do aumento da mem\u00f3ria, o problema reside frequentemente em TTLs demasiado curtas, objetos demasiado grandes ou granularidade de chaves incorreta; nesse caso, otimizo a <strong>Chaves<\/strong> e reduzo os dados desnecess\u00e1rios. No WordPress, verifico o tamanho e o n\u00famero de objetos na cache, bem como o comportamento dos plugins que escrevem na cache de forma demasiado agressiva. A cada itera\u00e7\u00e3o, a taxa de evic\u00e7\u00e3o diminui, os tempos de resposta estabilizam e a cache suporta a <strong>Carga<\/strong> fi\u00e1vel.<\/p>\n\n<h2>Runbook: Quando os despejos ficam fora de controlo<\/h2>\n\n<ul>\n  <li>Validar o alarme: taxa de acertos\/erros, evacua\u00e7\u00f5es, mensagens de erro (<em>O comando OOM n\u00e3o \u00e9 permitido<\/em>), verificar as lat\u00eancias.<\/li>\n  <li>Medida imediata: se poss\u00edvel, tempor\u00e1ria <code>mem\u00f3ria m\u00e1xima<\/code> Aumentar ligeiramente para ganhar estabilidade; em alternativa, limitar o tr\u00e1fego (limite de taxa\/contrapress\u00e3o).<\/li>\n  <li>Ajustar a pol\u00edtica: No caso de \u00abCache-only\u00bb, se necess\u00e1rio, definir para <strong>allkeys-lru<\/strong> Mudar para criar espa\u00e7o de forma mais agressiva; ativar o Lazyfree para evitar picos de lat\u00eancia.<\/li>\n  <li>Limpar de forma seletiva: Espa\u00e7os de nomes sem import\u00e2ncia atrav\u00e9s de <code>SCAN<\/code> + <code>DESLIGAR<\/code> apagar; verificar os TTLs e aumentar os tempos de validade demasiado curtos, caso a recarga sobrecarregue a fonte prim\u00e1ria.<\/li>\n  <li>Identificar grandes consumidores: <code>--bigkeys<\/code>, <code>UTILIZA\u00c7\u00c3O DA MEM\u00d3RIA<\/code>, grandes fluxos\/conjuntos ordenados; marcar as teclas de atalho para o pr\u00e9-aquecimento.<\/li>\n  <li>Ter em conta a persist\u00eancia: est\u00e1 a decorrer uma reescrita RDB\/AOF? Assegurar margem suficiente ou deslocar a janela.<\/li>\n  <li>Estabiliza\u00e7\u00e3o posterior: ajuste fino de <code>maxmemory-samples<\/code>, par\u00e2metros LFU, desfragmenta\u00e7\u00e3o; documentar o efeito de aprendizagem.<\/li>\n  <li>Preven\u00e7\u00e3o sustent\u00e1vel: atualizar o planeamento de capacidade, implementar inst\u00e2ncias separadas para diferentes pol\u00edticas, aperfei\u00e7oar os alertas de m\u00e9tricas.<\/li>\n<\/ul>\n\n<h2>S\u00edntese conclusiva<\/h2>\n\n<p>No que diz respeito aos caches puros, na pr\u00e1tica costumo optar por <strong>allkeys-lfu<\/strong>, para conte\u00fados atualizados em <strong>allkeys-lru<\/strong>, para dados mistos, utilizo pol\u00edticas \u00abvolatile\u00bb e, para dados sens\u00edveis, \u00abnoeviction\u00bb. \u00c9 fundamental definir TTLs claros, reservas de mem\u00f3ria bem organizadas e uma monitoriza\u00e7\u00e3o vis\u00edvel, para que as evic\u00e7\u00f5es ocorram de forma previs\u00edvel e sem surpresas. Com esta estrutura, evito a perda de dados, mantenho a taxa de acertos elevada e reajo com tranquilidade aos picos de carga. A tabela acima ajuda na fase inicial; as m\u00e9tricas conduzem, posteriormente, o ajuste fino. Assim, cada ambiente de alojamento encontra uma solu\u00e7\u00e3o simples e robusta <strong>Estrat\u00e9gia<\/strong> para a evic\u00e7\u00e3o do Redis e fornece p\u00e1ginas de forma r\u00e1pida e constante <strong>de<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>As pol\u00edticas de evic\u00e7\u00e3o do Redis determinam quais as chaves que s\u00e3o removidas quando a mem\u00f3ria fica cheia. Descobre qual a estrat\u00e9gia mais adequada para servidores de alojamento, WordPress e configura\u00e7\u00f5es de cache.<\/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\/pt\/wp-json\/wp\/v2\/posts\/20492","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=20492"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20492\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20485"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20492"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20492"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20492"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}