Início / dba / Perguntas / 311242
Accepted
Iliana Kollia
Asked: 2022-04-23 09:22:01 +0800 CST

ATUALIZAÇÕES simultâneas do MySQL

  • 772

Digamos que temos a seguinte situação em um aplicativo usando MySQL onde um usuário pode comprar um item e cada item tem um único comprador, mas o preço do item pode mudar.

Pseudo-código :

BEGIN TRANSACTION

seenPrice = SELECT price FROM Item
    WHERE id = ABC AND buyer IS NULL

UPDATE Item SET buyer = X
    WHERE id = ABC AND buyer IS NULL AND price = seenPrice

COMMIT

A seenPricevariável e as buyer IS NULL AND price = seenPriceverificações na instrução UPDATE servem como um meio de bloqueio otimista para garantir que nenhum problema de simultaneidade apareça .

Em um ambiente multi-threaded onde um thread A e um thread B passam pela SELECTinstrução ao mesmo tempo e dizem que o thread A executa a UPDATEinstrução primeiro, a simultaneidade não é uma preocupação , mas é possível que A e B executem a UPDATEinstrução no mesmo tempo exato? Para contextualizar o aplicativo está sendo desenvolvido usando Spring Boot e Spring Data JPA.

mysql concurrency

3 respostas

  1. Best Answer

    é possível que A e B executem a UPDATEinstrução ao mesmo tempo exato?

    As instruções podem começar a ser executadas ao mesmo tempo, mas não podem atualizar a mesma linha simultaneamente. Uma instrução de atualização deve adquirir um bloqueio exclusivo na linha antes que possa ser modificada, e a aquisição de bloqueio é uma operação atômica estritamente serializada, o que significa que uma das sessões simultâneas sempre adquirirá o bloqueio primeiro e as outras sessões serão bloqueadas .

    A aquisição de bloqueio é sempre atômica, independentemente do DBMS ou mecanismo de armazenamento - se não fosse, seria completamente inútil como mecanismo de controle de simultaneidade.

    O mecanismo de bloqueio não se importa se seu aplicativo é escrito usando uma abordagem de bloqueio otimista ou pessimista - o que muda é o momento em que o bloqueio é feito. Com o bloqueio pessimista, você espera que haja muita atividade simultânea e deseja garantir que sua transação seja bem-sucedida (ao custo de impedir atualizações simultâneas):

    Inscrição Base de dados
    SELECT ... FOR UPDATE Adquirir bloqueio
    Faça outra coisa
    ...
    UPDATE ...
    COMMIT Liberar bloqueio

    Com o bloqueio otimista, você não espera muita atividade simultânea, portanto, a probabilidade de seu aplicativo não concluir a atualização é baixa e você não mantém o bloqueio por muito tempo:

    Inscrição Base de dados
    SELECT ...
    Faça outra coisa
    ...
    UPDATE ... Adquirir bloqueio
    COMMIT Liberar bloqueio
    • 2

  2. Não, não é possível que A e B executem o UPDATE exatamente ao mesmo tempo. Um ou outro adquirirá o bloqueio na linha primeiro e, em seguida, o outro será bloqueado até que o vencedor se comprometa.

    Uma vez que o vencedor se compromete, a condição buyer IS NULLnão será mais verdadeira, então o UPDATE da thread que esperou não a afetará.

    Podemos fazer um experimento para testar isso:

    Na janela 1:

    mysql> begin;

mysql> select * from item where id=1 and buyer is null;
+-------+----+-------+
| price | id | buyer |
+-------+----+-------+
| 19.95 |  1 |  NULL |
+-------+----+-------+

    Na janela 2, faça o mesmo, inicie uma transação e visualize o preço.

    Na janela 1:

    mysql> update item set buyer=42 where id=1 and buyer is null and price=19.95;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

    Na janela 2:

    mysql> update item set buyer=84 where id=1 and buyer is null and price=19.95;
(hangs, waiting)

    Na janela 1:

    mysql> commit;

    Na janela 2:

    (finishes waiting)
Query OK, 0 rows affected (4.53 sec)
Rows matched: 0  Changed: 0  Warnings: 0

    Observe zero linhas correspondidas ou alteradas! Porque o comprador não era mais nulo na versão confirmada mais recente da linha.

    • 0

  3. Como você está testando buyer IS NULLem ambas as instruções, o processamento "funcionará". No entanto, uma conexão diferente pode se infiltrar entre o SELECTand UPDATEe set buyer.

    Então, você deve verificar para ver se o UPDATErealmente foi bem-sucedido. Se não, então o que? Diga ao usuário "Desculpe, você passou por toda a interface do usuário apenas para que outra pessoa entrasse e comprasse o que você queria". Eca.

    Em vez disso, faça FOR UPDATEno SELECT. Dessa forma, você pode detectar o problema mais cedo.

    E não escreva código que fique preso a uma transação por mais de alguns segundos. Isso pode levar a todos os tipos de colapsos desagradáveis ​​em seu aplicativo.

    • 0

relate perguntas