Uma camada de cache rápida, altamente disponível, resiliente e dimensionável que se estende por todas as nuvens.
O armazenamento em cache melhora o tempo de resposta do aplicativo porque mantém cópias dos dados usados com mais frequência em um armazenamento efêmero, mas muito rápido. Se quiser atingir esses objetivos, recomendamos soluções de cache na memória, que mantêm o conjunto de trabalho em DRAM rápida, em vez de discos giratórios lentos, mostrando-se extremamente eficazes. O armazenamento em cache é comumente utilizado para melhorar a latência do aplicativo, mas um cache altamente disponível e resiliente também pode ajudar a dimensionar os aplicativos. Ao transferir responsabilidades da lógica do aplicativo principal para a camada de cache, liberamos recursos de computação para processar mais solicitações de entrada. Continue lendo para conhecer alguns estudos de caso.
Como você sabe, a maioria dos bancos de dados tradicionais foi projetada para oferecer funcionalidade robusta em vez de velocidade em escala. Muitas vezes, o cache do banco de dados é usado para armazenar cópias de tabelas de pesquisa e respostas a consultas caras do DBMS, a fim de melhorar o desempenho do aplicativo e reduzir a carga na fonte de dados.
Uma parte integrante da criação de aplicativos escalonáveis e responsivos é o armazenamento em cache dos dados da sessão do usuário. Como cada interação do usuário requer acesso aos dados da sessão, manter esses dados em cache acelera o tempo de resposta do aplicativo ao usuário. Manter os dados da sessão no cache é melhor do que manter as sessões fixas no nível do balanceador de carga, porque o cache permite que as solicitações sejam processadas por qualquer servidor de aplicativos sem perder os estados do usuário. A abordagem do balanceador de carga, por outro lado, força todas as solicitações de uma sessão a serem processadas por um único servidor de aplicativos.
Os aplicativos modernos são criados com componentes acoplados, de forma frágil, que se comunicam por meio de diferentes APIs. Os componentes do aplicativo usam APIs para fazer solicitações de serviço a outros componentes, tanto dentro (arquitetura de microsserviços) quanto fora (em um caso de uso de software como serviço) do próprio aplicativo. Sabemos que armazenar em cache a resposta da API, mesmo que brevemente, melhora o desempenho do aplicativo ao evitar essa comunicação entre processos.
O primeiro requisito que uma camada de cache deve atender é o alto desempenho sob qualquer carga. Pesquisas indicam que, para que os usuários percebam uma experiência como “instantânea”, o tempo de resposta de ponta a ponta deve estar dentro de 100 milissegundos. Simplificando, uma camada de cache de alto desempenho deve fornecer uma taxa de transferência consistentemente alta com baixa latência – para que não seja gargalo no desempenho.
Dia dos Namorados, Black Friday, catástrofes naturais ou pandemias são eventos de Transbordo, e uma camada de cache de alto desempenho deve ser capaz de escalonar e atender à demanda resultante do crescimento dos negócios. A escalabilidade deve ser alcançada de forma dinâmica, sem paralisação ou tempo de inatividade ou migrações off-line, ou mesmo sem aumentar o tempo de resposta.
Cada vez mais organizações estão adotando estratégias de várias nuvens a fim de evitar a dependência de fornecedores ou para aproveitar as melhores ferramentas de vários provedores de nuvem. No entanto, é muito mais difícil gerenciar um sistema de cache geograficamente distribuído que garanta latência inferior a um milissegundo e, ao mesmo tempo, seja capaz de solucionar conflitos de conjuntos de dados em várias nuvens.
Essa é a maneira mais comum de usar o Redis como um cache. Em nossa estratégia, o aplicativo inicialmente pesquisa o cache para recuperar os dados. Se os dados não forem encontrados (falha no cache), o aplicativo os buscará diretamente do armazenamento de dados operacionais. Os dados são carregados no cache somente quando são necessários (por isso, o método também é conhecido como carregamento lento). Os aplicativos de leitura intensiva podem se beneficiar muito da implementação de uma abordagem de cache.
Assim, os dados são inicialmente gravados no cache (por exemplo, no Redis) e, em seguida, atualizados de forma assíncrona no armazenamento de dados operacional. Isso nos permite melhorar o desempenho de gravação e facilita o desenvolvimento de aplicativos, pois o desenvolvedor grava em um único local (Redis). Temos boas notícias: o RedisGears oferece recursos de gravação direta e indireta.
Dê uma olhada na demonstração no GitHub
Essa estratégia é semelhante à abordagem de write-back, pois é semelhante à de write-through, em que o cache fica entre o aplicativo e o armazenamento de dados operacional, mas as atualizações são feitas de forma síncrona. Esse modelo de gravação favorece a consistência dos dados entre o cache e o armazenamento de dados, pois a gravação é realizada no thread principal do servidor. Temos boas notícias: o RedisGears oferece recursos de gravação direta e indireta.
Dê uma olhada na demonstração no GitHub
Se tivermos uma grande quantidade de dados históricos (por exemplo, um mainframe) ou um requisito de que cada gravação seja registrada em um armazenamento de dados operacional, os conectores de alterar captura de dados (CDC) do Redis Enterprise podem identificar alterações de dados individuais e propagar cópias exatas sem interromper as operações em andamento com consistência quase em tempo real. O CDC, juntamente com a capacidade do Redis Enterprise de usar vários modelos de dados, é capaz de prover informações valiosas sobre dados que antes estavam bloqueadas.
Vários recursos de modelo de dados no RedisO desempenho do aplicativo depende da camada de cache. Até mesmo um segundo de tempo de inatividade pode ter um efeito extremo no desempenho e na capacidade de atender ao seu SLA, pois o cache pode executar milhões de operações por segundo. Os principais fatores para garantir uma camada de cache altamente disponível e proporcionar uma experiência consistente ao usuário são os backups automáticos do Redis Enterprise, a detecção instantânea de falhas, a recuperação rápida entre racks/zonas/regiões e as várias opções de persistência de dados.
É sabido que uma camada de cache de aplicativos de alto desempenho deve ser dimensionada de forma fácil e instantânea a fim de atender aos requisitos de crescimento e aos picos de demanda. O alto desempenho do Redis Enterprise com latência inferior a um milissegundo, a verdadeira arquitetura sem compartilhamento que permite o dimensionamento linear, o suporte a vários usuários e a arquitetura com vários núcleos, garantem a utilização total dos recursos de computação e um desempenho superior.
A camada de cache deve oferecer alta disponibilidade e baixa latência em todas as regiões geográficas, independentemente do ambiente de implantação. Além disso, a tecnologia Ativo-Ativo do Redis Enterprise, baseada em CRDTs, fornece latência local para suas operações de leitura e gravação, resolução perfeita de conflitos para tipos de dados simples e complexos e garante a continuidade dos negócios – mesmo quando um grande número de réplicas está inativo. Os resultados: redução dos problemas de desenvolvimento e da sobrecarga operacional.
Há muitas soluções disponíveis que se baseiam em tecnologias de nicho ou são criadas para casos de uso específicos e não são amplamente adotadas. Esse não é o caso do Redis de código aberto, que suporta mais de 50 linguagens de programação, mais de 150 bibliotecas de clientes e é a camada de cache padrão na maioria dos ambientes de implantação. Somos o banco de dados mais bem avaliado pelo quarto ano consecutivo e o Redis é o Redis de código aberto que traz recursos de nível empresarial para sua camada de cache.
Não queremos que você adicione sobrecarga operacional à sua equipe, portanto, a implantação de uma camada de cache deve ser fácil e rápida. O Redis Enterprise pode ser implantado como um serviço totalmente gerenciado em nuvens públicas, liberando-o de tarefas de provisionamento, aplicação de patches, monitoramento e outras tarefas de gerenciamento. E se você quiser obter o controle total de gerenciamento e configuração, ele também pode ser implantado como software em sua própria infraestrutura. É por isso que o modelo híbrido é suportado para preservar a flexibilidade operacional.
O Redis foi projetado com base no conceito de estruturas de dados e você pode armazenar seu conjunto de dados por meio de Strings, Hashes, Sorted Sets, Sets, Lists, Streams e outras estruturas de dados ou módulos Redis.
Ao usar o Node.js, você pode recuperar e armazenar pares de valores-chave com cadeias simples por meio dos comandos GET e SET do objeto cliente, veja abaixo como fazer:
// Conecte o cliente redis à instância local. const client = redis.createClient(6379) // Recupere um valor de cadeia de caracteres do Redis se ele já existir para essa chave return client.get(‘myStringKey’, (err, value) => { if (value) { console. log(‘O valor associado a essa chave é: ‘ + valor) } else{ //chave não encontrada // Armazenamento de uma única cadeia de caracteres no armazenamento do Redis client.set(‘myStringKey’, ‘Redis Enterprise Tutorial’); } } } } });Com esse fragmento, você pode tentar recuperar o valor da cadeia de caracteres associado à chave myStringKey usando o comando GET. Se a chave não for encontrada, o comando SET armazena o valor do Redis Enterprise Tutorial para myStringKey.
O mesmo código pode ser escrito em Python, aqui está:
# Conectar o cliente Redis à instância local. r = redis.Redis(host=’localhost’, port=6379, db=0) # Recuperar um valor de cadeia de caracteres do Redis se ele já existir para essa chave value = r.get(‘myStringKey’) if value == None: # chave não encontrada # Armazenar uma única cadeia de caracteres no armazenamento do Redis r.set(‘myStringKey’, ‘Redis Enterprise Tutorial’) else: print ‘O valor associado a essa chave é: ‘, value.
