Hoje, compartilharei uma pergunta de entrevista de alta frequência para uma empresa de primeiro nível. “Como garantir consistência de dados com base na arquitetura de Redis e MySQL”. Este problema tem confundido muitos programadores que trabalham há mais de 5 anos.A dificuldade não é o problema em si, mas a ideia de resolvê-lo.
1
introdução de fundo
Em geral, o Redis é usado como cache para operações de leitura entre aplicativos e bancos de dados. O principal objetivo é reduzir a E/S do banco de dados e melhorar o desempenho da E/S dos dados. Conforme mostrado na figura, este é o projeto arquitetônico geral do Redis mais MySQL.
Quando o aplicativo precisar ler alguns dados, ele primeiro tentará carregá-los no Redis e retornará diretamente se acertar. Se não houver ocorrência, consulte o banco de dados e, em seguida, armazene os dados em cache no Redis após consultá-los.
Nessa arquitetura, haverá um problema, ou seja, um dado é armazenado no banco de dados e no Redis ao mesmo tempo. Quando os dados mudam, o Redis e o MySQL precisam ser atualizados ao mesmo tempo. Desde as atualizações são sequenciais, os dois lados No ambiente de escrita, ele não pode satisfazer as características ACID como operações puras de banco de dados. Portanto, pode haver uma situação em que uma parte não consegue atualizar enquanto a outra parte consegue, resultando em problemas de consistência de dados.
2
Soluções
Se houver um problema de consistência de dados, como podemos resolvê-lo? Geralmente, as duas soluções a seguir vêm à mente.
Atualize o banco de dados primeiro e depois atualize o cache;
Exclua o cache primeiro e depois atualize o banco de dados.
Se o esquema de atualizar primeiro o banco de dados e depois atualizar o cache for adotado, também haverá esse problema. Se a atualização do cache falhar, os dados no banco de dados e no Redis serão inconsistentes.
Se o cache for excluído primeiro e depois o banco de dados for atualizado, a situação ideal é que quando o aplicativo acessar o Redis na próxima vez, ele descubra que os dados no Redis estão vazios e carregue-os e salve-os do banco de dados para o Redis, então o os dados são consistentes. Porém, em casos extremos, a atomicidade da exclusão do Redis e da atualização do banco de dados não pode ser garantida, portanto, se outros threads acessarem esse processo, ainda haverá inconsistências de dados.
Portanto, se você precisar garantir a consistência dos dados do Redis e do MySQL em casos extremos, poderá usar apenas o esquema de consistência final.
Conforme mostrado na figura, por exemplo, a comunicação de mensagens confiável baseada em RocketMQ é usada para alcançar consistência eventual.
Para outro exemplo, você também pode monitorar o log do Binlog no MySQL diretamente por meio do componente Canal e sincronizar os dados atualizados com o Redis.
Como isso é implementado com base na consistência eventual, se o cenário de negócios não puder aceitar inconsistências de dados de curto prazo, esta solução não poderá ser utilizada.
O que foi dito acima é meu entendimento sobre esse problema.
3
Resumir
Quando estamos entrevistando, o entrevistador também pode fazer diversas perguntas puramente técnicas sem cenários, como: “Sua solução de consistência final” ainda apresenta inconsistência de dados? Como resolver isso?
Não entre em pânico, a tecnologia atende aos negócios, portanto, diferentes cenários de negócios têm diferentes opções de tecnologia e designs de soluções. Portanto, neste momento, você pode perguntar ao entrevistador: qual é o cenário de negócios específico?
Todos devem lembrar que uma determinada solução técnica não pode ser aplicada a todos os cenários de negócios, existe apenas a solução mais adequada e não existe uma solução ideal.