Avalanche de cache
Suponha que um sistema tenha 7.000 solicitações por segundo durante o período de pico. Nesse momento, usamos o cache para resistir a essas altas solicitações. No entanto, se um grande número de caches falhar em um determinado momento, ou o servidor de cache ficar inativo, essas solicitações agirão diretamente em bancos de dados comuns (como o MySQL). Com um volume tão alto de solicitações, o MySQL definitivamente não será capaz de suportá-lo e, em seguida, travará. Se o banco de dados travar, também fará com que o sistema trave.
Resumimos as condições para o gatilho da avalanche de cache:
“”
Alta simultaneidade
O servidor de cache está fora do ar
Invalidação centralizada de um grande número de caches
A consequência é: o sistema trava.
A solução é aumentar o limite atual de acesso de enfileiramento ao banco de dados. Supondo que nosso banco de dados possa suportar no máximo 2.000 solicitações por segundo, quando solicitamos o banco de dados, as solicitações por segundo precisam ser controladas em 2.000, e o restante das solicitações precisa para ser colocado na fila. Ao mesmo tempo, precisamos usar um cluster para garantir a alta disponibilidade do servidor de cache. Além disso, também precisamos definir aleatoriamente o tempo de expiração da chave de cache para evitar que a chave expire ao mesmo tempo.
Resolução de avalanche
Com relação às operações de limitação de corrente, você pode usar os plug-ins de limitação de corrente relacionados ao Spring Cloud. Aqui, usamos semáforos de semáforo para simular operações de limitação de corrente mais baixa.
Aqui, limitamos que pode haver até 5 solicitações de visita ao mesmo tempo. Quando temos 9 solicitações chegando, apenas 5 solicitações recebem tokens de acesso e as 4 solicitações restantes ficam esperando do lado de fora. Ao final do acesso anterior, os tokens serão liberados, e as próximas 4 solicitações irão antecipar esses tokens, que serão executados repetidamente.
Aqui, executamos uma operação de limitação atual.
Penetração de cache
Supondo que haja uma chave que nunca existirá no cache, quando um hacker usa essa chave para atacar o sistema, como 7.000 ataques por segundo, o cache não será usado de qualquer maneira. A solicitação de ataque é atingida diretamente no banco de dados , e o banco de dados deve ser Não é possível retê-lo. Fez com que o banco de dados travasse, ao mesmo tempo, o sistema também travaria.
penetrar
Nossa solução é determinar se os dados de destino existem antes de consultar e ignorar aqueles que não existem. Intercepte o tráfego antes do cache e do banco de dados.
Solução penetrante
Conforme mostrado na figura acima, adicione um filtro. Antes de iniciar o sistema, precisamos carregar os dados do ponto de acesso no cache. Ao acessar os dados do ponto de acesso, eles serão julgados uma vez pelo filtro. Se a solicitação não existir no cache, ele retornará diretamente., Não passará pelo banco de dados.
Filtros Podemos usar filtros Bloom, o código de amostra de filtros Bloom é o seguinte:
O filtro Bloom espalha principalmente o valor calculado pela chave por meio do algoritmo de hash no bitmap, que existe como 0 e 1 no bitmap.
bitmap
No entanto, o algoritmo acima tem falhas:
“Os filtros Bloom não podem filtrar com precisão. (O filtro Bloom julga que ele não existe, 100% não existe e, se for considerado que existe, pode não existir.) Em teoria, o valor de cálculo de hash é colidido (hashes de conteúdo diferentes calculam o mesmo valor), resultando em elementos de inexistência podem ser considerados como existindo
”
Obviamente, o filtro Bloom não precisa interceptar todas as solicitações, ele só precisa controlar a quebra do cache até uma determinada quantidade.
Em relação à penetração do cache, também podemos usar as seguintes soluções:
“Os dados que não podem ser recuperados no cache não são recuperados no banco de dados. Nesse momento, o par de valor-chave também pode ser escrito como nulo de chave e o tempo efetivo do cache pode ser definido como um tempo curto, como 30 segundos. Não pode ser usado). Isso pode impedir que o usuário atacante use repetidamente o mesmo ataque de força bruta id.
”
Porém, o esquema acima tem uma falha: o hacker pode acessar simultaneamente várias chaves inexistentes por um curto período de tempo, e também acessar o banco de dados, portanto, na prática, ele precisa ser otimizado e modificado de acordo com a cena.
A avalanche e a penetração de cache são geralmente encontradas em situações de alta simultaneidade. Também são o conteúdo de entrevistas de alta frequência com empresas da Internet. Com o domínio desse conhecimento, acredito que você tenha entrado em um novo mundo.
Recomendado no passado
Leia o código QR para ficar mais emocionante. Ou pesquise Lvshen_9 no WeChat , você pode responder para obter informações em segundo plano
回复"java" 获取java电子书；
回复"python"获取python电子书；
回复"算法"获取算法电子书；
回复"大数据"获取大数据电子书；
回复"spring"获取SpringBoot的学习视频。
回复"面试"获取一线大厂面试资料
回复"进阶之路"获取Java进阶之路的思维导图
回复"手册"获取阿里巴巴Java开发手册(嵩山终极版)
回复"总结"获取Java后端面试经验总结PDF版
回复"Redis"获取Redis命令手册，和Redis专项面试习题（PDF）
回复"并发导图"获取Java并发编程思维导图（xmind终极版）Outro: Clique em [ Meus benefícios ] para ter mais surpresas.