prefácio
Depois que o sistema torna-se complexo, distribuído, serviço e outras tecnologias de micro-arquitetura, é necessário considerar a aplicação no sistema. Em particular, a grande quantidade de dados, a necessidade de uma divisão de banco de dados .
Tais como: registro de dados do usuário, o volume, e você precisa considerar sub-biblioteca de sub-mesa
Uma vez que o banco de dados foi dividida, em seguida, um monte de dores de cabeça, um dos quais é um problema transação . Então, olhamos para o problema é a forma de aparecer em?
cena
Figura sobre um primeiro a chegar,
Após a divisão dos dados, é semelhante ao esquema acima
Nós figura acima exemplo, o usuário tomou dados de usuários, uma vez dezenas de milhões sobre a necessidade de sub-biblioteca de sub-mesa ; FIG em três pontos no banco de dados, cada biblioteca para garantir alta disponibilidade.
Este projeto de arquitetura, a transação vai encontrar um problema, nós olhamos para o cenário de negócios específica: Um usuário de transferência de 100 yuan para o usuário B, este negócio é relativamente simples, temos que analisar os passos que específicas :
1, a conta do utilizador A para deduzir 100 yuan 2, então os do utilizador B representa adicional 100
A lógica é simples, o pseudocódigo
O código é relativamente clara, eu sinto não há nenhum problema, então nós temos que analisar o problema mentira?
problema
Vemos no negócio de transferência, há duas etapas, um usuário A é a dedução de operação de dinheiro, um usuário está operando B mais dinheiro
Se você está no mesmo banco de dados, você pode garantir que esta operação de duas etapas, ao mesmo tempo, quer ter sucesso ou não ter sucesso, ao mesmo tempo. Isto garante que a transferência de consistência dos dados.
No entanto, se os dados do usuário Um conjunto A, B, usuário B no cluster fazer? Porque eles não são a mesma transação em; A taxa de utilização tão bem sucedido, mas o usuário B, mais o dinheiro falhou; seria poço, dados incompletos para cima.
Este problema é semelhante ao da arquitetura micro-serviço será mais , porque todos os serviços são módulos independentes, todas as chamadas de longa distância , nenhuma lei na mesma transação, a transação vai encontrar problemas.
Como resolver isso? Existem alguns programas on-line, tais como: consolidação de duas fases, TCC, etc., não é comumente eventual esquema de consistência. Today'll informá-lo sobre como usar o middleware de mensagens para resolver . Então nós colocamos o plano para ajustar o visual, adicionar mensagens middleware , e ver como otimização.
Mensagens soluções de middleware
A figura é o uso de mensagens de maneira middleware, a dedução do tráfego assíncrono, e negócio de dinheiro , depois de uma cobrança bem sucedida, envia uma "mensagem de sucesso de débito" para o middleware de mensagens ; add negócio de dinheiro Subscribe "mensagem de sucesso de débito" , em seguida, o usuário B para o dinheiro add
O sistema sabe como usuário B mais dinheiro? É o corpo da mensagem que contém a conta de origem e a identificação da conta de destino, e a quantidade de dinheiro
Desta vez, talvez amiguinhos vão perguntar, também deve ser um problema, certo: Cena um: Após a primeira mensagem de carga
A primeira carga e, em seguida, enviar uma mensagem, enviar a mensagem em caso de falha, o usuário B não seria capaz de adicionar dinheiro
Que a ordem de ajustes Cena 2: primeira mensagem, após dedução
Débito sucesso mensagem é enviada com sucesso , mas o usuário A carga falhou , você pode adicionar dinheiro para subscrever o serviço de notícias, o usuário B mais dinheiro
Devemos ver um problema, que é não garantida débito e mensagens de envio e sucesso ou fracasso, ao mesmo tempo , resultando em dados inconsistentes.
programa de serviços RocketMQ
Por causa dos problemas acima, o RocketMq middleware de mensagens mensagem é dividida em duas fases : fase Preparado e fase Preparado fase de validação (fase preliminar)
O palco é principalmente para enviar uma mensagem para rocketmq, mas a mensagem é armazenada apenas em em commitlog , mas consumeQueue não visível, é o lado do consumidor (extremidades de subscrição) não pode ver esta mensagem .
comprometer / fase de anulação (fase de validação)
O palco principal é a mensagem preparada é salvo consumeQueue em que para que os consumidores podem ver o fim desta mensagem , que pode consumir a mensagem .
Usamos o diagrama para ilustrar o seguinte:
todo o processo :
1, antes das deduções, para enviar uma mensagem pronta
2, depois de enviar a mensagem com êxito preparar, executar operações de crédito locais
3, após dedução de sucesso, em seguida, enviar uma mensagem de confirmação
4, o fim da mensagem (e Negócios dinheiro) você pode ver uma mensagem de confirmação, consumo desta mensagem, mais dinheiro
Confirmação mensagem Descrição
NOTA: A mensagem de confirmação acima pode comprometer as mensagens podem ser assinantes consumidos, também pode ser uma notícia de reversão, ou seja, a implementação da operação de débito locais não apresentar mensagem de reversão, a mensagem é apagada a preparação, os assinantes não podem consumir
Vamos analisar cenário anormal :
Anormal 1: Se você enviar uma mensagem preparação falhar, o procedimento a seguir não vai; isso é normal e
anormal 2: Se você enviar uma mensagem de sucesso preliminar, mas a implementação de uma transação local falhar, o que não é um problema, porque esta mensagem não está pronto para ser consumido final inscrever-se para o consumidor final do negócio não será executado.
Abnormal 3: Se você enviar uma preparação mensagem bem-sucedida, a transação local é bem sucedido, mas não conseguiu enviar uma mensagem de confirmação; este é um problema, porque o usuário um débito de sucesso, mas adicione o negócio dinheiro não está inscrito para a mensagem de confirmação, você não pode adicionar dinheiro. Aqui houve dados inconsistentes.
Isso RocketMq é como resolvê-lo?
Volte RocketMQ
imagem
Como RocketMq resolver o problema acima, a idéia central é que volte [Estado] , que é RocketMq regularmente travessia commitlog na mensagem de preparação.
Porque provisionamento mensagem acabará por se tornar a mensagem de reversão ou cometer mensagem , para que a mensagem está pronta para atravessar de volta para verificar o estado de implementação do negócio local, se encontrado sem a realização de um negócio de sucesso local em rollBack , se executado com sucesso envia mensagens de commit.
O acima anomalia 3, pronto para enviar a mensagem for bem sucedida, a transação de débito local é bem sucedido, mas não conseguiu enviar uma mensagem de confirmação, porque RocketMq irá realizar uma volta investigação preliminar para a mensagem , verifique novamente após o negócio descoberta foi cobrado com sucesso , em seguida, reedição "de cometer confirmação mensagem " , assim juntar dinheiro para o negócio pode se inscrever para esta mensagem se.
Na verdade, essa idéia também resolve o anormal 2, porque não há transação local é executado com sucesso, RocketMQ volta para viagens de negócios, não encontrou nenhuma execução bem-sucedida, a reversão será enviada uma mensagem de confirmação, a mensagem é apagada .
Verifique juiz de volta se o sucesso do negócio
Pequenas parceiros na verificação de volta no negócio, como determinar se a transação local é executado com sucesso ?
Se a transação local executa uma série de tabelas, não é que queremos que essas tabelas devem ser realizados para determinar se-lo com sucesso ? Isto não é muito problema, e de negócios e são acoplamento.
Existe uma maneira melhor? É criar uma tabela de transação , a mesa de negócios e ligação Transação na mesma transação local , se a transação for bem sucedida de débito local, registros de transação deveria ter sido o estado TransactionId é "Concluído". Quando RocketMq volta para verificar, basta verificar o correspondente se o status TransactionId é 'Concluído' como , sem se preocupar com os dados de negócios específico.
Autor: Lost er
link: https: //www.jianshu.com/p/286cac4625b6
Fonte: Jane livros
estão protegidas por copyright do autor. reimpressão comercial entre em contato com o autor autorizado, reimpressão não comercial por favor, indicar a fonte.
