Sistemas Distribuídos Transações Distribuídas. Vinícius Fernandes Soares Mota

Transcrição

1 Sistemas Distribuídos Transações Distribuídas Vinícius Fernandes Soares Mota 1

2 2 Transações Na última aula... Transação: Unidade lógica de trabalho abrange um conjunto de operações de manipulação de dados que executam uma única tarefa Conecta ao Banco de Dados Desconecta Começa transação Operações de consulta/atualização... Finaliza transação Começa transação Operações de consulta/atualização... Finaliza transação

3 3 Controle de Concorrência Execução Serial (sequencial): A B t 1 t 2 t 3 tempo Execução Intercalada: A B A B t 1 t 2 t 3 t 4 t 5 tempo

4 Regras para conflito das operações read e write 4 Operações que dependem da ordem em que foram executas Operações das várias transações Conflito Razão read read Não Porque um par de operações de leitura não dependem da ordem em que foram executadas read write Sim A ordem altera o resultado final write write Sim A ordem altera o resultado final

5 5 Transações Distribuídas Transação Distribuída: transação cujas operações devem ser executadas em várias das estações de uma rede. Envolve atualização de dados em múltiplos BD Exemplo: transferência bancária de uma conta localizada em uma agência A para uma agência B UPDATE A.conta SET saldo= saldo 100 WHERE num = 49950; UPDATE B.conta SET saldo= saldo WHERE num = 80410; COMMIT;

6 6 Transações Distribuídas Dificuldade: garantia global de atomicidade Ou todos servidores efetivam a transação (commit) Ou transação é abortada em todos os servidores Solução: Protocolo para Garantia de Atomicidade (Atomic Commit Protocol)

7 Transações Distribuídas planas e aninhadas 7 (a) Transação plana (b) Transação aninhada X T 11 M X T T Y Cliente T T 1 T 12 T 21 N Cliente Z T 2 Y P T 22

8 Transações Distribuídas: Transação bancária aninhada 8 X Cliente T 1 A a.withdraw(10) T T = opentransaction Y opensubtransaction a.withdraw(10); opensubtransaction b.withdraw(20); opensubtransaction c.deposit(10); opensubtransaction d.deposit(20); closetransaction T 2 T 3 T 4 Z B C D b.withdraw(20) c. deposit(10) d.deposit(20)

9 Coordenando uma Transação distribuída 9 opentransaction closetransaction. join join participante A AgênciaX a.withdraw(4); T participante Cliente b.withdraw(t, 3); B b.withdraw(3); T = opentransaction a.withdraw(4); c.deposit(4); b.withdraw(3); d.deposit(3); closetransaction join Note: O Coordenador é um dos servidores, ex. AgênciaX AgênciaY participante C D AgênciaZ c.deposit(4); d.deposit(3);

10 Protocolos de confirmação atômica 13 Devem garantir que uma transação foi concluída com sucesso ou falhar Protocolo de confirmação de uma fase: Coordenador comunica pedido de confirmação ou cancelamento para todos os participantes Repete até que todos confirmem que seguiram o pedido

11 Protocolos de confirmação atômica 14 Devem garantir que uma transação foi concluída com sucesso ou falhar Protocolo de confirmação de uma fase: Coordenador comunica pedido de confirmação ou cancelamento para todos os participantes Repete até que todos confirmem que seguiram o pedido Por quê é inadequado?

12 Protocolos de confirmação atômica 15 Devem garantir que uma transação foi concluída com sucesso ou falhar Protocolo de confirmação de uma fase: Por quê é inadequado? Não permite que um servidor tome uma decisão unilateral de cancelar uma transação

13 16 Two Phase Commit Protocol (2PC) Protocolo para garantia de atomicidade de transações distribuídas Executado em todas as estações que tomam parte de uma transação distribuída Supõe a existência de um nodo coordenador, o qual é responsável pelo monitoramento da transação distribuída Normalmente, é o próprio nodo que disparou a transação Duas fases: Fase 1: Votação Fase 2: Apuração Suposição: transações já foram disparadas para os n nodos participantes

14 17 2PC: Fase 1 (Votação) Coordenador envia mensagem Prepare(CanCommit) para todos os participantes Participante responde com um Sim ou Não. Em caso de resposta Não, participante descarta transação.

15 18 2PC: Fase 2 (Apuração) Têm início após o recebimento de n votos Caso todos os votos sejam Sim Coordenador envia mensagem docommit para todos os participantes, que então realizam commit e respondem com um havecommited (acks) Após receber n havecommited, coordenador sinaliza sucesso da transação Caso haja um único voto Não Coordenador envia doabort para todos os participantes, que então abortam a transação Após receber n havecommited, coordenador finaliza protocolo

16 19 Comunicação no 2PC Coordenador Participante passo estado passo estado 1 prepared to commit cancommit? (waiting for votes) Yes 2 prepared to commit 3 committed docommit (uncertain) havecommitted 4 committed done

17 20 Comunicação no 2PC Quantas mensagens são necessárias? Coordenador Participante passo estado passo estado 1 prepared to commit cancommit? (waiting for votes) Yes 2 prepared to commit 3 committed docommit (uncertain) havecommitted 4 committed done

18 2PC: Número de Mensagens Trocadas 21 Observações: Nodos não podem alterar seu voto Um único Não tem poder de veto Número de mensagens trocadas: n mensagens do tipo CanCommit n mensagens contendo os votos dos participantes n mensagens doabort ou docommit n havecommited Total de mensagens: 4n O protocolo poderia funcionar sem as msg havecommited

19 22 2PC: Tratamento de Falhas Coordenadores e participantes entram em alguns estados em que ficam esperando mensagens uns dos outros E se estas mensagens não chegarem? Devido, por exemplo, a problemas na rede Soluções: timeout, para abandonar estado de espera Após o timeout: Abortar a transação Reenviar uma mensagem

20 23 2PC: Situações Possíveis de Falhas Situação 1: Coordenador esperando voto de um ou mais participantes Se voto não chegar dentro de um certo intervalo de tempo (timeout), coordenador aborta a transação Deve enviar antes mensagem doabort para todos os participantes

21 24 2PC: Situações Possíveis de Falhas Situação 2: Coordenador esperando ACK de participante Se ACK não chegar dentro de um certo intervalo de tempo (timeout), deve reenviar mensagem docommit ou doabort e então voltar a esperar um ACK. Veja que, neste caso, coordenador permanece bloqueado, esperando ACK.

22 25 2PC: Situações Possíveis de Falhas Situação 3: Participante que votou Sim e que encontrase esperando docommit ou doabort Não pode tomar uma decisão unilateral (exemplo: reverter seu voto para Não) Deve permanecer bloqueado, aguardando resultado da transação Logo, falhas têm os seguintes efeitos sobre o Protocolo 2PC Podem requerer retransmissão de mensagens Podem dar origem a bloqueios

23 Uma variante descentralizada do 2PC 26 Os participantes se comunicam diretamente uns com os outros, em vez de indiretamente por meio do coordenador. Na fase 1, o coordenador envia seu voto para todos os participantes. Na fase 2, se o voto do coordenador for Não, os participantes apenas cancelam a transação; se for Sim, cada participante envia seu voto para o coordenador e para os outros participantes, cada um dos quais decide sobre o resultado, de acordo com o voto, e o executa. 1. Calcule o número de mensagens e o número de rodadas necessárias para isso. 2. Quais são as vantagens ou desvantagens, em comparação com a variante centralizada?

24 Uma variante descentralizada do 2PC 27 Número de mensagens: Fase 1: Coordenador envia seu voto para N participantes = N Fase 2: cad N participante envia seu voto para os outros (N 1) participantes + coordenador = N*(N 1). Total = N*N. No. rodadas: Cada participante + coordenador = 2 rodadas. Vantagens:O número de rodadas é menor. Desvantagem: A quantidade de mensagens N*N ao invés de 3N

25 28 2PC: Implementações SGBD com suporte a distribuição de dados: Exemplos: Oracle, Microsoft SQL Server, IBM DB2 etc Monitores de Transação: Componente essencial em um sistema/cliente servidor de 3 camadas que necessita acessar diversos BD Principais tarefas: Garantir atomicidade de transações distribuídas (geralmente via 2PC) Multiplexar carga de acesso a um SGBD Exemplos: Microsoft Transaction Server (MTS), BEA Tuxedo, IBM Encina, Java Transaction Server etc

26 Microsoft Transaction Server (MTS) 29 M ic r o s o f t T r an s ac tio n S er v er C lien te Ap lic ação T er m in ais T elef ô n ic o s C lien te Ap lic ação C lien te Ap lic ação C lien tes D is tr ib u ted T r an s ac tio n C o o r d in ato r Aplicações: objetos DCOM (objetos cujos métodos podem ser chamados remotamente a partir de clientes) Exemplo de aplicação: Cadastrar um novo cliente em uma empresa de telecomunicações (envolve inserções em dois bancos de dados: terminais telefônicos e clientes)

27 Padrões para Transações Distribuídas 30 Objetivo: padronizar serviços de transações distribuídas, de forma a permitir interoperabilidade entre: Aplicação e Monitor de Transação Monitor de Transação e SGBD Principal padrão: Distributed Transaction Processing (DTP) Proposto pelo consórcio X/Open

28 31 Interfaces do Padrão DTP Interface TX: padroniza interface entre aplicação e monitor de transação Principais funções: tx_begin, tx_commit, tx_rollback, tx_open, tx_close etc Suportada pelos principais monitores de transação, a exceção do MTS Interface XA: padroniza interface de comunicação entre monitor de transação e SGBD (gerenciador de recursos) Principais funções: xa_prepare, xa_commit etc (mensagens trocadas no protocolo 2PC) Suportada pelos principais monitores de transação (inclusive MTS) e pelos principais SGBDs.

29 Controle de Concorrência em transações Distribuídas 32 Travamento Ordenação por carimbo de tempo Controle de concorrência otimista

30 Controle de Concorrência em transações Distribuídas 33 Travamento

31 Controle de Concorrência em transações Distribuídas 34 Travamento

32 Controle de Concorrência em transações Distribuídas 35 Ordenação por carimbo de tempo Coordenador publica um timestamp para cada transação Timestamp deve ser globalmente exclusivo Servidores garantem que cada transação é executada sequencialmente

33 Controle de Concorrência em transações Distribuídas 36 Ordenação por carimbo de tempo Transação T e U acessam um mesmo objeto U Acessa o objeto após T Usando Timestamp <timestamp, id_servidor> Servidores confirmaram nesta ordem Exige certa sincronização de relógios

34 Controle de Concorrência em transações Distribuídas 37 Controle de concorrência otimista Cada transação é validada antes de ser confirmada Cada transação tem um identificador As transações são executadas nesta ordem

35 Controle de Concorrência em transações Distribuídas 38 Controle de concorrência otimista Cada transação é validada antes de ser confirmada Cada transação tem um identificador As transações são executadas nesta ordem Problema Pode levar a um impasse quando quando dois servidores começarem transações simultaneamente

36 Controle de Concorrência em transações Distribuídas 39 Controle de concorrência otimista Nenhum servidor poderá confirmar, porque um está esperando a confirmação do outro

37 40 Deadlocks (impasses) distribuídos Um deadlock ou impasse pode ocorrer porque as transações esperam uma pela outra Uma transação está em deadlock se está bloqueada e permanecerá assim até que ocorra uma intervenção externa Algoritmos de CC baseados em bloqueio podem resultar em impasses Algoritmos de ordenação de timestamp que exigem a espera de transações também podem causar impasses

38 41 Deadlocks (impasses) distribuídos Grafo de espera (Wait for graph WFG) Existe um arco Ti Tj no WFG se a transação Ti estiver esperando que outra transação Tj libere um bloqueio sobre alguma entidade. Há um impasse se há ciclo no grafo

39 42 Deadlocks (impasses) distribuídos Travamento d.deposit(10) U V W lock D b.deposit(10) lock B a.deposit(20) lock A at Y at X b.withdraw(30) wait at Y c.withdraw(20) wait at Z c.deposit(30) lock C at Z a.withdraw(20) wait at X

40 43 Deadlocks (impasses) distribuídos Mantido por W Espera por C D A Mantido por Z X Espera por V Mantido por U Mantido por B Espera por Y

41 44 Deadlocks (impasses) distribuídos Mantido por W Espera por Formação do ciclo C D A Mantido por W Z X Espera por V Mantido por U V Mantido por B Espera por U Y

42 45 Exercício Construa o grafo de espera por das transações abaixo. Está ocorrendo um impasse?

43 46 Detecção de impasses Ignorar Deixe que o programador da aplicação lide com ele, ou re inicie o sistema Prevenção Garantir que os impasses nunca ocorram. Gerenciador de transações verifica uma transação quando ela é iniciada e não permite que elaprossiga se houver possibilidade de impasse. Não exigem suporte em tempo de execução. Não adequada p/ SGBD Anulação Detectam situações potenciais de impasse com antecedência e asseguram que eles não ocorrerão (ordem pré definida, timestamp). Exigem suporte em tempo de execução. Detecção e Recuperação (mais usual) Permitem que impasses ocorram, detectam nos monitorando formação de ciclos no WFG e rompendo os. Exigem suporte em tempo de execução

44 47 Detecção de impasse centralizada Servidor assume papel detector de impasse global Cada servidor envia seu grafo de espera local Grafo de espera local Grafo de espera local Detector de impasse global T U V T T X Y U V

45 48 Detecção de impasse centralizada Por que a solução centralizada não é uma boa idéia?

46 49 Detecção de impasse centralizada Por que a solução centralizada não é uma boa idéia? Falta de tolerância a falhas Escalabilidade Como decidir a frequência de construção do grafo? Se frequente, Custo para enviar grafo de espera local pode ser alto Senão, pode demorar para detectar um impasse

47 50 Problema do impasse fantasma Detecta um impasse que não é impasse

48 51 Problema do impasse fantasma Detecta um impasse que não é impasse T U V T X Y Considere a seguinte mudança: U Libera objeto em X U Solicita objeto mantido em V servidor Y

49 52 Problema do impasse fantasma Detecta um impasse que não é impasse T U V T T X Y U V Considere a seguinte mudança: U Libera objeto em X U Solicita objeto mantido em V servidor Y

50 53 Detecção de impasse distribuído Caminhamento pelas arestas (Edge Chasing) Servidores têm conhecimento de algumas arestas Tentam encontrar ciclos encaminhando mensagens de sondagem Mensagem representa relacionamentos espera por da transação

51 54 Caminhamento pelas arestas Algoritmo em três etapas Início: servidor nota que uma transação T começa a esperar por outra transação U Envia uma mensagem de sondagem contendo a aresta <T U> para o servidor do objeto em que a transação U está parada Detecção consiste no recebimento de mensagens de sondagem e em decidir se o impasse ocorreu e se as mensagens de sondagens devem ser encaminhadas. Solução quando um ciclo é detectado, uma transação do ciclo é cancelada para desfazer o impasse

52 55 Caminhamento pelas arestas C Z Mantido por W Espera por A X Mantido por O servidor X inicia a detecção, enviando a mensagem de sondagem <W U> para o servidor de B (servidor Y). Espera por V U Mantido por B Espera por Y

53 56 Caminhamento pelas arestas C Z Mantido por W Espera por A X Mantido por O servidor X inicia a detecção, enviando a mensagem de sondagem <W U> para o servidor de B (servidor Y). Espera por V U Mantido por B Espera por Y

54 57 Caminhamento pelas arestas C Mantido por W Espera por A O servidor Y recebe a mensagem de sondagem <W U>, nota que B é mantido por V e anexa V na mensagem de sondagem para produzir <W U V>. Z Espera por V Mantido por B X Espera por Mantido por U Ele nota que V está esperando por C no servidor Z. mensagem de sondagem é encaminhada para o servidor Z. Y

55 58 Caminhamento pelas arestas C Mantido por W Espera por A O servidor Y recebe a mensagem de sondagem <W U>, nota que B é mantido por V e anexa V na mensagem de sondagem para produzir <W U V>. Z Espera por V Mantido por B X Espera por Mantido por U Ele nota que V está esperando por C no servidor Z. mensagem de sondagem é encaminhada para o servidor Z. Y

56 59 Caminhamento pelas arestas Mantido por W Espera por O servidor Z recebe a mensagem de sondagem <W U V>, C Z Espera por V Mantido por B A X Espera por Mantido por U nota que C é mantido por W e anexa W na mensagem de sondagem <W U V W>. Y

57 60 Caminhamento pelas arestas C Z Espera por Mantido por Impasse detectado V W Mantido por Espera por B A X Espera por Mantido por U O servidor Z recebe a mensagem de sondagem <W U V>, nota que C é mantido por W e anexa W na mensagem de sondagem <W U V W> Ciclo detectado. Y

58 61 Caminhamento pelas arestas Antes que um servidor transmita uma mensagem de sondagem para outro servidor, ele consulta o coordenador da última transação no caminho para descobrir se ela está esperando por outro objeto de alguma parte O algoritmo deve encontrar qualquer ocorrência de impasse desde que as transações que estão esperando não sejam canceladas não existam falhas como mensagens perdidas ou servidores falhando.

59 62 Caminhamento pelas arestas Antes que um servidor transmita uma mensagem de sondagem para outro servidor, ele consulta o coordenador da última transação no caminho para descobrir se ela está esperando por outro objeto de alguma parte O algoritmo deve encontrar qualquer ocorrência de impasse desde que as transações que estão esperando não sejam canceladas não existam falhas como mensagens perdidas ou servidores falhando

60 63 Caminhamento pelas arestas Uma mensagem de sondagem que detecta um ciclo envolvendo N transações será encaminhada por (N 1) coordenadores de transação por intermédio de (N 1) servidores de objetos, Logo, exigindo 2(N 1) mensagens. A maioria dos impasses envolve ciclos contendo apenas duas transações não há necessidade de preocupação excessiva com o número de mensagens envolvidas.

61 64 Prioridades de transação Se dois servidores começam a detecção de impasse simultaneamente Mais de uma transação pode ser cancelada

62 65 Prioridades de transação Se dois servidores começam a detecção de impasse simultaneamente Mais de uma transação pode ser cancelada (a) Situação inicial (b) Detecção iniciada por T (c) Detecção iniciada por W Espera por V W T Espera por U V U T U W V T U W Espera por T W T U W V T V W V T W V T U W U Espera por

63 66 Prioridades de transação Prover prioridade para transações T > U > V > W Ao detectar ciclo, W é cancelada (a) Situação inicial (b) Detecção iniciada por T (c) Detecção iniciada por W Espera por V W T Espera por U V U T U W V T U W Espera por T W T U W V T V W V T W V T U W U Espera por

64 67 Reforçando Supondo que esteja em uso o travamento de duas fases restrito, descreva como as ações do protocolo de confirmação de duas fases se relaciona com as ações de controle de concorrência de cada servidor individual. Como a detecção de impasse distribuído se encaixa nisso?

65 68 Reforçando Dado o conjunto de Transações abaixo ordene utilizando travamento em duas fases Desenhe o grafo de espera por da sua solução U leia(a) escreva(a) V escreva(a) escreva(b) escreva(c) W leia(a) leia(b) leia(c)

66 69 Questões Transações Distribuídas Vinícius Fernandes Soares Mota