Duas soluções de transação distribuída

## 1. 2PC
2PC é um protocolo de confirmação de duas fases, que divide todo o processo de transação em duas fases: fase de preparação e fase de confirmação, 2 refere-se a duas fases, P refere-se à fase de preparação, C Refere-se à fase de envio.

Alguns bancos de dados relacionais, como Oracle e MySQL no computador, oferecem suporte ao contrato de envio em duas fases, conforme mostrado abaixo:

1. Fase de preparação: o gerenciador de transações envia uma mensagem de preparação para cada participante, cada participante do banco de dados executa a transação localmente e grava um log de Desfazer / Refazer local. No momento, a transação não é confirmada. (O log de Desfazer registra os dados antes da modificação, que é usado para reversão do banco de dados, e o Redo registra os dados modificados, que são usados ​​para gravar arquivos de dados após a confirmação de transações)

2. Fase de confirmação: se o gerenciador de transações recebe uma mensagem de falha de execução ou tempo limite do participante, ele envia diretamente uma mensagem de reversão para cada participante; caso contrário, envia uma mensagem de confirmação; o participante é baseado na transação As instruções do gerente executam uma operação de confirmação ou reversão
   e liberam os recursos de bloqueio usados ​​durante o processamento da transação. Nota: Os recursos de bloqueio devem ser liberados no estágio final.

A figura a seguir mostra as duas fases do 2PC, com dois casos de sucesso e fracasso:

Sucesso:

Falha:

## 2. Mecanismo de compensação do
TCC O TCC é, na verdade, o mecanismo de compensação usado.A idéia principal é que, para cada operação, uma operação de confirmação e compensação (cancelamento) correspondente seja registrada. É dividido em três etapas:

• Tente estágio é principalmente para fazer a detecção do sistema de negócios e reserva de recursos
• A fase de Confirmação é principalmente para confirmar e enviar o sistema de negócios.Quando a fase de Tentativa é executada com êxito e a fase de Confirmação é iniciada, a fase de Confirmação padrão fica livre de erros. Ou seja: Enquanto Try for bem-sucedido, Confirme deve ser bem-sucedido.
• A fase Cancelar é principalmente para cancelar os negócios executados no estado de erro de execução dos negócios e precisa reverter e liberar os recursos reservados.

Por exemplo: A deseja transferir dinheiro para B, a ideia é provavelmente:

我们有一个本地方法，里面依次调用 
1、首先在 Try 阶段，要先调用远程接口把 B和 A的钱给冻结起来。 
2、在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。 
3、如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。 

Vantagens: Comparada com o envio em duas fases, a usabilidade é mais forte

Desvantagens: A consistência dos dados é pior. O TCC pertence a um método de compensação na camada de aplicativo, portanto, os programadores precisam escrever muito código de compensação durante a implementação.Em alguns cenários, alguns processos de negócios podem não ser bem definidos e manipulados pelo TCC.

## 3. Consistência final da mensagem A consistência final da
mensagem deve ser a mais usada no setor, e sua idéia principal é dividir as transações distribuídas em transações locais para processamento.Esta idéia vem do ebay. Podemos ver alguns desses detalhes no seguinte fluxograma:

A ideia básica é:

O produtor da mensagem precisa criar uma tabela de mensagens adicional e registrar o status de envio da mensagem. As tabelas de mensagens e os dados comerciais devem ser enviados em uma transação, o que significa que eles devem estar em um banco de dados. Em seguida, a mensagem será enviada ao consumidor da mensagem via MQ. Se a mensagem não for enviada, ela será tentada novamente.

O consumidor da mensagem precisa processar essa mensagem e concluir sua própria lógica de negócios. No momento, se o processamento da transação local for bem-sucedido, isso indica que o processamento foi bem-sucedido.Se o processamento falhar, ele tentará novamente a execução. Se for um fracasso comercial, você poderá enviar uma mensagem de compensação comercial ao produtor para notificá-lo a executar reversão e outras operações.

O produtor e o consumidor varrem regularmente a tabela de mensagens local e enviam as mensagens não processadas ou com falha novamente. Se houver uma lógica de reconciliação automática confiável, essa solução ainda será muito prática.

Vantagens: Uma implementação muito clássica, evitando transações distribuídas e alcançando consistência eventual.

Desvantagens: a tabela de mensagens será acoplada ao sistema de negócios.Se não houver uma solução em pacote, haverá muitas tarefas para resolver.