transacções em sistemas...
Post on 16-Dec-2018
216 Views
Preview:
TRANSCRIPT
1
Page 1
Departamento de Engenharia Informática
Transacções em Sistemas
Distribuídos
Departamento de Engenharia Informática
Função efectuarPagamento do PagAmigo
Primeira solução
efectuarPagamento(clienteA, clienteB, Montante)
{
bancoA.LerSaldo (contaA, SaldoA);
bancoB.LerSaldo (contaB, SaldoB);
bancoA.ActualizarSaldo (contaA, saldoA-Montante);
bancoB.ActualizarSaldo (contaB, saldoB+Montante);
}
Quais os problemas desta solução?
2
Page 2
Departamento de Engenharia Informática
Função efectuarPagamento do PagAmigo
Solução com Transacção Atómica
efectuarPagamento(clienteA, clienteB, Montante)
{
beginTransaction;
bancoA.LerSaldo (contaA, SaldoA);
bancoB.LerSaldo (contaB, SaldoB);
bancoA.ActualizarSaldo (contaA, saldoA-Montante);
bancoB.ActualizarSaldo (contaB, saldoB+Montante);
commit;
}
Departamento de Engenharia Informática
Função efectuarPagamento do PagAmigo
Outra solução com Transacção Atómica
efectuarPagamento(clienteA, clienteB, Montante)
{
beginTransaction;
bancoA.LerSaldo (contaA, SaldoA);
bancoB.LerSaldo (contaB, SaldoB);
if (saldoA < montante)
abort;
else {
bancoA.ActualizarSaldo (contaA,saldoA-Montante);
bancoB.ActualizarSaldo
(contaB, saldoB + Montante);
commit;
}
}
Em que situações pode a transação abortar?
3
Page 3
Departamento de Engenharia Informática
Transacções Atómicas Locais
Revisão da cadeira de Bases de Dados
Departamento de Engenharia Informática
Sistema Transaccional
Aplicações
Sistema Transaccional
IniciarConfirmarAbortar
LerEscrever
Sistema Operativo
Hardware
Aplicações
4
Page 4
Departamento de Engenharia Informática
Transação
• Uma transação é uma sequência de leituras e escritas a objetos partilhados com outras transações
12/13 Sistemas Distribuídos 7
Departamento de Engenharia Informática
Propriedades das transacções – ACID
Atomicidade
• Transacção ou se executa na totalidade ou não se executa
• O sistema tem de ser capaz de repor a situação inicial no caso da transacção abortar (por inciativa do programador ou falha do sistema)
5
Page 5
Departamento de Engenharia Informática
Propriedades das transacções – ACID
Consistência
• Uma transação é uma transformação correta do estado.
– Supõe-se que o conjunto das ações da transação não viola nenhuma das regras de integridade associadas ao estado
– Isto requer que a transação seja um programa correto
12/13 Sistemas Distribuídos 9
Departamento de Engenharia Informática
Propriedades das transacções – ACID
Isolamento
• Normalmente definida pela condição de serializabilidade (serial-equivalence):
– Considere uma execução concorrente de leituras e escritas de múltiplas transações
– A execução concorrente diz-se serializável quando existe uma execução sequencial (das mesmas transações) equivalente à execução concorrente
• Ou seja, cujas leituras devolvam o mesmo valor e objetos escritos ficam com mesmo valor em ambas as execuções (concorrente e sequencial)
6
Page 6
Departamento de Engenharia Informática
Propriedades das transacções – ACID
Isolamento
Esta execução concorrente é serializável?Se sim, qual a execução sequencial equivalente?
Departamento de Engenharia Informática
Propriedades das transacções – ACID
Isolamento
Esta execução concorrente é serializável?Se sim, qual a execução sequencial equivalente?
7
Page 7
Departamento de Engenharia Informática
Propriedades das transacções - ACID
• Durabilidade
– os resultados de uma transacção que confirmou permanecem depois de esta acabar e sobrevivem ao conjunto de faltas expectáveis
– Solução: resultados escritos em memória estável e com capacidade de recuperação das faltas dos discos que forem toleradas.
Atomic, Consistent, Isolated, Durable
Departamento de Engenharia Informática
Como gerir execuções concorrentes de
transações?
12/13 Sistemas Distribuídos 18
8
Page 8
Departamento de Engenharia Informática
Controlo de concorrência
• Solução pessimista (“pedir licença”)
– Pressupõe que os conflitos são frequentes e obriga à prévia sincronização de todos os acessos.
Leitura Escrita
Leitura Compatível Conflito
Escrita Conflito Conflito
Trincos de Leitura/Escrita
Departamento de Engenharia Informática
Controlo de concorrência pessimista
Sincronização em 2 fases estrita
• Cada objeto/grupo de objetos geridos por um trinco de leitura/escrita
• Sincronização em duas fases estrita (strict two phase locking):
– À medida que a transação vai lendo/escrevendo sobre objetos, vai adquirindo sucessivamente os respetivos trincos (primeira fase)
– Na terminação da transação (commit ou abort), liberta os trincos (segunda fase)
9
Page 9
Departamento de Engenharia Informática
Controlo de concorrência pessimista
Sincronização em 2 fases estrita: exemplo
12/13 Sistemas Distribuídos 25
Departamento de Engenharia Informática
Interblocagem
• A sincronização com trincos pode conduzir a interblocagem obrigando a mecanismos para a resolver:
– Prevenção (ex: ordem parcial sobre trincos, adquirir todos os trincos pela mesma ordem, caso sejam conhecidos de antemão)
• Problema: na maior parte das vezes não é possível, e origina quebra de desempenho
– Detecção da interblocagem
• usando temporizador – método simples , pouco preciso, mas adequado
• ou grafo com história de sincronização das transacções (indica recursos protegidos por trincos e as transacções que esperam por eles)
• e obrigando a abortar as transacções
10
Page 10
Departamento de Engenharia Informática
Interblocagem: exemplo
Departamento de Engenharia Informática
Isolamento (cont.)
• Solução pessimista (“pedir licença”)– Pressupõe que os conflitos são frequentes e obriga à prévia
sincronização de todos os acessos.
• Solução optimista (“pedir desculpa”)– Considera que os conflitos são raros– Na confirmação verifica a existência de conflitos– Obriga a manter carimbos temporais das actualizações para
poder determinar quando há um conflito e nesse caso abortar as transacções envolvidas
11
Page 11
Departamento de Engenharia Informática
Solução optimista
Departamento de Engenharia Informática
Recuperação das falhas de paragem
12/13 Sistemas Distribuídos 30
12
Page 12
Departamento de Engenharia Informática
Recuperação das Falhas de Paragem
• A recuperação tem de basear-se na existência de informação redundante.
• A política de recuperação é condicionada pela política de actualização dos dados:– actualização directa (in-place updating) - as escritas
são efectuadas sobre os dados reais residentes nos suportes magnéticos.
– actualização em versões (out-of-place updating) -são criadas novas versões dos dados, preservando os valores originais.
Departamento de Engenharia Informática
Actualização Directa
• A política de recuperação depende da forma como é actualizada a cache.
• No momento da confirmação:– Limpar a cache (cache flush) na altura da confirmação
– ou
– Manter os dados em cache
• No momento da escrita de dados– Permitir a escrita de dados de transacções activas na memória
persistente.
– ou
– Manter os dados das transacções activas apenas em memória volátil (gestão assíncrona)
• Necessário manter informação redundante no ficheiro de diário (log)
• A informação a manter depende destas decisões
13
Page 13
Departamento de Engenharia Informática
Write Ahead Logging
• A gestão assíncrona da cache é sempre mais eficiente e permite gerir melhor a memória volátil.
• Neste caso o diário tem de conter informação para fazer e desfazer o resultado das operações (redo/undo)
• É também necessário garantir que a
informação é escrita no diário antes da
modificação das páginas (write-ahead logging)
Departamento de Engenharia Informática
Actualização em Versões:
Páginas sombra (Shadow pages)
• Copia-se inicialmente a tabela de páginas de modo a poder reconstituir a versão
• Se a transacção confirmar é necessário comutar atomicamente o ficheiro no directório
• A dispersão de ficheiros pelo disco e a proliferação de versões são limitações deste método.
14
Page 14
Departamento de Engenharia Informática
Gestão do Diário
• Aspectos a considerar
– Registos: físicos ou lógicos
– Robustez do diário a falhas dos discos
– Escrita síncrona/assíncrona dos registos
– Redução do espaço do ficheiro do diário através de marcas de recuperação (checkpointing)
– Faltas durante a recuperação
Departamento de Engenharia Informática
Exemplo de Diário
15
Page 15
Departamento de Engenharia Informática
Arquitectura do Sistema Transaccional
12/13 Sistemas Distribuídos 37
Departamento de Engenharia Informática
Arquitectura do Sistema Transaccional
• Gestor de Sincronização – é responsável pela sincronização de todos os acessos aos dados
manipulados pelas transacções. Deve, portanto, ser chamado em todas as situações de leitura ou escrita para gerir os trincos associados aos objectos e tratar os problemas de interblocagem.
• Gestor da cache – gere a relação entre os discos e a memória volátil. A optimização é
obtida, evitando tanto quanto possível executar escritas síncronas e agrupando escritas em bloco para o disco.
• Gestor do Diário (Log) – gere a informação redundante. Esta informação é mantida numa lista
que regista as operações relevantes de actualização da estrutura de dados.
– O diário é na realidade um ficheiro escrito sequencialmente, o que garante que a informação é registada segundo a ordem de execução das operações.
16
Page 16
Departamento de Engenharia Informática
Arquitectura do Sistema Transaccional
• Gestor da recuperação – recupera o sistema para um estado consistente
sempre que uma falta for detectada. A gestão da cache, a informação escrita no diário e o algoritmo de recuperação estão intimamente relacionados
• Gestor da memória estável – garante a persistência dos dados.
– fornece uma abstracção de memória persistente, capaz de manter a informação mesmo quando existem falhas dos discos.
Departamento de Engenharia Informática
Transacções Atómicas
Distribuídas
17
Page 17
Departamento de Engenharia Informática
Transacções distribuídas:
Modelo de Faltas
• Distribuição implica lidar com:– Falta dos discos
– Falta das máquinas
– Falta das comunicações
• O modelo de faltas tem de considerar diversas simplificações
– Sistemas: apenas faltas de paragem não se consideram faltas bizantinas
– Modelo funciona num sistema assíncrono (tempo de propagação das mensagens pode ser arbitrariamente longo)
– Faltas temporárias de comunicação toleradas pelos protocolos de transporte, não se consideram faltas permanentes da rede (partições)
Faltas de Paragem
Departamento de Engenharia Informática
Papel do Coordenador
..
BranchZ
BranchX
participant
participant
C
D
Client
BranchY
B
A
participantjoin
join
join
T
a.withdraw(4);
c.deposit(4);
b.withdraw(3);
d.deposit(3);
openTransaction
b.withdraw(T, 3);
closeTransaction
T = openTransaction
a.withdraw(4);
c.deposit(4);b.withdraw(3);d.deposit(3);
closeTransaction
Note: the coordinator is in one of the servers, e.g. BranchX
Só quando é chamado closeTransaction se executa o protocolo para confirmar ou abortar a transacção atomicamente
18
Page 18
Departamento de Engenharia Informática
Protocolo de confirmação em
duas fases
Two-Phase Commit (2PC)
Departamento de Engenharia Informática
Transacções distribuídas:
Problemas a considerar
• A tomada de decisão de abortar ou confirmar uma transacção é o problema mais complexo a resolver
• Requer um consenso entre os diferentes participantes numa transacção distribuída
19
Page 19
Departamento de Engenharia Informática
Protocolo (sem falhas)
canCommit?
Yes
doCommit
haveCommitted
Coordinator
1
3
(waiting for votes)
committed
done
prepared to commit
step
Participant
2
4
(uncertain)
prepared to commit
committed
statusstepstatus
Departamento de Engenharia Informática
Protocolo (sem falhas)CoordenadorEnvia PREPARAR a todos
if (todos votaram sim)decisãocoord = commitEnvia COMMIT a todos
elsedecisãocoord = abortEnvia ABORT a todos que votaram sim
exit
Participante i
Envia votoi ao coord.if (votoi == não)
decisãoi = abortexit
if (recebe ABORT)decisãoi = abort
elsedecisãoi = commit
exit
20
Page 20
Departamento de Engenharia Informática
Interacção Cliente-Coordenador
API do Coordenador
openTransaction() -> trans;
starts a new transaction and delivers a unique TID trans. This
identifier will be used in the other operations in the transaction.
closeTransaction(trans) -> (commit, abort);
ends a transaction: a commit return value indicates that the
transaction has committed; an abort return value indicates that
it has aborted.
abortTransaction(trans);
aborts the transaction.
Departamento de Engenharia Informática
Operações no 2PC
canCommit?(trans)-> Yes / No
Call from coordinator to participant to ask whether it can commit a
transaction. Participant replies with its vote.
doCommit(trans)
Call from coordinator to participant to tell participant to commit its part of a
transaction.
doAbort(trans)
Call from coordinator to participant to tell participant to abort its part of a
transaction.
haveCommitted(trans, participant)
Call from participant to coordinator to confirm that it has committed the
transaction.
getDecision(trans) -> Yes / No
Call from participant to coordinator to ask for the decision on a transaction
after it has voted Yes but has still had no reply after some delay. Used to
recover from server crash or delayed messages.
21
Page 21
Departamento de Engenharia Informática
Transacções distribuídas:2PC - diagramas de interacções
2008/2009 José Alves Marques, Rodrigo Rodrigues e João Barreto
Pronto?
W diário
Envia mensagem
W diário
Envia mensagem
Espera
W diário
Envia mensagem
diário
Todas?
Termina transacção
W diário
Envia mensagem
Espera
W diárioEnvia mensagem
Todas?
Espera
diário
prepararbegincommit
end
Um Não?
W diárioEnvia mensagem
abort
Abortar?
Espera
W diário
abort
ready
abort
S
S
S
S
commit
commitS
Departamento de Engenharia Informática
Logs do protocolo
• Assume um diário (log) persistente com escritas atómica
Evento Info. escrita no log Instante da escrita
Coord. envia PREPARAR Begin commit Em paralelo com envio
Participante vota sim Sim Antes de enviar voto
Participante vota não Não Em paralelo com envio
Coord. decide commit Commit Antes de enviar commit
Coord. decide abort Abort Em paralelo com envio
Particip. recebe decisão Commit ou Abort Em paralelo com decisão
22
Page 22
Departamento de Engenharia Informática
Diagrama de Estados - Coordenador
inicial
espera
abort commit
temporizador
expirou
Input: -
Output: Envia PREPARAR a todos
Input: Recebe SIM de todos
Output: Envia COMMIT a todos
Input: Recebe um ou mais NÃOOu temporizador expira
Output: Envia ABORT a todos
A detecção de faltas de
paragem é por timeout
coordenador pode logo tomar a
decisão de abortar ou tentar
contactar novamente os
participantes
Departamento de Engenharia Informática
Diagrama de Estado - Participante
inicial
Preparado
abort commit
Input: Recebe PREPARAR e votoi == simOutput: Envia sim ao coordenador
Input: Recebe COMMIT
Input: (Recebe PREPARARe votoi == não)
Ou temporizador expira
Output: Envia não ao coord.
Input: Recebe
ABORT
temporizador
expirou
Executar protocolo de
terminação
23
Page 23
Departamento de Engenharia Informática
Transacções distribuídas:
Tolerância a faltas no 2PC
• Não recepção de mensagens– Detectadas com um temporizador no Coordenador ou nos
Participantes
• Timeout no Coordenador– Estado Esperar
• Não pode confirmar unilateralmente a transacção
• Mas pode unilateralmente optar por abortar a transacção
– Se considerar que o atraso na resposta se deve a uma falta
– Estados Abortar e Confirmar• O Coordenador não pode terminar a transacção
– Tem que receber a confirmação de todos os Participantes
• Pode repetir a mensagem global previamente enviada
2008/2009 José Alves Marques, Rodrigo Rodrigues e João Barreto
Departamento de Engenharia Informática
Transacções distribuídas:Tolerância a faltas no 2PC
•Timeout num Participante– Estado Inicial
•Pode optar unilateralmente por abortar a transacção
•Ou verifica o estado do Coordenador
– Estado Preparado•Não pode progredir
–Depende da decisão do Coordenador que já influenciou
–A transacção fica activa e bloqueada até se saber essa decisão
•Se os Participantes interactuarem é possível evoluir»Obtendo a decisão do coordenador que chegou aos outros Participantes
•Falha permanente do Coordenador (apenas)
–Protocolos de eleição de um novo Coordenador
2008/2009 José Alves Marques, Rodrigo Rodrigues e João Barreto
24
Page 24
Departamento de Engenharia Informática
Recuperação depois de falta de paragem
• Recuperação do Coordenador
– Estados Inicial e Esperar• Repete as mensagens de Preparação para obter
novamente a votação dos TMs
– Estado Confirmar ou Abortar• Se ainda não recebeu todas as confirmações repete o
envio da mensagem global previamente enviada
• Recuperação de um Participante
– Estado Inicial• Aborta unilateralmente a transacção
– Estado Preparado• Reenvia o seu voto (sim ou não) para o Coordenador
Departamento de Engenharia Informática
Transacções distribuídas:
Problemas do 2PC
• O protocolo é bloqueante:
– Obriga os Participantes a esperar pela recuperação do Coordenador
– E vice-versa
• Não é possível fazer uma recuperação totalmente independente
• Há alternativas não-bloqueantes
– Sob modelos de faltas mais restritivos
– Normalmente muito mais complexas (ex. 3PC)
25
Page 25
Departamento de Engenharia Informática
Arquitectura X/OpenTransacções distribuídas
12/13 Sistemas Distribuídos 68
Departamento de Engenharia Informática
Consórcio X/OPEN
• Esforço de normalização dos protocolos e interfaces para interligação de sistemas de informação heterogéneos
– DTP (Distributed Transaction Processing)
– Muito influenciado pela norma de facto que constituiu a arquitectura SNA da IBM e a sua interface LU 6.2
26
Page 26
Departamento de Engenharia Informática
Arquitectura X/Open
• Gestores de Recursos - RM (resource manager) – Armazenam os dados
• Em BDs relacionais, sistemas de ficheiros com actualizações atómicas, etc.
– Garantem localmente as propriedades das transacções
• Monitores Transaccionais - TM (transaction managers) – Coordenadores dos RM
• Através da interface XA
– Execução dos protocolos de iniciação/terminação das transacções
– Um em cada máquina (ou em cada grupo de máquinas)
Departamento de Engenharia Informática
Transacções distribuídas X/Open
Aplicação
TM
RM
IniciarConfirmar
Abortar
LerEscrever
Associar
PrepararConfirmar
Abortar
27
Page 27
Departamento de Engenharia Informática
Transacções distribuídas:
X/Open (com distribuição)
Aplicação
TM
RM
SC
TM
RM
SC
Departamento de Engenharia Informática
Transacções distribuídas:
X/Open
• Uma aplicação inicia uma transacção– Invoca o TM local que lhe atribui um identificador único
• A aplicação contacta em seguida os RMs– Para efectuar as operações de leitura e escrita– Usa o identificador da transacção
• Os RMs associam-se à transacção– Quando um RM recebe a primeira operação relacionada com uma
transacção desconhecida contacta o TM local para se associar à transacção
• A transacção termina– Todos os TM envolvidos executam um protocolo de consenso
distribuído
28
Page 28
Departamento de Engenharia Informática
TP-Monitor components (generic)
persistentqueue
Application
program
Recovery
manager
Log
manager
database
persistentqueue
data
dictionary
context
database
program
library
client
external
resource
manager
client
client
Pre
sen
tati
on
ser
vic
es
Au
then
tica
tion
Administration and operations interfaces
Monitor services
scheduling load balancing
server classqueues
contextbinding
internal
resource
managers
From “Transaction Processing” Gray&Reuter. Morgan Kaufmann 1993
Departamento de Engenharia Informática
Monitor Transaccional Tuxedo da BEA
Application Program (AP)
Transaction
Manager (TM)
TX API
XA
+
XA
XAP-TP
C-ISAM or SQL or
Other
Communication
Resource Manager
(CRM)
X/Open DTP Reference Model
OSI-TP
Tuxedo System in DTP Model
C, COBOL, 4GLs or CASE appllications
System /T
Communications
TX API
XA+
XA
XAP-TP
OSI-TP
Unix System V
System /T
XATMI or
CPI-C or
TxRPC or
Peer-toPeer
XATMI or
TxRPC
Resource
Manager (RM)
XA-Compliant
Resouce Manager
SQL
top related