View
219
Download
0
Category
Preview:
Citation preview
Módulo 7Transacciones Distribuidas
Facultad de IngenieríaDepartamento de Informática
Universidad Nacional de la Patagonia “San Juan Bosco”
Sistemas Distribuidos
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
El modelo transaccionalLa actualización de una cinta maestra es tolerante a
las fallas.Inventario
previo
Actualización
del día
Nuevo
inventario
Cinta
de salida
Cintas
de entrada Computadora
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
a) Commit de una Transacción para reservar tres vuelos
b) Aborto de la transacción cuando el tercer vuelo no esta disponible
BEGIN_TRANSACTIONreserve BUE -> JFK;reserve JFK -> Nairobi;reserve Nairobi -> El Cabo;
END_TRANSACTION(a)
BEGIN_TRANSACTIONreserve BUE -> JFK;reserve JFK -> Nairobi;reserve Nairobi -> El Cabo full =>
ABORT_TRANSACTION(b)
El modelo transaccional
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
¿Qué es una transacción?
� Base de datos
� Sistema de archivos
� Objetos
� Cliente
Transacciones Distribuidas
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Transacciones Atómicas
Propiedades
Serializabilidad: Las transacciones concurrentes no interfieren unas con otras.
Atomicidad: Desde el mundo exterior la transacción es indivisible. (todo o nada).
Permanencia: Una vez que la transacción se ejecuta los cambios son permanentes.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Tipos de Transacciones
� Planas
� Anidadas
Transacciones Distribuidas
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
T : transacción de nivel superior
T1= abreSubTransacción T2= abreSubTransacción
abreSubTransacción abreSubTransacciónabreSubTransacción
abreSubTransacción
T1 : T2 :
T11 : T12 :
T211:
T21 :
prov.commit
prov. commit
abort
prov. commitprov. commit
prov. commit
commit
Transacciones Anidadas
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Se usa el término transacciones distribuidas para referirse a transacciones planas o anidadas que acceden a objetos administrados por múltiples servidores.
Cuando una transacción distribuida llega a su fin, la propiedad de atomicidad de las transacciones requiere que todos los servidores involucrados produzcan el commit (consumación) de la transacción o todos ellos la abortan.
La manera en que el coordinador logra ésto, depende del protocolo elegido.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Una transacción anidada Una transacción distribuida
Transacción anidada Transacción distribuida
subtransacción subtransacción subtransacción subtransacción
BD aerolíneas BD hotelBD distribuida
Dos BDs diferentes
(independientes)
Dos partes fisicamente
separadas de la misma DB
Transacciones distribuidas
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Transacciones distribuidas planas y anidadas
En una transacción plana, el cliente hace requeri-mientos a más de un servidor. Cada transacción accede a los objetos en los servidores secuencial-mente.
El cliente de la transacción plana espera completar todos sus requerimientos antes de pasar a la próxima.
En una transacción anidada, la transacción de mayor nivel puede abrir subtransacciones y, a su vez cada subtransacción puede abrir otras en niveles más bajos de anidamiento.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Transacción plana Transacción anidada
Cliente
X
Y
Z
X
Y
M
NT1
T2
T11
Cliente
P
T
T12
T21
T22
T
T
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Ejemplo de una transacción bancaria anidada
Sea una transacción distribuida donde el cliente transfiere $10 de la cuenta A a C y $20 de B a D.
Las cuentas A y B están separadas en servidores X e Y y las cuentas C y D están en el servidor Z.
Si la transacción se estructura como un conjunto de cuatro transacciones anidadas, los cuatro requerimientos ( dos depósitos y dos retiros) pueden correr en paralelo y el efecto total es lograr mayor rendimiento que una transacción simple ejecutando las cuatro operaciones secuencialmente.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
a.retiro(10)
c.depósito(10)
b.retiro(20)
d.depósito(20)
Cliente A
B
C
T1
T2
T3
T4
T
D
X
Y
Z
T = abreTransacción
abreSubTransacción a.retiro(10);
abreSubTransacción b.retiro(20);
abreSubTransacción c.depósito(10);
abreSubTransacción d.depósito(20);
cierraTransacción
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
El coordinador de una transacción distribuidaLos servidores que ejecutan requerimientos que son parte
de una transacción distribuida necesitan poder comunicarse con otros para coordinar sus acciones cuando la transacción commits.
Un clienta comienza la transacción enviando un requerimiento abreTransacción a un coordinador en algún servidor.
El coordinador que es contactado lleva adelante la abreTransacción y retorna un identificador al cliente (éste debe ser único).
El coordinador que abre la transacción se convierte en el coordinador para la transacción distribuida.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Cada uno de los servidores que administra un objeto acce-dido por la transacción es un participante en la transac-ción, se llamará participante.
Los participantes son responsables en la cooperación con el coordinador para llevar adelante el protocolo de commit de la transacción.
Durante el progreso de la transacción, el coordinador re-gistra los participantes y éstos registran al coordinador.
Ejemplo : Un cliente cuya transacción (plana) involucra las cuentas A, B, C y D en los servidores SucX, SucY y SucZ.
La transacción T del cliente transfiere $3 de la cuenta B a D y $4 de A a C.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Nota: el coordinador está en uno de los servidores, p.e. SucX
..
SucZ
C
D
Cliente
SucY
B
A
participantejoin
join
join
T
a.retiro(4);
c.depósito(4);
d.depósito(3);
abreTransaction
b.depósito(T,3);
cierraTransacción
SucX
participante
participante
b.retiro(3);T=abreTransacción
a.retiro(4);
c.depósito(4);
b.retiro(3);
d.depósito(3);
cierraTransacción
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
a) Indice y bloques de disco (3) de un archivo
b) La situación luego que una transacción ha modificado el bloque 0 y agregado el bloque 3
c) Luego del commit
Indice
Cuadros libres
Indice
original
Espacio
privado
Implementación - Espacio privado
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
a) Una transacción
b) – d) La bitácora luego de ejecutar la sentencia
x = 0;y = 0;BEGIN_TRANSACTION;
x = x + 1;y = y + 2x = y * y;
END_TRANSACTION;(a)
Bitácora
[x = 0 / 1]
(b)
Bitácora
[x = 0 / 1][y = 0/2]
(c)
Bitácora
[x = 0 / 1][y = 0/2][x = 1/4]
(d)
Escritura con bitácora
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Protocolos de Commit atómicos
Una transacción llega a su fin cuando los requeri-mientos del cliente han llegado a commit o abort.
Los protocolos pueden ser:
�Commit de una fase atómico
�Commit de dos fases atómico
�Commit de tres fases atómico
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Commit de una fase atómico
Una manera simple de completar una transacción en forma atómica por el coordinador es comunicar el requerimiento de commit o abort a todos los participantes de la transacción y mantenerse repitiendo el requerimiento hasta que todos ellos tengan conocimiento de que todos lo han llevado a cabo.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
InicialDesea
commitCommited
Abortado
Send
vote-commitReceive
commit
Send
vote-abort
o
Receive
abort
Receive
abort
Participante
Estados de commit de una sola fase (participante)
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Commited
Abortado
Inicial Debe commit
Debe abortar
Receive all
vote-commit
Send
commit
Receive any
vote-abort
Send
abortCoordinador
Estados de commit de una sola fase (coordinador)
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Bloqueo de transacciones
Pueden ocurrir cuando hay fallas en la red.
La situación se puede dar con una transacción que no ha fallado sin embargo está bloqueada esperando un commit o abort.
¿Qué decisiones podría tomar Ti cuando “detecta”(timeout) que está bloqueada?
commit sin autorización
abortar.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Commit de dos fases atómicoHay voto seguido de decisión.
Se reduce la posibilidad de bloqueo.
Diferencia con el anterior: si la transacción no recibe respuesta (timeout) entra en un estado de recuperación.
Para evitar el bloqueo la Ti hace un help-me a los demás participantes.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Cuando un participante recibe un help-me:
Un participante en estado committed replica commit. Lo hace en forma segura porque ya recibió el commit del coordinador.
Un participante en estado abortado envía abort porque ya sabe que la transacción va a abortar.
Si el participante no ha votado aún (en estado inicial) puede ayudar a resolver el problema si decide arbitrariamente abortar (envía abort y vote-abort)
Si el participante está en esperando commit no puede resolver el problema, no responde.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Otra modificación es que el coordinador envía un begin-vote a todos los participantes.
Si la recuperación del estado desea commit es necesaria, cada transacción debe o necesita conocer los restantes participantes.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Timeout
Recuperar
DecidiendoInicial Deseacommit
Commited
Abortado
Send
vote-commit
Receive
commitSend
vote-abort
Receive
abort
Receive
abort
Receive
commit
Timeout
Send
help-me
Bloqueado
Receive
begin-vote
Estados de commit de dos fases (participante)
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Commited
Abortado
Inicial Debe commit
Debe abortar
Receive all
vote-commitSend
commitTimeout o
Receive any
vote-abort
Send
abort
Esperando
Send
begin-vote
Estados de commit de dos fases (coordinador)
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
T : transacción de nivel superior
T1= abreSubTransacción T2= abreSubTransacción
abreSubTransacción abreSubTransacciónabreSubTransacción
abreSubTransacción
T1 : T2 :
T11 : T12 :
T211:
T21 :
prov.commit
prov. commit
abort
prov. commitprov. commit
prov. commit
commit
Commit para transacciones Anidadas
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Commit de tres fases atómico
Un participante no commit hasta que todos los participantes commit y además hasta que no sabe que todos los participantes también lo saben.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Transacciones
BEGIN_TRANSACTION
END_TRANSACTION
Administrador
transacciones
Planificador
Administrador
datos
READ / WRITE
LOCK / RELEASE u
Operaciones con
estampillas de tiempo
Ejecuta read / write
Organización general de administradores para manejo de transacciones.
Control de Concurrencia
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Administrador
transacciones
Planificador Planificador Planificador
Administrador
datos
Administrador
datos
Administrador
datos
Máquina A Máquina B Máquina C
Control de Concurrencia
Organización general de administradores para manejo de transacciones distribuidas.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Control de Concurrencia en Transacciones Distribuidas
Cada servidor administra un conjunto de objetos y es responsable de mantener la consistencia cuando son accedidos por transacciones concurrentes.
Cada servidor aplica un control de concurrencia a sus objetos.
Esto quiere decir que si la transacción T es antes que la U en el acceso conflictivo a un objeto en un servidor entonces deben ser hechas en tal orden en todos los servidores cuyos objetos son accedidos en manera conflictiva por T y U.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Locking
En una transacción distribuida un lock sobre un objeto es mantenido localmente (en el mismo servidor).
El administrador local de locks puede decidir si otorga un lock o hace que la transacción que lo requirió espere.
Sin embargo no puede liberar ningún lock mientras la transacción que los tiene no haya terminado (commit o aborto).
Cuando es usado el locking para control de concurrencia, los objetos permanecen con el lock y no están disponibles para otras transacciones durante el protocolo de commit atómico.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Dado que los administradores de locks en diferentes servidores otorgan locks independiente de los demás, es posible que diferentes servidores impongan diferente orden sobre las transacciones.
Considerese el siguiente entrelazado de las transacciones T y U en los servidores X e Y:
T U
Write(A) en X lock A
Write(B) en Y lock B
Read(B) en Y espera U
Read(A) en X espera por T
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Se tiene T antes que U en un servidor y U antes que T en el otro.
Estos órdenes diferentes pueden llevar a una dependencia cíclica entre transacciones que deriva en una situación de interbloqueo.
Cuando se detecta una condición de interbloqueo las transacciones son abortadas.
En este caso el coordinador será informado y abortará las transacciones en los participantes involucrados.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Control de Concurencia por Estampillas de Tiempo
En transacciones distribuidas se requiere que cada coordinador genere una única estampilla de tiempo global.
Esta estampilla de tiempo es dada al cliente por el primer coordinador accedido por la transacción.
La estampilla de tiempo de la transacción es pasada al coordinador de cada servidor en los cuales se realizan operaciones de la transacción.
Los servidores son conjuntamente responsables de que las transacciones distribuidas sean realizadas de manera serial.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Por ejemplo: si la versión de un objeto accedido por la transacción U llega al commit después de la versión accedida por T en un servidor, entonces si T y Uacceden al mismo objeto en otros servidores, deben llegar al commit en el mismo orden.
Para lograr el mismo orden en todos los servidores, los coordinadores deben estar de acuerdo en el ordenamiento de sus estampillas de tiempo.
Una estampilla de tiempo consiste de un par:
<estampilla de tiempo local,identificador del servidor>
Se necesita sincronización de relojes.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Cuando el ordenamiento por estampillas de tiempo es usado para el control de concurrencia los conflictos son resueltos cuando cada operación es efectuada.
Si la resolución del conflicto requiere que una transacción sea abortada, el coordinador será informado y abortarálas transacciones de todos los participantes.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas Control de Concurrencia Optimista
Cada transacción es validada antes de permitir el commit.
Una transacción distribuida es validada por una colección de servidores independientes, cada uno de los cuales valida las transacciones que acceden a sus objetos propios.
Sea las transacciones T y U entrelazadas, las cuales acceden a los objetos A y B en los servidores X e Yrespectivamente:
T URead(A) en X Read(B) en YWrite(A) Write(B)Read(B) en Y Read(A) en XWrite(B) Write(A)
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Las transacciones acceden a los objetos en el orden Tantes que U en el servidor X y U antes que T en el servidor Y.
Si se supone que T y U empiezan la validación al mismo tiempo, el servidor X valida T primero y el servidor Yvalida U primero.
Solo una transacción puede realizar la fase de validación y actualización a la vez.
En el ejemplo, cada servidor está inhabilitado de validar la otra transacción hasta que la primera haya completado.
Esto es un interbloqueo de commit.
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
Ejemplo de interbloqueo distribuido
U V Wd.deposita(10) lock D
a.deposita(20) lock A
en X
b.extrae(30) espera en Y
b.deposita(10) lock B
en Y
c.extrae(20) esperaen Z
c.deposita(30) lock Cen Z
a.extrae(20) esperaen X
Sistemas Distribuidos: Transacciones DistribuidasJRA © 2009
Transacciones Distribuidas
D
Esperapor
Mantenido por
B
X
Y
Z
Mantenido por
W
UV
AC
W
V
U
Espera
por
Esperapor
Mantenidopor
Mantenidopor
Módulo 7Transacciones Distribuidas
Facultad de IngenieríaDepartamento de Informática
Universidad Nacional de la Patagonia “San Juan Bosco”
Fin
Recommended