Controle de simultaneidade
Quando pode haver simultaneidade no programa, precisamos usar certos meios para garantir a precisão dos dados no caso de simultaneidade.Este método garante que o usuário atual e outros usuários operem juntos e os resultados obtidos sejam separados dele. O resultado da operação é o mesmo. Este método é chamado controle de simultaneidade. O objetivo do controle de simultaneidade é garantir que o trabalho de um usuário não afete injustificadamente o trabalho de outro usuário.
A falha no controle de simultaneidade pode levar a problemas como leituras sujas, leituras fantasmas e leituras não repetíveis.
O controle de simultaneidade que costumamos dizer está geralmente relacionado ao sistema de gerenciamento de banco de dados (DBMS). A tarefa do controle de simultaneidade no DBMS é garantir que, quando várias transações acessem os mesmos dados no banco de dados ao mesmo tempo, o isolamento e a unidade das transações e a unidade do banco de dados não sejam destruídos.
Meios para alcançar o controle de concorrência
Os principais meios de obter o controle de simultaneidade podem ser basicamente divididos em controle de simultaneidade otimista e controle de simultaneidade pessimista.
Antes de iniciar a introdução, deve ficar claro: se é um bloqueio pessimista ou otimista, é um conceito definido pelas pessoas e pode ser considerado uma idéia. De fato, não apenas o sistema de banco de dados relacional tem os conceitos de bloqueio otimista e pessimista, como hibernação, tair, memcache, etc., têm conceitos semelhantes. Portanto, bloqueios otimistas, bloqueios pessimistas e outros bloqueios de banco de dados não devem ser comparados.
Bloqueio pessimista
Quando queremos modificar um dado em um banco de dados, para evitar ser modificado por outros ao mesmo tempo, a melhor maneira é bloquear diretamente os dados para impedir a simultaneidade. Esse método de usar um mecanismo de bloqueio de banco de dados para bloquear antes de modificar dados é chamado de controle de concorrência pessimista (também chamado de "controle de concorrência pessimista", abreviado como "PCC").
Enciclopédia Baidu
Fechaduras pessimistas, como o nome sugere, têm fortes características exclusivas e exclusivas. Refere-se a uma atitude conservadora em relação aos dados que estão sendo modificados pelo mundo externo (incluindo outras transações atuais do sistema e processamento de transações de sistemas externos). Portanto, em todo o processo de processamento de dados, os dados estão em um estado bloqueado. A implementação de bloqueios pessimistas geralmente depende do mecanismo de bloqueio fornecido pelo banco de dados (apenas o mecanismo de bloqueio fornecido pela camada do banco de dados pode realmente garantir a exclusividade do acesso aos dados; caso contrário, mesmo que o mecanismo de bloqueio seja implementado neste sistema, não há garantia de que o sistema externo não será modificado Dados).
O motivo pelo qual é chamado de bloqueio pessimista é porque é um método de controle de concorrência que possui uma atitude pessimista em relação à modificação de dados. Geralmente, pensamos que a probabilidade de os dados serem modificados simultaneamente é relativamente alta, portanto, precisamos bloquear antes de modificar.
Bloqueios pessimistas são principalmente bloqueios compartilhados ou exclusivos
- O bloqueio compartilhado também é chamado de bloqueio de leitura ou bloqueio S, para abreviar. Como o nome indica, bloqueios compartilhados significam que várias transações podem compartilhar um bloqueio para os mesmos dados e podem acessar os dados, mas só podem lê-lo e não podem modificá-lo.
- Bloqueios exclusivos também são chamados de bloqueios de gravação ou bloqueios X, para abreviar. Como o nome indica, os bloqueios exclusivos não podem coexistir com outros bloqueios.Se uma transação adquirir um bloqueio exclusivo para uma linha de dados, outras transações não poderão mais adquirir outros bloqueios para essa linha, incluindo bloqueios compartilhados e bloqueios exclusivos, mas as transações que adquirirem bloqueios exclusivos serão possíveis. Leia e modifique as linhas de dados.
O controle de concorrência pessimista é na verdade uma estratégia conservadora de "buscar bloqueio antes do acesso", o que fornece uma garantia para a segurança do processamento de dados.
Mas em termos de eficiência, o mecanismo de manipulação do bloqueio causará sobrecarga adicional no banco de dados e aumentará a chance de conflito. Além disso, reduzirá o paralelismo.Se uma transação bloquear uma linha de dados, outras transações deverão aguardar a conclusão da transação antes de processar essa linha de dados.
Bloqueio otimista (bloqueio otimista)
O bloqueio otimista é relativo ao bloqueio pessimista.O bloqueio otimista pressupõe que os dados não causem conflitos em circunstâncias normais; portanto, quando os dados são enviados para atualização, ele verifica formalmente se os dados conflitam ou não. Se um conflito for encontrado, retorne Forneça ao usuário as informações incorretas e permita que ele decida como fazê-lo.
Enciclopédia Baidu
O mecanismo de bloqueio otimista adotou um mecanismo de bloqueio mais relaxado. Bloqueios otimistas são bloqueios relativamente pessimistas e também são um mecanismo para evitar erros de processamento de dados causados por leituras fantasmas do banco de dados e tempo excessivo de processamento de negócios. Para garantir a precisão dos dados.
Comparado com o bloqueio pessimista, o bloqueio otimista não usa o mecanismo de bloqueio fornecido pelo banco de dados ao processar o banco de dados. A maneira geral de obter um bloqueio otimista é registrar a versão dos dados.
O controle de concorrência otimista acredita que a probabilidade de corridas de dados entre transações é relativamente pequena; portanto, deve ser feita diretamente o máximo possível e não será bloqueada até que seja confirmada, para que não ocorram bloqueios ou impasses.
Perceber maneira
Implementação de bloqueio pessimista
A realização do bloqueio pessimista geralmente depende do mecanismo de bloqueio fornecido pelo banco de dados. No banco de dados, o processo de bloqueio pessimista é o seguinte:
- Antes de modificar o registro, tente adicionar um bloqueio exclusivo ao registro.
- Se o bloqueio falhar, o registro está sendo modificado, portanto, a consulta atual pode ter que esperar ou lançar uma exceção. O método de resposta específico é determinado pelo desenvolvedor de acordo com as necessidades reais.
- Se o bloqueio for adicionado com êxito, o registro poderá ser modificado e a transação será desbloqueada após a conclusão da transação.
- Enquanto isso, se houver outras operações que modifiquem o registro ou adicionem um bloqueio exclusivo, aguardaremos o desbloqueio ou a exceção direta.
Tome o mecanismo MySql Innodb comumente usado como exemplo para ilustrar como usar o bloqueio pessimista no SQL.
Para usar o bloqueio pessimista, devemos desativar a propriedade commit automático do banco de dados MySQL. Como o MySQL usa o modo de confirmação automática por padrão, ou seja, quando realizamos uma operação de atualização, o MySQL envia os resultados imediatamente. (Instrução SQL: definir autocommit = 0)
Para ilustrar o uso de bloqueios pessimistas com a necessidade de deduzir o estoque durante a colocação do pedido do Taobao:
Como acima, antes de modificar o registro com id = 1, primeiro bloqueie-o por meio de atualização e modifique-o. Essa é a estratégia de bloqueio pessimista mais típica.
Se o código acima para modificar o inventário ocorrer simultaneamente, apenas um encadeamento poderá abrir a transação e obter o bloqueio com id = 1. Ao mesmo tempo, outras transações deverão aguardar o envio da transação para execução. Dessa forma, podemos garantir que os dados atuais não sejam modificados por outras transações.
Como mencionamos acima, o uso de select ... para atualização bloqueará os dados, mas precisamos prestar atenção a alguns níveis de bloqueio, o bloqueio no nível de linha padrão do MySQL InnoDB. Os bloqueios no nível da linha são baseados em índices.Se uma instrução SQL não puder usar um índice, os bloqueios no nível da linha não serão usados.Os bloqueios no nível da tabela serão usados para bloquear a tabela inteira.Esta necessidade de atenção.
Implementação de bloqueio otimista
O uso de bloqueio otimista não requer o uso de mecanismos de bloqueio de banco de dados.
O conceito de bloqueio otimista realmente elaborou seus detalhes de implementação específicos. Há duas etapas principais: detecção de conflitos e atualização de dados. Existe uma maneira mais típica de sua implementação é o CAS (Compare and Swap).
O CAS é uma tecnologia de bloqueio otimista. Quando vários threads tentam usar o CAS para atualizar a mesma variável ao mesmo tempo, apenas um deles pode atualizar o valor da variável, enquanto os outros threads falham. O thread com falha não é suspenso, mas é Informe o fracasso desta competição e tente novamente.
Por exemplo, o problema anterior de dedução de estoque pode ser alcançado através do bloqueio otimista da seguinte maneira:
Acima, antes de atualizarmos, primeiro verificamos a quantidade (quantidade) atual de estoque na tabela de inventário e, em seguida, ao atualizar, usamos a quantidade de estoque como condição de modificação. Quando enviamos uma atualização, julgamos que o número de inventário atual do registro correspondente na tabela do banco de dados é comparado com o número de inventário retirado pela primeira vez. Se o número de inventário atual da tabela do banco de dados for igual ao número de inventário retirado pela primeira vez, ele será atualizado. Caso contrário, são considerados dados desatualizados.
A declaração de atualização acima tem um problema mais importante, a saber, o lendário problema ABA .
Por exemplo, se um segmento um obtém o número de inventário 3 do banco de dados, outro segmento dois também obtém o número 3 do inventário e dois executam algumas operações para se tornarem 2 e depois dois transformam o número do inventário em 3 novamente. Quando o encadeamento um executa a operação CAS, verifica-se que o banco de dados ainda é 3 e a operação é bem-sucedida. Embora a operação CAS do encadeamento um seja bem-sucedida, isso não significa que esse processo não seja um problema.
Existe uma maneira melhor de resolver o problema ABA, ou seja, através de um campo de versão única que pode ser incrementado sequencialmente. Mude para o seguinte método:
Sempre que o bloqueio otimista executar uma operação de modificação de dados, ele trará um número de versão.Depois que o número da versão e o número da versão dos dados forem consistentes, você poderá executar a operação de modificação e realizar uma operação +1 no número da versão, caso contrário, a execução falhará. Como o número da versão de cada operação aumentará de acordo, não haverá problema ABA, porque o número da versão aumentará apenas e não diminuirá.
Além da versão, você também pode usar registros de data e hora, porque os registros de data e hora estão aumentando naturalmente em ordem.
De fato, o SQL acima ainda apresenta alguns problemas: quando uma alta concorrência é encontrada, apenas um thread pode ser modificado com êxito e, em seguida, haverá um grande número de falhas.
Para sites de comércio eletrônico como o Taobao, alta simultaneidade é uma ocorrência comum e obviamente não é razoável permitir sempre que os usuários percebam falhas. Portanto, ainda precisamos encontrar maneiras de reduzir a granularidade do bloqueio otimista.
Há uma sugestão melhor, que pode reduzir a força de bloqueio otimista, maximizar a taxa de transferência e melhorar a simultaneidade! Como segue:
Na instrução SQL acima, se o número de pedidos feitos pelo usuário for 1, o controle de bloqueio otimista será executado por meio da quantidade-1> 0.
Durante a execução da instrução de atualização acima, ele consultará o valor da quantidade em uma operação atômica e o deduzirá por 1.
O controle da granularidade do bloqueio é um assunto importante em um ambiente de alta simultaneidade.A escolha de um bom bloqueio pode aumentar bastante a taxa de transferência e o desempenho, garantindo a segurança dos dados.
Como escolher
Na escolha de bloqueio otimista e pessimista, observe principalmente a diferença entre os dois e os cenários aplicáveis.
-
O bloqueio otimista realmente não é bloqueado e é altamente eficiente. Uma vez que a granularidade do bloqueio não é bem compreendida, a probabilidade de falha na atualização será relativamente alta e é provável que ocorra uma falha nos negócios.
-
Bloqueios pessimistas dependem de bloqueios de banco de dados e são ineficientes. A probabilidade de falha na atualização é relativamente baixa.
Com a proposição das três arquiteturas altas da Internet (alta simultaneidade, alto desempenho e alta disponibilidade), bloqueios pessimistas foram usados cada vez menos em ambientes de produção, especialmente em cenários de negócios com uma quantidade relativamente grande de simultaneidade.
