Especificação XA
XA é a especificação de interface (ou seja, função de interface) entre o middleware de transações e o banco de dados definido pelo X/Open DTP, que é usada pelo middleware de transações para notificar o banco de dados sobre o início, fim, commit, rollback, etc. das transações. As funções da interface XA são fornecidas por fornecedores de banco de dados.
O acordo de submissão de segunda ordem e o acordo de submissão de terceira ordem derivaram dessa ideia. Pode-se dizer que commits em duas etapas são, na verdade, a chave para implementar transações distribuídas XA (para ser preciso: commits em duas etapas garantem principalmente a atomicidade das transações distribuídas: ou seja, todos os nós fazem tudo ou nada)
2PC
Commit em duas fases refere-se a um algoritmo projetado para manter consistência nos commits de transação para todos os nós com base na arquitetura de sistema distribuído no campo de redes de computadores e bancos de dados. Frequentemente, um commit em duas etapas também é chamado de protocolo. Em um sistema distribuído, cada nó pode saber o sucesso ou fracasso de sua própria operação, mas não pode saber o sucesso ou fracasso das operações de outros nós. Quando uma transação abrange múltiplos nós, para manter as características ACID da transação, é necessário introduzir um componente que atue como coordenador para controlar os resultados de todos os nós (chamados participantes) e, por fim, instruir esses nós a realmente enviar os resultados (como gravar dados atualizados no disco, etc.). Portanto, a ideia do algoritmo para a submissão em duas etapas pode ser resumida da seguinte forma: os participantes notificarão o coordenador sobre o sucesso ou fracasso da operação, e então o coordenador decidirá se submetem a operação ou a abortam com base nas informações de feedback de todos os participantes.
As chamadas duas etapas são: a primeira: a fase de preparação (fase de votação) e a segunda etapa: a fase de submissão (etapa de execução).
Estágio de preparação
O coordenador de transações (gerenciador de transações) envia uma mensagem Prepare para cada participante (gerenciador de recursos), e cada participante retorna uma falha diretamente (como uma falha na verificação de permissão), ou executa a transação localmente, escreve logs de refazer e desfazer localmente, mas não faz commit e chega ao estado de "tudo está pronto, apenas o vento leste é devido".
A fase de preparação pode ser ainda dividida nas seguintes três etapas:
1) O nó coordenador pergunta a todos os nós participantes se podem realizar uma votação e começa a esperar uma resposta de cada nó participante.
2) O nó participante realiza todas as operações de transação até que a consulta seja iniciada e escreve as informações de Desfazer e Refazer no log. (Nota: Se for bem-sucedido, cada participante já realizou a operação de transação)
3) Cada nó participante responde à consulta iniciada pelo nó coordenador. Se a operação de transação do nó participante for realmente executada com sucesso, retorna uma mensagem de "Concordar"; Se a operação de transação do nó participante realmente falhar, retorna uma mensagem de "abortado".
Etapa de submissão
Se o coordenador receber uma mensagem de falha ou tempo de espera de um participante, ele enviará uma mensagem de rollback diretamente para cada participante. Caso contrário, envie uma mensagem de Commit; Os participantes realizam operações de commit ou rollback de acordo com as instruções do coordenador para liberar todos os recursos de lock usados no processo de transação. (Nota: Os recursos de bloqueio devem ser liberados na fase final)
Em seguida, o processo da fase de submissão é discutido separadamente em dois casos.
Quando a mensagem correspondente recebida pelo nó coordenador de todos os nós participantes é Concordar:
Etapa de submissão
Se o coordenador receber uma mensagem de falha ou tempo de espera de um participante, ele enviará uma mensagem de rollback diretamente para cada participante. Caso contrário, envie uma mensagem de Commit; Os participantes realizam operações de commit ou rollback de acordo com as instruções do coordenador para liberar todos os recursos de lock usados no processo de transação. (Nota: Os recursos de bloqueio devem ser liberados na fase final)
Em seguida, o processo da fase de submissão é discutido separadamente em dois casos.
Quando a mensagem correspondente recebida pelo nó coordenador de todos os nós participantes é Concordar:
1) O nó coordenador emite uma solicitação de "commit" para todos os nós participantes.
2) O nó participante completa oficialmente a operação e libera os recursos ocupados durante todo o período da transação.
3) O nó participante envia uma mensagem "Feito" para o nó coordenador.
4) O nó coordenador conclui a transação após receber o feedback da mensagem "Feito" de todos os nós participantes.
1) O nó coordenador emite uma solicitação de "rollback" para todos os nós participantes.
2) O nó participante usa as informações de Desfazer previamente escritas para realizar um rollback e liberar recursos ocupados durante todo o período da transação.
3) O nó participante envia uma mensagem de "rollback completado" para o nó coordenador.
4) O nó coordenador cancela a transação após receber o feedback da mensagem "Rollback Complete" de todos os nós participantes.
Os commits da fase 2 parecem fornecer operações atômicas, mas infelizmente, os commits da fase 2 ainda têm algumas desdesvanções:
1. Problema de bloqueio síncrono. Durante a execução, todos os nós participantes estão bloqueando transações. Quando um participante ocupa um recurso público, outros nós de terceiros precisam ser bloqueados para acessar o recurso público.
2. Ponto único de falha. Devido à importância do coordenador, quando o coordenador falha. Os participantes continuarão bloqueando o bloqueio. Especialmente na segunda etapa, se o coordenador falhar, todos os participantes ainda estão em estado de travamento dos recursos transacionais e não podem continuar a concluir as operações de transação. (Se o coordenador desligar, você pode reeleger um coordenador, mas isso não resolve o problema de que o participante está bloqueado por causa do coordenador caído)
3. Inconsistência de dados. Na segunda etapa da segunda etapa do commit, quando o coordenador envia uma solicitação de commit ao participante, ocorre uma exceção de rede local ou o coordenador falha durante o processo de requisição de commit, o que faz com que apenas alguns participantes aceitem a solicitação de commit. Após receber o pedido de commit, esses participantes realizarão a operação de commit. No entanto, outras máquinas que não recebem uma requisição de commit não podem executar o commit da transação. Como resultado, a consistência do departamento de dados ocorre em todo o sistema distribuído.
4. Problemas que não podem ser resolvidos na segunda etapa: O coordenador cai após enviar uma mensagem de commit, e o único participante que recebe essa mensagem também está fora do ar. Portanto, mesmo que o facilitador eleija um novo facilitador por meio do acordo eleitoral, o status da transação é incerto, e ninguém sabe se a transação foi submetida.
3PC
O commit em três fases, também conhecido como protocolo de commit em três fases, é uma versão aprimorada do commit em duas fases (2PC).
Diferente dos commits de dois estágios, há duas mudanças para commits de três estágios.
1. Introduzir um mecanismo de timeout. Ao mesmo tempo, um mecanismo de tempo é introduzido tanto no facilitador quanto nos participantes.
2. Insira uma etapa preparatória na primeira e segunda etapas. Isso garante que o estado de todos os nós participantes seja consistente até a etapa final de commit.
Em outras palavras, além de introduzir um mecanismo de timeout, o 3PC novamente divide a etapa de preparação do 2PC em duas, de modo que existem três estágios de CanCommit, PreCommit e DoCommit nas três etapas do commit.
Estágio CanCommit
A fase CanCommit do 3PC é na verdade muito semelhante à fase de preparação do 2PC. O coordenador envia um pedido de commit ao participante, que responde Sim se puder comprometer, ou Sem resposta.
1. Consulta de Transação O facilitador envia uma solicitação CanCommit ao participante. Pergunte se você pode realizar uma operação de commit de transação. Depois, comece a esperar uma resposta dos participantes.
2. Feedback de Resposta Após receber a solicitação CanCommit, o participante retornará uma resposta Sim e entrará no estado pronto se acreditar que a transação pode ser executada sem problemas. Caso contrário, feedback Não
Fase de Pré-Commit
O facilitador decide se decora ou não a operação de Pré-Commit da transação com base na resposta do participante. Dependendo da resposta, há duas possibilidades.
Se o feedback que o facilitador recebe de todos os participantes for uma resposta Sim, então a pré-execução da transação é realizada.
1. Enviar um Pedido de Pré-Compromisso O facilitador envia um pedido de Pré-Compromisso ao participante e avança para a etapa de Preparação.
2. Pré-Commit de Transação Após o participante receber a solicitação de PreCommit, ele realiza a operação de transação e registra as informações de desfazer e refazer no registro de transações.
3. Feedback de Resposta Se o participante executar com sucesso a operação de transação, uma resposta ACK é retornada enquanto se começa a esperar pela instrução final.
1. Enviar um pedido de interrupção O facilitador envia um pedido de aborto para todos os participantes.
2. Interromper a transação Após o participante receber a solicitação de ABORT do coordenador (ou após o timeout, a solicitação do coordenador não ter sido recebida), a interrupção da transação é executada.
Essa etapa do commit real de transação também pode ser dividida nas seguintes duas situações.
Execute um commit
1. Enviar uma solicitação de commit O Coordinating recebe a resposta ACK enviada pelo participante, então ele irá do estado pré-commit para o estado de commit. e enviar um pedido de doCommit para todos os participantes.
2. Submissão de Transação Após receber a solicitação doCommit, o participante executa o commit formal da transação. e libere todos os recursos da transação após concluir o commit da transação.
3. Responda ao feedback Após a transação ser submetida, envie uma resposta Ack ao coordenador.
4. Concluir a transação Após o coordenador receber a resposta ACK de todos os participantes, a transação é concluída.
Se o coordenador não receber uma resposta ACK do participante (pode não ser uma resposta ACK do receptor, ou a resposta pode ter expirado), então a transação de interrupção é executada.
1. Enviar um pedido de interrupção O facilitador envia um pedido de aborto para todos os participantes
2. Rollback de Transação Após receber a solicitação de ABORT, o participante usa as informações de desfazer registradas na Fase 2 para realizar a operação de rollback da transação e libera todos os recursos da transação após concluir o rollback.
3. Resultados do feedback Após o participante concluir o rollback da transação, envie uma mensagem ACK ao coordenador
4. Interromper a transação Após o coordenador receber a mensagem ACK do participante, a transação é interrompida.
A diferença entre 2PC e 3PC
Em relação ao 2PC, o 3PC resolve principalmente o problema do ponto único de falha e reduz o bloqueio, porque, uma vez que o participante não recebe uma mensagem do coordenador a tempo, ele executa o commit por padrão. Em vez de manter recursos de transação o tempo todo e ficar em um estado de bloqueio. Mas esse mecanismo também causa problemas de consistência de dados, porque a resposta de aborto enviada pelo coordenador não é recebida pelo participante em tempo devido a razões de rede, e então o participante executa a operação de commit após aguardar o timeout. Isso cria inconsistências de dados com outros participantes que recebem o comando abortar e realizam um rollback.
|
Publicado em 17/03/2021 10:15:10
|
|
|
