paint-brush
5 mecanismos de cache para acelerar seu aplicativopor@pragativerma
17,846 leituras
17,846 leituras

5 mecanismos de cache para acelerar seu aplicativo

por Pragati Verma8m2022/09/12
Read on Terminal Reader
Read this story w/o Javascript

Muito longo; Para ler

O cache é uma técnica de buffer em que armazenamos os dados acessados com frequência em memória ou espaço temporário para torná-los prontamente disponíveis e reduzir a carga de trabalho de nosso aplicativo, servidor ou banco de dados. Ele pode ser implementado em diferentes níveis em um aplicativo da Web, dependendo do caso de uso. O cache ocorre em diferentes níveis, como o cache de borda ou CDN (rede de entrega de conteúdo) ou cache do lado do servidor (cache do lado do servidor) O cache pode ser usado com todos os tipos de armazenamentos de dados, incluindo bancos de dados NoSQL, bem como bancos de dados relacionais.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - 5 mecanismos de cache para acelerar seu aplicativo
Pragati Verma HackerNoon profile picture
0-item
1-item


Se você é um desenvolvedor de back-end, o Caching é a solução ideal sempre que precisar acelerar seu aplicativo da web. No entanto, há muito sobre o Caching que falta ao decidir a estratégia de Caching certa para seu aplicativo da web. Portanto, neste artigo, discutiremos as várias estratégias de cache disponíveis e como escolher a certa para o seu caso de uso.


O que é cache?

Em termos mais simples, o Caching é uma técnica de buffer em que armazenamos os dados acessados com frequência em memória ou espaço temporário para torná-los prontamente disponíveis e reduzir a carga de trabalho de nosso aplicativo, servidor ou banco de dados. Ele pode ser implementado em diferentes níveis em um aplicativo da Web, dependendo do caso de uso.


Cache em diferentes níveis em um aplicativo da Web

O armazenamento em cache ocorre em diferentes níveis em um aplicativo da Web, como o seguinte:


Cache de borda ou CDN (rede de entrega de conteúdo)

Um CDN é usado para armazenar em cache ativos estáticos (como imagens, vídeos ou páginas da Web) em servidores distribuídos geograficamente, de modo que possa enviar o conteúdo mais rapidamente ao usuário final usando o cache.


Fonte: https://imagekit.io/


Considere um CDN como uma rede de supermercados: em vez de viajar centenas de quilômetros até os campos onde os alimentos são cultivados, os compradores vão ao supermercado local, que ainda precisa de algumas viagens, mas é consideravelmente mais próximo. As compras de supermercado levam minutos em vez de dias, já que as mercearias estocam alimentos de fazendas distantes. Da mesma forma, o CDN armazena em cache o conteúdo que aparece na Internet, permitindo que as páginas da Web carreguem significativamente mais rápido.


Fonte: https://awesome-tech.readthedocs.io/


Quando um usuário usa um CDN para solicitar qualquer conteúdo de um site, o CDN recupera o conteúdo de um servidor de origem e mantém uma cópia do conteúdo para solicitações futuras. O conteúdo armazenado em cache é mantido no cache CDN enquanto os usuários continuarem a acessá-lo.


Cache do banco de dados

Cache de banco de dados refere-se aos algoritmos de cache inteligentes nativos usados por qualquer banco de dados para otimizar leituras e gravações. O cache, neste caso, pode residir em várias áreas, incluindo o banco de dados, o aplicativo ou como uma camada autônoma.


O cache de banco de dados pode ser usado com todos os tipos de armazenamento de dados, incluindo bancos de dados NoSQL, bem como bancos de dados relacionais, como servidor SQL - MySQL ou MariaDB, etc. Também funciona bem com muitas plataformas de dados, como AWS e Microsoft Azure.


Cache do navegador ou cache do lado do cliente

Os navegadores ou clientes armazenam os ativos estáticos com base nos cabeçalhos de expiração do cache. Os cabeçalhos de cache HTTP especificam por quanto tempo o navegador pode atender as respostas de cache subsequentes para o conteúdo da Web solicitado. Além disso, os navegadores podem armazenar em cache a resposta para solicitações GET para evitar chamadas de dados desnecessárias.


Cache do lado do servidor

O cache do servidor é o mecanismo de cache mais conhecido e usado, no qual os dados são armazenados em cache em um aplicativo de servidor. Aqui as coisas dependem muito das necessidades do negócio, é altamente otimizado para aplicações com menos usuários simultâneos.


O cache da web do lado do servidor geralmente envolve o uso de um proxy da web para manter as respostas da web dos servidores da web na frente dos quais ele reside, diminuindo significativamente sua carga e latência. Esses caches são implementados pelos administradores do site e atuam como um agente intermediário entre o navegador e os servidores de origem.


Outra forma de cache do lado do servidor é utilizando os armazenamentos de valor-chave, como Memcached e Redis. Em contraste, para proxies reversos, que apenas armazenam em cache a resposta HTTP para uma solicitação HTTP específica, qualquer conteúdo da Web necessário para o desenvolvedor do aplicativo pode ser armazenado em cache usando um armazenamento de objeto de chave/valor. O conteúdo da Web geralmente é obtido usando um código de aplicativo ou uma estrutura de aplicativo que pode explorar o armazenamento de dados na memória.


Outra vantagem de empregar armazenamentos de chave/valor para cache online é que eles são frequentemente usados para armazenar sessões da web e outros materiais em cache. Isso fornece uma solução unificada para uma variedade de situações de aplicação.


Por que precisamos de Cache?

Existem vários benefícios do cache, conforme mencionado abaixo:


Melhor desempenho do aplicativo

Conforme discutimos anteriormente, Cache é uma camada de armazenamento de dados de alta velocidade que armazena um subconjunto de dados acessados com frequência e geralmente transitórios, para que solicitações futuras sejam atendidas mais rapidamente do que o acesso ao local de armazenamento original. Assim, o Caching permite a reutilização eficiente de dados previamente acessados ou computados. Portanto, a operação de leitura/gravação de dados é reduzida em grande magnitude e ajuda a melhorar o desempenho geral do aplicativo.


Reduza o custo do banco de dados

Uma única instância de cache pode fornecer centenas de milhares de operações de entrada/saída por segundo, reduzindo assim o custo total ao reduzir o número de instâncias de banco de dados necessárias. Portanto, a economia de custo pode ser significativa se as cobranças de armazenamento forem por taxa de transferência.


Reduza a carga no back-end

O armazenamento em cache pode efetivamente reduzir a carga no servidor de back-end e salvá-lo de um desempenho mais lento, redirecionando as partes específicas da carga de leitura do banco de dados de back-end para a camada de cache na memória. Ele pode evitar que o sistema falhe em momentos de sobrecarga ou pico de tráfego.


Desempenho previsível

Um desafio comum com aplicativos modernos é quando se trata de lidar com picos de uso de aplicativos. Por exemplo - pico em aplicativos de mídia social durante um evento tecnológico mundial, uma partida de críquete ou um dia de eleição, ou uma venda festiva em um site de comércio eletrônico, etc. O aumento da carga no aplicativo pode resultar em latência para obter dados, tornando o desempenho bem como a experiência do usuário imprevisível. Embora, usando um cache na memória de alto rendimento, possamos atenuar esse problema em grande medida.


Elimine os pontos de acesso do banco de dados

Um pequeno subconjunto de dados, como um perfil de celebridade ou produto popular, provavelmente será recuperado com mais frequência do que o restante em muitos aplicativos. Isso pode causar pontos de acesso em seu banco de dados e exigir superprovisionamento de recursos de banco de dados com base nos requisitos de taxa de transferência para os dados usados com mais frequência. O armazenamento de chaves comuns na memória reduz a necessidade de superprovisionamento, ao mesmo tempo em que oferece desempenho rápido e previsível para os dados acessados com mais frequência.


Aumente a taxa de transferência de leitura (IOPS)

Além de reduzir a latência, os sistemas in-memory fornecem taxas de solicitação significativamente maiores do que um banco de dados semelhante baseado em disco. Uma única máquina de cache lateral distribuída pode atender a centenas de milhares de solicitações por segundo.


Tendo discutido os benefícios do armazenamento em cache, vamos nos aprofundar nas estratégias de armazenamento em cache com alguns casos de uso do mundo real. Neste artigo, vamos nos concentrar principalmente nas estratégias de cache do lado do servidor.


5 tipos diferentes de estratégias de cache de servidor

Cache à parte

Nesta estratégia de caching, o cache é logicamente colocado de lado e a aplicação se comunica diretamente com o banco de dados ou com o cache para saber se a informação solicitada está presente ou não. Primeiramente o aplicativo verifica com o cache, se a informação for encontrada, ele lê e retorna os dados, e é conhecido como cache hit , caso contrário, se a informação não for encontrada, é conhecido como cache miss , nesse caso, o O aplicativo consulta o banco de dados para ler as informações e retorna os dados solicitados ao cliente e também os armazena no cache para uso futuro.


Fonte: https://www.prisma.io


É essencialmente benéfico em casos de uso com muita leitura. Portanto, se o servidor de cache estiver inativo, o sistema funcionará corretamente ao se comunicar diretamente com o banco de dados, mas não é uma solução confiável ou de longo prazo em caso de pico de carga ou picos que podem ocorrer repentinamente.


A estratégia de gravação mais comum é gravar diretamente no banco de dados, no entanto, isso pode levar à inconsistência de dados no caso de gravações frequentes. Para lidar com essa situação, os desenvolvedores geralmente usam um cache com TTL (Time to Live) e continuam servindo até que expire.


Aqui está uma rápida visão geral do cache com e sem TTL e quando usá-los:


Cache com TTL

Um cache com TTL é o cache mais comumente usado quando os dados são atualizados com frequência. Nesses casos, você deseja que o cache expire em intervalos regulares, portanto, você pode usar um cache com limite de tempo e o cache será excluído automaticamente assim que o intervalo de tempo passar.


Por exemplo - sessões de servidor ou scorecards esportivos.


Cache sem TTL

Um cache sem TTL é usado para armazenar necessidades que não precisam ser atualizadas com frequência, por exemplo, conteúdo em um site que oferece cursos. Nesse caso, o conteúdo será atualizado ou publicado com pouca frequência e, portanto, é muito mais fácil armazenar em cache sem limite de tempo.


Cache Write-Through

Como o nome sugere, nessa estratégia, qualquer nova informação é primeiro gravada no cache antes da memória/banco de dados principal. Nesse caso, o cache está logicamente entre o aplicativo e o banco de dados. Portanto, se um cliente solicitar alguma informação, o aplicativo não precisa verificar com o cache a disponibilidade das informações, pois o cache já possui as informações e, portanto, elas são recuperadas diretamente do cache e servidas ao cliente.


Fonte: https://www.prisma.io


No entanto, aumenta a latência de uma operação de gravação. Mas, se combinado com outra estratégia de cache chamada cache de leitura, podemos garantir a consistência dos dados.


Cache de Leitura

Nessa estratégia de armazenamento em cache, o cache fica alinhado com o banco de dados de forma que, sempre que houver um erro de cache (dados não encontrados no cache), os dados ausentes serão preenchidos no banco de dados e retornados ao cliente.


Fonte: https://www.prisma.io


Como você deve ter adivinhado, funciona melhor para aplicativos com muitos recursos prontos, de modo que o mesmo conjunto de informações é solicitado repetidas vezes. Por exemplo, um site de notícias serviria as mesmas histórias por um dia indefinidamente.


A desvantagem dessa estratégia é que, se os dados forem solicitados pela primeira vez, será sempre uma falta de cache e, portanto, será mais lento que uma solicitação normal.


Escreva de volta

Nesta estratégia de caching, sempre que há uma operação de escrita, a aplicação escreve a informação na cache que imediatamente reconhece as alterações e depois de algum tempo, volta a escrever os dados na base de dados. Também é conhecida como estratégia de cache Write-behind.


Fonte: https://www.prisma.io


É uma boa estratégia de armazenamento em cache para aplicativos pesados em operações de gravação para melhorar o desempenho de gravação do aplicativo. Ele também pode ajudar a acomodar tempos de inatividade moderados do banco de dados e falhas que podem ocorrer nas instâncias.


Também pode funcionar bem quando emparelhado com um cache de leitura. Além disso, pode reduzir ainda mais a carga de trabalho de gravação no banco de dados se o processamento em lote for suportado. No entanto, a desvantagem é que, se houver uma falha no cache, os dados podem ser perdidos para sempre. Na maioria dos bancos de dados relacionais, o mecanismo de cache write-back é ativado por padrão.


Write-Around

Nesse caso, os dados são gravados diretamente no banco de dados e apenas os dados lidos são armazenados no cache.


Fonte: https://www.prisma.io


Ele pode ser combinado com o cache de leitura e pode ser uma boa escolha em situações em que os dados são gravados uma vez e lidos apenas algumas vezes. Por exemplo, quando há necessidade de logs ou chats em tempo real.


Conclusão

Neste artigo, discutimos o que é cache e os diferentes níveis de cache em um aplicativo e por que precisamos dele. Em seguida, também discutimos várias estratégias de cache para cache do lado do servidor. No entanto, não é necessário que qualquer uma dessas estratégias de cache atenda aos seus casos de uso prático, mas é sempre recomendável optar por uma combinação dessas estratégias para obter os melhores resultados.


Para um desenvolvedor novo nisso, pode ser necessário tentar e errar, ou podemos dizer, acertar ou errar para obter uma compreensão mais completa do conceito no sentido prático e encontrar a melhor solução para um caso de uso específico.


Isso foi tudo para este artigo, espero que você tenha achado útil. Deixe-me saber o que você pensa. Você pode se conectar comigo aqui:


Linkedin | Twitter | GitHub


Continue lendo!