Use redis como processo de banco de dados de cache mysql:
Leia os dados em cache primeiro. Se houver dados em cache, o resultado será retornado imediatamente; se não houver dados, os dados serão lidos no banco de dados e os dados lidos serão sincronizados com o cache para fornecer os dados de retorno para a próxima solicitação de leitura.
Embora isso possa reduzir a pressão no banco de dados, mas se os dados forem modificados e excluídos, poderá causar inconsistências entre o cache e os dados do banco de dados em um cenário de alta simultaneidade multithread.
Cena 1:
A principal causa do problema é que, quando os pedidos de leitura e gravação de dados são simultâneos, os dados do banco de dados e do cache foram atualizados, mas os dados acessados ainda são antigos e os dados de leitura sujos são exibidos.Nós assumimos que não há problema no processo de solicitação de leitura, analise o processo de solicitação de gravação Otimização
- Atualize o cache primeiro e depois o banco de dados
Este plano definitivamente não funcionará. O motivo é que o cache de atualização é bem-sucedido e o banco de dados de atualização é anormal, o que faz com que os dados do cache sejam completamente inconsistentes com os dados do banco de dados.
- Atualize o banco de dados primeiro e, em seguida, atualize o cache
Essa solução também não funciona, o princípio é o mesmo que o primeiro, a atualização do banco de dados é bem-sucedida, a atualização do cache falha e o problema de inconsistência dos dados também ocorrerá.
Resolver
Quando encontramos uma solicitação de gravação, podemos primeiro excluir os dados em cache e, em seguida, atualizar o banco de dados, para que, independentemente da atualização do banco de dados falhe ou da exclusão do cache, o cache seja sempre consistente com o banco de dados. Esse tipo de esquema geralmente pode atender às operações simultâneas de dezenas de milhares de pessoas, porque o tempo entre a exclusão do cache e a atualização do banco de dados pode ser calculado em milissegundos e a simultaneidade normal tem pouco efeito.
Cena dois:
Centenas de milhões de acessos simultâneos resultam em inconsistência entre cache e dados.
Resolver
Solução 1: Separação de leitura e escrita
As solicitações de leitura acessam apenas o cache, as solicitações de gravação modificam apenas o banco de dados e o cache
A solicitação de gravação para modificar o banco de dados e o cache é uma ação transacional.Se a atualização do banco de dados for bem-sucedida e a atualização do cache falhar, o banco de dados será revertido para garantir que os dados do cache e do banco de dados sejam fortemente consistentes. Dessa forma, a separação de leitura e gravação é realizada, o que não apenas melhora a velocidade de resposta da leitura, mas a solicitação de gravação é responsável pela consistência do cache e do banco de dados.
Solução 2: solicitação de armazenamento em fila
A solução do cenário 1 é seguida. Para solucionar seus defeitos, uma fila é adicionada. Quando uma solicitação de gravação é encontrada, a solicitação de gravação é colocada na fila. A fila gerencia a solicitação de gravação de maneira unificada. Se a solicitação de gravação for processada com êxito, ela será excluída da fila. Quando uma solicitação de leitura chegar, verifique a fila para verificar se há uma solicitação de gravação correspondente.Se houver, coloque-a na fila e aguarde a execução da solicitação de gravação antes de executar a solicitação de leitura. Para impedir que uma solicitação seja bloqueada, configure um mecanismo de tempo limite ou um mecanismo de expiração para ela.
Cena três:
A quantidade de acesso é grande, o processador está atrasado para processar e o número de solicitações na fila está ficando cada vez mais alto, o que afetará a eficiência da consulta.
Resolver:
Cluster de banco de dados distribuído, além de fila de mensagens (kafka, etc.)
Link original: https://www.cnblogs.com/vinic-xxm/p/11911691.html