Olá? Sou o Jayon.

Hoje, vou explicar os critérios para configurar o cache. Como é um post que escrevo com base na minha experiência prática, ele serve apenas como referência, ok? ㅎㅎ

O que é cache?

O cache significa armazenar previamente o resultado de uma solicitação para que possa ser servido rapidamente. Ou seja, o resultado é armazenado previamente e, quando uma solicitação chega, em vez de consultar o DB ou API, o cache é acessado para tratar a solicitação. A origem do cache é a Lei de Pareto.

A Lei de Pareto afirma que 80% dos resultados são causados por 20% das causas. Veja a imagem abaixo!

Ou seja, o cache não precisa armazenar todos os resultados e, armazenando apenas os 20% mais usados ao servir, a eficiência geral pode ser melhorada.

Quais dados devem ser armazenados em cache?

De acordo com a Lei de Pareto, você não deve armazenar em cache dados aleatórios, apenas os dados essenciais. Então, quais dados devem ser armazenados em cache?

Dados que precisam ser lidos com frequência, mas raramente escritos

Em teoria, diz-se que "os dados que precisam ser lidos com frequência, mas raramente escritos, devem ser armazenados em cache", mas os critérios de "leitura frequente" e "escrita rara" são bastante vagos.

Por isso, investigo os dados a serem armazenados em cache seguindo estas etapas.

• Verifique o TOP 5 das chamadas de consulta do RDB por meio de um APM como o DataDog.
• Entre eles, procure as consultas de consulta e verifique qual tabela está sendo consultada.
• Verifique quantas vezes a consulta de atualização da tabela correspondente é chamada.

Esse processo visa verificar se há muitas consultas, mas poucas consultas de atualização. Na minha experiência prática, verifiquei que uma tabela tinha 1.740.000 consultas por dia, mas no máximo 500 consultas de atualização. Isso parece um candidato ideal para o cache. ㅎㅎ

Dados sensíveis a atualizações

Dados sensíveis a atualizações significam que a discrepância entre o RDB e o cache deve ser pequena. Por exemplo, as informações relacionadas a pagamentos são muito sensíveis a atualizações, portanto, mesmo que atendam aos critérios de cache acima, você deve considerar a aplicação.

Tive que armazenar em cache a tabela relacionada a pagamentos que atende a essas duas características. Portanto, não apliquei o cache a toda a lógica que usa essa tabela relacionada a pagamentos, mas sim a lógica relativamente segura que não envolve pagamentos reais, como um cache parcial.

Cache local vs. cache global

Agora, definimos quais dados serão armazenados em cache e o escopo do cache. Então, precisamos pensar em "onde" armazenar os dados em cache. Normalmente, você pode armazenar na memória local ou em um servidor separado como o Redis.

Cache local

O cache local é um método de armazenamento dos dados a serem armazenados em cache na memória do servidor de aplicação. Geralmente, Guava cache ou Caffeine cache são usados.

Vantagens

• Como o cache é consultado na memória do mesmo servidor durante a execução da lógica de aplicativo, a velocidade é rápida.
• É fácil de implementar.

Desvantagens

• Se houver várias instâncias, vários problemas ocorrerão.
  • O cache alterado em uma instância não pode ser propagado para outras instâncias. No entanto, existem bibliotecas de cache local que propagam alterações para outras instâncias.
  • Como o cache é armazenado em cada instância, é necessário inserir o cache novamente quando uma nova instância é iniciada. Isso pode resultar em muitos acessos em cache e, devido ao tráfego, a instância pode falhar.

Cache global

O cache global é um método que usa um servidor separado, como o Redis, para armazenar dados em cache.

Vantagens

• Como o cache é compartilhado entre instâncias, mesmo que o cache seja modificado em uma instância, todas as instâncias podem obter o mesmo valor de cache.
• Mesmo que uma nova instância seja iniciada, ela pode ver o repositório de cache existente, então você não precisa inserir o cache novamente.

Desvantagens

• Como você precisa passar pelo tráfego de rede, a velocidade é mais lenta em comparação com o cache local.
• Um servidor de cache separado é necessário, o que resulta em custos de gerenciamento de infraestrutura.
  • Custos de gerenciamento de infraestrutura? → Taxas de servidor, tempo necessário para configurar e manter a infraestrutura, planejamento de medidas de resposta a falhas, etc.

O que escolhi?

O servidor de aplicativo da minha empresa atual é configurado para executar várias instâncias, mas escolhi o cache local.

Existem três razões principais.

• Os dados a serem armazenados em cache no RDB são pouco menos de 40.000, então mesmo que todos sejam colocados na memória, eles são menores que 4 MB.
• O desempenho de consulta de dados relacionados a pagamentos precisava ser bom.
• O Redis já existe, mas armazenar novos caches no Redis resultaria em custos de infraestrutura.

Como atualizar o cache?

Se houver vários servidores de aplicativos e o cache local estiver aplicado, o valor do cache armazenado em cada servidor de aplicativo pode ser diferente. Por exemplo, o valor de cache armazenado no servidor A é "1", mas o valor de cache armazenado no servidor B pode ser "2" porque foi alterado no servidor B. Nesse caso, se o usuário enviar uma solicitação ao balanceador de carga, ele receberá valores diferentes do servidor A e do servidor B.

Portanto, você deve configurar cada instância para que o cache seja removido automaticamente e consultado no RDB. Nesse caso, TTL é usado principalmente.

Quanto tempo o TTL deve ser definido?

TTL é a abreviação de Time To Live, que é uma configuração que exclui o cache após um determinado período de tempo. Por exemplo, se o TTL for definido como 5 segundos, os dados em cache serão excluídos automaticamente após 5 segundos. Em seguida, se ocorrer um erro de cache, os dados serão buscados no RDB e armazenados.

Então, quanto tempo o TTL deve ser definido?

Leitura/gravação ocorrendo em um servidor de cache

Se a leitura/gravação ocorrer em um servidor de cache global, como o Redis, ou em um servidor de aplicativo com cache local, o valor do TTL pode ser aumentado para unidades de tempo ou mais. De qualquer forma, o cache será atualizado durante a gravação e o servidor que obtém os dados desse cache sempre receberá os dados atualizados.

Nesse caso, você também pode configurar o cache para que ele não seja definido e o cache seja excluído gradualmente usando o algoritmo LRU quando o servidor de cache estiver cheio.

Leitura/gravação ocorrendo em vários servidores de cache

Se a leitura/gravação ocorrer em vários servidores de cache global ou em vários servidores de aplicativo com cache local, é melhor definir o TTL em unidades de segundos ou minutos. Isso ocorre porque existe a possibilidade de ler dados desatualizados do servidor de cache que ainda não refletiu os dados modificados.

Nesse caso, o TTL é decidido em vários contextos. Quanto mais importante a atualização e maior a probabilidade de modificação do valor, mais curto deve ser o TTL. Quanto menos importante a atualização e menor a probabilidade de modificação do valor, mais longo pode ser o TTL.

Como configurei o TTL?

Os dados que eu armazeno em cache estão relacionados a pagamentos e, embora o cache não seja aplicado à lógica rigorosa em que os pagamentos reais ocorrem, a atualização é importante devido à natureza dos pagamentos. No entanto, como a probabilidade de atualização é baixa, o TTL foi definido com segurança para cerca de 5 segundos.

Conclusão

Resumindo, o método de cache que escolhi é o seguinte.

• Dados relacionados a pagamentos
• Consultas muito frequentes, mas atualizações raras.
• O cache é aplicado à lógica que não envolve pagamentos reais, mas que inclui consultas.
• O cache local foi aplicado e o TTL foi definido como 5 segundos.

A próxima etapa é realizar um teste de desempenho com base no método de cache aplicado. Ainda estou pensando em como executar o teste de desempenho específico, então escreverei sobre isso em um post posterior!