transações distribuídas - brhott.files.wordpress.com · • se f or sim, cada part icipante en...

Sistemas DistribuídosTransações Distribuídas

Vinícius Fernandes Soares Mota

1

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

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

Desconecta

DECSI/ICEA UFOP

2

Controle de Concorrência

• Execução Serial (sequencial):

• Execução Intercalada:

tempot2t1 t3

AB

tempot2t1 t3

AB

AB

t4 t5

DECSI/ICEA UFOP

3

Regras para conflito das operações read e write

Operações que dependem da ordem em que foram executas

DECSI/ICEA UFOP

Operações das váriastransaçõ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

4

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 + 100 WHERE num = 80410;

• COMMIT;

DECSI/ICEA UFOP

5


• 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)

DECSI/ICEA UFOP

6

Transações Distribuídas planas e aninhadas

DECSI/ICEA UFOP

7

(a) Transação plana (b) Transação aninhada

Cliente

X

Y

Z

X

Y

M

NT1

T2

T11

Cliente

P

TT12

T21

T22

T

T

Transações Distribuídas:Transação bancária aninhada

DECSI/ICEA UFOP

8

a.withdraw(10)

c.deposit(10)

b.withdraw(20)

d.deposit(20)

Cliente A

B

C

T1

T2

T3

T4

T

D

X

Y

Z

T = openTransactionopenSubTransaction

a.withdraw(10);

closeTransaction

openSubTransactionb.withdraw(20);

openSubTransactionc.deposit(10);

openSubTransactiond.deposit(20);

Coordenando uma Transação distribuída

DECSI/ICEA UFOP

9

..

AgênciaZ

AgênciaX

participante

participante

C

D

Cliente

AgênciaY

B

A

participantejoin

join

join

T

a.withdraw(4);

c.deposit(4);

b.withdraw(3);

d.deposit(3);

openTransaction

b.withdraw(T, 3);

closeTransaction

T = openTransactiona.withdraw(4);c.deposit(4);b.withdraw(3);d.deposit(3);

closeTransaction

Note: O Coordenador é um dos servidores, ex. AgênciaX

Protocolos de confirmação atômica• 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

DECSI/ICEA UFOP

13


• 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

DECSI/ICEA UFOP

14

Por quê é inadequado?


• Protocolo de confirmação de uma fase:

DECSI/ICEA UFOP

15

Por quê é inadequado?

Não permite que um servidor tome uma decisão unilateral de cancelar uma transação

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

DECSI/ICEA UFOP

16

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.

DECSI/ICEA UFOP

17

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

DECSI/ICEA UFOP

18

Comunicação no 2PC

DECSI/ICEA UFOP

19

canCommit?

Yes

doCommit

haveCommitted

Coordenador

1

3

(waiting for votes)

committed

done

prepared to commit

passo

Participante

2

4

(uncertain)

prepared to commit

committed

estadopassoestado

Comunicação no 2PC

DECSI/ICEA UFOP

20

canCommit?

Yes

doCommit

haveCommitted

Coordenador

1

3

(waiting for votes)

committed

done

prepared to commit

passo

Participante

2

4

(uncertain)

prepared to commit

committed

estadopassoestado

Quantas mensagens são necessárias?

2PC: Número de Mensagens Trocadas• 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 msghaveCommited

DECSI/ICEA UFOP

21

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

DECSI/ICEA UFOP

22

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

DECSI/ICEA UFOP

23


• 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.

DECSI/ICEA UFOP

24


• 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

DECSI/ICEA UFOP

25

Uma variante descentralizada do 2PC

• 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?

DECSI/ICEA UFOP

26

Uma variante descentralizada do 2PC

• 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 (N1) 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 aoinvés de 3N

DECSI/ICEA UFOP

27

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

DECSI/ICEA UFOP

28

Microsoft Transaction Server (MTS)

Ap lic ação

Ap lic ação

Ap lic ação

M ic r o s o f t T r an s ac tio n S er v er

C lien te

C lien te

C lien te

T er m in a isT e le f ô n ic o s

C lien tes

D is tr ib u ted T r an s ac tio n C o o r d in a to 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)

DECSI/ICEA UFOP

29

Padrões para Transações Distribuídas• 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

DECSI/ICEA UFOP

30

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.

DECSI/ICEA UFOP

31

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

• Travamento

• Ordenação por carimbo de tempo

• Controle de concorrência otimista

DECSI/ICEA UFOP

32


• Travamento

DECSI/ICEA UFOP

33


• Travamento

DECSI/ICEA UFOP

34


• 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

DECSI/ICEA UFOP

35


• 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

DECSI/ICEA UFOP

36


• 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

DECSI/ICEA UFOP

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

• Problema• Pode levar a um impasse quando quando dois servidores começarem transações simultaneamente

DECSI/ICEA UFOP

38


• Controle de concorrência otimista

DECSI/ICEA UFOP

39

Nenhum servidor poderá

confirmar, porque um está esperando a

confirmação do outro

Deadlocks (impasses) distribuídos

DECSI/ICEA UFOP

40

• 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


DECSI/ICEA UFOP

41

• Grafo de espera (Waitfor 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


• Travamento

DECSI/ICEA UFOP

42

U V W

d.deposit(10) lock D

b.deposit(10) lock B

a.deposit(20) lock A at Y

at X

c.deposit(30) lock C

b.withdraw(30) wait at Y at Z

c.withdraw(20) wait at Z

a.withdraw(20) wait at X


DECSI/ICEA UFOP

43

D

Esperapor

Esperapor

Mantido por

Mantido por

BEsperapor

Mantido por

X

Y

Z

Mantido por

W

UV

AC


DECSI/ICEA UFOP

44

D

Esperapor

Esperapor

Mantido por

Mantido por

BEsperapor

Mantido por

X

Y

Z

Mantido por

W

UV

AC W

V

U

Formação do ciclo

Exercício

Construa o grafo de espera por das transações abaixo. Está ocorrendo um impasse?

DECSI/ICEA UFOP

45

Detecção de impasses

• Ignorar• Deixe que o programador da aplicação lide com ele, ou reinicie 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, detectamnos monitorando formação de ciclos no WFG e rompendoos. Exigem suporte em tempo de execução

DECSI/ICEA UFOP

46

Detecção de impasse centralizada

• Servidor assume papel detector de impasse global

• Cada servidor envia seu grafo de espera local

DECSI/ICEA UFOP

47

X

T U

Y

V TT

U V

Grafo de espera local Grafo de espera local Detector de impasse global


• Por que a solução centralizada não é uma boa idéia?

DECSI/ICEA UFOP

48


• 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

DECSI/ICEA UFOP

49

Problema do impasse fantasma

• Detecta um impasse que não é impasse

DECSI/ICEA UFOP

50



DECSI/ICEA UFOP

51

Considere a seguinte mudança:U Libera objeto em XU Solicita objeto mantido em V servidor Y

X

T U

Y

V T



DECSI/ICEA UFOP

52

Considere a seguinte mudança:U Libera objeto em XU Solicita objeto mantido em V servidor Y

X

T U

Y

V TT

U V

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 datransação

DECSI/ICEA UFOP

53

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

DECSI/ICEA UFOP

54

Caminhamento pelas arestasO servidor X inicia a detecção, enviando a mensagem de sondagem <W → U> para o servidor de B (servidor Y).

DECSI/ICEA UFOP

55

Esperapor

Esperapor

Mantido por

Mantido por

BEsperapor

Mantido por

X

Y

Z

W

UV

AC

Caminhamento pelas arestasO servidor X inicia a detecção, enviando a mensagem de sondagem <W → U> para o servidor de B (servidor Y).

DECSI/ICEA UFOP

56

Esperapor

Esperapor

Mantido por

Mantido por

BEsperapor

Mantido por

X

Y

Z

W

UV

AC

Caminhamento pelas arestas• 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>.

• Ele nota que V está esperando por C no servidor Z.

• mensagem de sondagem é encaminhada para o servidor Z.

DECSI/ICEA UFOP

57

Esperapor

Esperapor

Mantido por

Mantido por

BEsperapor

Mantido por

X

Y

Z

W

UV

AC

Caminhamento pelas arestas• 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>.

• Ele nota que V está esperando por C no servidor Z.

• mensagem de sondagem é encaminhada para o servidor Z.

DECSI/ICEA UFOP

58

Esperapor

Esperapor

Mantido por

Mantido por

BEsperapor

Mantido por

X

Y

Z

W

UV

AC

Caminhamento pelas arestas• 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>.

DECSI/ICEA UFOP

59

Esperapor

Esperapor

Mantido por

Mantido por

BEsperapor

Mantido por

X

Y

Z

W

UV

AC

Caminhamento pelas arestas• 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.

DECSI/ICEA UFOP

60

Esperapor

Esperapor

Mantido por

Mantido por

BEsperapor

Mantido por

X

Y

Z

W

UV

ACImpassedetectado


• 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.

DECSI/ICEA UFOP

61


• 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

DECSI/ICEA UFOP

62


• 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.

DECSI/ICEA UFOP

63

Prioridades de transação

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

DECSI/ICEA UFOP

64


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

DECSI/ICEA UFOP

65

(a) Situação inicial (b) Detecção iniciada por T (c) Detecção iniciada por W

U

T

V

W

Espera por

Espera por

V

W

U

T

T U W VT U W

T UEspera por

UV

T

W

W V TW V T U

W VEspera por

→

→ →→ →

→ →→ → →

→


• Prover prioridade para transações• T > U > V > W• Ao detectar ciclo,W é cancelada

DECSI/ICEA UFOP

66

(a) Situação inicial (b) Detecção iniciada por T (c) Detecção iniciada por W

U

T

V

W

Espera por

Espera por

V

W

U

T

T U W VT U W

T UEspera por

UV

T

W

W V TW V T U

W VEspera por

→

→ →→ →

→ →→ → →

→

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?

DECSI/ICEA UFOP

67

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

DECSI/ICEA UFOP

68

U V

leia(A)

escreva(A)

W

escreva(A)escreva(B)escreva(C)

leia(A)

leia(B)

leia(C)

Questões

DECSI/ICEA UFOP

Vinícius Fernandes Soares Mota


69

transações distribuídas - brhott.files.wordpress.com · • se f or sim, cada part icipante en...

Documents