{"id":21597,"date":"2026-09-20T15:02:45","date_gmt":"2026-09-20T13:02:45","guid":{"rendered":"https:\/\/webhosting.de\/redis-key-expiration-performance-analysieren-optimieren-cache\/"},"modified":"2026-09-20T15:02:45","modified_gmt":"2026-09-20T13:02:45","slug":"analisar-e-otimizar-o-desempenho-da-expiracao-de-chaves-do-redis-e-da-cache","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/redis-key-expiration-performance-analysieren-optimieren-cache\/","title":{"rendered":"Analisar e otimizar o desempenho da expira\u00e7\u00e3o de chaves do Redis"},"content":{"rendered":"<p>Estou a analisar o desempenho de <strong>Chave do Redis<\/strong> Controla a expira\u00e7\u00e3o de forma espec\u00edfica e otimiza-a com passos claros e mensur\u00e1veis. \u00c9 assim que reduzo <strong>Lat\u00eancia<\/strong>, suaviza os picos de carga e mant\u00e9m o consumo de mem\u00f3ria sob controlo, sem comprometer o rendimento.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>Resumo os aspectos mais importantes do <strong>Vencimento<\/strong>-Desempenho de forma a que os principiantes possam come\u00e7ar imediatamente e os avan\u00e7ados possam aperfei\u00e7oar o seu desempenho de forma espec\u00edfica. Os pontos-chave que se seguem abordam os aspetos mais importantes e indicam onde surgem os obst\u00e1culos mais comuns. Nesse sentido, concentro-me em <strong>TTL<\/strong>- Estrat\u00e9gias, limpeza ativa e passiva, bem como comportamentos de evic\u00e7\u00e3o. Al\u00e9m disso, estabele\u00e7o indicadores de monitoriza\u00e7\u00e3o que permitem detetar problemas numa fase precoce. Desta forma, \u00e9 poss\u00edvel avaliar o desempenho de forma sistem\u00e1tica e sustent\u00e1vel <strong>boi<\/strong>.<\/p>\n<ul>\n  <li><strong>Pregui\u00e7oso<\/strong> vs. <strong>Ativo<\/strong> Expira\u00e7\u00e3o: compreender e medir a intera\u00e7\u00e3o<\/li>\n  <li><strong>TTL<\/strong>-Dispers\u00e3o: compensa\u00e7\u00f5es contra a deteriora\u00e7\u00e3o simult\u00e2nea<\/li>\n  <li><strong>hz<\/strong>-Ajuste: Equilibrar a frequ\u00eancia dos ciclos em segundo plano<\/li>\n  <li><strong>Pol\u00edtica de despejo<\/strong>: allkeys-lru vs. variantes volatile<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong>: Observar os valores de expira\u00e7\u00e3o, evic\u00e7\u00e3o e lat\u00eancia<\/li>\n<\/ul>\n<p>Apostam numa abordagem coerente <strong>TTLs<\/strong>, limpeza adaptativa e limites bem definidos. Desta forma, distribuo os momentos de execu\u00e7\u00e3o, evito evic\u00e7\u00f5es desnecess\u00e1rias e mantenho os tempos de resposta fiavelmente baixos. Al\u00e9m disso, utilizo m\u00e9tricas que identificam <strong>Fases<\/strong> sinalizar imediatamente e permitir a ado\u00e7\u00e3o de medidas corretivas precisas.<\/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\/09\/redis-performance-4217.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Expira\u00e7\u00e3o de chaves no Redis: funcionamento e impacto na lat\u00eancia<\/h2>\n<p>O Redis combina <strong>pregui\u00e7oso<\/strong> e <strong>ativo<\/strong> A expira\u00e7\u00e3o permite combinar um ritmo elevado com uma carga limitada na CPU. Na expira\u00e7\u00e3o \u00ablazy\u00bb, o servidor s\u00f3 elimina as chaves no momento do acesso, quando o TTL expira. Desta forma, n\u00e3o s\u00e3o necess\u00e1rias opera\u00e7\u00f5es adicionais em segundo plano para dados que, de qualquer forma, s\u00e3o lidos regularmente. A expira\u00e7\u00e3o ativa complementa o modelo atrav\u00e9s de verifica\u00e7\u00f5es curtas e frequentes das chaves prestes a expirar, para remover entradas esquecidas. Esta arquitetura mant\u00e9m as lat\u00eancias baixas e liberta mem\u00f3ria sem recorrer a solu\u00e7\u00f5es dispendiosas e permanentes <strong>Digitaliza\u00e7\u00f5es<\/strong>.<\/p>\n<p>A lat\u00eancia percept\u00edvel ocorre sobretudo quando um grande n\u00famero de entradas expira num curto espa\u00e7o de tempo. Nessa altura, o Redis investe mais <strong>CPU<\/strong> entra em limpeza ativa, o que reduz temporariamente a capacidade para opera\u00e7\u00f5es do cliente. A press\u00e3o adicional sobre a mem\u00f3ria agrava a situa\u00e7\u00e3o, uma vez que as evic\u00e7\u00f5es desencadeiam trabalho paralelo. Por isso, planeio deliberadamente distribuir os momentos de execu\u00e7\u00e3o e mantenho o limite de `MaxMemory` de forma a que ainda reste margem. Assim, os tempos de resposta permanecem fi\u00e1veis mesmo em picos de expira\u00e7\u00e3o. <strong>baixo<\/strong>.<\/p>\n\n<h2>A expira\u00e7\u00e3o \u00ablazy\u00bb e a expira\u00e7\u00e3o \u00abactive\u00bb em pormenor<\/h2>\n<p>A \u00abLazy Expiration\u00bb destaca-se nos conte\u00fados mais lidos <strong>Chaves<\/strong>, porque a verifica\u00e7\u00e3o no momento do acesso associa de forma elegante a data de elimina\u00e7\u00e3o \u00e0 utiliza\u00e7\u00e3o. No entanto, as entradas raramente lidas continuariam a ocupar espa\u00e7o na mem\u00f3ria, apesar do TTL ter expirado. \u00c9 aqui que entra em a\u00e7\u00e3o a expira\u00e7\u00e3o ativa: o Redis seleciona amostras aleat\u00f3rias do conjunto de chaves com tempo de expira\u00e7\u00e3o e remove consistentemente as entradas expiradas. Se a percentagem de entradas expiradas numa amostra for elevada, o Redis alarga o ciclo de forma adaptativa. Desta forma, a capacidade de limpeza aumenta temporariamente, at\u00e9 que a percentagem de entradas expiradas volte a <strong>diminui\u00e7\u00f5es<\/strong>.<\/p>\n<p>Tenho em conta que esta estrat\u00e9gia funciona de forma probabil\u00edstica. Isso \u00e9 intencional, porque an\u00e1lises pontuais ou varreduras globais completas, com milh\u00f5es de chaves, <strong>Lat\u00eancia<\/strong> o que iria sobrecarreg\u00e1-lo. Com TTLs bem definidos e uma frequ\u00eancia de hz adequada, o Redis elimina os dados atempadamente e mant\u00e9m o ritmo de funcionamento leve. Verifico regularmente quantas chaves com TTL existem e com que rapidez as entradas expiradas desaparecem. Esta observa\u00e7\u00e3o fornece indica\u00e7\u00f5es sobre se devo ajustar ligeiramente a limpeza ativa <strong>refor\u00e7ar<\/strong> ou acalme.<\/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\/09\/redis_performance_meeting_3821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Padr\u00e3o de risco: momento TTL id\u00eantico e press\u00e3o de armazenamento<\/h2>\n<p>A situa\u00e7\u00e3o torna-se problem\u00e1tica quando muitos caches t\u00eam o mesmo <strong>Data de vencimento<\/strong> recebidos. Em seguida, as aplica\u00e7\u00f5es e o Redis eliminam e renovam um grande n\u00famero de objetos num curto espa\u00e7o de tempo. A expira\u00e7\u00e3o ativa aumenta e, ao mesmo tempo, os clientes geram reconstru\u00e7\u00f5es que acedem a bases de dados ou APIs. Quando o limite de `Maxmemory` \u00e9 escasso, entram tamb\u00e9m em jogo as evi\u00e7\u00f5es, o que gera ainda mais trabalho. Esta coincid\u00eancia impulsiona <strong>Lat\u00eancia<\/strong> e a utiliza\u00e7\u00e3o da CPU aumentou significativamente.<\/p>\n<p>Resolvo isso desacoplando os momentos de expira\u00e7\u00e3o e suavizando assim os picos. Al\u00e9m disso, verifico se as evic\u00e7\u00f5es ocorrem com demasiada frequ\u00eancia devido a uma configura\u00e7\u00e3o demasiado restritiva do Maxmemory. Especialmente em hor\u00e1rios de pico, vale a pena ter alguma margem de manobra para que as expira\u00e7\u00f5es e as reconstru\u00e7\u00f5es tenham tempo suficiente para <strong>Ar<\/strong> tenho. Sempre que poss\u00edvel, separo tamb\u00e9m as estruturas de longa dura\u00e7\u00e3o dos dados que s\u00e3o apenas de cache em inst\u00e2ncias distintas. Desta forma, os diferentes ciclos de vida entram em conflito com menos frequ\u00eancia e os servidores funcionam <strong>previs\u00edvel<\/strong>.<\/p>\n\n<h2>Conce\u00e7\u00e3o TTL: Desacoplamento e dispers\u00e3o contra \u00abstampedes\u00bb<\/h2>\n<p>Um pequeno desvio aleat\u00f3rio de cerca de \u00b110 % em rela\u00e7\u00e3o \u00e0 base-<strong>TTL<\/strong> distribui os momentos de expira\u00e7\u00e3o por um intervalo de tempo. Desta forma, evito picos de tr\u00e1fego, porque nem tudo expira ao mesmo tempo e tem de ser reconstru\u00eddo. Para teclas de atalho particularmente cr\u00edticas, recorro \u00e0 atualiza\u00e7\u00e3o probabil\u00edstica pouco antes do fim do prazo: uma parte dos acessos \u00e9 atualizada, enquanto outros continuam a ler dados ainda aceit\u00e1veis, embora ligeiramente mais antigos. Desta forma, distribuo o esfor\u00e7o de reconstru\u00e7\u00e3o de forma cont\u00ednua. Esbo\u00e7o padr\u00f5es adicionais relativos a prazos de validade e arquitetura no meu <a href=\"https:\/\/webhosting.de\/pt\/estrategias-de-expiracao-do-redis-grandes-sistemas-de-cache-arquitetura-de-cache\/\">Estrat\u00e9gias de expira\u00e7\u00e3o<\/a>, que adapto de forma pragm\u00e1tica \u00e0s cargas de trabalho.<\/p>\n<p>Atribuo TTLs de forma sistem\u00e1tica a cada objeto de vida curta <strong>Estrutura<\/strong>. Sem o TTL, a pol\u00edtica de evic\u00e7\u00e3o pode funcionar de forma enganadora, uma vez que, nesse caso, tem de remover tamb\u00e9m conte\u00fados de longa dura\u00e7\u00e3o. Para caches puros, costumo escolher \u00aballkeys-lru\u00bb; para cargas de trabalho mistas, prefiro \u00abvolatile-lru\u00bb ou \u00abvolatile-ttl\u00bb. Desta forma, os dados de longa dura\u00e7\u00e3o s\u00e3o preservados, enquanto os objetos da cache s\u00e3o removidos em primeiro lugar. TTLs e pol\u00edticas bem concebidas, em conjunto, proporcionam <strong>Planeamento<\/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\/09\/redis-expiration-optimization-2384.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configura\u00e7\u00e3o: hz, pol\u00edticas de evic\u00e7\u00e3o e estrat\u00e9gias de TTL<\/h2>\n<p>O par\u00e2metro <strong>hz<\/strong> controla a frequ\u00eancia das tarefas em segundo plano, incluindo a expira\u00e7\u00e3o ativa. Valores mais elevados limpam mais rapidamente, mas consomem recursos da CPU. Valores mais baixos poupam recursos da CPU, mas mant\u00eam as chaves expiradas por mais tempo. Aumento o valor de hz com cuidado, medo a lat\u00eancia e o consumo de CPU e s\u00f3 o aumentei ainda mais quando a mem\u00f3ria permaneceu ocupada por um per\u00edodo sensivelmente mais longo. Paralelamente, adapto a pol\u00edtica de evic\u00e7\u00e3o e o design do TTL de forma rigorosa \u00e0 finalidade de utiliza\u00e7\u00e3o <strong>de<\/strong>.<\/p>\n<p>A tabela seguinte resume as op\u00e7\u00f5es principais e os efeitos t\u00edpicos. Utilizo-a como um guia pr\u00e1tico para ponderar cuidadosamente as decis\u00f5es. Cada linha centra-se nos efeitos sobre a lat\u00eancia, a RAM e nas orienta\u00e7\u00f5es concretas para o funcionamento. Desta forma, o trabalho de afina\u00e7\u00e3o mant\u00e9m-se compreens\u00edvel e conduz a <strong>mensur\u00e1vel<\/strong> Resultados.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Componente<\/th>\n      <th>Op\u00e7\u00e3o\/Configura\u00e7\u00e3o<\/th>\n      <th>Efeito na lat\u00eancia<\/th>\n      <th>Impacto na RAM<\/th>\n      <th>Nota pr\u00e1tica<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Ciclos em segundo plano<\/td>\n      <td>baixa frequ\u00eancia<\/td>\n      <td><strong>Baixa<\/strong>maior carga da CPU, potencialmente mais chaves antigas<\/td>\n      <td>As chaves expiradas permanecem ativas por mais tempo<\/td>\n      <td>Adequado para cargas de trabalho tranquilas; m\u00e9tricas rigorosas <strong>observar<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Ciclos em segundo plano<\/td>\n      <td>frequ\u00eancia moderada\/elevada<\/td>\n      <td>Limpeza mais r\u00e1pida, mais CPU temporariamente<\/td>\n      <td>Recupera\u00e7\u00e3o mais r\u00e1pida da RAM<\/td>\n      <td>Para caches com elevada taxa de altera\u00e7\u00e3o <strong>\u00fatil<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Despejo<\/td>\n      <td>allkeys-lru<\/td>\n      <td>Tempos de resposta constantes na mem\u00f3ria cache pura<\/td>\n      <td>Limpa de forma agressiva as chaves n\u00e3o utilizadas<\/td>\n      <td>Recomendado para puros <strong>Caches<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Despejo<\/td>\n      <td>vol\u00e1til-lru<\/td>\n      <td>Preserva as estruturas duradouras<\/td>\n      <td>Remove apenas as chaves TTL<\/td>\n      <td>Frequentemente para cargas de trabalho mistas <strong>vantajoso<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Despejo<\/td>\n      <td>vol\u00e1til-ttl<\/td>\n      <td>Retirar ap\u00f3s o TTL residual mais curto<\/td>\n      <td>Autoriza\u00e7\u00e3o muito espec\u00edfica<\/td>\n      <td>Se os TTL forem bons <strong>Sinal<\/strong> transportar<\/td>\n    <\/tr>\n    <tr>\n      <td>Conce\u00e7\u00e3o TTL<\/td>\n      <td>\u00b110 % Desvio<\/td>\n      <td>Menos reconstru\u00e7\u00f5es simult\u00e2neas<\/td>\n      <td>Suaviza as fases de expira\u00e7\u00e3o<\/td>\n      <td>Mais simples, muito <strong>mais eficaz<\/strong> Truque anti-debandamento<\/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\/09\/redis_performance_4221.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoriza\u00e7\u00e3o: quais s\u00e3o as m\u00e9tricas que realmente importam<\/h2>\n<p>N\u00e3o me baseio apenas em <strong>CPU<\/strong> e RAM. Outros indicadores relevantes s\u00e3o: o n\u00famero de chaves expiradas por intervalo, a propor\u00e7\u00e3o de chaves com TTL em rela\u00e7\u00e3o ao total de chaves, a taxa e a dura\u00e7\u00e3o dos ciclos de expira\u00e7\u00e3o ativos, a taxa de acertos na cache, bem como a distribui\u00e7\u00e3o da lat\u00eancia atrav\u00e9s da mediana, P95 e P99. Frequentemente, os picos de lat\u00eancia est\u00e3o correlacionados com fases em que muitas chaves expiram simultaneamente ou em que as evic\u00e7\u00f5es se intensificam. Identifico esses padr\u00f5es com grande precis\u00e3o temporal, para aplicar medidas corretivas de forma direcionada. Para obter informa\u00e7\u00f5es orientadas por eventos, utilizo ainda <a href=\"https:\/\/webhosting.de\/pt\/redis-keyspace-notificacoes-alojamento-monitorizacao-de-cache-arquitetura-de-eventos-redispower\/\">Notifica\u00e7\u00f5es do Keyspace<\/a> como complemento <strong>Sinais<\/strong>.<\/p>\n<p>Estabele\u00e7o limites claros para a taxa de expira\u00e7\u00e3o, a taxa de evic\u00e7\u00e3o e os percentis de lat\u00eancia. Se os valores ultrapassarem repetidamente os limites, ajusto os TTLs, a frequ\u00eancia (hz) ou a pol\u00edtica de evic\u00e7\u00e3o. Paralelamente, avalio se a aplica\u00e7\u00e3o est\u00e1 a desencadear demasiadas verifica\u00e7\u00f5es completas, que entram em conflito com os ciclos de expira\u00e7\u00e3o. Os pain\u00e9is transparentes facilitam a comunica\u00e7\u00e3o com as equipas que preenchem as caches ou as sess\u00f5es <strong>utilizar<\/strong>. Desta forma, todos os envolvidos t\u00eam a mesma perspetiva sobre a utiliza\u00e7\u00e3o da capacidade e os efeitos.<\/p>\n\n<h2>Manter o equil\u00edbrio entre a mem\u00f3ria e a lat\u00eancia<\/h2>\n<p>Eu dimensiono <strong>Maxmemory<\/strong> de forma a que o Redis utilize cerca de 70\u201375 % da RAM dispon\u00edvel. Esta margem deixa espa\u00e7o para as caches do sistema operativo e outros servi\u00e7os. Em condi\u00e7\u00f5es de carga cont\u00ednua, isso impede que as evic\u00e7\u00f5es comecem demasiado cedo e aumentem as lat\u00eancias. Se, mesmo assim, forem eviccionadas muitas entradas, ajusto os TTLs ou separo as cargas de trabalho por tipo em inst\u00e2ncias diferentes. Al\u00e9m disso, verifico se os objetos s\u00e3o desnecessariamente grandes e opto por estruturas mais enxutas <strong>Estruturas<\/strong>.<\/p>\n<p>Nos casos em que os tempos de liberta\u00e7\u00e3o possam causar problemas, considero a liberta\u00e7\u00e3o ass\u00edncrona de mem\u00f3ria. Mecanismos como <a href=\"https:\/\/webhosting.de\/pt\/redis-otimizacao-libertacao-de-memoria-em-segundo-plano-otimizacao\/\">Lazy Free<\/a> podem dissociar a elimina\u00e7\u00e3o e, assim, uniformizar os tempos de resposta. Ao mesmo tempo, acompanho de perto os efeitos, para que o trabalho em segundo plano n\u00e3o sobrecarregue a CPU de forma permanente. Prefiro pequenas altera\u00e7\u00f5es frequentes em vez de grandes mudan\u00e7as de uma s\u00f3 vez. Isso reduz o risco e minimiza o impacto para todos os envolvidos. <strong>vis\u00edvel<\/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\/09\/redis_performance_analyse_1467.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Perspetiva de alojamento e de cluster<\/h2>\n<p>Tenho em conta <strong>Rede<\/strong>-Lat\u00eancia entre a aplica\u00e7\u00e3o e a inst\u00e2ncia do Redis, porque cada mil\u00e9simo de segundo conta. A escalabilidade vertical, com RAM suficiente e n\u00facleos de CPU em n\u00famero adequado, alivia a carga nos ciclos de expira\u00e7\u00e3o. No caso de espa\u00e7os de chaves muito grandes, distribuo a carga atrav\u00e9s de sharding ou de clusters, para que o trabalho de expira\u00e7\u00e3o e evic\u00e7\u00e3o n\u00e3o se concentre numa \u00fanica inst\u00e2ncia. Para ambientes de produ\u00e7\u00e3o, escolho fornecedores que d\u00e3o prioridade \u00e0s cargas de trabalho em mem\u00f3ria e oferecem I\/O consistente. Em compara\u00e7\u00f5es, o webhoster.de revela-se uma recomenda\u00e7\u00e3o fi\u00e1vel para configura\u00e7\u00f5es de servidor com <strong>Redis<\/strong>-Desempenho.<\/p>\n<p>Testo as configura\u00e7\u00f5es em condi\u00e7\u00f5es realistas antes de as implementar em grande escala. A reprodu\u00e7\u00e3o de cargas representativas ajuda a avaliar os efeitos da dispers\u00e3o do TTL, dos ajustes de hz e das altera\u00e7\u00f5es na evic\u00e7\u00e3o. Em seguida, planeio janelas de manuten\u00e7\u00e3o para migra\u00e7\u00f5es graduais. Desta forma, garanto tempos de resposta curtos e um consumo de mem\u00f3ria controlado, sem surpresas durante o funcionamento em produ\u00e7\u00e3o. O resultado: uma camada de cache que distribui a carga de forma uniforme <strong>transporta<\/strong>.<\/p>\n\n<h2>Padr\u00f5es de escrita e renova\u00e7\u00e3o: a aplica\u00e7\u00e3o do TTL at\u00f3mico no quotidiano<\/h2>\n<p>Defino os TTLs <strong>at\u00f3mico<\/strong> durante a grava\u00e7\u00e3o, em vez de os atribuir numa etapa separada. Comandos como SET com EX\/PX garantem que as chaves nunca sejam armazenadas sem tempo de expira\u00e7\u00e3o. Desta forma, evito valores at\u00edpicos que mais tarde forcem evic\u00e7\u00f5es ou bloqueiem a mem\u00f3ria a longo prazo. Quando atualizo valores existentes, utilizo op\u00e7\u00f5es que <strong>TTL<\/strong> mantidos, se tal for desej\u00e1vel do ponto de vista sem\u00e2ntico. Isto evita o \u201erejuvenescimento\u201c involunt\u00e1rio de conte\u00fados de longa dura\u00e7\u00e3o e preserva a previsibilidade dos prazos de retirada.<\/p>\n<p>No caso de teclas de atalho com tr\u00e1fego intenso, n\u00e3o atualizo o TTL cegamente a cada acesso. Em vez disso, defino <strong>probabil\u00edstica<\/strong> Renova\u00e7\u00e3o pouco antes do fim do prazo, para dosificar o trabalho. Estes padr\u00f5es reduzem a carga de grava\u00e7\u00e3o e diminuem a probabilidade de muitas chaves ficarem \u201enovas\u201c em simult\u00e2neo e, mais tarde, voltarem a ficar em simult\u00e2neo <strong>caducar<\/strong>. Al\u00e9m disso, aplico suaviza\u00e7\u00e3o com jitter (\u00b1X %) no lado de escrita.<\/p>\n<ul>\n  <li>Manter a consist\u00eancia da API de escrita: utilizar sempre SET com EX\/PX ou variantes equivalentes.<\/li>\n  <li>Evitar o desvio do TTL: renovar apenas se o tempo de validade restante ficar abaixo de um limiar definido.<\/li>\n  <li>Atualiza\u00e7\u00f5es sem altera\u00e7\u00e3o do TTL: escolher deliberadamente op\u00e7\u00f5es que mantenham o atual <strong>Data de validade<\/strong> respeitar.<\/li>\n<\/ul>\n\n<h2>Persist\u00eancia, \u00abCopy-on-Write\u00bb e expira\u00e7\u00e3o em massa<\/h2>\n<p>Em ambientes com <strong>RDB<\/strong>-Instant\u00e2neos ou <strong>AOF<\/strong> A expira\u00e7\u00e3o em massa pode provocar efeitos secund\u00e1rios adicionais. Durante um fork (BGSAVE\/AOF Rewrite), muitas opera\u00e7\u00f5es de elimina\u00e7\u00e3o ou altera\u00e7\u00e3o resultam num aumento do volume de opera\u00e7\u00f5es \u00abcopy-on-write\u00bb. Consequentemente, a necessidade de RAM tempor\u00e1ria aumenta, apesar de, na verdade, se estar a libertar mem\u00f3ria. Por isso, planeio deliberadamente grandes ondas de limpeza <strong>em diferido<\/strong> relativamente \u00e0s janelas de persist\u00eancia ou regule a expira\u00e7\u00e3o ativa nessas fases.<\/p>\n<p>Quando os registos s\u00e3o muito grandes, separo a partilha do caminho da solicita\u00e7\u00e3o. Elimina\u00e7\u00e3o ass\u00edncrona (<strong>DESLIGAR<\/strong> ou modos \u00abLazy-Free\u00bb) alivia a carga do ciclo de eventos principal e uniformiza os tempos de resposta. Ao mesmo tempo, monitorizo a carga das threads em segundo plano, para que a CPU n\u00e3o fique a funcionar a plena capacidade durante longos per\u00edodos. Em caso de <strong>r\u00e1cio_de_fragmenta\u00e7\u00e3o_de_mem\u00f3ria<\/strong> Avalio a desfragmenta\u00e7\u00e3o ativa e verifico se existem objetos ou codifica\u00e7\u00f5es (por exemplo, cadeias de caracteres compress\u00edveis) que estejam a causar fragmenta\u00e7\u00e3o desnecess\u00e1ria.<\/p>\n<p>\u00c9 importante prestar aten\u00e7\u00e3o tamb\u00e9m ao ficheiro AOF: a atualiza\u00e7\u00e3o frequente dos TTLs gera entradas adicionais no registo. Em caches com grande volume de grava\u00e7\u00f5es, pode ocorrer um <strong>Reescrever<\/strong> vale a pena faz\u00ea-lo mais cedo, assim que a rela\u00e7\u00e3o entre a carga e o tamanho do AOF se alterar. Observo estes efeitos durante o funcionamento e defino as janelas de manuten\u00e7\u00e3o de forma a que o tr\u00e1fego dos utilizadores e as tarefas internas se sobreponham o menos poss\u00edvel <strong>sobrepor<\/strong>.<\/p>\n\n<h2>Notas espec\u00edficas sobre a expira\u00e7\u00e3o, por tipo de dados<\/h2>\n<p>No Redis, a expira\u00e7\u00e3o tem sempre efeito <strong>N\u00edvel-chave<\/strong>. Isso \u00e9 fundamental para a conce\u00e7\u00e3o de estruturas:<\/p>\n<ul>\n  <li>Hashes\/Listas\/Conjuntos: os elementos que os comp\u00f5em n\u00e3o t\u00eam um TTL pr\u00f3prio. Se apenas alguns campos espec\u00edficos tiverem de expirar, separo-os em chaves pr\u00f3prias ou mantenho, al\u00e9m do contentor, um <strong>\u00cdndice<\/strong>, que remove periodicamente os elementos obsoletos.<\/li>\n  <li>Conjuntos ordenados para a frescura: para classifica\u00e7\u00f5es com prazos de validade, utilizo carimbos de data\/hora como pontua\u00e7\u00e3o e elimino <strong>ZREMRANGEBYSCORE<\/strong> . Isso \u00e9 mais f\u00e1cil de planear do que um \u00fanico TTL na chave do contentor, caso apenas uma parte deva ser atualizada.<\/li>\n  <li>Fluxos: Em vez de definir o TTL no fluxo, eu defino <strong>MAXLEN<\/strong>\/<strong>~<\/strong> Estrat\u00e9gias para limitar a mem\u00f3ria de forma controlada e gradual. \u00c9 assim que evito picos de carga repentinos causados por um grande volume de <strong>Expirar<\/strong>.<\/li>\n  <li>Valores grandes (\u201eBig Keys\u201c): a sua expira\u00e7\u00e3o pode causar uma lat\u00eancia significativa. Divido os objetos grandes em segmentos mais pequenos ou elimino-os de forma ass\u00edncrona, para que as solicita\u00e7\u00f5es individuais n\u00e3o atinjam o custo total de liberta\u00e7\u00e3o <strong>pagar<\/strong>.<\/li>\n<\/ul>\n<p>No caso de objetos Rate Limiter, Session ou Token, aplico explicitamente a corre\u00e7\u00e3o de janelas de tempo. Modelos como <strong>Janela de correr<\/strong> ou o Token Bucket com jitter impedem que muitos limites sejam reiniciados de forma sincronizada a cada minuto ou hora. Isto reduz os efeitos de sincroniza\u00e7\u00e3o com a expira\u00e7\u00e3o ativa e suaviza o <strong>Curva de carga<\/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\/09\/redis-analyse-4907.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O ajuste na pr\u00e1tica: plano de medi\u00e7\u00e3o, limiares e manuais de procedimentos<\/h2>\n<p>Procedo de forma iterativa e defino um <strong>plano de medi\u00e7\u00e3o<\/strong> que abranja as hip\u00f3teses essenciais. O objetivo \u00e9 otimizar de forma reproduz\u00edvel a intera\u00e7\u00e3o entre a distribui\u00e7\u00e3o de TTL, a limpeza ativa, a pol\u00edtica de evic\u00e7\u00e3o e o buffer de mem\u00f3ria.<\/p>\n<ul>\n  <li>Registar a linha de base: lat\u00eancia (P50\/P95\/P99), <strong>chaves_expiradas<\/strong>, <strong>chaves_despejadas<\/strong>, rela\u00e7\u00e3o entre chaves e TTL, utiliza\u00e7\u00e3o da CPU, mem\u00f3ria e fragmenta\u00e7\u00e3o.<\/li>\n  <li>Priorizar hip\u00f3teses: por exemplo, \u201eO jitter do TTL reduz os picos P99 em \u226520 %\u201c, \u201ehz+2 reduz a ocupa\u00e7\u00e3o da RAM em \u226510 % sem aumento do P95\u201c.<\/li>\n  <li>Altera\u00e7\u00f5es controladas: um par\u00e2metro por experimento (jitter do TTL, hz, pol\u00edtica), dura\u00e7\u00e3o \u2265 v\u00e1rios per\u00edodos do TTL.<\/li>\n  <li>Avalia\u00e7\u00e3o: Comparar as m\u00e9tricas antes e depois, documentar as regress\u00f5es e registar claramente a decis\u00e3o.<\/li>\n<\/ul>\n<p>Para o funcionamento, defino <strong>Livros de execu\u00e7\u00e3o<\/strong> com fatores desencadeantes e medidas claras. Exemplos:<\/p>\n<ul>\n  <li>A lat\u00eancia do P99 aumenta e <strong>chaves_expiradas<\/strong> Aumentar rapidamente: aumento imediato do jitter nas novas opera\u00e7\u00f5es de grava\u00e7\u00e3o, aumentar temporariamente a frequ\u00eancia de forma moderada e, em seguida, verificar se o buffer Maxmemory ainda \u00e9 adequado.<\/li>\n  <li>Elevado <strong>chaves_despejadas<\/strong>-Taxa em TTLS est\u00e1veis: separar a carga de trabalho ou alterar a pol\u00edtica para variantes vol\u00e1teis; verificar, em paralelo, os tamanhos dos objetos.<\/li>\n  <li>Redu\u00e7\u00e3o gradual da RAM quando existem muitas chaves expiradas: refor\u00e7ar de forma seletiva a expira\u00e7\u00e3o ativa, aumentar ligeiramente os ciclos em segundo plano e, se necess\u00e1rio, ajustar as op\u00e7\u00f5es \u00abLazy-Free\u00bb.<\/li>\n<\/ul>\n<p>Para <strong>An\u00e1lise da causa raiz<\/strong> Combino m\u00e9tricas com eventos: momentos de implementa\u00e7\u00e3o, picos de tr\u00e1fego, tarefas em lote, janelas de persist\u00eancia. Muitas vezes, verifica-se uma correla\u00e7\u00e3o clara entre o evento e o pico na m\u00e9trica. Utilizo estas indica\u00e7\u00f5es para isolar rapidamente poss\u00edveis problemas e ajustar com precis\u00e3o os par\u00e2metros.<\/p>\n\n<h2>Detalhes do cluster: distribuir os slots e resolver os pontos de congestionamento<\/h2>\n<p>Nos clusters, tenho o cuidado de garantir que as teclas de atalho tenham <strong>TTLs<\/strong> nem todos caem no mesmo slot. Uma estrat\u00e9gia equilibrada de hashtags evita que as expira\u00e7\u00f5es ativas e as reconstru\u00e7\u00f5es se acumulem num \u00fanico shard. Al\u00e9m disso, distribuo as classes de dados (sess\u00f5es, cache de p\u00e1ginas, sinalizadores de funcionalidades) de forma a que os seus ciclos de vida sejam homog\u00e9neos por fragmento. Isto facilita a escolha de pol\u00edticas de evic\u00e7\u00e3o adequadas para cada fragmento e mant\u00e9m a <strong>Lat\u00eancia<\/strong> est\u00e1vel.<\/p>\n<p>Ao migrar chaves entre shards ou inst\u00e2ncias, verifico se <strong>TTLs restantes<\/strong> s\u00e3o mantidos e as regras de jitter continuam a ser aplicadas. Antes de movimentos em grande escala, prevejo per\u00edodos de seguran\u00e7a para evitar que os processos de rehashing, expira\u00e7\u00e3o e persist\u00eancia ocorram simultaneamente. O resultado s\u00e3o <strong>Transi\u00e7\u00f5es<\/strong> sem picos de carga.<\/p>\n\n<h2>Controlar de forma consciente as notifica\u00e7\u00f5es do Keyspace e os custos indiretos<\/h2>\n<p><strong>Notifica\u00e7\u00f5es do Keyspace<\/strong> s\u00e3o sinais valiosos para integrar eventos de expira\u00e7\u00e3o na l\u00f3gica da aplica\u00e7\u00e3o. Ativo apenas os canais necess\u00e1rios e limito deliberadamente os ouvintes, para evitar sobrecarga. Em per\u00edodos de pico, limito o n\u00famero de consumidores ligados, para que n\u00e3o sobrecarreguem ainda mais o thread do Redis. Sempre que poss\u00edvel, processei os eventos <strong>ass\u00edncrono<\/strong> e agrup\u00e1-las, em vez de desencadear imediatamente a\u00e7\u00f5es subsequentes dispendiosas para cada evento.<\/p>\n\n<h2>Reconhecer e retificar padr\u00f5es de erro<\/h2>\n<p>Em primeiro lugar, os picos de lat\u00eancia costumam acumular-se durante as horas de ponta <strong>Minuto<\/strong> ou por hora, quando os processos em lote definem TTLs id\u00eanticos. Desfaso os feeds no tempo e adiciono deslocamentos aleat\u00f3rios. Em segundo lugar, por vezes o espa\u00e7o de armazenamento aumenta lentamente, apesar de os TTLs estarem definidos. A causa \u00e9 frequentemente uma limpeza ativa insuficiente, por exemplo, devido a um valor baixo de hz ou \u00e0 falta de acessos. Nesse caso, aumento moderadamente o valor de hz e valido chaves cr\u00edticas com acessos ligeiros em segundo plano, at\u00e9 que as entradas expiradas sejam rapidamente <strong>desaparecer<\/strong>.<\/p>\n<p>Em terceiro lugar, um grande n\u00famero de evictions quando se atinge o limite de Maxmemory indica TTLs demasiado longos ou uma pol\u00edtica inadequada. Quando estruturas importantes s\u00e3o substitu\u00eddas no allkeys-lru, distribuo melhor as cargas de trabalho e utilizo variantes volatile. Al\u00e9m disso, verifico se \u00e9 poss\u00edvel dividir o espa\u00e7o de chaves em objetos \u00abquentes\u00bb e \u00abfrios\u00bb, por exemplo, atrav\u00e9s de namespaces ou inst\u00e2ncias separadas. Adicionalmente, monitorizo as lat\u00eancias P99, pois estas revelam os pontos de estrangulamento mais cedo do que o <strong>m\u00e9dia<\/strong>. \u00c9 assim que intervenho antes de o utilizador sentir as consequ\u00eancias.<\/p>\n\n<h2>Resumo e pr\u00f3ximas etapas<\/h2>\n<p>Otimizo o desempenho da expira\u00e7\u00e3o ao <strong>TTL<\/strong>-Utilizo dispers\u00e3o, pol\u00edticas de evic\u00e7\u00e3o sensatas e uma frequ\u00eancia de atualiza\u00e7\u00e3o (hz) cuidadosamente ajustada. A monitoriza\u00e7\u00e3o com chaves que expiram a cada intervalo, tempos de ciclo ativos e lat\u00eancias P95\/P99 torna os efeitos vis\u00edveis. Se atenuar os tempos de expira\u00e7\u00e3o simult\u00e2neos e mantiver uma reserva de RAM realista, os tempos de resposta permanecem constantes. Utilizo procedimentos de liberta\u00e7\u00e3o ass\u00edncronos de forma seletiva, sempre que estes atenuam picos de lat\u00eancia. Com limites claros, testes cont\u00ednuos e pequenos passos mensur\u00e1veis, mantenho o Redis como uma solu\u00e7\u00e3o que escala de forma fi\u00e1vel <strong>Componente<\/strong>.<\/p>\n<p>Em seguida, defino limiares concretos por inst\u00e2ncia, escaloneio os TTLs com deslocamentos e verifico a pol\u00edtica de evic\u00e7\u00e3o em rela\u00e7\u00e3o aos dados de utiliza\u00e7\u00e3o atuais. Depois, ajusto o hz para um valor m\u00ednimo e volto a medir at\u00e9 que as fases de expira\u00e7\u00e3o decorram sem problemas. Para ambientes de grande dimens\u00e3o, planeio inst\u00e2ncias separadas para conte\u00fados de curta e longa dura\u00e7\u00e3o. Com esta abordagem, garanto tempos de resposta curtos, um consumo de mem\u00f3ria previs\u00edvel e um n\u00edvel elevado e constante de <strong>Cache<\/strong>-Taxa de acertos.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprenda a otimizar o desempenho da expira\u00e7\u00e3o de chaves do Redis com estrat\u00e9gias de TTL adequadas, pol\u00edticas de evic\u00e7\u00e3o e monitoriza\u00e7\u00e3o espec\u00edfica, mantendo o seu cache est\u00e1vel. Foco: expira\u00e7\u00e3o de chaves do Redis.<\/p>","protected":false},"author":1,"featured_media":21590,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21597","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":"124","_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 Key","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":"21590","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21597","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=21597"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21597\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21590"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21597"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21597"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21597"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}