O uso do cache Redis melhora muito o desempenho e a eficiência das aplicações, especialmente para consultas de dados. Mas, ao mesmo tempo, isso também traz alguns problemas. Entre eles, o problema mais importante é a consistência dos dados, que é estritamente insolúvel. Se for necessária consistência de dados, então o cache não pode ser usado.
Outros problemas típicos são penetração de cache, avalanche de cache e quebra de cache. Atualmente, também existem soluções mais populares no setor. Este artigo não pretende resolver esses três problemas de forma mais perfeita, nem subverter as soluções populares na indústria. Em vez disso, vamos demonstrar esses três fenômenos problemáticos a partir da operação real do código. A razão para fazer isso é que é difícil ter um conceito muito vívido na cabeça apenas olhando para a explicação acadêmica desses problemas, e com demonstrações reais de código, você pode aprofundar sua compreensão e compreensão desses problemas.
Penetração de cache
Penetração de cache refere-se à consulta de dados que não existem em um banco de dados. Se a chave não existir ou expirar, o banco de dados é consultado e os objetos consultados são colocados no cache. Se o objeto de consulta do banco de dados estiver vazio, ele não é armazenado em cache.
Fluxo de código
- parâmetro passa o ID da chave primária do objeto
- Obtenha o objeto do cache com base na chave
- Se o objeto não estiver vazio, ele retorna diretamente
- Se o objeto estiver vazio, realize uma consulta ao banco de dados
- Se o objeto consultado do banco de dados não estiver vazio, coloque-o no cache (defina o tempo de expiração). Imagine essa situação, o que aconteceria se o parâmetro passado fosse -1? Esse -1 é um objeto que não pode existir. O banco de dados será consultado toda vez, e cada consulta estará vazia, e não será armazenada em cache toda vez. Se houver um ataque malicioso, essa vulnerabilidade pode ser explorada para pressionar o banco de dados ou até sobrecarregá-lo. Mesmo que UUID seja usado, é fácil encontrar uma CHAVE inexistente e atacar.
No meu trabalho, uso o método de cache de valores nulos, ou seja, passo 5 no [processo de código], se o objeto consultado do banco de dados estiver vazio, ele também é colocado no cache, mas o tempo de expiração definido é curto, como defini-lo para 60 segundos.
Avalanche de cache
Avalanche de cache refere-se à expiração do conjunto de cache durante um determinado período de tempo.
Uma das razões para a avalanche, por exemplo, ao escrever este artigo, em breve será às zero horas do décimo segundo dia, e logo haverá uma onda de compras rápidas. Então, à uma hora da manhã, o estoque desse lote de mercadorias vai expirar. A consulta de acesso para esse lote de mercadorias cai no banco de dados, e para o banco de dados haverá picos de pressão periódicos.
Quando Xiaobian realiza projetos de comércio eletrônico, geralmente adota diferentes categorias de bens e armazena em cache diferentes ciclos. Bens na mesma categoria, mais um fator aleatório. Dessa forma, o tempo de expiração do cache pode ser dispersado o máximo possível, e o tempo de cache dos produtos em categorias populares é maior, e o tempo de cache dos produtos em categorias impopulares é menor, o que também pode economizar os recursos do serviço de cache.
Na verdade, a expiração centralizada não é muito fatal, e a avalanche mais fatal do cache é que um nó do servidor de cache cai ou se desconecta. Como a avalanche de cache que ocorre naturalmente precisa ser criada em um determinado período de tempo, o banco de dados pode suportar a pressão, e nesse momento, o banco de dados também pode suportar a pressão. Não passa de pressão periódica sobre o banco de dados. O tempo de inatividade do nó de serviço de cache causa pressão imprevisível sobre o servidor de banco de dados, e é provável que sobrecarregue o banco de dados em um instante.
Quebra do cache
Quebra do cache refere-se a uma chave que está muito quente, constantemente carregando grande concorrência; grande concorrência concentra-se em acessar esse ponto; quando essa chave falha, uma grande concorrência contínua rompe o cache e solicita diretamente o banco de dados, assim como se fosse perfurar um buraco em uma barreira.
Quando Xiaobian fazia projetos de e-commerce, ele transformou esse produto em um "sucesso".
Na verdade, na maioria dos casos, esse tipo de explosão é difícil de exercer uma pressão esmagadora sobre o servidor de banco de dados. Poucas empresas alcançaram esse nível. Portanto, o editor pragmático se preparou para os produtos principais antecipadamente, para que o cache nunca expire. Mesmo que alguns produtos fermentem sozinhos até virar fumadas, podem ser definidos como nunca vencendo.
A estrada principal é simples, e o cadeado de rejeição mútua da chave mutex realmente não é usado.
|
Publicado em 19/11/2019 09:55:04
|
|
|
|
