Redis Cache despejo

Geralmente, um cache é um componente de software ou hardware que mantém dados de solicitações anteriores do cliente, para que os dados possam ser recuperados e servidos mais rapidamente para as solicitações feitas no futuro. Na maioria dos casos, os sistemas de back -end não são tão rápidos quanto você gostaria que eles fossem. O cache fica entre a camada de banco de dados de back -end e o aplicativo cliente, fornecendo recuperação rápida de dados e um tempo de resposta rápido.

Quando os dados solicitados estão disponíveis no cache Redis, os dados podem ser atendidos diretamente do cache Redis sem redirecionar a solicitação para o banco de dados primário, que é chamado de cache acertado. Por outro lado, se os dados não estiverem disponíveis no Cache Redis, a solicitação precisar.

Com esse tipo de comportamento, o Redis Caching é uma excelente opção para muitos casos de uso.

• Inferências de aprendizado de máquina
• Pesquisas de texto completo
• Consultas complexas de banco de dados relacionais
• Resultados da API de terceiros

Os caches Redis trazem sua aplicação vários benefícios ao introduzir um grande desafio, chamado de speration cache de cache. Em algum momento, seu cache pode estar cheio de dados obsoletos que nem são válidos para hoje. Portanto, deve haver um mecanismo para despejar os dados antigos ou inválidos enquanto você continua usando seu cache redis com novos dados.

Redis Cache despejo

Quando o Redis Cache foi introduzido pela primeira vez, os desenvolvedores estavam usando o valor TTL (tempo de vida) para cada chave para manter uma quantidade relativamente constante de memória, combinando a velocidade dos dados entrando e saindo do sistema. Isso foi muito trabalho manual para desenvolvedores, o que é algo que o servidor Redis deveria estar lidando.

Portanto, a abordagem ideal deve ser para expulsar automaticamente os dados antigos, à medida que o limite máximo de memória de cache é atingido, o que também é o processo seguido pelo sistema memcached. Redis usa o especial MaxMemory Diretiva para notificar que o limite máximo de memória foi atingido.

Diretiva de configuração MaxMemory

Redis usa a diretiva de configuração MaxMemory para identificar a memória máxima disponível para o cache trabalhar. Existem duas maneiras pelas quais você pode definir o valor da diretiva MaxMemory.

• Usando o redis.arquivo conf
• Config Set Command no tempo de execução

A seguir é um exemplo de um redis.arquivo conf que mostra como você pode especificar a memória máxima de cache para o conjunto de dados. Nesse caso, a diretiva MaxMemory foi definida como 1000 bytes.

Da mesma forma, o comando Redis Config Set pode ser usado para definir a diretiva MaxMemory em tempo de execução, como mostrado no seguinte.

Conjunto de configuração MaxMemory 100

Além disso, se você definir o valor da diretiva MaxMemory como 0, isso significa que nenhum limite de memória foi especificado para o cache Redis. Na maioria dos sistemas de 64 bits, esse valor é definido como 0. O sistema de 32 bits usa o limite máximo de memória de 3 GB implicitamente.

Quando o cache Redis atinge o valor da memória especificado pela diretiva MaxMemory, ele começa a remover as chaves de acordo com a política de despejo selecionada. Se nenhuma chave atender aos critérios de política, nada será despejado. Em vez disso, o servidor Redis responderá com erros a comandos como LPush e definido que consome mais memória e responderá apenas a comandos somente leitura como Get.

Na seção a seguir, discutiremos as políticas de despejo de Redis e como elas determinam quais chaves devem ser despejadas ou não.

Políticas de despejo

Uma política de despejo determina o comportamento do cache redis quando o valor maxmemory é alcançado. Redis removerá todas as chaves que atendem aos critérios políticos fornecidos em um determinado momento. Portanto, é importante garantir que você tenha um banco de dados grande o suficiente para manter as chaves desejadas. As seções a seguir descrevem as diferentes políticas de despejo de Redis disponíveis para uso.

Várias políticas de despejo estão disponíveis para uso e Noeviction é um dos mais amplamente utilizados se você não quiser remover nenhuma chave antiga quando o limite máximo de memória for atingido. No entanto, ele lançará erros em todas as operações de gravação Redis para notificar o usuário de que o cache está cheio e liberar algum espaço. Em resumo, os dados não serão salvos no cache até que você libere algum espaço manualmente.

No Volátil-ttl Política, Redis coloca amostras de chaves cujos campos de expiração são definidos como true e despeja aqueles com o menor valor de TTL. Se não houver chaves com o campo de expiração definido como true, nenhum despejo acontecerá, o que é semelhante ao Noeviction política.

Esta é outra versão da política volátil-TTL, onde Redis remove aleatoriamente as chaves cujo campo de expiração é definido como true. Novamente, considera apenas as chaves que têm um valor TTL, mas não todo o espaço chave.

Isso é mais semelhante ao Random volátil política, mas com o Allkeys-Random Política, todo o espaço principal será considerado, não apenas as chaves com um valor TTL. Nesse caso, Redis despejará chaves aleatoriamente para adicionar novos dados.

Ambas as políticas acima usam um algoritmo aleatório para despejar as chaves do cache, o que é bastante arriscado e pode não ser a maneira ideal de fazer o despejo -chave. Então, Redis introduziu uma maneira mais ideal de fazer isso com o novo LRU (menos usado recentemente) algoritmo.

O algoritmo LRU (menos usado)

O algoritmo LRU é baseado na suposição de que, se uma determinada chave foi acessada recentemente, há uma maior probabilidade de acessá -la novamente em um futuro próximo. Por outro lado, se não usamos uma determinada chave há muito tempo, há uma chance maior de que a chave não seja usada em breve ou nunca mais. Com essa suposição, o algoritmo LRU tenta despejar as teclas menos recentemente usadas do cache Redis, que é uma abordagem mais ideal do que os algoritmos de despejo de chave aleatória.

Para implementar esta política, o objeto Redis usa um novo lru Campo com 24 bits atribuídos, que acompanham quando a chave foi usada pela última vez. Com o algoritmo LRU em vigor, é necessário um número especificado de teclas aleatórias e despeja o com o maior tempo de marcha lenta ou o tempo de acesso mais antigo. A diretiva MaxMemory-Samples é usada para especificar o número de chaves por amostra. Isso pode ser definido usando o comando de configuração de configuração, conforme mostrado no seguinte.

Conjunto de configurações MaxMemory Samples 5

É importante ter em mente que Redis executa uma aproximação do algoritmo LRU para manter as coisas simples e economizar recursos de computação como CPU e memória.

Existem dois sabores da política de despejo da LRU.

As chaves menos recentemente usadas com o campo de expiração definidas como true serão removidas. As chaves que não estão associadas a um valor TTL não serão despejadas sob esta política, porque a amostra é tirada apenas das chaves cujo campo de expiração é definido como verdadeiro.

Todas as chaves com o maior tempo de marcha lenta serão removidas. Nesse caso, Redis manterá as chaves usadas mais recentemente.

O algoritmo LFU (menos usado)

Redis introduziu o novo algoritmo LFU (menos usado) na versão 4 da versão 4.0 para identificar as teclas raramente usadas e removê -las do cache quando o limite máximo de memória é atingido. Com a política de LFU, as chaves acessadas com muita frequência permanecerão.

As chaves com os campos de expiração definidos como true e os que são menos usados ​​entre a amostra selecionada serão despejados.

Ele procura todo o espaço chave para as teclas raramente usadas e as exclui enquanto mantém as teclas usadas com frequência.

Conclusão

Para concluir, Redis usa a diretiva MaxMemory para especificar o limite máximo de memória do cache Redis. Conforme discutido, quando o cache atinge seu limite máximo de memória, a política de despejo configurada dispara e remove as chaves. Redis usa as aproximações dos algoritmos LRU e LFU para encontrar os melhores candidatos para despejo.