Algoritmos Distribuidos PDF

Diseño de Sistemas Distribuidos
Máster en Ciencia y Tecnología Informática

Curso 2017-2018
Modelos y algoritmos distribuidos
Félix García Carballeira

Grupo de Arquitectura de Computadores
felix.garcia@uc3m.es
•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •1

Principales características de un sistema
distribuido
§ Múltiples procesos
§ Comunicación y sincronización entre procesos mediante paso
de mensajes
§ Espacio de direcciones de memoria disjuntos
§ Ausencia de reloj global
§ Procesos deben interactuar y cooperar para alcanzar un
objetivo común

Ejemplos
§ World Wide Web

§ Servidores de ficheros en red / distribuidos
§ Aplicaciones bancarias
§ Redes peer to peer
§ Sistemas de control de procesos
§ Redes de sensores
§ Grid computing
§ …

Motivación: ZooKeeper
§ Servicio de coordinación de alto rendimiento para construir

aplicaciones distribuidas
§ Forma parte del proyecto Apache Hadoop que desarrolla SW
abierto para construir aplicaciones distribuidas, escalables y
fiables
§ ZooKeeper se puede utilizar para:
q Implementar consenso distribuido
q Elección de líder
q Barreras de sincronización
q Cerrojos distribuidos
q Configuración dinámica
q Servicios de gestión de grupos de procesos

ZooKeeper en Hadoop

¿Por qué es difícil la coordinación en
sistemas distribuidos?
§ El emisor no puede saber:
q Si el mensaje fue recibido
q Si el receptor falló antes o después de procesar el mensaje
Impossibility of distributed consensus with one faulty

process
Michael J. Fischer, Nancy A. Lynch, Michael S. Paterson
Journal of the ACM (JACM)
Volume 32 , Issue 2 (April 1985) , Pages: 374 – 382

Funcionamiento
§ Datos organizados de forma jerárquica en memoria

§ Los clientes establcecen una sesión cuando se conectan a
ZooKeerper

Modelo de datos
§ Znode
q Almacenado en memoria
q Espacio de nombres
jerárquicos
q No están pensados para
almacenamiento general
(varios KB)
§ Tipos:
q Normales
q Efímeros
q Secuenciales
§ Los clientes pueden manipular los
znodes a través del API de
ZooKeeper

Tipos de znodes
§ Efímeros: los znodes creados por un cliente son borrados al

final de la sesión del cliente (o fallo del cliente)
§ Secuenciales: incrementan un contador añadido al nombre del
znode

Protocolo de pertenencia a un grupo de
procesos

znodes y flag watch
§ Los clientes puede hacer operaciones de lectura sobre un

znode con el flag watch activado
§ El servidor notifica (callback) al cliente cuando la información
del nodo ha cambiado
§ Las notificaciones indican el cambio no los nuevos datos

Sesiones
§ Un cliente se conecta a ZooKeeper e inicia una sesión

§ Las sesiones tienen asociado un timeout
§ ZooKeeper considera que un cliente falla si no recibe nada una
vez expirado el timeout
§ La sesión finaliza cuando el cliente falla o cuando la cierra de
forma explícita

API del cliente
§ Create(path, data, flags)

§ Delete(path, version)
§ Exist(path, watch)
§ getData(path, watch)
§ setData(path, data, version)
§ getChildren(path, watch)
§ Sync(path)

API del cliente
§ Create(path, data, flags)

q flags: ephemeral, sequential
§ Delete(path, version)
§ Exist(path, watch)
§ getData(path, watch)
§ setData(path, data, version)
§ getChildren(path, watch)
§ Sync(path)

Cerrojos con ZooKeeper

Servidores
client
client server replica
client
client
server replica

Servidores
client
client •read server replica
client
client
server replica

Servidores
client
client •write server replica
client •propagate & sych
client
server replica
•broadcast atómico

Fallos
client
client
client
server replica

¿Qué ofrece ZooKeeper?
§ Consistencia secuencial: las actualizaciones de un cliente se

aplican en el orden en el que fueron enviadas en todos los
servidores
§ Atomicidad: las actualizaciones se realizan de forma atómica
§ Imagen única del sistema con independencia del servidor al
que se conecta
§ Fiabilidad: cuando una actualización se completa, perdura

¿Cómo lo consigue?
§ Broadcast atómico
Entrega de mensajes fiable, si un mensaje se entrega a un
q
servidor será entregado a todos

§ Orden total: si en un servidor un mensaje A se entrega antes
que un mensaje B, entonces en todos los servidores se hace de
igual forma
§ Orden causal:
q Si un mensaje B es enviado después de que un mensaje A
ha sido entregado por el emisor de B, A debe ser ordenado
antes que B
q Si un proceso envía C después de enviar B, C debe
ordenarse después de B
¿Cómo lo consigue?
§ El orden total lo consigue con identificadores únicos en los

mensajes (proceso líder)
§ Algoritmo de elección de líder
§ La consistencia se asegura utilizando Quorums

¿En qué se basa ZooKeeper?
§ En algoritmos distribuidos utilizados para:

q Ordenar de eventos
q Entrega causal de mensajes
q Elección de un proceso coordinador (líder)
q Consenso distribuido
q …

Problemas típicos en sistemas
distribuidos
§ Sincronización de relojes
§ Exclusión mutua
§ Elección de líder
§ Consenso distribuido
§ Comunicación en grupos
§ Gestión de réplicas
§ Estados globales

Algoritmos distribuidos
§ Algoritmos que trabajan en sistemas distribuidos

§ Realizan tareas:
Comunicación
q
q Gestión de datos y de recursos

q Sincronización
q Consenso
§ Deben trabajar bajo:
q Actividades concurrentes en múltiples localizaciones
q Incertidumbre del tiempo, ordenación de eventos, .
q Posibilidad de fallos (procesos, procesadores, redes)

Teorema CAP

Modelos de sistemas distribuidos
§ Modelo síncrono
Relojes sincronizados
q
q Entrega de mensajes acotada

q Tiempo de ejecución de procesos acotado
§ Modelo asíncrono
q No hay sincronización de relojes
q Entrega de mensajes no acotada
q Tiempo de ejecución de procesos totalmente arbitraria
§ Sistemas parcialmente síncronos
q Tiempos acotados pero desconocidos

Tipos de pasos de mensajes
§ Paso de mensajes síncrono

q El envío y la recepción de un mensaje m, ocurren
simultáneamente
§ Paso de mensajes asíncrono

q El envío de un mensaje m y su recepción no están acoplados. No
tienen porque ocurrir de forma consecutiva

Modelo de sistema distribuido
§ Modelo de sistema:
Procesos secuenciales {P1, P2, ...Pn} que ejecutan un
q
algoritmo local
q Canales de comunicación
§ Eventos en Pi
q Ei = {ei1, ei2, ...ein}
§ Tipos de eventos locales
q Internos (cambios en el estado de un proceso)
q Comunicación (envío, recepción)
e e e e 01 02 03 04 e05
P0
§ Diagramas espacio-tiempo
P1
e11 e12 e13

Sistema distribuido como un sistema de
transición de estados
§ Un sistema distribuido se puede modelar como un sistema
de transición de estados STE (C, → , I)
1. C es un conjunto de estados
2. → describe las posibles transiciones(→ Í C ´ C)
3. I describe los estados iniciales(I Í C)
§ El estado de un sistema distribuido, C, se puede describir

como
q La configuración actual de cada proceso/procesador
q Los mensajes en tránsito por la red

Configuraciones y estados
§ En el sistema de transición de estados del sistema distribuido

q Los estados se denominan configuraciones
q Las transiciones se denominan transiciones de configuración
§ En el sistema de transición de estados de cada proceso

q Los estados se denominan estados
q Las transiciones se denominan eventos
§ Una ejecución en un sistema distribuido es una secuencia de

configuraciones (g1, g2, g3, …) donde:
g1 es una configuración inicial,
q
Hay una transición entre gi→gi+1 para todo i ≥ 1

q
La secuencia puede ser finita o infinita

q
§ Una ejecución o secuencia de estados define el comportamiento del

sistema
Historia de un sistema distribuido

Algoritmos locales
§ Algoritmo local:
q Un proceso cambia de un estado a otro (evento inerno)
q Un proceso cambia de un estado a otro y envía un mensaje a otro
proceso (evento de envío)
q Un proceso recibe un mensaje y cambia su estado (evento de
recepción)
§ Restricciones
q Un proceso p solo puede recibir un mensaje después de
haber sido enviado por otro
q Un proceso p solo puede cambiar del estado c al estado d si
está actualmente en el estado c

Orden causal
§ La relación ≤H sobre eventos de una ejecución distribuida, denominada

orden causal, se define como:
q Si e ocurre antes que f en el mismo proceso, entonces e ≤H f
q Si s es un evento de envío y r su correspondiente evento de recepción,

entonces s ≤H r
q ≤H Es transitiva
§ Si a ≤H b y b ≤H c entonces a ≤H c
q ≤H es reflexiva.
§ a ≤H a para cualquier evento
§ Dos eventos , a y b, son concurrentes sii a ≤H b y b ≤H a

Ejemplos de eventos
•Eventos concurrentes •Eventos relacionados

causalmente
•p1
•p2
•p3
•time
•Eventos relacionados
causalmente

Ejecuciones equivalentes
§ Dos ejecuciones distribuidas F y E son equivalentes (F~E )

si:
q Tienen el mismo conjunto de eventos
q Se mantiene el orden causal

Ejemplos de ejecuciones equivalentes
•p1
•Mismo color ~ orden causal
•p2
•p3
•tiempo
•p1
•p2
•p3
•tiempo
•p1
•p2
•p3
•tiempo

Algoritmos distribuidos
§ Los algoritmos distribuidos deben tener las siguientes

propiedades:
q La información relevante se distribuye entre varias
máquinas
q Los procesos toman las decisiones sólo en base a la
información local
q Debe evitarse un punto único de fallo
q No existe un reloj común

Ejemplos de algoritmos distribuidos
§ ordenación de eventos
§ Exclusión mutua distribuida
§ Algoritmos de elección
§ Comunicación multicast y ordenación de mensajes
§ Problemas de consenso
§ Detección de interbloqueos
§ Asignación de recursos
§ Planificación
§ Tolerancia a fallos

Ordenación de eventos
§ Monitorización del comportamiento de una aplicación distribuida
q Ejemplo: el observador debe ordenar los eventos de recepción de
mensajes en los procesos P1 y P2
§ e1, e2, e3, e4, e5
P1
m1 m3 m4
m2 m5
P2
Observador
e1 e2 e3 e4 e5

Ejemplo
§ Monitorización del comportamiento de una aplicación distribuida

q El observador debe ordenar los eventos de recepción de mensajes en los
procesos P1 y P2
§ e1, e2, e3, e4, e5
P1
m1 m3 m4
m2 m5
P2
Observador
e1 e2 e3 e4 e5
§ Para ordenar eventos podemos asignarles marcas de tiempo

§ ei ¬ ek Û MT(ei) < MT (ek )

¿Marcas de tiempo en el observador?
P1
m1
m2
P2
Observador
e2 e1
?
¿Marcas de tiempo en de los procesos?
1 3
P1
m1
m2
6 8
P2
Observador
e1-6 e2-3
?
¿Marcas de tiempo en de los procesos?
1 3
P1
m1
m2
6 8
P2
Observador
e1-6 e2-3
Los relojes deben estar sincronizados

Relojes físicos
§ Para ordenar dos eventos de un proceso basta con asignarles

una marca de tiempo
§ Para un instante físico t
q Hi(t): valor del reloj HW (oscilador)
q Ci(t): valor del reloj SW (generado por el SO)
§ Ci(t) = a Hi(t) + b
q Ej: # ms o ns transcurridos desde una fecha de referencia
§ Resolución del reloj: periodo entre actualizaciones de Ci(t)
q Determina la ordenación de eventos
§ Dos relojes en dos computadores diferentes dan medidas
distintas
q Un reloj actual puede tener una deriva de1s al día
q Necesidad de sincronizar relojes físicos de un sistema
distribuido
Sincronización de relojes físicos
§ D: Cota máxima de sincronización

§ S: fuente del tiempo UTC, t
§ Sincronización externa:
Los relojes están sincronizados si |S(t) - Ci(t)| < D
q
q Los relojes se consideran sincronizados dentro de D

§ Sincronización interna entre los relojes de los computadores de
un sistema distribuido
q Los relojes están sincronizados si |Ci(t) - Cj(t)| < D
q Dados dos eventos de dos computadores se puede establecer
su orden en función de sus relojes si están sincronizados
§ Sincronización externa Þ sincronización interna
Ü
Relojes lógicos
§ Dado que no se pueden sincronizar perfectamente los relojes

físicos en un sistema distribuido, no se pueden utilizar relojes
físicos para ordenar eventos
§ ¿Podemos ordenar los eventos de otra forma?
P1
m1 m3 m4
m2 m5
P2
Observador e1 e2 e3 e4 e5

Causalidad potencial
§ En ausencia de un reloj global la relación causa-efecto

(precede a) es la única posibilidad de ordenar eventos
§ Relación de causalidad potencial (Lamport)

eij = evento j en el proceso i
q
q Si j < k entonces eij ¬ eik

q Si ei=send(m) y ej=receive(m), entonces ei ¬ ej
q La relación es transitiva
§ Dos eventos son concurrentes (a || b) si no se puede deducir
entre ellos una relación de causalidad potencial

Aplicación de los relojes lógicos
§ Sincronización de relojes lógicos

§ Depuración distribuida
§ Registro de estados globales
§ Monitorización
§ Entrega causal
§ Actualización de réplicas

Relojes lógicos (algoritmo de Lamport)
§ Algoritmo de Lamport (1978)

§ Cada proceso P mantiene una variable entera RLp (reloj lógico)
§ Cuando un proceso P genera un evento, RLp=RLp+1
§ Cuando un proceso envía un mensaje m a otro le añade el valor
de su reloj
§ Cuando un proceso Q recibe un mensaje m con un valor de
tiempo t, el proceso actualiza su reloj, RLq=max(RLq,t) +1
§ El algoritmo asegura que si a ≤H b entonces RL(a) < RL(b)

Ejemplo
•p1
•0 •1 •2 •3 •4
•p2
•0 •4 •5
•p3
•0 •1 •6
•tiempo

Relojes lógicos totalmente ordenados
§ Los relojes lógicos de Lamport imponen sólo una relación de

orden parcial:
q Eventos de distintos procesos pueden tener asociado una
misma marca de tiempo.
§ Se puede extender la relación de orden para conseguir una
relación de orden total añadiendo el nº de proceso
q (Ta, Pa): marca de tiempo del evento a del proceso P
§ (Ta, Pa) < (Tb, Pb) sí y solo si
q Ta < Tb o
q Ta=Tb y Pa<Pb

Algoritmo de Welch
§ ¿Qué ocurre si el sistema ya dispone de un reloj?

No se puede cambiar el valor del reloj si es mantenido por
q
un algoritmo diferente
§ Algoritmo de Welch
q En lugar de avanzar el reloj en respuesta a los mensajes que
llegan, se retrasa la entrega de esos mensajes hasta que se
alcanza el valor de tiempo
q Los mensajes que llegan se almacenan en un buffer FIFO si
su marca de tiempo es menor que la marca de tiempo del
proceso receptor

Problemas de los relojes lógicos
§ No bastan para caracterizar la causalidad

q Dados RL(a) y RL(b) no podemos saber:
§ si a precede a b
§ si b precede a a
§ si a y b son concurrentes
§ Se necesita una relación (F(e), <) tal que:

q a ≤H b si y sólo si F(a) < F(b)
q Los relojes vectoriales permiten representar de forma
precisa la relación de causalidad potencial

Problemas de los relojes lógicos
e11 e12
P1
(1) (2)
e21 e22
P2
(1) (3)
e31 e32 e33

P3
(1) (2) (3)
C(e11) < C(e22), y e11¬e22 es cierto

C(e11) < C(e32), pero e11 ¬ e32 es falso

Relojes vectoriales
§ Desarrollado independientemente por Fidge, Mattern y Schmuck

§ Todo proceso lleva asociado un vector de enteros RV
§ RVi[a] es el valor del reloj vectorial del proceso i cuando ejecuta el evento
a.
§ Mantenimiento de los relojes vectoriales
q Inicialmente RVi= 0 " i
q Cuando un proceso i genera un evento
§ RVi[i ] = RVi[i ] +1
q Todos los mensajes llevan el RV del envío
q Cuando un proceso j recibe un mensaje con RV
§ RVj = max(RVj , RV ) (componente a componente)
§ RVj[j ] = RVj[j ] +1 (evento de recepción)

Ejemplo
•p1
•[1,0,0] •[2,0,0] •[3,0,0] •[4,0,0] •[5,0,0]
•p2
•[0,1,0] •[4,2,0] •[4,3,0]
•p3
•[0,0,1] •[0,0,2] •[4,3,3]
•tiempo

Propiedades de los relojes vectoriales
§ RV < RV´ si y solo si

RV ¹ RV´ y
q
q RV[i ] £ RV´[i ], " i

§ Dados dos eventos a y b
q a ≤H b si y solo si RV(a) < RV(b)
q a y b son concurrentes cuando
§ Ni RV(a) £ RV(b)[i ] ni RV(b ) £ RV(b)

Entrega causal
§ Se distinguen los eventos recibir y entregar

§ Entrega FIFO
sendi(m) ≤H sendi(m´) entonces entregak(m) ≤H entregak(m´)
q
§ Entrega causal
q sendi(m) ≤H sendj(m´) entonces entregak(m) ≤H entregak(m´)
§ La entrega causal requiere retrasar la entrega de un mensaje a un
proceso hasta estar seguros que entre dos envíos no hay uno
intermedio
§ Se puede implementar con relojes vectoriales

Ejemplo de entrega no causal
P1
m
P2
m’
P3
send(m) ≤H send(m’) pero en P3 se recibe antes m’

Exclusión mutua distribuida
§ Los procesos ejecutan el siguiente fragmento de código

entrada()
SECCIÓN CRÍTICA
salida()
§ Requisitos para resolver el problema de la sección crítica
q Exclusión mutua
q Progreso
q Espera acotada
§ Algoritmos
q Algoritmo centralizado
q Algoritmo distribuido
q Anillo con testigo
q …..
Algoritmo centralizado
0 1 2 0 1 2 0 1 2
entrada salida
entrada OK
OK No hay respuespuesta
(bloquea al cliente)
C C C

Algoritmo distribuido de Ricart y
Agrawala
} Algoritmo de Ricart y Agrawala requiere la existencia un
orden total de todos los mensajes en el sistema
} Un proceso que quiere entrar en una sección crítica (SC) envía
un mensaje a todos los procesos (y a él mismo) con una marca
de tiempo lógica
} Cuando un proceso recibe un mensaje
} Si el receptor no está en la SC ni quiere entrar envía OK al
emisor
} Si el receptor ya está en la SC no responde
} Si el receptor desea entrar, compara la marca de tiempo del
mensaje. Si el mensaje tiene una marca menor envía OK. En
caso contrario entra y no envía nada.
} Cuando un proceso recibe todos los mensajes puede entrar
Ejemplo
a) Dos procesos (P0, P2) quieren entrar en la región al mismo
tiempo
b) El proceso 0 tiene la marca de tiempo más baja, entra él.
c) Cuando el proceso 0 acaba, envía un OK, de esa forma el
proceso 2 entra
•64
•Félix García Carballeira •Sistemas Distribuidos (2017-2018)
Anillo con testigo
§ Los procesos se ordenan conceptualmente como un anillo
§ Por el anillo circula un testigo
§ Cuando un proceso quiere entrar en la SC debe esperar a
recoger el testigo
§ Cuando sale de la SC envía el testigo al nuevo proceso del
anillo
•65
Ejemplo. Algoritmo de votación de
Maekawa
§ Idea: no solicitar permiso de todos los procesos, solo de un
subconjunto
q Los subconjuntos deben solaparse
§ A cada proceso Pi se le asocia un conjunto de votantes
q { Vi | i = 1, …, N }
§ Pi está en Vi
§ Vi Ç Vj ≠ Æ
§ Todos subconjuntos de igual tamaño
§ Cada proceso Pj está contenido en M subconjutos
votantes
§ Solución optima
q K~ N
q M=K
Algoritmo de votación de Maekawa
enter():
state := WANTED;
Multicast request to processes in Vi - { Pi };
Wait until (K - 1) responses are received;
state := HELD;
When Pj receives a request from Pi, i ≠ j:

if(state == HELD or voted == TRUE) {
Queue request without responding;
} else {
Reply to Pi;
voted := TRUE;
}

Algoritmo de votación de Maekawa
release():
state :=RELEASED;
Multicast release to processes in Vi - { Pi };
When Pj receives a release msg from Pi i ≠ j:

if(request queue == EMPTY) {
voted := FALSE;
} else {
Remove head of queue, P(k);
Reply to process P(k);
voted := TRUE;
}

Cerrojos en ZooKeeper

Algoritmos de elección
§ Útil en aplicaciones donde es necesario la existencia de un
coordinador
Varios procesos necesitan elegir un líder/coordinador
q
Por ejemplo, en una red token ring, cuando el testigo se pierde

q
En ZooKeeper cuando el coordinador falla

q
§ El algoritmo debe ejecutarse cuando falla el coordinador

§ Algoritmos de elección
Algoritmo del matón
q
Algoritmo de anillo
q
§ El objetivo de los algoritmos es que la elección sea única aunque el

algoritmo se inicie de forma concurrente en varios procesos
•70
Variantes del problema
§ ¿Comunicación síncrona o asíncrona?

§ ¿Cómo están conectados los procesos?
En anillo, completamente conectados, …
q
§ ¿El número de procesos es conocido?

§ ¿Los procesos tienen un identificador único?

Elección de líder con ZooKeeper

Algoritmo del máton
§ Suposiciones:
q Comunicación síncrona
q Procesos completamente conectados
q Entrega de mensajes fiable

Algoritmo del matón. Ejemplo
} Utiliza timeouts (T) para detectar fallos
} Asume que cada proceso conoce qué procesos tiene ID
mayores
} 3 tipos de mensajes:
n coordinador: anuncio a todos los procesos con IDs menores
n elección: enviado a procesos con IDs mayores
n OK: respuesta a elección
} Si no se recibe dentro de T, el emisor de elección envía
coordinador
} En caso contrario, el proceso espera durante T a recibir un
mensaje coordinador. Si no llega comienza una nueva
elección
•74
§ Cuando un proceso P observa que el coordinador no responde
inicia una elección:
a) Proceso 4 envía elección

b) Proceso 5 y 6 responden, diciéndole que pare
c) Ahora 5 y 6 comienzan la elección …
•75
d) Proceso 6 dice a 5 que pare

e) Proceso 6 indica a todos que es el coordinador
•76
Algoritmo LCR (basado en anillo)
§ Algoritmo LeLarnn, Chang y Roberts

§ Suposiciones:
q Comunicación síncrona
q Procesos en anillo
q Identificador único para cada proceso
q Tamaño de la red desconocida

Algoritmo del anillo
§ Cualquier proceso puede comenzar la elección y envía un
mensaje de elección a su vecino con su identificador y se
marca como participante
§ Cuando un proceso recibe un mensaje de elección compara el
identificador del mensaje con el suyo:
q Si es mayor reenvía el mensaje al siguiente
q Si es menor y no es un participante sustituye el identificador del
mensaje por el suyo y lo reenvía.
q Si es menor y es un participante no lo reenvía
q Cuando se reenvía un mensaje el proceso se marca como participante
§ Cuando un proceso recibe un identificador con su número y es
el mayor se elige como coordinador
§ El coordinador notifica al resto

Algoritmo del anillo
§ El 2 y el 5 generan mensajes de elección y lo envían al siguiente
§ Se elige como coordinador el proceso que recibe un mensaje con su nº y es
el mayor
§ Este proceso a continuación envía mensajes a todos informando que es el
coordinador
1 2 2
6
0 3
7 4
6 5
5
•79
Comunicación multicast
§ Las primitivas de comunicación básicas soportan la

comunicación uno a uno.
§ Broadcast: el emisor envía un mensaje a todos los nodos del
sistema.
§ Multicast: el emisor envía un mensaje a un subconjunto de
todos los nodos.
§ Estas operaciones se emplean normalmente mediante
operaciones punto a punto.

Utilidad
§ Servidores replicados: un servicio replicado consta de un grupo

de servidores. Las peticiones de los clientes se envían a todos los
miembros del grupo. Aunque algún miembro del grupo falle la
operación se realizará.
§ Mejor rendimiento:
q Replicando datos.
q Cuando se cambia un dato, el nuevo valor se envía a todos los
procesos que gestionan las réplicas.

Tipos de multicast
§ Multicast no fiable: no hay garantía de que el mensaje se

entregue a todos los nodos.
§ Multicast fiable: el mensaje es recibido por todos los nodos en
funcionamiento.
§ Multicast atómico: el protocolo asegura que todos los
miembros del grupo recibirán los mensajes de diferentes nodos
en el mismo orden.
§ Multicast causal: asegura que los mensaje se entregan de
acuerdo con las relaciones de causalidad.

Justificación del multicast atómico
§ Sea un banco con una base de datos replicada para almacenar

las cuentas de los clientes.
§ Considere la cuenta X con un saldo de 1000 euros.
q Un usuario ingresa 200 eurosenviando un multicast a las
dos bases de datos.
q Al mismo tiempo se paga un 10% de intereses, enviando un
multicast a las dos bases de datos.
q ¿Qué ocurre si los mensajes llegan en diferente a orden a las
dos bases de datos?

Implementación del multicast
§ Implementación de operaciones multicast:

q Mediante operaciones punto a punto.
q Mecanismo poco fiable.
§ Problemas de fiabilidad:
q Alguno de los mensajes se puede perder.
q El proceso emisor puede fallar después de realizados
algunos envíos. En este caso algunos procesos no recibirán
el mensaje.

Multicast fiable
§ Se envía un mensaje a todos los procesos y se espera confirmación

de todos.
Si todos confirman el multicast se ha completado.
q
Si alguno no confirma se retransmite. Si no envía confirmación

q
se puede asumir que el proceso ha fallado y se elimina del grupo.

§ Si el emisor falla durante el proceso la operación no será atómica.
Para que la operación sea atómica, si el emisor falla alguno de los
q
receptores debe completar el envío a todos los demás.

§ Cuando un proceso recibe un mensaje lo envía al resto
§ Cuando un proceso recibe un mensaje envía una confirmación y
monitoriza al emisor para ver si falla. Si falla completa el multicast.
§ En cualquier caso hay que descartar los mensajes duplicados

Ejemplo de multicast sin ordenación
P1 P2 P3 P4
A B
Tiempo
A B

Ordenación de las actualizaciones
§ Es importante el orden en el que se realizan las peticiones

¿Qué ocurre en un sistema asíncrono cuando un cliente
modifica un dato y más tarde otro cliente quiere consultar
ese dato?
§ Algunas aplicaciones requieren un orden en la realización de
las peticiones.
§ Orden total: dadas dos peticiones r1 y r2 entonces o r1 es
procesada en todos los procesos antes que r2 o r2 lo es antes
que r1.
§ Ordenación causal: se basa en la relación de precedencia que
recoge las relaciones de causalidad potencial. Si r1 precede a r2
entonces r1 se procesa antes que r2 en todos los procesos

Ordenación total y causal
t2
t1
tiempo
c1
c2 c3
FE1 GR1 GR2 GR3 FE2

Problemas en servidores georeplicados

Tipos de anomalías que no siguen orden
causal (1)

causal (2)

causal (3)

Implementación
§ Una petición recibida no se entrega hasta que las restricciones de

ordenación se puedan cumplir.
§ Un mensaje estable pasa a la cola de entrega
§ Debe asegurarse
q Seguridad: ningún mensaje fuera de orden
q Progreso: todos los mensajes se entregan
entrega
cola de cola de
espera entrega
Peticiones

Implementación de la ordenación total
} Se asigna a cada petición un identificador de orden total
(IOT)
} Este identificador se utiliza para entregar los mensajes en el
mismo orden a todos los procesos
} Método centralizado:
q Se utiliza un proceso secuenciador encargado de asignar
IOT a los mensajes
q Cada mensaje se envían al secuenciador
} El secuenciador incrementa IOT
} El secuenciador le asigna un IOT y lo envía a los procesos
q Cuando un proceso recibe un mensaje con un IOT mayor
del esperado, pide al secuenciador que le envíe de nuevo el
mensaje
q Posible cuello de botella y punto de fallo crítico
•94
Método distribuido
§ Birman y Joseph 1987
§ Cada proceso q en el grupo almacena:
q Aq: mayor número de secuencia acordado que se ha observado hasta el
momento
q Pq: su mayor número de secuencia propuesto
q Los identificadores deben incluir el número de proceso para asegurar un orden
total
§ Cuando un proceso p realiza un BCAST envía el mensaje al resto
§ Cada proceso q que recibe el mensaje de p
q Propone Pq=Max(Aq, Pq) + 1
q Almacena (m, Pq) en su cola y lo marca como no entregable
q Envía Pq al emisor del mensaje (p)
§ El proceso q recibe todos los números de secuencia propuesto y selecciona el mayor
A como el siguiente número de secuencia acordado y lo envía a todos
q En q se fija Aq = Max(Aq, A) y se marca el mensaje como entregable
q Se reordena la cola y si está el primero se entrega
•95
Ejemplo
•Nodo 1 •Nodo 2 •Nodo 3
•A1 = 14 •A12 = 15 •A3 = 16
•Multicast (M1) •Multicast(M2) •Multicast(M3)
•Inicialmente:
• Los tres nodos realizan un multicast simultáneo

Ejemplo
•A1 = 14 •A12 = 15 •A3 = 16
•Inicialmente:
• Los tres nodos realizan un multicast simultáneo

Ejemplo
•A1 = 14 •A12 = 15 •A3 = 16
M3 M1 M2 M2 M1 M3 M1 M3 M2
15.1 16.1 17.1 … 16.2 17.2 18.2 … 17.3 18.3 19.3 …
U U U U U U U U U
•Etapa 1:
• Los mensajes llegan a los receptores en orden distinto
• Se les propone un número de secuencia, Pq=Max(Aq, Pq) + 1
• (se añade identificador de proceso)
• Se insertan en las colas y se marcan como no entregables (U)

Ejemplo
•A1 = 14 •A12 = 15 •A3 = 16
M3 M1 M2 M2 M1 M3 M1 M3 M2
15.1 17.3 17.1 … 16.2 17.3 18.2 … 17.3 18.3 19.3 …
U U U U U U U U U
•Etapa 2:
• El Nodo 1 recibe las marcas asociada a M1 envidas por el nodo 2 (17.2) y 3 (17.3)
• y calcula el máximo de las tres, y se las envía al resto (17.3)

Ejemplo
•A1 = 14 •A12 = 15 •A3 = 16
M3 M2 M1 M2 M1 M3 M1 M3 M2
15.1 17.1 17.3 … 16.2 17.3 18.2 … 17.3 18.3 19.3 …
U U D U D U D U U
•Etapa 2:
• Se marca M1 como entregable y se reordenan las colas
• M1 se puede entregar en el nodo 3 porque ser el primero de la cola

Ejemplo
•A1 = 14 •A12 = 15 •A3 = 16
M3 M2 M1 M2 M1 M3 M3 M2
15.1 17.1 17.3 … 16.2 17.3 18.2 … 18.3 19.3 …
U U D U D U U U
•Etapa 2:
• M1 se entrega en el nodo 3

Ejemplo
•A1 = 14 •A12 = 15 •A3 = 16
M3 M2 M1 M2 M1 M3 M3 M2
15.1 17.1 17.3 … 16.2 17.3 18.2 … 18.3 19.3 …
U U D U D U U U
•Etapa 3:
• El Nodo 2 recibe las marcas asociada a M2 envidas por el nodo 1 (17.1) y 3 (19.3) ,
• Calcula el máximo (19.3)

Ejemplo
•A1 = 14 •A12 = 15 •A3 = 16
M3 M2 M1 M2 M1 M3 M3 M2
15.1 19.3 17.3 … 19.3 17.3 18.2 … 18.3 19.3 …
U U D U D U U U
•Etapa 3:
• El Nodo 2 recibe las marcas asociada a M2 envidas por el nodo 1 (17.1) y 3 (19.3) ,
• Calcula el máximo (19.3)
• Se la envía al resto

Ejemplo
•A1 = 14 •A12 = 15 •A3 = 16
M3 M1 M2 M1 M3 M2 M3 M2
15.1 17.3 19.3 … 17.3 18.2 19.3 … 18.3 19.3 …
U D D D U D U D
•Etapa 3:
• M2 se marca como entregable y se reordenan las colas

Ejemplo
•A1 = 14 •A12 = 15 •A3 = 16
M3 M1 M2 M3 M2 M3 M2
15.1 17.3 19.2 … 18.2 19.3 … 18.3 19.3 …
U D D U D U D
•Etapa 3:
• M2 se marca como entregable y se reordenan las colas
• M1 se entrega en el nodo 2

Ejemplo
•A1 = 14 •A12 = 15 •A3 = 16
M3 M1 M2 M3 M2 M3 M2
15.1 17.3 19.2 … 18.2 19.3 … 18.3 19.3 …
U D D U D U D
•Etapa 4:
• Calcula el máximo de todas (18.3)

Ejemplo
•A1 = 14 •A12 = 15 •A3 = 16
M3 M1 M2 M3 M2 M3 M2
18.3 17.3 19.2 … 18.3 19.3 … 18.3 19.3 …
U D D U D U D
•Etapa 4:
• Calcula el máximo de todas (18.3)
• Se las envía al resto

Ejemplo
•A1 = 14 •A12 = 15 •A3 = 16
M1 M3 M2 M3 M2 M3 M2
17.3 18.3 19.2 … 18.3 19.3 … 18.3 19.3 …
D D D D D D D
•Etapa 4:
• Se marca M3 como entregable y se reordenan las colas
• Se pueden entregar todos los mensajes en todos los nodos
• El orden de entrega: M1, M3 y M2 (se asegura el orden de entrega en todos los nodos)

Implementación de la ordenación causal
} Cada proceso pi, almacena un vector VT con n componentes
} En el proceso pj, la componente i indica el último mensaje
recibido de i
} Algoritmo para actualizar el vector
q Todos los procesos inicializan el vector a 0
q Cuando pi envía un nuevo mensaje incrementa VTi(i) en 1 y
añade VT al mensaje
} Cuando a pj le llega un mensaje de pi con VT se entrega si:
q VT(i) = VTj(i) + 1 (siguiente en la secuencia de pi)
q VT(k) £ VTj(k) para todo k ¹ i (todos los mensajes
anteriores se han entregado a i)
} Cuando un mensaje con VT se entrega a pj se actualiza su
vector:
} VTj = max(VTj, VT), para k=1, 2, ... , n
•109
Ejemplo
(0,0,0) (0,1,0) (0,1,1)

P0
(0,0,0) (0,1,0)
P1
(0,1,1)
(0,0,0)
P2
(0,1,0) (0,1,1)
•110
Ejemplo
§ Vector enviado por el proceso 0: (4, 6, 8, 2, 1, 5)
§ Vector en el proceso 1: (3, 7, 8, 2, 1, 5)
§ ¿Se puede entregar el mensaje enviado por el 0?
•111
Ejemplo
§ Vector enviado por el proceso 0: (4, 6, 8, 2, 1, 5)
§ ¿Se puede entregar el mensaje enviado por el 0?
q Al 1 si:
§ Es el siguiente en la secuencia de mensajes recibidos del 0 y
no se han perdido mensajes.
q Al 2 no:
§ Es el siguiente en la secuencia de mensajes recibidos del 0.
§ Le falta un mensaje del proceso 1
•112
Problemas de consenso
§ Objetivo: que un conjunto de procesos se pongan de acuerdo en una

determinada acción o valor.
§ Un servicio de consenso consta de
Un conjunto de N procesos que deben tener una visión
q
consensuada de un determinado objeto, valor o acción

Clientes que envían peticiones a los procesos para proponer un
q
valor
Objetivo: que el conjunto de procesos consensuen un valor
q
§ Un protocolo de consenso es correcto sii:

Todos los nodos deciden el mismo valor (seguridad)
q
El valor decidido debe haber sido propuesto por algún nodo

q
Todos los nodos deciden el valor en el algún momento

q
(terminación)
Protocolos de consenso
§ Dado un conjunto de proceso P1….Pn que se comunican

mediante paso de mensajes, el objetivo es alcanzar un acuerdo
sobre un determinado valor aun en presencia de fallos
P1
v1
v3
P3
Algoritmo de
v2 consenso
P2

Aplicaciones
§ Transacciones distribuidas
§ En grupos de procesos
§ Elección de líder
§ Servidores replicados

Two-phase-commit
§ Two-phase-commit (2PC), Jim Gray (1970)

§ Denominamos coordinador al proceso que realiza la operación
Coordinador: P0 P1 P2
multicast: ok to commit? OK to commit
recoger las respuestas

todos ok => send(commit) Grabar en
área temporal
else => send(abort)
Procesos: ok
ok to commit=> guardar
la petición en un
¡Commit! Hacer los cambios
área temporal y responder ok permanentes
commit => hacer los cambios

permanentes
abort => borrar los datos temporales

Ejemplo
•ok to
commit?

Ejemplo
•ok to
commit?
•ok

Ejemplo
•ok to
commit?
•commit •ok
•Hacer los
cambios
permanentes

Modos de fallo en sistemas distribuidos
§ Fallo parada (fail stop): el nodo que falla no se recupera

§ Fallo por omisión: fallo que causa que un componente no
responda en algunas ocasiones
§ Fallo con recuperación (fail recover): un componente falla,
pero continua su ejecución sin fallo posteriormente
§ Fallos de tiempo: el componente responde demasiado tarde, no
se cumple el rendimiento esperado, ..
§ Fallos bizantinos: funcionamiento arbitrario

Posibles fallos en 2PC
§ Alguno de los procesos (coordinador, participantes) falla

durante el protocolo
§ Se pierde alguno de los mensajes del protocolo
§ Para hacer frente a los fallos (no bizantinos):
q Cada proceso almacena la información del protocolo en
almacenamiento persistente
§ Cuando el proceso se recupera recupera la información
previamente guardada
q Se utilizan timeouts para evitar los bloqueos en el protocolo

Ejemplo con fallo en la respuesta
•Coordinador A B C
•ok to
commit?
•ok •Proceso falla

Ejemplo con fallo en la respuesta
•ok to
commit?
•timeout

Ejemplo con fallo respuesta
•ok to
commit?
•abort

Fallo en el coordinador
•ok to
commit?
•ok
•commit

Fallo en el coordinador
§ El proceso C puede enviar un mensaje al coordinador

pidiéndole la decisión
q Si la recibe OK
q Si no la recibe tiene que esperar a que el coordinador se
recupere
§ El proceso C puede solicitar la decisión a alguno de los otros
participantes

Acciones después de una recuperación
§ Si falló el coordinador, cuando reinicia:

Si el estado fue “commit” entonces envía “commit”
q
q Si en estado fue “abort” entonces envía “abort”

§ Si falló un proceso, cuando reinicia:
q Si no encontró “ok” aborta la operación
q Si encontró “ok”, ejecuta el protocolo de terminación para
decidir

Fallos de bloqueo del protocolo 2PC
§ El coordinador envía una petición “ok to commit” a A, B, C y D

§ Todos responden “ok”
§ El coordinador envía “commit” a A y a continuación el
coordinador y A fallan
§ B, C y D han respondido “ok” pero no reciben “commit” ni del
coordinador ni de A

Imposibilidad de consenso
§ En un sistema síncrono es posible

§ En un sistema asíncrono es imposible
q Impossibility of distributed consensus with one faulty process
Michael J. Fischer, Nancy A. Lynch, Michael S. Paterson
Journal of the ACM (JACM)
Volume 32 , Issue 2 (April 1985) , Pages: 374 – 382
§ ¿Por qué?
q En un sistema asíncrono: no se puede determinar si un
proceso ha fallado o no (puede ejecutar más lento o sus
mensajes pueden retrasarse)
§ No existe un detector de fallos
§ En sistemas síncronos 3PC asegura seguridad y terminación
§ 2PC no asegura terminación
Three-phase commit
• coordinador participantes (A, B, C …)
•canCommit?
•yes Fase 1
•prepareCommit
Fase 2
•ACK
•doCommit
•haveCommitted Fase 3
• Dale Skeen el al. (1980)

¿Resuelve el problema de bloqueo?
§ Asumir que el coordinador y A fallan en la fase 3 justo

después del doCoomit a A
§ Si alguno de los procesos restantes ha recibido prepareCommit
puede terminar el protocolo
§ Si ninguno ha recibido prepareCommit, abortan

Empleo de timeouts
• coordinador participantes (A, B, C …)
•canCommit?
•yes Fase 1
•prepareCommit Timeout -> abortar

Fase 2
Timeout -> abortar •ACK
•doCommit Timeout -> commit

•haveCommitted Fase 3
Timeout -> abortar

Particiones de red
§ 2PC y 3PC no funcionan en caso de particiones de red

§ A recibe prepareCommit del coordinador
§ Ocurre una partición de A con el resto
§ El resto de participantes no recibe
prepareCommit y abortan
§ A está preparado para commit, de
acuerdo al protocolo, decide commit
de forma unilateral

Consenso basado en quorums
§ Se definen dos operaciones READ y WRITE

§ Hay un conjunto de N nodos, que sirven peticiones
q Un READ debe realizarse sobre R copias
q Un WRITE debe realizarse sobre W copias
q Cada réplica tiene un número de versión V
q Debe cumplirse que:
§ R+W>N
§ W+W>N
§ R, W < N

Método de votación
§ READ
Se lee de R réplicas, se queda con la copia con la última
q
versión
§ WRITE
q Hay que asegurarse que todas las réplicas se comportan
como una sola (seriabilidad)
q Se realiza en primer lugar una operación READ para
determinar el número de versión actual.
q Se calcula el nuevo número de versión.
q Se inicia un 2PC para actualizar el valor y el número de
versión en W o más réplicas.

Votación jerárquica
§ El problema de los esquemas basados en quorum es que W

aumenta al aumentar el número de réplicas
§ Solución: quorum jerárquico
q Ej: número de réplicas = 5 x 5 = 25 (nodos hoja)
•0
•1
•2

Votación jerárquica
§ El quorum se realiza por niveles
R1W1 R2 W2 RT WT
1 5 1 5 1 25
1 5 2 4 2 20
1 5 3 3 3 15
2 4 2 4 4 16
2 4 3 3 6 12
3 3 3 3 9 9
¿Cuál se elige?
Replicación de datos utilizando 2PC
§ Sea un conjunto de procesos {P0, P1,...,Pn} que mantienen una réplica sobre
las que se hacen operaciones readi, updatei
§ Objetivo: definir dos operaciones distribuidas READ y UPDATE que son
disponibles incluso cuanto t < n procesos fallan y devuelven fallos
indistinguibles de aquellos que no fallan.
§ Se denota como qr el número de réplicas que deben leerse para una
operación READ
§ Se denota como qu el número de réplicas que deben actualizarse para un
UPDATE.
§ Para utilizar esquemas basados en quorum se necesita:
q qr + qu > n
q qu+qu > n

§ Para tolerar t fallos, será necesario que

q qu no sea mayor que n-t
q r>t
§ Se asocia un número de versión a cada dato. El número de versión se
incrementa en cada actualización.
§ READ: el proceso lee qr réplicas y descarta las réplicas con números
pequeños. El resto deben ser idénticos y se utilizará como valor leído.
§ UPDATE: utiliza el protocolo 2PC
q Se realiza en primer lugar una operación READ para determinar el
número de versión actual.
q Se calcula el nuevo número de versión.
q Se inicia un 2PC para escribir el valor y el nº de versión en qu o más
réplicas.

§ UPDATE (Continuación)
q Una réplica indica abortar si ella tiene un nº de versión
mayor
q En caso contrario bloquea las READ y espera en ok to
commit
q El coordinador comprometerá el resultado si sólo recibe
mensajes commit de al menos qu réplicas. En caso contrario
aborta.
q Las operaciones READ se retrasan durante el estado ok to
commit.
q Si llegan operaciones UPDATE en ok to commit las aborta

Paxos
§ Leslie Lamport (1989)

§ Protocolo para alcanzar consenso basado en máquinas de
estado finito (asegura seguridad y terminación)
§ Todos los nodos alcanzan consenso a pesar de fallos en los
nodos, particiones de red y retrasos en la entrega de mensajes

Aplicación de Paxos
§ Google: Chubby (servicio de cerrojos distribuido basado en

Paxos)
q Bigtable y otros servicios de Google utilizan Chubby
§ Yahho: ZooKeeper (servicio de cerrojos distribuido basado en
Paxos)

Propiedades de Paxos
§ Seguridad: si se alcanza consenso, todos los nodos acuerdan el

mismo valor
§ Tolerancia a fallos: si menos de la mitad de los nodos fallan, el
resto alcanza acuerdo
§ Terminación no garantizada en casos muy improbables en el
mundo real

Idea básica
§ Similar a 2PC pero con dos procesos (proposer, aceptors)

§ Uno o más nodos deciden ser coordinador (proposer)
§ El nodo proposer propone un valor y solicita la aceptación de
un conjunto de nodos aceptors
§ El nodo proposer anuncia el valor elegido o lo intenta de
nuevo sino se ha alcanzado un valor

Idea básica


Idea básica

§ Cualquier nodo puede
proponer/(aceptar

Mecanismos utilizados en Paxos
§ Las propuestas van ordenadas con un número de propuesta

único
§ 2PC necesita que todos los nodos acuerden el valor
§ Paxos solo necesita la mitad + 1 de los nodos para alcanzar
consenso
q Permite que el sistema siga funcionando en presencia de
fallos
q Resuelve los problemas de partición (no puede haber dos
mayorías simultáneamente)

Funcionamiento
§ Cada proposer propone un valor a todos los nodos accpetors

§ Cada acceptor acepta el primer valor propuesto que recibe y
rechaza el resto
§ Si el proposer recibe respuestas positivas de una mayoría,
elige ese valor
§ El nodo proposer envía el valor elegido a todos los nodos
§ Todas las propuestas llevan un orden global

Ordenación de las propuestas
§ Cada aceptor debe ser capaz de aceptar múltiples propuestas

§ Cada propuesta lleva asociada un número de orden global que
utilizan los nodos acceptors para aceptar/rechazar
q Ej: (dirección de nodo:número de secuencia local)
§ Reglas para aceptar propuestas:
q Cuando un nodo acceptor recibe una nueva propuesta con
número N, lo compara con el número de propuesta M ya
aceptada
§ Si N > M acepta la nueva propuesta, en caso contrario la
rechaza
q Si el acceptor decide aceptar la nueva propuesta N, le pide
al proposer que utilice el mismo valor de la propuesta M
Protocolo detallado
§ Cada nodo almacena:

q (Na. Va): propuesta con número más alta y su valor
q Nh: número de propuesta más alto visto
q N: número de propuesta actual

Fase 1
§ Fase 1 (Propuesta):
q Un nodo decide hacer una propuesta (líder)
q Elige N > Nh
q Envía (propuesta, N) a todos los nodos
q Cuando se recibe (propuesta, N)
IF (N < Nh)
Responder rechazar
ELSE
Nh = N
Responder (propuesta-OK, Na, Va)
No aceptará ninguna propuesta futura con valor < N

Fase 2
§ Fase 2 (Aeptar):
q IF el lider obtiene una mayoría de OK
§ V = valor del Na recibido más alto
§ IF (V = null) el lider elige cualquier valor V
§ Envía (aceptar, N, -V) a todos los nodos
q IF el lider no obtiene mayoría
§ Espera y reinicia el protocolo
q Cuando un nodo recibe (aceptar, N, V)
IF (N < Nh)
Responde con rechazar
ELSE
Na = N; Va = V; Nh=N
Responder OK

Fase 3
§ Fase 3 (decidir)
q Si el lider recibe OK de una mayoría
§ Envía (decidir, Va) a todos los nodos
q Sino espera (aleatoriamente) y reinicia el protocolo

Ejemplo

Acuerdo bizantino
§ En la mayoría de las ocasiones cuando un componente o

sistema falla, su funcionamiento es arbitrario.
q Pueden enviar información diferente a diferentes
componentes con los que se comunica.
q Alcanzar un acuerdo entre las observaciones que hacen
diferentes componentes puede ser complicado en presencia
de fallos.
§ El objetivo con acuerdo bizantino es alcanzar un acuerdo
sobre un determinado valor en un sistema donde los
componentes pueden fallar de forma arbitraria.
§ Importancia:
q Permite enmascarar fallos arbitrarios.
q Permite construir procesadores con fallos de tipo fallo-
parada
Definición del problema
§ Sistema distribuido compuesto por una serie de nodos

(generales) que intercambian información entre ellos.
§ Los componentes pueden exhibir fallos bizantinos (generales
traidores)
q Un nodo con fallo puede enviar información diferente a
diferentes nodos (para un mismo dato).
§ Objetivo: que los nodos sin fallo alcancen un acuerdo o

consenso sobre un determinado valor (ataque, retirada, espera).
Es decir que vean el mismo valor para un dato.

Problema con tres nodos
nodo k
nodo i nodo j
0
X
¿puede el nodo i y nodo k llegar a un consenso en el valor?

1 nodo k
1
nodo i 0
nodo j
0
X

1 nodo k
0
nodo i 0
nodo j
1 0

§ Utilizando tres nodos, si uno falla el problema no puede

resolverse.
§ Se necesitan 3m+1 nodos para hacer frente a m fallos
bizantinos
1 nodo k
1
nodo i 0
nodo j
1 nodo k
0
nodo i 0
nodo j

Solución para cuatro nodos
} Suposiciones:
Los mensajes enviados se entregan correctamente.
}
El receptor conoce al emisor de un mensaje

}
Se puede detectar la ausencia de un mensaje

}
} Algoritmo (Lamport, Pease y Shostack) para cuatro nodos:

Se basa en el intercambio de mensajes entre los nodos
}
Cada nodo Ni realiza la observación Oi

}
Cada nodo mantiene un vector V con información recibida de los

}
otros nodos. Vi(j) almacena el valor recibido de Nj

Inicialmente Vi(i) = Oi y Vi(j) = null (" i ¹ j)
}
Cada nodo envía un mensaje al resto indicando su observación.

}
Cuando un nodo recibe una observación actualiza su vector y

}
envía a los otros dos nodos la observación recibida.

Solución
§ Después del intercambio de mensajes, cada nodo construye un
vector con los valores mayoritarios
§ Si no existe mayoría entonces se asume que no hay un
observación coherente.

Ejemplo. Etapa inicial
Nodo 1
* * * *
Nodo 4 Nodo 2
* * * E * A * *
Nodo 3
* * A *

Ejemplo. Primer intercambio de mensajes
Nodo 1
* * * *
Nodo 4 Nodo 2
E A A E R A A E
Nodo 3
R A A E
V3(1) V3(2) V3(3) V3(4)

Ejemplo. Segundo intercambio de mensajes
Nodo 1
* * * *
Nodo 4 Nodo 2
E A A E V4(j) V2(j) R A A E
R E V1(j) V1(j) R R
V2(j)
Nodo 3 V3(j)
R A R E
R A A E V3(j)
R A V3(j) V4(j) E A
E R V1(j)
Vi(1) Vi(2) Vi(3) Vi(4) Vi(1) Vi(2) Vi(3) Vi(4)
R E V2(j)
E A V3(j)
Vi(1) Vi(2) Vi(3) Vi(4)
Vi(j) -> La observación que de j dice i

Etapa final
Nodo 1 Nodo 2
V2(j) R A A E
* * * *
V1(j) R R
V3(j) R E
V4(j) E A
Nodo 4
Vi(1) Vi(2) Vi(3) Vi(4)
R A A E
Nodo 2
Nodo 3 R A A E
R A A E

El problema del interbloqueo
§ Situación en la que cada proceso

está bloqueado en espera de un PA R2
recurso (o evento) que está asignado

a (o sólo puede producir)
un proceso (también bloqueado) del R1 PB
conjunto
•Interbloqueo
§ Tipos:
q De recursos
q De comunicación

Estrategias
§ Modelización de interbloqueos mediantes grafos

§ Prevención de interbloqueos
§ Evitación de interbloqueos
§ Detección de interbloqueos

Estados globales consistentes
§ En un sistema distribuido existen ciertas situaciones que no es

posible determinar de forma exacta por falta de un estado
global:
q Recolección de basura: Cuando un objeto deja de ser
referenciado por ningún elemento del sistema.
q Detección de interbloqueos: Condiciones de espera cíclica
en grafos de espera (wait-for graphs).
q Detección de estados de terminación: El estado de actividad
o espera no es suficiente para determinar la finalización de
un proceso.

Definiciones
El estado global de un sistema distribuido se denota por G=(S,L),

donde:
q S={s1, s2, s3, s4,...,sM} : Estado interno de cada uno de los M
procesadores.
q L={Li,j| i,j Î1..M} : Li,j Estado de los canales unidireccionales
Ci,j entre los procesadores. El estado del canal son los
mensajes en él encolados
m1 m2 m2 mk
Sj Si
Cij
Lij={m , …, m } 1 k

Snapshots
El análisis de los estados globales de un sistema se realiza por
medio de snapshots: Agregación del estado local de cada
componente así como de los mensajes actualmente en
transmisión.
Debido a la imposibilidad de determinar el estado global de todo

el sistema en un mismo instante se define una propiedad de
consistencia en la evaluación de dicho estado.

Cortes consistentes
§ Un corte es un conjunto de eventos (contiene al menos un

evento por proceso)
§ Un corte es consistente si para cada evento que contiene,
incluye también todos los eventos que le preceden causalmente
§ Si a y b son dos eventos en un sistema distribuido y C un corte
consistente, entonces:
q (a Î C) Ù (b ® a) Þ b Î C
§ Si para un mensaje m, el evento receive(m) Î C, entonces el
evento send(m) Î C.

Cortes Consistentes
Corte no consistente Corte consistente
p1 p2 p3 p1 p2 p3
m1 m1
m2 m4 no se m2
ha enviado
m3 m3
m4 ya ha
m4 m4
llegado
m5 m5

Algoritmo de Chandy-Lamport
§ Algoritmo para determinar un estado global consistente

§ Supone canales FIFO
§ Un proceso denominado iniciador comienza el algoritmo de
snapshot distribuido.
§ Cualquier proceso puede iniciar el algoritmo.
§ El proceso iniciador envía un mensaje especial denominado
“marcador”
§ El estado global consta de los estados de los procesos y de los
canales.
q Los canales son pasivos: la responsabilidad de registrar el
estado de un canal depende del proceso emisor

Suposiciones
§ Entre cada par de procesos el canal es FIFO

§ No hay fallos en los procesos ni en los canales durante la
ejecución del algoritmo
§ Cualquier proceso puede iniciar el algoritmo en cualquier
instante
§ Los procesos pueden seguir enviando y recibiendo los
mensajes de aplicación durante la ejecución del algoritmo
§ Idea: es que cada proceso registre su estado y para cada canal,

todos los mensajes que entraron después de que él registrata su
estado y antes de que el emisor le envíe un mensaje marcador
(lo que supone que ya ha registrado su estado).
Algoritmo
§ Entre Pi y Pj el canal se denomina Cij
§ Proceso iniciador (P1) de forma atómica:
q Registra su estado local S1
q P1 envía el marcador a todos sus vecinos a través de los canales salientes.
q A partir de este momento almacenará en los canales Ck1 los mensajes de
aplicación que vaya recibiendo
§ Cuando un proceso Pi recibe un marcador de Pj (iniciador o no):
q Si aun no ha grabado su estado:
§ Pi graba su estado Si
§ Graba el estado del canal Cji como vacío. Para el resto de canales se
almacenarán los mensajes de aplicación a partir de ese momento
§ Reenvía un mensaje marcador al resto de procesos (entre la recepción del
marcador y su reenvío no ejecuta ningún otro evento).
q Si ya ha grabado su estado:
§ Se registra el estado del canal Cji como completo
§ El algoritmo termina para un proceso una vez que ha recibido el marcador de todos
los procesos
Algoritmo
§ Una vez registrados todos los estados (el algoritmo ha

terminado)
q El estado global consistente puede ensamblarse en cada
proceso haciendo que cada proceso envíe los datos del
estado que él ha registrado, por ejemplo, a otro proceso

Ejemplo
saldo inicial saldo inicial
elementos disponibles elementos disponibles
Tipos de mensajes:
• (order 10, $100): se piden 10 elementos y se transfiere $100
• (5 widgets): se envían 5 elementos

Ejemplo
¿Qué estado se registra para cada proceso y cada canal?

Ejemplo
¿Qué estado se registra para cada proceso y cada canal?

Ejercicio
¿qué estado se registra?

Algoritmos Distribuidos PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Algoritmos Distribuidos PDF

Cargado por

Copyright:

Formatos disponibles

Diseño de Sistemas Distribuidos

Máster en Ciencia y Tecnología Informática

Modelos y algoritmos distribuidos

Félix García Carballeira

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •1

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •2

§ World Wide Web

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •3

§ Servicio de coordinación de alto rendimiento para construir

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •4

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •5

Impossibility of distributed consensus with one faulty

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •6

§ Datos organizados de forma jerárquica en memoria

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •7

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •8

§ Efímeros: los znodes creados por un cliente son borrados al

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •9

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •10

§ Los clientes puede hacer operaciones de lectura sobre un

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •11

§ Un cliente se conecta a ZooKeeper e inicia una sesión

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •12

§ Create(path, data, flags)

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •13

§ Create(path, data, flags)

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •14

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •15

client server replica

client server replica

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •16

client •read server replica

client server replica

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •17

client •write server replica

client •propagate & sych

client server replica

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •18

client server replica

client server replica

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •19

§ Consistencia secuencial: las actualizaciones de un cliente se

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •20

servidor será entregado a todos

§ El orden total lo consigue con identificadores únicos en los

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •22

§ En algoritmos distribuidos utilizados para:

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •23

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •24

§ Algoritmos que trabajan en sistemas distribuidos

q Gestión de datos y de recursos

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •25

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •26

q Entrega de mensajes acotada

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •27

§ Paso de mensajes síncrono

§ Paso de mensajes asíncrono

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •28

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •29

§ El estado de un sistema distribuido, C, se puede describir

•Félix García Carballeira •Sistemas Distribuidos (2017-2018) •30

§ En el sistema de transición de estados del sistema distribuido

§ En el sistema de transición de estados de cada proceso