核心思想Sim: Para cada operação, deve ser registrada uma operação de confirmação e compensação (cancelamento) correspondente. É dividido em três etapas:
- Etapa de teste: principalmente para verificar o sistema de negócios (consistência) e reserva de recursos (quase-isolamento)
- Fase de confirmação: é principalmente para confirmar e submeter o sistema de negócio.Quando a fase de teste é executada com sucesso e a fase de confirmação começa, a fase de confirmação padrão não cometerá erros. Isto é: Contanto que a tentativa seja bem-sucedida, a confirmação deve ser bem-sucedida. (A operação de confirmação satisfaz a idempotência. É necessário um design idempotente. É necessário tentar novamente após a falha de confirmação.
) - A fase Cancelar serve principalmente para cancelar o negócio executado no estado de erro de execução do negócio e precisa ser revertido, e os recursos reservados são liberados. (Cancelar a operação satisfaz a idempotência)
O único ponto do coordenador é resolvido , e esta atividade empresarial é iniciada e concluída pela parte empresarial principal. O gerente de atividades de negócios também se tornou multiponto, introduzindo clusters.
Bloqueio síncrono: introduz um tempo limite, compensa após o tempo limite e não bloqueia o recurso inteiro, converte o recurso em uma forma de lógica de negócios e reduz a granularidade.
Consistência dos dados , após ter um mecanismo de compensação, o gerente da atividade empresarial controla a consistência.
Desvantagens : Pode falhar em Confirmar e Cancelar. O TCC é um método de compensação na camada de aplicativo , portanto, os programadores precisam escrever muitos códigos de compensação ao implementá-lo. Em alguns cenários, alguns processos de negócios podem não ser bem definidos e processados com o TCC.
O seguinte foi transferido de: Por favor, não me pergunte sobre o princípio de implementação da transação distribuída TCC durante a entrevista! [As notas de arquitetura de Shishan]
1. Escreva na frente
Neste artigo, usarei o vernáculo + desenho manual, combinado com a prática de caso de um sistema de e-commerce, para explicar a todos exatamente o que é uma transação distribuída de TCC.
Em primeiro lugar, pode haver alguns princípios do Spring Cloud envolvidos. Se você tem alunos que não são muito claros, pode consultar o artigo anterior: " Por favor, não me pergunte sobre os princípios básicos do Spring Cloud na entrevista ! "
Dois, introdução do cenário de negócios
Vejamos primeiro o cenário de negócios: suponha que agora você tenha um sistema de comércio eletrônico com um cenário de pagamento de pedido.
Depois de pagar por um pedido, precisamos seguir os seguintes passos:
- Alterar o status do pedido para "pago"
- Dedução do estoque de commodities
- Adicionar pontos aos membros
- Crie uma ordem de saída de vendas para notificar o armazém para entregar mercadorias
Três, pensando melhor
Perceba o efeito de uma transação distribuída TCC.
- Serviço de pedido - modificar o status do pedido,
- Serviço de estoque - dedução de estoque,
- Pontos de aumento de serviço,
- Serviços de armazenamento - criam ordens de saída de vendas.
As etapas acima, sejam bem-sucedidas ou falhadas juntas, devem ser uma transação holística.
Por exemplo, o status do pedido agora é alterado para "pago" e o serviço de estoque falha em deduzir o estoque. O estoque desse produto era originalmente de 100 peças. Agora vendi 2 peças. Deveria ter 98 peças.
Os resultados disso? Devido à anormalidade do banco de dados de operação do serviço de estoque, a quantidade de estoque ainda é 100. Isso não é uma armadilha? Claro que isso não pode acontecer!
Mas se você não usar a solução de transação distribuída TCC, apenas use o Spring Cloud para desenvolver tal sistema de microsserviço, é muito provável que faça esse tipo de coisa.
Vamos dar uma olhada na figura a seguir, que expressa intuitivamente o processo acima.
Então nós有必要使用TCC分布式事务机制来保证各个服务形成一个整体性的事务。
Qualquer uma das etapas acima foi bem-sucedida. Se alguma operação de serviço falhar, todas elas serão revertidas juntas e a operação concluída será desfeita .
Por exemplo, se o serviço de estoque falhar em deduzir o estoque, o serviço de pedido deve cancelar a operação de modificação do status do pedido e, em seguida, parar de realizar as duas operações de adicionar pontos e notificar a entrega.
Em quarto lugar, implemente as transações distribuídas TCC no terreno
Como implementar uma transação distribuída TCC para que cada serviço tenha sucesso junto? Ou falham juntos?
Vamos analisar passo a passo. É explicado com um sistema de desenvolvimento Spring Cloud como pano de fundo.
1. Estágio 1 de realização do TCC: Experimente
Em primeiro lugar, onde está o serviço de pedidos, seu código é mais ou menos assim:
Na verdade, depois que o serviço de pedidos conclui a operação do banco de dados local, ele usa o Feign do Spring Cloud para chamar outros serviços. Mas apenas confiar neste código não é suficiente para implementar transações distribuídas TCC? !
Em primeiro lugar, o anterior 订单服务muda seu próprio status para: OrderStatus.UPDATING .
No método pay (), altere o status do pedido (pago) para UPDATING ( 修改中). Significa apenas que alguém está modificando esse status.
库存服务Na interface reduceStock () fornecida diretamente, não deduza diretamente o inventário. Você pode congelar o inventário .
Por exemplo, originalmente sua quantidade de estoque é 100, você não deve diretamente 100-2 = 98, deduzir este estoque!
Você pode definir o estoque vendável: 100-2 = 98, definir como 98 não é problema e, em seguida, definir 2 em um campo de estoque congelado separado. Em outras palavras, 2 estoques estão congelados.
积分服务A interface addCredit () é a mesma, não adiciona pontos de membro diretamente para o usuário. Você pode primeiro adicionar pontos em um campo de pontos pré-adicionados na tabela de pontos .
Por exemplo: os pontos do usuário eram originalmente 1190, mas agora você tem que adicionar 10 pontos, não diretamente 1190 + 10 = 1200 pontos!
Você pode manter os pontos inalterados em 1190. Em um campo de pré-aumento, por exemplo, campo prepare_add_credit, defina 10, o que significa que há 10 pontos prontos para aumentar.
仓储服务A interface saleDelivery () é a mesma. Você pode criar um pedido de entrega de venda primeiro, mas o status do pedido de entrega de venda é " DESCONHECIDO ".
Em outras palavras, esta ordem de saída de vendas acabou de ser criada e ainda não é certo qual é o seu status neste momento!
O processo de transformação da interface acima é, na verdade, o estágio representado pela primeira letra T na chamada transação distribuída TCC, que é o estágio Try.
Resumindo o processo acima,如果你要实现一个TCC分布式事务，首先你的业务的主流程以及各个接口提供的业务含义，不是说直接完成那个业务操作，而是完成一个Try的操作。
Esta operação é geralmente para bloquear um determinado recurso, definir um estado de preparação, congelar parte dos dados, etc., que provavelmente são todas essas operações.
Em seguida, é dividido em duas situações:
2. Fase dois de implementação do TCC: Confirmar
A primeira situação é ideal, ou seja, cada serviço executa sua própria operação Try, e todos são executados com sucesso. Neste ponto, você precisa contar TCC分布式事务框架para promover a execução do acompanhamento.
Aqui está uma breve menção, se você quiser jogar transações distribuídas TCC, você deve introduzir uma estrutura de transação distribuída TCC, como o código aberto doméstico ByteTCC, himly, tcc-transaction. Caso contrário, é impossível realizar a implementação de cada etapa e avançar a implementação da próxima etapa manualmente, o que é muito complicado.
Se você introduzir uma estrutura de transação distribuída TCC em cada serviço, a estrutura de transação distribuída TCC embutida no serviço de pedido pode perceber que a operação Try de cada serviço foi bem-sucedida.
Nesse momento, a estrutura de transação distribuída do TCC controlará a entrada para o próximo estágio do TCC, o primeiro estágio C, que é o estágio de Confirmação. Para atingir esse estágio, você precisa adicionar algum código a cada serviço.
Por exemplo, 订单服务você pode adicionar uma lógica de Confirmação para definir formalmente o status do pedido como "pago", que provavelmente é semelhante ao seguinte: da
库存服务mesma forma, você pode ter uma classe InventoryServiceConfirm que fornece uma reduçãoStock () A lógica de confirmação da interface , aqui é deduzir os 2 estoques do campo de estoque previamente congelado para 0.
Nesse caso, o estoque vendável foi alterado para 98 antes e agora os dois estoques congelados se foram e a dedução do estoque foi oficialmente concluída.
积分服务Da mesma forma, você pode fornecer uma classe CreditServiceConfirm no serviço de pontos, que tem uma lógica Confirmar da interface addCredit (), que deve deduzir os 10 pontos do campo pré-adicionado e, em seguida, adicioná-lo ao campo de pontos do membro real, mudando de 1190 para 1120.
仓储服务O mesmo é verdade. Você pode fornecer uma classe WmsServiceConfirm no serviço de armazenamento, fornecer uma lógica de confirmação da interface saleDelivery () e modificar formalmente o status da ordem de saída de vendas para "criado", que pode ser visualizado e usado pelo armazenamento gerentes em vez de permanecer "DESCONHECIDO" no estado intermediário anterior.
Ok, a lógica de Confirmação dos vários serviços acima foi implementada. Uma vez que a estrutura de transação distribuída TCC no serviço de pedidos detecta que a fase de teste de cada serviço foi bem sucedida, ela executará a lógica de Confirmação de cada serviço .
A estrutura de transação TCC no serviço de pedidos será responsável por se comunicar com a estrutura de transação TCC em cada serviço e chamar a lógica de confirmação de cada serviço por sua vez. Em seguida, a execução de toda a lógica de negócios de cada serviço é formalmente concluída.
3. Estágio três de realização do TCC: Cancelar
E se for uma situação anormal? Por exemplo: na fase Try, como no serviço de ponto, ele executou um erro, o que vai acontecer neste momento?
A estrutura da transação TCC no serviço de pedidos pode ser percebida e, então, ele decidirá reverter toda a transação distribuída TCC.
Em outras palavras, ele executará cada serviço 第二个C阶段，Cancel阶段。
Da mesma forma, para atingir esta fase de Cancelamento, cada serviço deve adicionar algum código.
Primeiro 订单服务, ele deve fornecer uma classe OrderServiceCancel, na qual haja uma lógica Cancelar da interface pay (), ou seja, o status do pedido pode ser definido como "CANCELADO", ou seja, o status do pedido é cancelado .
库存服务O mesmo é verdade. A lógica Cancelar de reduzir Estoque () pode ser fornecida, que consiste em deduzir o estoque congelado por 2 e adicioná-lo de volta ao estoque vendável, 98 + 2 = 100.
积分服务Também é necessário fornecer a lógica Cancelar da interface addCredit () para deduzir os 10 pontos do campo de pontos pré-adicionados.
仓储服务Também é necessário fornecer uma lógica de cancelamento da interface saleDelivery () para modificar o status do pedido de saída de vendas para "CANCELADO" e defini-lo como cancelado.
Então, neste momento, contanto que a estrutura de transação distribuída TCC do serviço de pedido detecte que a lógica Try de qualquer serviço falhou, ela se comunicará com a estrutura de transação distribuída TCC em cada serviço e, em seguida, chamará a lógica Cancelar de cada serviço .
Cinco, resumo e pensamento
Se você quiser jogar transações distribuídas TCC:
Primeiro, você precisa selecionar uma determinada estrutura de transação distribuída TCC e cada serviço terá essa estrutura de transação distribuída TCC em execução.
Então, sua interface original precisa ser transformada em três lógicas, Try-Confirm-Cancel.
- Primeiro, o link de chamada de serviço executa a lógica Try por sua vez
- Se tudo estiver normal, a estrutura de transação distribuída TCC avançará a execução da lógica Confirmar e concluirá toda a transação.Se tudo estiver normal, a estrutura de transação distribuída TCC avançará a execução da lógica Confirmar e concluirá toda a transação.
- Se houver um problema com a lógica Try de um serviço, a estrutura de transação distribuída do TCC avançará a execução da lógica Cancelar de cada serviço após detectá-la e cancelará as várias operações realizadas antes.
Esta é a chamada transação distribuída TCC.
A ideia central da transação distribuída TCC, para ser franco, é que quando você se depara com as seguintes situações,
- O banco de dados de um serviço está fora do ar
- Um certo serviço desligou sozinho
- A infraestrutura desse serviço, como redis, elasticsearch e MQ está funcionando incorretamente
- Alguns recursos são insuficientes, como estoque insuficiente.
1. Experimente primeiro, não conclua a lógica de negócios, primeiro tente ver se cada serviço pode basicamente funcionar normalmente e se você pode congelar os recursos de que preciso primeiro.
2. Se o Try estiver ok, ou seja, o banco de dados subjacente, redis, elasticsearch e MQ podem todos gravar dados e você reservou alguns recursos que precisa usar (como congelar uma parte do inventário).
3. Em seguida, execute a lógica de confirmação de cada serviço, basicamente, o Confirm pode garantir a conclusão de uma transação distribuída com alta probabilidade.
4. Então, se um serviço falhar na fase de teste, por exemplo, o banco de dados subjacente está inativo ou o redis está inativo e assim por diante.
Nesse momento, a lógica de cancelamento de cada serviço é executada automaticamente e a lógica de teste anterior é revertida. Todos os serviços não executam nenhuma lógica de negócios projetada. Certifique-se de que todos tenham sucesso ou falhem juntos.
Seis. Outros problemas
Se algo inesperado acontecer, por exemplo, o serviço de pedidos de repente travar e reiniciar novamente, como a estrutura de transação distribuída do TCC garante que as transações distribuídas que não foram executadas antes continuem a ser executadas?
Portanto, a estrutura de transação do TCC 都是要记录一些分布式事务的活动日志的pode ser gravada no arquivo de log no disco ou no banco de dados. Os vários estágios e estados da operação de transação distribuída são preservados.
O problema ainda não acabou, e se a execução da lógica Cancelar ou Confirmar de um determinado serviço continuar falhando?
Também é muito simples: a estrutura de transações do TCC registra o status de cada serviço por meio do log de atividades.
Por exemplo, se for verificado que o Cancelar ou Confirmar de um determinado serviço não foi bem-sucedido, ele continuará tentando chamar sua lógica de Cancelar ou Confirmar, e deve ser bem-sucedido!
Claro, se o seu código não grava nenhum bug, tem testes suficientes e você basicamente tentou na fase de teste, então, em geral, Confirmar e Cancelar podem ser bem-sucedidos!
Por fim, vou dar uma imagem para dar uma olhada em nosso negócio, além de todo o processo de execução após transações distribuídas:
muitas grandes empresas na verdade desenvolvem a estrutura de transações distribuídas TCC por si mesmas, especificamente no uso interno da empresa.
No entanto, se sua empresa não desenvolveu uma estrutura de transação distribuída TCC, geralmente escolherá uma estrutura de código aberto.
Aqui, o autor recomenda vários bons frameworks para todos, todos os quais são de código aberto por nossas próprias fontes domésticas: ByteTCC, tcc-transaction, himly.
Se você estiver interessado, pode ir ao endereço do github para aprender como usá-lo e como integrá-lo a estruturas de serviço como Spring Cloud e Dubbo.
Contanto que essas estruturas estejam integradas ao seu sistema, é fácil alcançar o maravilhoso efeito de transação distribuída TCC acima.
No próximo artigo, vamos falar sobre as transações distribuídas implementadas pela solução de consistência eventual de mensagem confiável e, ao mesmo tempo, falar sobre a arquitetura de garantia de alta disponibilidade que usa essa solução na produção real.