隔离级别
读未提交 (RU) 可以读取正在修改的数据
读已提交 （RC) 可以读取修改后的数据，不可读取正在修改的数据
可重复读 （RR) 多次读取 前后都一致，别的事务插入修改的数据不会读到
串化 （SR)
事务并发带来隔离问题
1 脏读：事务A读取事务B正在更新的数据，然后B回滚操作，那么事务A读取到的数据是脏的。
2 不可重复： 事务A多次读取同一批数据，事务B在事务A多次读取过程中，对数据做了更新提交操作。
导致事务A前后读取数据不一致。
3 幻读：事务A修改数据，事务B插入一条件数据，事务A再读的时候发现还有一笔数据没有修改。
隔离级别与并发问题
读未提交 (RU) 可脏读，可幻读，不可重复读
读已提交 （RC) 不可， 可幻读，不可重复读
可重复读 （RR) 不可 ， 可幻读， 可重复读
串化 （SR) 不可 不可 可
Como resolver o banco de dados autônomo?
Para resolver o problema ACID do banco de dados independente, vários fornecedores de banco de dados usam basicamente transação + bloqueio + MVCC para garantir.
Atomicidade: transação + modo de bloqueio para alcançar
Consistência: também é uma questão de resolver
Nível de isolamento: ORACLE realiza o nível de isolamento RC através de UNDO + transação + bloqueio, evitando leitura fantasma e leitura não repetível
O que é uma transação? Uma transação é um conceito que garante a consistência dos dados antes e depois da modificação. 100 linhas de dados não podem ser modificadas. 50 linhas são modificadas com êxito e as outras 50 linhas não são modificadas.
Nem pode causar inconsistências na lógica de negócios antes e depois dos dados. Por exemplo, a conta A deduziu 50 com sucesso e a conta B aumentou em 50 falhou.
Portanto, pode ser visto do acima que uma transação consiste em uma única instrução e uma multi-instrução.
Por padrão, uma única instrução inicia automaticamente a transação e várias instruções precisam ser abertas manualmente
Use o seguinte comando para compactar várias instruções juntas.
começar a trasction
comprometer-se;
Por meio do prompt de transação, o banco de dados modificará as linhas modificadas pela instrução juntas ou as modificará juntas e falhará.
E se houver sucesso parcial e falha parcial? Reverta a modificação com sucesso.
Assim, o requisito de atomicidade é atendido por meio da transação.
Transação Distribuída (ACID)
Então, em um banco de dados distribuído, nossas transações ou declarações modificadas são todas emitidas para os 4 ou mais fragmentos a seguir.
Banco de dados independente independente para cada fragmento.
Se um fragmento for emitido, não é ruim, você pode fazer uso total do mecanismo inerente do banco de dados a seguir para obter atomicidade
E se houver várias transações fragmentadas abaixo?
Por exemplo, quando uma única instrução de modificação é emitida para 4 fragmentos, o padrão é dividir uma grande transação em 4 subtransações.
Envie as 4 subtransações para o seguinte banco de dados para execução.
Então, o mesmo é verdadeiro para o caso em que parte das linhas do banco de dados independente é modificada com êxito e parte da modificação não é bem-sucedida.
Por exemplo, dois shards são modificados com êxito e os outros dois shards não são modificados.
O motivo da falha pode ser que o banco de dados fragmentado está desligado, aguardando um bloqueio, e a subtransação é eliminada ao encontrar um deadlock.
Em seguida, registre a execução de cada transação em diferentes fragmentos na camada superior e marque OK se a execução for bem-sucedida, caso contrário, será FALHA
GTID, SQL_ID, SHADING01, SHARDING02, SHAGDING03, SHADING04
00X1 S02, OK, OK FALHA, FALHA
A modificação parcial é bem-sucedida e os fragmentos OK são revertidos,
Além disso, deve-se definir um TIEM_OUT para a transação emitida.Após o timeout, a execução é considerada falha, e o comando ROLLBACK é emitido para o sucesso.
Para transações com várias instruções, adicionamos um SQL_ID, exigindo que todos os SQL nesta transação sejam executados em todos os nós de shard para estar OK, e qualquer FAILE deve ser revertido.
consistência
Não deve ser um problema no modo distribuído, porque cada consulta é emitida para o banco de dados após ser lida usando o MVCC do banco de dados.
Quando um registro de bloqueio de transação é encontrado, os dados antigos também serão lidos no MVCC UNDO.
Você também encontrará esses problemas.Por exemplo, dois shards são lidos no momento T1 e os dados dos próximos dois shards são lidos no momento T2, e os dados desses dois shards foram modificados e enviados.
Como o tempo de envio para os próximos dois shards é diferente, os dados dos quatro shards são inconsistentes antes e depois.
O design do banco de dados ZTE é criar um GTID acima, e cada tabela abaixo tem uma coluna oculta GTID, e cada consulta também obtém o GTID e, em seguida, compara-o com o GTID da linha
Se os dados forem atualizados, a leitura falha. Sem usar o mecanismo MVCC, a gravação na verdade bloqueava a leitura.
Desta forma, é necessário modificar o código-fonte do MYSQL PG, melhorar a interface, melhorar a consulta de rollback com base no valor GTID e a leitura do instantâneo MVCC.
A mesma leitura repetida e leitura fantasma são difíceis de alcançar em um ambiente distribuído, porque o seguinte mecanismo MVCC de banco de dados (MYSQL, PG, ORACLE) não pode ser usado
Portanto, é necessário modificar o núcleo MYSQL, adicionar uma interface MVCC distribuída, acima do middleware do nó de computação, e emitir transações ou declarações de consulta por meio dessa interface.
Cada transação e instrução de consulta carrega um indicador de tempo, como GTID ou SCN. O banco de dados a seguir adiciona uma coluna para cada linha de dados para armazenar GTID (SCN, TIMESTAMP).
A instrução da interface distribuída determina se o instantâneo deve ser lido de acordo com o GTID oculto. Em vez de uma interface distribuída, use o ID de transação MYSQL original ou o SCN do ORACLE.