Resumo comparativo dos quatro modos do Seata | Spring Cloud 59

I. Introdução

Através da seguinte série de capítulos:

docker-compose implementa implantação de alta disponibilidade do Seata Server | Spring Cloud 51

Estudo da teoria do modo Seata AT, isolamento de transações e análise parcial do código-fonte | Spring Cloud 52

Spring Boot integra Seata com exemplo de transação distribuída no modo AT | Spring Cloud 53

Aprendizagem, uso e precauções da teoria do modo Seata XA | Spring Cloud54

Aprendizagem da teoria do modo Seata TCC, construção de exemplo de uso em nível de produção e precauções | Spring Cloud55

Resolva os problemas de idempotência, suspensão e reversão vazia no modo Seata TCC | Spring Cloud56

Aprendizagem da teoria do modo Seata Saga, construção de exemplo de uso em nível de produção e precauções (1) | Spring Cloud57

Aprendizagem da teoria do modo Seata Saga, construção de exemplo de uso em nível de produção e precauções (2) | Spring Cloud58

Temos uma compreensão profunda da teoria e do uso de Seataseus modos de transação AT, XA, TCCe , e comparamos e resumimos os quatro modos da teoria básica distribuída de hoje e .SagaSeata

Dois, assuntos

A simples compreensão de uma transação é uma unidade de execução de programa ( ) que atualiza vários dados no banco de dados.A unitrigor, uma transação deve ter atomicidade, consistência, isolamento e persistência, referidos como ACID.

• Atomicidade ( Atomicity): Todas as operações dentro de uma transação são executadas ou não executadas.

• Consistência ( Consistency): Consistência significa que a transação deve mudar o banco de dados de um estado consistente para outro, ou seja, os resultados antes e depois do processamento do banco de dados devem ser consistentes com os resultados após a execução de acordo com as regras de negócio.

• Isolamento ( Isolation): Refere-se ao fato de que múltiplas transações não irão interferir entre si quando executadas simultaneamente.

• Persistência ( Durability): Refere-se ao fato de que após a conclusão de uma transação, os dados são armazenados para sempre, e outras operações ou falhas subsequentes não afetarão o resultado da transação.

3. Transações distribuídas

Como o nome indica, as transações distribuídas são para implementar transações em sistemas distribuídos, que são compostos por várias transações locais.

A causa raiz do uso de transações distribuídas: alta simultaneidade, quando um servidor está muito ocupado, é necessário adicionar vários servidores para ajudar a responder às solicitações. Nesse momento, surgirá um problema, ou seja, há apenas uma cópia dos dados, como garantir que em um ambiente distribuído, após a execução de cada transação, os dados estejam corretos, como serviço de estoque, serviço de pedido e pagamento serviço. Eles são implantados separadamente. Neste momento, faça Depois que a compra for concluída, todos os três serviços precisam concluir as operações correspondentes, falhando juntos ou obtendo sucesso juntos. Isso leva ao problema de resolver transações distribuídas.

4. Teoria CAP

Em um sistema distribuído, os três elementos de consistência ( Consistency), disponibilidade ( Availability) e tolerância de partição ( ) podem atingir no máximo dois pontos ao mesmo tempo, sendo impossível cuidar dos três.Partition tolerance

• Consistência ( Consistency): Se todos os backups de dados em um sistema distribuído têm o mesmo valor ao mesmo tempo. (equivalente a todos os nós acessando a mesma cópia de dados mais recente)

• Disponibilidade ( Availability): Após a falha de alguns nós no cluster, se o cluster como um todo ainda pode responder às solicitações de leitura e gravação do cliente. (alta disponibilidade para atualizações de dados)

• Tolerância de partição ( Partitiontolerância): Em termos de efeito prático, a partição é equivalente ao requisito de limite de tempo para comunicação. Se o sistema não conseguir obter consistência de dados dentro do limite de tempo, significa que ocorreu uma partição e deve ser feita uma escolha entre C e A para a operação atual

A parte sobreposta na figura é a troca que deve ser feita em um ambiente distribuído: ou CP, ou AP, ou CA, mas não existe CAP.

CP: Sacrifique a usabilidade. O protocolo de sincronização de replicação geralmente usa um protocolo de quorum estrito ( Paxos, Raft, ZAB) ou 2PCprotocolo. CPOs tipos de sistemas são MongoDB, HBase, Zookeeper, Redise ElasticSearchassim por diante.

AP: Sacrifique a consistência. O protocolo de sincronização de replicação geralmente usa um protocolo de quorum não estrito. APOs tipos de sistemas são Couch DB, Cassandra, e Amazon Dynamoassim por diante.

CA: Deixando RDBMSde lado Oraclee MySQLsem falar, entre os sistemas distribuídos que se dizem CAsistemáticos, estão o Google Spannere o Ali OceanBase.

P: Por que consistência e disponibilidade não podem ser garantidas em um sistema distribuído?

Resposta: Em primeiro lugar, existe uma premissa: para sistemas distribuídos, a tolerância a falhas de partição é o requisito mais básico, então basicamente só podemos escolher entre consistência ( C) e disponibilidade ( ) ao projetar um sistema distribuído.A

Se a consistência for garantida ( C): Para o nó N1e N2, ao escrever dados N1em , N2a operação nele deve ser suspensa, e somente quando N1chegarem os dados de sincronização N2é que as N2solicitações de leitura e gravação podem ser feitas, e N2a solicitação enviada pelo cliente durante a operação suspensa será falha no recebimento ou expirou. Obviamente, isso é antitético à usabilidade.

Se a disponibilidade for garantida ( A): Então N2as operações de leitura e escrita não podem ser suspensas, mas N1se os dados estiverem sendo escritos ao mesmo tempo, isso viola o requisito de consistência.

CAPACIDA soma em e Aé Cbem diferente:

• CA diferença:

  • ACIDA consistência diz respeito às regras do banco de dados, e o banco de dados sempre faz a transição de um estado consistente para outro estado consistente;

  • CAPConsistência é replicar dados entre multi-servidores distribuídos para que esses servidores tenham os mesmos dados. Devido a limitações de velocidade da rede, o tempo consumido por essa replicação em diferentes servidores não é fixo. Clusters visualizam diferentes nós organizando clientes Mantêm uma visão lógica de dados não sincronizados na Internet, conceito de consistência no domínio distribuído;

• AA diferença:

  • ACIDrefere-se Aà atomicidade ( Atomicity), o que significa que uma transação é considerada como uma unidade mínima indivisível de trabalho e todas as operações na transação são confirmadas com sucesso ou revertidas após falha;

  • CAPrefere-se Aà disponibilidade ( Availability), que se refere a se o cluster como um todo pode responder às solicitações de leitura e gravação do cliente após a falha de alguns nós do cluster;

Cinco, teoria BASE

BASEé um acrônimo para Basically Available(basicamente disponível), Soft state(estado suave) e Eventually consistent(eventualmente consistente).

Em um sistema distribuído, CAPa teoria é o pensamento orientador, e BASEa teoria é uma extensão da CAPteoria , que é o resultado de uma troca entre consistência e disponibilidade no sistema. A ideia central é: mesmo que consistência forte não possa ser alcançado, cada aplicação pode De acordo com suas próprias características de negócio, métodos apropriados podem ser adotados para que o sistema atinja a consistência final.APCAP

• Disponibilidade básica ( Basically Available): Significa que quando um sistema distribuído falha, é permitido perder parte da disponibilidade para garantir que o núcleo esteja disponível.

• Estado flexível ( Soft state）: refere-se a permitir que o sistema tenha um estado intermediário e considera-se que o estado intermediário não afetará a disponibilidade geral do sistema. Por exemplo, o atraso que permite a sincronização de réplica entre diferentes nós é a personificação do flexível estado.

• Consistência Final ( Eventually consistent): Significa que todas as cópias no sistema podem finalmente atingir um estado consistente após um determinado período de tempo. Portanto, a essência da consistência final é que o sistema precisa garantir que os dados finais possam ser consistentes e não precisa garantir a forte consistência dos dados do sistema em tempo real.

6. Consistência da transação

• Consistência forte: após a atualização bem-sucedida de determinados dados no sistema, os acessos subsequentes podem ver o valor atualizado.

• Consistência fraca: após a atualização de determinados dados no sistema, o acesso subsequente pode obter o valor atualizado ou o valor antes da alteração.

• Consistência final: Um determinado dado no sistema é atualizado, e após um período de tempo, todos os acessos são finalmente atualizados.

Assuntos rígidos: siga ACIDo princípio, consistência forte.

Transações flexíveis: siga BASEa teoria, consistência eventual.

七、Definir

SeataÉ uma solução de transação distribuída aberta em conjunto pela Ant Financial e Alibaba em janeiro de 2019. Comprometida em fornecer serviços de transações distribuídas fáceis de usar e de alto desempenho, criando uma solução distribuída completa para os usuários.

Endereço do site oficial: http://seata.io/ , onde documentos e podcasts fornecem muitas instruções de uso e análise de código-fonte.

7.1 Arquitetura

SeataExistem três funções importantes no gerenciamento de transações:

• TC( Transaction Coordinator) - Coordenador de transações: mantém o estado das transações globais e filiais e coordena o commit ou rollback das transações globais.

• TM( Transaction Manager) - Gerenciador de transações: define o escopo de uma transação global, inicia uma transação global, confirma ou reverte uma transação global.

• RM( Resource Manager) - Gerenciador de recursos: Gerencie recursos para transações de filiais, fale com TC para registrar transações de filiais e relatar o status das transações de filiais e direcionar transações de filiais para confirmação ou reversão

SeataCom base na arquitetura acima, quatro diferentes soluções de transações distribuídas são fornecidas:

• XAModo: modo de transação em fases de consistência forte, sacrificando certa disponibilidade e sem intrusão nos negócios

• TCCModo: modo de transação em fases eventualmente consistente com invasão de negócios

• ATModo: modo de transação em fases eventualmente consistente, sem intrusão nos negócios, também o modo padrão da Seata

• SAGAModo: modo de transação longa, com invasão de negócios

7.2 Modo XA

7.2.1 Mecanismo geral

Dentro Seatada estrutura de transações distribuídas definidas por , um modo de transaçãoXA que usa o suporte de recursos de transação (bancos de dados, serviços de mensagens, etc.) para XAo protocolo gerenciar transações de ramificação com o mecanismo do protocolo .

O trabalho da primeira etapa do RM:

① Registre a transação da filial no TC

② Execute o sql de negócios da filial, mas não envie

③ Relatar o status de execução ao TC

O trabalho da segunda fase do TC:

• TC detecta o status de execução da transação de cada filial

  • a. Se tudo for bem-sucedido, notifique todos os RMs para confirmar a transação
  • b. Se houver uma falha, notifique todos os RMs para reverter a transação

O trabalho da segunda fase do RM:

• Receba instruções de TC, transações de commit ou rollback

7.2.2 Vantagens e desvantagens

• Quais são as vantagens do modo XA?

  • A forte consistência das transações atende ao princípio ACID.

  • Bancos de dados comumente usados ​​são suportados, a implementação é simples e não há intrusão de código

• Quais são as desvantagens do modo XA?

  • Como os recursos do banco de dados precisam ser bloqueados no primeiro estágio e liberados somente após o final do segundo estágio, o desempenho é ruim

  • Contando com bancos de dados relacionais para realizar transações

7.3 Modo AT

7.3.1 Mecanismo geral

ATpadrão é uma evolução do protocolo two-phase commit (padrão de transação em fases eventualmente consistente). Compensa XAo defeito que o período de bloqueio do recurso no modo é muito longo.

Trabalho da primeira fase RM:

• registrar transação de filial

• registro undo-log(instantâneo de dados)

• Executar negócios sqle enviar

• relatar status da transação

RMTrabalhe no commit do estágio 2 :

• undo-logapenas apague

RMTrabalhe durante a reversão da fase 2 :

• De acordo com undo-loga restauração dos dados antes da atualização

7.3.2 A diferença entre AT e XA

• XANa primeira fase do modo, as transações não são confirmadas e os recursos são bloqueados; ATna primeira fase do modo, os recursos não são bloqueados.

• XAOs padrões dependem de mecanismos de banco de dados para reversão; ATos padrões utilizam instantâneos de dados para reversão de dados.

• XAEsquemas são fortemente consistentes; ATesquemas são eventualmente consistentes.

7.4 Modo TCC

7.4.1 Mecanismo geral

O todo é um modelo de confirmação de duas fases . Uma transação global é composta por várias transações de filial, e as transações de filial devem atender aos requisitos do modelo two-phase commit , ou seja, cada transação de filial precisa ter a sua:

• Trycomportamento do primeiro estágio
• segundo estágio Confirmou Cancelcomportamento

No processo acima, um total de três métodos estão envolvidos, Try, Confirme Cancel, esses três métodos são métodos completamente definidos pelo usuário, que precisam ser implementados por nós mesmos. Comparado com ATo modo de transação, TCCeste modo não depende do suporte de transação do banco de dados subjacente.

7.4.2 Vantagens e desvantagens

TCCO que cada fase do padrão faz?

• Try: verificação e reserva de recursos

• Confirm: Execução e Envio de Negócios

• Cancel: liberação de recursos reservados

TCCQuais são as vantagens?

• Conclua a transação de confirmação direta em um estágio, libere recursos do banco de dados e tenha bom desempenho

• Comparado com o modelo AT, não há necessidade de gerar instantâneos, não há necessidade de usar bloqueios globais e o desempenho é o mais forte

• Não depende de transações de banco de dados, mas depende de operações de compensação, que podem ser usadas para bancos de dados não transacionais

TCCQuais são as desvantagens?

• Há invasão de código e é muito problemático escrever manualmente as interfaces try, confirm e cancel

• Estado flexível, as transações são eventualmente consistentes

• É necessário considerar Confirma Cancelfalha da soma e fazer o processamento idempotente

7.5 Modo Saga

7.5.1 Mecanismo geral

SagaO modo é Seatauma solução de transação de longo prazo fornecida. No Sagamodo, cada participante no processo de negócios envia uma transação local. Quando um determinado participante falha, os participantes anteriores bem-sucedidos são compensados. O serviço de encaminhamento de primeiro estágio e o serviço de segundo estágio Serviços de compensação são implementados pelo desenvolvimento de negócios.

Base teórica: Hector & Kenneth publicaram o artigo Sagas (1987)

7.5.2 Vantagens e desvantagens

• Cena aplicável:
  • Processo de negócios longo e muitos processos de negócios
  • Os participantes incluem outras empresas ou serviços do sistema legado que não podem fornecer as três interfaces exigidas pelo modelo TCC
• Vantagem:
  • Confirme transações locais em uma fase, sem bloqueio, alto desempenho
  • Arquitetura orientada a eventos, os participantes podem executar de forma assíncrona, alto rendimento
  • Os serviços de compensação são fáceis de implementar
• deficiência:
  • Isolamento não é garantido

8. Comparação dos quatro modos do Seata

-	XA	NO	TCC	SAGA
consistência	consistência forte	consistência fraca	consistência fraca	eventualmente consistente
isolamento	completamente isolado	Com base no isolamento de bloqueio global	Isolamento com base na reserva de recursos	sem isolamento
hacking de código	nenhum	nenhum	Sim, existem três interfaces para escrever	Sim, para escrever máquina de estado e negócios de compensação
desempenho	Diferença	bom	muito bom	muito bom
Cenas	Serviços com altos requisitos de consistência e isolamento	A maioria dos cenários de transações distribuídas com base em bancos de dados relacionais pode	Transações com requisitos de alto desempenho e transações envolvendo dados não relacionais	O processo de negócios é longo e há muitos processos de negócios, e os participantes incluem outras empresas ou serviços de sistemas legados, que não podem fornecer as TCCtrês interfaces exigidas pelo modelo