Resumo Da Materia - P2

SISTEMAS DISTRIBUIDOS RESUMO P2
1) SINCRONIZAO DE RELGIO
Em um Sistema Distribuido conseguir acordo nos horrios no trivial, pois existem vrios ns de computao, cada
qual responsvel por manter sua informao local de tempo.
Por exemplo, um sistema com arquivos distribudos em dois nos. Qual arquivo mais novo? Do ponto de vista de um
observador externo quando cada maquina tem seu prprio relgio, um evento que ocorreu aps outro evento pode,
ainda assim, receber um horrio anterior. Conforme mostra a Figura abaixo:
A temporizao exata importante em sistemas de Operaes bancrias, Agendamento de pagamento, transferncias,

etc. Exemplos reais de problemas causados por relgio:
1. Bug do Milnio (Y2K): No foi um problema sob o ponto de vista do relgio, mas sim sob o ponto de vista da
representao de data (ano 2000 = 1900).
2. Bug do ano 2038: representao mxima 231-1 de um nmero signed 32-bit integer (time_t stamp in Unix). J
corrigido em arquiteturas 64-bits.
impossvel garantir sincronismo absoluto dos relgios, uma vez que, os cristais utilizados para medir o tempo
possuem frequncias diferentes um do outro.
RELGIOS FSICOS
So utilizados para fazer a Sincronizao Externa, pois alguns sistemas precisam sincronizar a base de tempo local com
uma base de tempo fsico. Para isto preciso ter um relgio externo para sincronizao, por exemplo, o UTC.
ALGORITMOS DE SINCRONICAO DE RELOGIOS

Tm como objetivo manter todas as mquinas o mais juntas
possvel em relao ao tempo. Os algoritmos so:
Algoritmo de Cristian (Relogio Fisico);
Algoritmo de Berkeley (Relogio Fisico);
Algoritmo de Bully (Algoritmo de Eleio Relogio
Logico);
Algoritmo Ring (Algoritmo de Eleio Relogio
Logico).
Fast Clock = Relogio Adiantado e Slow Clock = Relogio

Atrasado. Taxa mxima de deriva especifica at que ponto a
defasagem de um relgio pode chegar.
A diferena entre os vrios algoritmos de sincronizao de

relgio encontra-se exatamente na maneira como essa
sincronizao peridica feita.
ALGORITMO DE CRISTIAN
A meta neste caso manter todas as mquinas sincronizadas a esta. Assume servidor passivo. O mtodo diz que a
estao escrava pede mestra informao de relgio e com base nessa informao, o relgio local atualizado.
O Algoritmo de leitura de relgio remoto executado da seguinte forma:

estao escrava (E) envia mensagem mestra: "hora=?"
mestra (M) responde: "hora=T"
Seja D a metade do tempo de trnsito total das mensagens, medido no relgio de E, e min o seu valor mnimo. Se os
relgios de E e M esto corretos, o valor do relgio M, quando E recebe a mensagem "hora=T?", est no intervalo de:
[T + min(1 - r), T + 2D(1 + 2r) - min (1 + r)]
Elaborado por Luciana SA Amancio Pgina 1

Problemas a serem tratados
Falhas na estao mestra
Falhas em estaes escravas
Trfego muito varivel no sistema de comunicao
Relgios no podem andar para trs. Se o cliente est

atrasado a Soluo Reduzir/aumentar a freqncia do
relgio, por exemplo, Uma interrupo adiciona 10mseg.
Se Reduzir: interrupo 9mseg e Adiantar: interrupo
11mseg
Mensagens no so instantneas existem um Tempo de

propagao da mensagem e o Tempo de tratamento da
mensagem (geralmente desconhecido).
ALGORITMO DE BERKELEY
No existe uma mquina com relgio sincronizado
externamente. A meta neste caso manter todas
as mquinas sincronizadas entre si tanto quanto
possvel. Em Berkeley, servidor ativo, pois
Pergunta s mquinas o tempo, Calcula mdia e
Notifica novo tempo a todas as maquinas.
Esse mtodo adequado para um sistema no qual

nenhuma maquina tenha receptor WWV. A hora do
Daemon de Tempo tem que ser ajustada
manualmente pelo operador de tempos em
tempos.
Se a hora marcada pelo daemon nunca fosse

calibrada manualmente, no haveria dano nenhum
contanto que nenhum dos outros ns se comunique
com computadores externos.
RELGIOS LGICOS
So utilizados para fazer a Sincronizao Interna, pois os processos veem eventos ordenados pelos seus relgios locais.
RELOGIOS LOGICOS DE LAMPORT
Se dois processos no interagirem, no necessrio que seus relgios sejam sincronizados porque a falta de
sincronizao no seria observvel e, portanto, no poderia causar problemas. Alm do mais, de modo geral, o que
importa no que todos os processos concordem com a hora exata, mas com a ordem em que os eventos ocorrem.
Ou seja, o Sincronismo do Relogio possvel sem usar tempo absoluto, pois a ordenao no precisa de preciso, basta
saber quem veio antes de quem. A execuo de processos uma seqncia de eventos. Logo, Receber e Enviar
mensagens so eventos.
A Relao acontece-antes (), descreve
ordenamento causal entre eventos:
(1) Se a e b so eventos no mesmo processo e a

acontece antes de b, ento a b.
(2) Se a o envio de uma mensagem m de algum

processo e b a recepo da mesma mensagem m
por algum processo, ento a b.
(3) Se a b e b c ento a c. ( R transitiva)
Eventos Concorrentes: Dois eventos a e b so

concorrentes (a||b), se no a b nem b a.
Conforme mostra a Figura na prxima pgina.
SISTEMA DE RELGIOS LGICOS
Um sistema de relgios lgicos representado por uma funo C que atribui um numero C(a) para todo evento a em
um sistema distribudo.

Condio do relgio: Se a b ento C(a) < C(b), Se o evento a ocorre antes do evento b o sistema de relgios deveria
mostrar C(a) < C(b). Condio de correo:
(C1) Para quaisquer 2 eventos a e b no mesmo processo Pi, a ocorre antes de b se Ci(a) < Ci(b).
(C2)Se a o evento enviar mensagem para um processo X e b o evento de receber mensagem em um processo Y,
ento Cx(a) e Cy(b) devem ser atribudos de tal forma que Cx(a) < Cy(b).
As seguintes regras de implementao fazem com que as condies C1 e C2 sejam satisfeitas:

(RI1) Relgio Ci incrementado entre dois eventos sucessivos em um processo Pi: Ci = Ci + d (d>0)
(RI2) (a) Se a o envio de m pelo processo Pi ento m selada com Tm=Ci(a).
(b) Se b o recebimento de m pelo processo Pj ento Cj recebe um valor >= Cj e > que Tm: Cj = max( Cj, ,Tm+1 )
Exemplo de Relogio Logico de Lamport: Trs processos, cada um com seu prprio relgio, diferentes taxas.
Algoritmo de Lamport corrige os relgios.
Outro exemplo de aplicao de Relogio Logico de Lamport no Multicast totalmente ordenado. Considere a
situao em que um banco de dados foi replicado em vrios sites. Digamos que na cidade de Nova York uma copia do
banco de dados atualizada, por exemplo, deposito em uma conta. Depois na cidade do Rio de Janeiro outra copia
atualizada, outro deposito realizado nessa mesma conta.
A questo importante nesse exemplo que ambas as copias devem ser exatamente as mesmas. Situaes como estas
requerem um multicast totalmente ordenado, isto , uma operao multicast pela qual todas as mensagens so
entregues na mesma ordem a cada receptor.
ALGORITMO DE ELEIO
Muitos algoritmos distribudos so baseados em processo coordenador. Os algoritmos de eleio normalmente assumem
as seguintes asseres:
Cada processo tem um nmero nico (endereo de rede, por exemplo);
Em uma eleio o processo de mais alta prioridade eleito coordenador;
A prioridade por ser obtida atravs de um nmero atribudo externamente ou
Atravs de um conjunto de caractersticas como, % ocupao de CPU, memria disponvel, caractersticas da
interface de rede, custo de processamento, etc;
Todo processo conhece o nmero do outro, apenas no sabe quem est ativo ou no.
ALGORITMO DE ELEIO ALGORITMO BULLY

Quando um processo nota que o coordenador no esta
mais respondendo as requisies ele inicia uma eleio.
1. O Processo P envia uma mensagem election para

todos os processoz com nmeros mais altos (PID -
prioridade).
2. Se nenhum responde, P ganha eleio e torna-se
coordenador.
3. Se um dos com prioridade maior responde, ele
assume. Neste caso o trabalho de P est feito, ele espera
a mensagem coordinator.
4. Se mensagem coordinator no acontecer, inicia nova
eleio.
ALGORITMO DE ELEIO ALGORITMO RING
Os Processos so arranjados em um anel lgico. Todos

sabem seus sucessores:
P envia mensagem de election com seu PID
Sucessor recebe mensagem, adiciona seu PID e passa

para o prximo.
Quando voltar a P, a mensagem muda para coordinator

e volta a circular no anel.
Cada um assume que o coordenador o maior PID da

lista circulante, e a lista contm os PIDs ativos.
2) EXCLUSO MUTUA DISTRIBUIDA
Para evitar que acessos concorrentes corrompam o recurso ou o tornem inconsistente, so necessrias solues que
garantam acesso mutuamente exclusivo pelos processos. Na excluso mutua distribuda quanto maior o numero de ns
maior o tempo de resposta.
A Exluso Mtua Distribuda tem como objetivo garantir que dois processos no usaro as mesmas estruturas de dados
ao mesmo tempo, por exemplo, a = 5; a++; printf(%d,a); a = 8; a++; printf(%d,a);
As Regies crticas nos sistemas centralizados so tratadas por semforos e monitores, por exemplo. Em Sistemas
distribudos o sistema consiste de n processos; cada processo Pi reside em um processador diferente. Cada processo
tem uma seo crtica que requer excluso mtua. Se Pi esta executando em sua seo crtica, ento nenhum outro
processo Pj esta executando em sua seo crtica.
ALGORITMOS DE EXCLUSO MUTUA DISTRIBUIDA
Algoritmos distribudos de excluso mtua podem ser classificados em duas categorias diferentes: Solues baseadas
em ficha e Solues baseadas em permisso.

As Solues baseadas em ficha consegue a excluso mtua entre os processos com uma s ficha disponvel quem tiver
com a ficha pode acessar o recurso compartilhado. Quando o processo termina de utilizar o recurso a ficha passada
para o prximo processo est esperando utilizar o recurso.
As Solues baseadas em permisso o processo que quiser acessar um recurso compartilhado em primeiro lugar ter
que pedir permisso aos outros processos para utilizar o recurso.
Os algoritmos utilizados na Excluso Mtua Distribuida so:

Algoritmo Centralizado;
Algoritmo Distribuido;
Algoritmo Token Ring
ALGORITMO CENTRALIZADO
No algoritmo centralizado o processo coordenador entra na regio crtica e envia uma mensagem. O coordenador d
permisso ou no. Ele utiliza uma fila de espera. Ao sair da regio crtica: envia mensagem.
Um processo eleito como o coordenador. Sempre que um processo quiser acessar um recurso compartilhado, envia
uma mensagem de requisio ao coordenador declarando qual recurso quer acessar e solicitando permisso. Se
nenhum outro processo estiver acessando aquele recurso naquele momento, o coordenador devolve uma resposta
concedendo a permisso.
Vantagens:
justo;
No tem esfomeao;
tem poucas mensagens.
Desvantagens:
O coordenador um ponto de
falha nico, portanto, se ele
falhar, todo o sistema pode
cair;
Se os processos normalmente
bloquearem aps emitir uma
requisio, no podem
distinguir um coordenador
inativo de uma permisso
negada, visto que, em ambos
os casos, nenhuma mensagem
volta.
ALGORITMO DISTRIBUIDO
O Alogoritmo Distribuido requer que haja uma ordenao total de todos os eventos no sistema. Isto , para qualquer
par de eventos, como mensagens no pode haver ambiguidade sobre qual realmente aconteceu em primeiro lugar. O
algoritmo de Lamport um modo de conseguir essa ordenao e pode ser usado para fornecer marcas de tempo para
excluso mutua distribuda.
Quando um processo quer acessar um recurso compartilhado, monta uma mensagem que contem o nome do recurso,
seu numero de processo e a hora corrente. Depois, envia a mensagem a todos os outros processos (inclusive para ele
mesmo). Adota-se como premissa que o envio de mensagem confivel, ou seja, nenhuma mensagem se perde.
Quando um processo recebe uma mensagem de requisio de outro processo, a ao que ele executa depende de seu
prprio estado em relao ao recurso nomeado na mensagem. Trs casos tm de ser claramente distinguidos:
1) Se o receptor no estiver acessando o recurso e no quiser acessa-lo, devolve uma mensagem OK ao rementente.
2) Se o recepetor j tiver acessado o recurso, simplesmente no responde. E coloca a requisio em uma fila.
3) Se o receptor tambm quiser acessar o recurso, mas ainda no o fez, ele compara a marca de tempo da mensagem
que chegou com a marca de tempo contida na mensagem que enviou para todos. A mais baixa vence. Se a marca de
tempo da mensagem que acabou de chegar for mais baixa, o recepator devolve uma mensagem OK. Se a marca de
tempo de sua prpria mensagem for mais baixa, o receptor enfileira a requisio que est chegando e nada envia.
Aps enviar requisies que pecam permisso, um processo se detem e espera ate que todos tenham dado permisso.
Logo que todas as permisses tenham entrado, ele pode seguir adiante. Quando conclui, envia mensagens OK para
todos os processos que esto em sua fila e remove todos eles da fila.
Esse algoritmo mais lento, mais complicado, mais caro e menos robusto que o Algoritmo Centralizado.

Processo que recebe a mensagem de broadcast
Se no est na RC e no quer entrar, envia um ACK-OK
Se j est na RC, no responde e enfila a mensagem.
Se no est na RC, mas quer entrar, compara o
carimbo de tempo.
Se o carimbo de tempo recebido for menor, envia um
ACK-OK.
Se o seu carimbo de tempo for menor, no responde e
enfila a msg.
Processo que enviou a mensagem espera at receber
ACK-OK de todo grupo.
Todos os processos so envolvidos em todas as

decises de RC.
Problema: agora temos n pontos de falha.
ALGORITMO TOKEN RING

Conforme mostra a figura temos uma rede de
barramento sem nenhuma ordenao inerente dos
processos. Um anel logico construido em software e
a cada processo designada uma posio no anel.
As posies no anel podem ser alocadas em ordem

numrica de endereos de rede ou por alguns outros
meios. No importa qual a ordenao, o que importa
que cada processo saiba quem a vez depois dele
mesmo.
Quando o anel inicializado, o processo 0 recebe uma

ficha. A ficha circula ao redor do anel. Ele passada
do processo K para o processo K+1 em mensagens
ponto-a-ponto.
Quando um processo adquire a ficha de seu vizinho, verifica para confirmar se precisa acessar o recurso compartilhado.
Caso necessite, o processo se adiante, faz todo o trabalho que precisa fazer e libera o recurso. Aps concluir, passa a
ficha ao longo do anel. No permitido acessar o recurso novamente, de imediato, usando a mesma ficha. Se um
processo receber a ficha de seu vizinho e no estiver interessado no recurso, ele apenas passa a ficha adiante.
Vantagens: No ocorre inanio.
Desvantagens: A ficha pode se perder e precisar ser regenerada, mas difcil detectar que ela se perdeu. Queda de
um processo do anel
3) REPLICAO
A replicao de dados consiste na manuteno de mltiplas cpias da mesma informao em dispositivos distintos de
um sistema distribudo. O objetivo aumentar a confiabilidade (eficcia) e do desempenho dos servios distribudos.
um conceito de grande importncia em Sistemas Distribudos como Web/Internet, Sistemas de arquivos distribudos e
Banco de dados distribudos.
Logo, h duas razes primarias para replicar dados: confiabilidade e desempenho. Quando os dados so replicados
aumento a confiabilidade do sistema. Por exemplo, se um sistema de arquivos foi replicado, pode ser possvel
continuar trabalhando aps a queda de uma replica simplesmente com comutao para uma das outras replicas. Alm
disso, oferece melhor proteo contra dados corrompidos.
A replicao dos dados tambm ajuda a melhorar o desempenho do sistema. Por exemplo, um sistema distribudo
precisa ser ampliado em quantidade e rea geogrfica. A ampliao em quantidade ocorre quando um numero cada vez
maior de processos precisa acessar dados que so gerenciados por um nico servidor. A ampliao de uma rea
geogrfica ocorre quando se coloca uma copia dos dados prxima ao processo que os est usando, o tempo de acesso
aso dados diminui. Por consequncia o desempenho aumenta.
A replicao pode ter um impacto positivo ou negativo considervel no desempenho de uma aplicao distribuda. O
impacto Positivo o Caching que reduz o impacto negativo da latncia na comunicao ao aproximar a informao do
local onde ela requerida; E o processamento concorrente de pedidos por vrios servidores em paralelo (leitura de
vrios dados). O impacto Negativo que muitas rplicas para gerenciar pode causar lentido.
Um servio estar sempre disponvel enquanto for possvel aos clientes se dirigirem a um servidor alternativo sempre
que o servidor habitual falhar. A replicao tambm til para melhorar a disponibilidade de um sistema. Aumenta a
proporo de tempo em que o sistema opera corretamente. A replicao uma forma de contrariar os efeitos dos tipos
de falhas que reduzem a disponibilidade de um sistema como FALHA DE SERVIDORES e DESCONEXO DA REDE.

A disponibilidade depender do nmero de rplicas e da probabilidade de

falha de cada rplica. Se os dados de que depende um servio forem
distribudos por vrios servidores com probabilidade iguais de falhar p. A
probabilidade de todos n falharem = pn e a Disponibilidade = 1 pn.
A replicao uma forma bsica de introduzir tolerncia a falhas num

sistema distribudo, incluindo falhas arbitrrias (ex: sabotagem), pois
existindo mltiplas rplicas da mesma informao no bastar
comprometer um servidor.
RAZES PARA REPLICAO
Confiabilidade: Menos Falhas (se tem mais de uma opo disponvel) e proteo contra dados corrompidos;
Desempenho: Escalabilidade (mais servidores para responder as requisies); Caching (colocar cpia de dados
prximo aos processos); Ampliao em quantidade para dividir trabalho de servidor centralizado, diminuindo o
esforo para cada servidor e Ampliao geogrfica para diminuir tempo de acesso a dados, aumentando o
desempenho dos clientes.
PROBLEMA DA REPLICAO DE DADOS
O problema da replicao que ter mltiplas copias pode levar a problemas de consistncia, pois sempre que uma
copia modificada se torna diferente das restantes e preciso modificar todas as outras copias para garantir
consistncia. Quando os dados replicados esto sujeitos a modificaes necessrio assegurar que as replicas
permaneam consistentes, o que pode incorrer em um alto custo que afetar negativamente o desempenho do sistema.
4) CONSISTNCIA
Um conjunto de copias consistente quando todas as copia so sempre iguais. Isso significa que uma operao de
leitura realizada em qualquer copia sempre retornara o mesmo resultado. Em consequncia, quando uma operao de
atualizao realizada sobre uma copia, a atualizao deve ser propagada para todas as copias antes que ocorre uma
operao subsequente, sem importar em qual copia essa operao foi iniciada e realizada. Um exemplo de
implementao de Consistncia o HW RAID.
A questo de quanto em quanto tempo devemos atualizar o estado, pois o Overhead (custo computacional e de
comunicao) para manter a coerncia pode superar os beneficios de escalabilidade. Por exemplos, pginas Web. Em
muitos casos, a nica soluo real para manter todas as copias iguais relaxar as restries de consistncia.
Na ausncia de um relgio global, difcil definir com preciso qual operao de escrita a ultima. Como alternativa,
precisamos fornecedor outras definies, o que resulta em um conjunto de modelos de consistncia. Cada modelo
restringe efetivamente os valores que uma operao de leitura sobre um item de dados pode retornar. Os modelos que
tem grandes restries so fceis de usar os que tm pequenas restries so difceis de usar. No entanto, os modelos
fceis de usar no funcionam tao bem quanto os difceis de usar. Os Modelos de Consistencia utilizados so:
Modelos de Consistencia Centrados em Dados

Consistencia Continua
Consistencia Sequencial
Consistencia Causal
Modelos de Consistencia Centrados no Cliente

Consistencia Eventual

MODELO DE CONSISTNCIA CENTRADO EM DADOS

A consistncia tem sido discutida no contexto de
operaes de leitura e escrita em dados compartilhados
por meio de: Memria Compartilhada, Banco de Dados
Compartilhado e Sistema de Arquivos Compartilhado. Os
termos listados anteriormente sero chamados
indistintamente de Depsito De Dados.
Conforme mostra a Figura ao lado, operaes de escrita

so propagadas para outras copias. Uma operao de
dados classificada como uma operao de escrita
quando altera os dados, caso contrrio classificada
como uma operao de leitura.
Cada processo que pode acessar dados do depsito tem

uma cpia local (ou prxima) disponvel do depsito
completo. Operaes de escrita so propagadas para
outras Cpias.
Um Modelo de Consistncia um contrato entre processos e depsito de dados que firma que o depsito funcionar
de maneira correta se os processos concordarem em obedecer a certas regras.
CONSISTNCIA CONTNUA
No existe a melhor soluo para replicar dados. A replicao de dados prope problemas de consitencia que no
podem ser resolvidos com eficincia de modo geral. Somente se abrandamos a consistncia que podemos ter
esperana de conseguir solues eficientes. Infelizmente, tambm no h regras gerais para abrandar a consistncia: o
que, exatamente, pode ser tolerado depende muito das aplicaes.
H modos diferentes para as aplicaes especificarem quais inconsitencias elas podem tolerar. Existe uma abordagem
geral que distingue trs eixos independentes para definir inconsistncias: desvio em valores numricos entre
replicas, desvio em idade entre replicas e desvio em relao a ordenao de operaes de atualizao. Esses
desvios formam as faixas da Consistencia Continua.
A medicao da inconsistncia em termos de desvios numricos pode ser utilizada por aplicaes para as quais dados
tm semntica numrica. Por exemplo, a replicao de registros que contm preos do mercado de aes.
O desvio numrico tambm pode ser entendido em termos de numero de atualizaes que foram aplicadas a
determinada replica, mas que ainda no foram vistas pelas outras. Por exemplo, uma cache web pode no ter visto as
atualizaes realizadas em um servidor web.
Os devios de idade esto relacionados com a ltima vez que uma replica foi atualizada. Por exemplo, previses do
tempo em geral.
Por fim, h classes de aplicaes nas quais permitido que a ordenao das atualizaes seja diferente nas varias
replicas, contanto que as diferenas fiquem dentro de um limite.
CONIT (Consistency Unit)
Para definir inconsistncias foi proposta uma unidade de consistncia, abreviada para CONIT. Uma Conit especifica a
unidade segundo qual a consitencia deve ser medida. Monitorao de CONITs mede o quo distante uma rplica em
relao outra.
Embora do ponto de vista de conceito as conits formem um modo atraente de capturar requisitos de consistncia, h
duas questes importantes que precisam ser tratadas antes que elas possam ser colocadas em uso na pratica. A
primeira questo que, para impor consistncia, precisamos ter protocolos. A segunda questo que os
desenvolvedores de programas devem especificar os requisitos de consistncias para suas aplicaes.
Consistncia continua pode ser implementada como um conjunto de ferramentas que, para os programadores, parece
apenas uma outra biblioteca que eles integram as suas aplicaes. Um conit simplesmente declarada junto com uma
atualizao de um item de dados.
Granularidade de Conit: Necessrio compromisso para manter Conits de granularidade grossa e Conits de granularid
ade fina. Se uma conit representar uma grande quantidade de dados, tal como um banco de dados completo, as
atualizaes so agregadas para todos os dados na conit. Em decorrncia, isso pode levar as replicas a entrar mais cedo
em um estado inconsistente.

Por exemplo, a diferena entre duas rplicas no pode ter mais que uma atualizao pendente. Nesse caso, quando
cada um dos itens de dado mostrado na Figura 7.3(a) tiver sido atualizado uma ves na primeira replica, a segunda
tambm precisara ser atualizada. Isso no acontece quando escolhermos uma conit menor, como mostra a Figura
7.3(b). Nesse caso, as replicas ainda so consideradas como atualizadas. Esse problema de particular importncia
quando os itens de dados contidos em uma conit so usados com total independncia; ento, diz-se que eles
compartilham falsamente a conit.
ORDENAO CONSISTENTE DE OPERAES
Os Modelos de programao concorrente que tratam de ordenar operaes consistentemente em dados compartilhados
replicados:
Consistncia Sequencial
Consistncia Causal
Ampliam os modelos de consistncia contnua no sentido que, quando for preciso comprometer atualizaes provisrias
em rplicas, estas tero de chegar a um acordo sobre uma ordenao global dessas atualizaes.
CONSISTNCIA SEQUENCIAL
A consistncia sequencial um modelo de consistncia centrado em dados que foi definido por Lamport 1979. Rm geral
diz que um deposito de dados sequencialmente consistente quando satifaz a seguinte condio:
O resultado de qualquer execuo o mesmo que seria se as operaes (de leitura e escrita) realizadas por
todos os processos no depsito de dados fossem executadas na mesma ordem sequencial e as operaes de
cada processo individual aparecessem nessa sequncia na ordem especificada por seu programa.
Essa definio significa que, quando processos executam concorrentemente em maquinas (possivelmente) diferentes,
qualquer intercalao vlida de operaes aceitvel, mas todos os processos vem a mesma intercalao de
operaes. Nada dito sobre o tempo. Nesse contexto o processo v escritas de todos, mas apenas suas prprias
leituras.
Notao:
As operaes de um processo so representadas ao longo de um eixo de tempo. Eixo de tempo na horizontal (tempo
cresce da esquerda para a direita)
Wi(x)a: Processo i escreve valor a em item de dados x
Ri(x)b: Processo i l valor b em item de dados x
Exemplo:
P1 executa uma escrita para um item de dados x, modificando o seu valor para a. Esta operao feita localmente e
depois propagada para os outros processos.
Mais tarde, P2 l o valor NIL e, pouco tempo depois, l a. (Existe um retardo para propagar a atualizao de x para
P2).

O contrato entre processos e o depsito de dados que os processos devem aceitar todos os resultados vlidos como
respostas adequadas e devem trabalhar corretamente se qualquer um deles ocorrer.
CONSISTNCIA CAUSAL
O modelo de Consistencia Causal representa um enfraquecimento da consistncia sequencial no sentido que faz
distino entre eventos que so potencialmente relacionados por causalidade e os que no so. Se o evento b
causado ou influenciado por um evento anterior a, a causalidade requer que todos vejam primeiro a e, depois, b.
Operacoes que no esto relacionadas por causalidade so denominadas concorrentes.
Para um depsito de dados ser considerado consistente por causalidade, necessrio que obedea seguinte condio:
Escritas que so potencialmente relacionadas por causalidade devem ser vistas por todos os processos na
mesma ordem. Escritas concorrentes podem ser vistas em ordem diferente em mquinas diferentes.

Portanto, implementar consistncia causal requer monitorar quais processos viram quais escritas, ou seja, significa que
preciso contruir e manter um grfico de dependncia que mostre qual operao dependente de quais outras
operaes. Uma maneira de fazer isso por meio de marcas de tempo vetoriais.
CONSISTNCIA versus COERNCIA
Um modelo de consistncia descreve o que pode ser esperado com relao aquele conjunto quando vrios processos
operam concorrentemente sobre aqueles dados. Ento, diz-se que o conjunto consistente se ele aderir as regras
descritas pelo modelo.
Onde a consistncia de dados se refere a um conjunto de itens de dados, modelos de coerncia descrevem o que pode
ser esperado para s um item de dados. Nesse caso, consideramos que um item de dados replicado em diversos
lugares; diz-se que ele coerente quando as varias copias aderem as regras como definidas por seu modelo de
coerncia associado.
MODELO DE CONSISTNCIA CENTRADOS NO CLIENTE
A capacidade de manipular operaes concorrentes sobre dados compartilhados e, ao mesmo tempo, manter a
consistncia sequencial fundamental para sistemas distribudos. Os depsitos de dados que focalizaremos so
caracterizados pela ausncia de atualizaes simultneas ou, quando tais atualizaes acontecem, elas podem ser
resolvidas com facilidade. Esses depsitos de dados oferecem um modelo de consistncia eventual.
Evitar consistncia no sistema todo, concentrando em o que os clientes querem, e no o que deveria ser mantido pelos
servidores.
Os Sistemas Distribuidos de grande escala (banco de dados) aplicam replicao para escalabilidade, mas podem
suportar apenas consistncia fraca, so eles:
DNS mudanas so propagadas devagar, inseres podem no ser imediatamente visveis.
NEWS artigos e reaes so colocadas e puxadas atravs da internet, de forma que reaes podem ser
vistas antes.
Lotus Notes servidores geograficamente dispersos replicam documentos, mas no fazem tentativa de
manter modificaes (concorrentes) mutuamente consistentes.
WWW Caches esto em todo lugar, mas no tem precisa garantia que est lendo a mais recente verso da
pgina.

CONSISTNCIA EVENTUAL (CONSISTNCIA PARA USURIOS MVEIS)
Banco de dados (de grande escala) distribudos e replicados que toleram um grau relativamente alto de inconsistncia,
por exemplo, DNS e WWW. Esses bancos de dados tm em comum que, se, nenhuma atualizao ocorrer por tempo
bastante longo, todas as replicas ficaro gradativamente consistentes. Essa forma de consistncia denominada
consistncia eventual.
Assim, depsitos de dados de consistncia eventual tm a seguinte propriedade: na ausncia de atualizaes, todas as
replicas convergem em direo a copias idnticas umas as outras. Em essncia, consistncia eventual exige apenas a
garantia de que as atualizaes sero propagadas para todas as replicas. De modo geral, conflitos escrita-escrita so
relativamente fceis de resolver quando consideramos que somente um pequeno grupo de processos pode realizar
atualizaes.
Depsitos de dados de consistncia eventual funcionam bem, contanto que os clientes sempre acessem a mesma
replica. Contudo, surgem problemas quando so acessadas replicas diferentes em um curto perodo.
Por exemplo, considere uma base de dados distribuda (conforme mostra a Figura ao lado) na qual voc tem acesso
atravs de seu notebook. Assumir que o notebook age como um front end para a base de dados. Na localizao A
acesso a base fazendo leituras e escritas.
Na localizao B continua seu trabalho, mas a no ser que voc acesse o mesmo servidor acessado na localizao A,
voc pode detectar inconsistncias como:
Suas atualizaes em A podem no terem sido propagadas ainda para B;
Voc pode estar lendo novas entradas daquelas disponveis em A
Suas modificaes em B podem eventualmente estar em conflito com aquelas em A.
Nota: A nica coisa que voc quer que as entradas que voc atualizou e/ou leu em A, esto em B da forma como voc
deixou em A. Assim, a base parecer consistente para voc.
Esse exemplo tpico de depsitos de dados de consistncia eventual e causado pelo fato de que, as vezes, os
usurios podem operar sobre replicas diferentes. O problema pode ser amenizado com a introduo de consistncia
centrada no cliente que d a um nico cliente uma garantia de consistncia de acesso a um deposito de dados por
esse cliente; no h nenhuma garantia para acessos concorrentes por clientes diferentes.
Modelo de consistncia centrado no cliente tem como premissa que a conectividade de rede no confivel e sujeita a
vrios problemas de desempenho. Existem quatro modelos de consistncia centrados no cliente que so:
Reads Monotnicos (Leituras Monotonicas)
Writes Monotnicos (Escritas Monotonicas)
Ler Escritas (Leia-suas-escritas)
Escrita-segue-Leitura (Escritas-seguem-leituras)

READS MONOTNICOS
O primeiro modelo de consistncia centrado no cliente o de leituras monotonicas. Diz-se que um deposito de dados
oferece consistncia de leitura monotonica se a seguinte condio for cumprida:
Se um processo ler o valor de um item de dados X, qualquer operao sucessiva de leitura em X executada
por esse processo sempre retornar o mesmo valor ou um valor mais recente (no l valores antigos).
Exemplo de Reads Monotonicos um banco de dados distribudo de email.
Na Figura acima (a) mostra o processo P realizando primeiro uma operao de leitura em X em L1, retornando o valor
de x1 (naquele instante). Esse valor resulta das operaes de escrita em WS(x1) realizadas em L1. Mais tarde, P realiza
um operao de leitura em x em L2. Para garantir consistncia de leitura monotonica, todas as operaes em
WS(x1) deveriam ter sido propagadas para L2 antes de ocorrer a segunda operao de leitura. Precisamos saber com
certeza que WS(x1) parte de WS(x2) o que expresso por WS(x1;x2).
Na Figura (b) mostra a situao na qual a consistncia de leitura monotonica no garantida. Depois de ler x1 em L1, o
processo P realiza a operao R(x2) em L2. Contudo, somente as operaes de escrita em WS(x2) foram realizadas em
L2. No h nenhuma garantia de que esse conjunto tambm contem todas as operaes contidas em WS(x1).
WRITES MONOTNICOS
Em muitas situaes, importante que operaes de escrita sejam propagadas na ordem correta para todas as copias
do deposito de dados. Essa propriedade expressa em consistncia de escrita monotonica. Em seu deposito vale a
seguinte condio:
Uma operao de escrita executada por um processo em um item de dados x concluda antes de qualquer
operao de escrita sucessiva em x pelo mesmo processo.
Exemplo de Writes Monotonicos uma biblioteca de software.
Na Figura acima em (a) o processo P realiza umaa operao de escrita em x na copia local L1. Mais tarde, P executa
outra escrita em L2. Para garantir consistncia de escrita monotonica, necessrio que a operao de escrita anterior
em L1 j tenha sido propagada para L2.
Na Figura acima em (b) est faltando a propagao de W(x1) para copia L2. Em outras palavras, no garantida a
consistncia de escrita monotonica, pois no possvel garantir que a copia de x na qual a segunda escrita est sendo
realizada tem o mesmo valor ou o valor mais recente no tempo W(x1) concludo em L1.
LER ESCRITAS
A seguir, apresentamos um modelo de consistncia centrado no cliente que est intimamente relacionado com leituras
monotnica. Diz-se que um deposito de dados fornece consistncia leia-suas-escritas, se a seguinte condio for valida:
O efeito de uma operao de escrita por um processo no item de dados x sempre ser visto por uma
operao de leitura sucessiva em x pelo mesmo processo.

Exemplo de Ler-escritas o browser Web.
Na Figura acima em (a) o processo P realizou uma operao de escrita W(x1) e, mais tarde, uma operao de leitura
em uma copia local diferente. A consistncia leia-suas-escritas garante que os efeitos da operao de escrita podem ser
vistos pela operao de leitura subsequente. Isso expresso por WS(x1;x2), que declara que W(x1) parte de WS(x2).
Na Figura (b) W(x1) foi deixada de fora de WS(x2), o que significa que os efeitos da operao de escrita pelo processo
anterior P no foram propagados para L2.
Escrita-segue-Leitura
O ultimo modelo de consistncia centrado no cliente um modelo no qual as atualizaes so propagadas como
resultado de operaes de leitura precedentes. Diz-se que um depositi de dados prov consistncia de escritas-
seguem-leituras, se a seguinte condio for vlida:
Uma operao de escrita por um processo em um item de dados x em seguinte a uma operao de leitura
anterior em x pelo mesmo processo ocorre sobre o mesmo valor, ou sobre o valor mais recente de x que foi
lido.
Na Figura acima em (a) um processo l x na copia local L1. As operaes de escrita que levaram ao valor que acabou
de ser lido tambm aparecem no conjunto de escrita em L2, onde o mesmo processo realiza, mais tarde, uma operao
d escrita.
Na Figura em (b) no dada nenhuma garantia de que a operao em L2 realizada sobre uma copia consistente com
que acabou de ser lida em L1.
5) GERENCIAMENTO DE REPLICAS
Uma questo fundamental para qualquer sistema distribudo que suporta replicao decidir onde, quando e por quem
as replicas devem ser posicionadas e, na sequencia, quais mecanismos usar para manter as replicas consistentes. O
problema do posicionamento em si deve ser subdividido em dois subproblemas: o de posicionar servidores de replicas e
o de posicionar contedo.
O posicionamento de servidor de replicas refere-se a achar as melhores localizaes para colocar um servidor que pode
hospedar um deposito de dados (ou parte dele).
Posicionamento de contedo refere-se a achar os melhores servidores para colocar contedo.
6) PROTOCOLOS DE CONSISTNCIA
Um Protocolo de Consistncia descreve uma implementao de um modelo especfico de consistncia. Os modelos mais
importantes e aplicados so aqueles onde as operaes so globalmente serializadas (seqencial, fraca c/sincronizao,
transaes). Enfatizamos apenas protocolos para consistncia sequencial que so:
Protocolo baseado em cpia primria
Protocolo escrita remota
Protocolo escrita local
Protocolo escrita-replicada: Replicao ativa
Protocolo de Votao
Protocolo de coerncia de cache

PROTOCOLO BASEADO EM CPIA PRIMRIA
No caso de consistncia sequencial prevalecem os protocolos baseados em primrios. Nesses protocolos, cada item de
dados x no deposito de dados tem um primrio associado, que responsvel por coordenar operaes de escrita em x.
PROTOCOLO ESCRITA REMOTA
O protocolo mais simples baseado em primrio e que suporta replicao aquele em que as operaes de escrita
precisam ser enviadas para um nico servidor fixo. Operaes de leitura podem ser executadas no local. Esses
esquemas tambm so conhecidos como protocolos de primrio e backup. Ele funciona como mostra a Figura abaixo:
Um processo que quer realizar uma operao de escrita, em um item de dados, envia essa operao para o servidor de
primrios para x. O servidor primrio executa a atualizao em sua copia local de x e, na sequencia, envia a atualizao
para os servidores de backup. Cada servidor de backup tambm efetua a atualizao e envia um reconhecimento de
volta ao servidor primrio. Quando todos os servidores de backup tiverem atualizado sua copia local, o servidor
primrio envia um reconhecimento de volta ao processo inicial.
Um problema potencial de desempenho desse esquema que pode levar um tempo relativamente longo antes que o
processo que iniciou a atualizao tenha permisso para continuar. Na verdade, uma atualizao implementada como
uma operao de bloqueio. Uma alternativa usar uma abordagem no bloqueadora. Tao logo o servidor primrio
tenha atualizado sua copia local de x, ele retorna um reconhecimento.
O principal problema de protocolos de primrio backup no bloqueadores tem a ver com tolerncia a falha. Com um
sistema bloqueador, o processo cliente sabe, com certeza, que a operao de atualizao apoiada por vrios outros
servidores. Isso no ocorre com uma soluo no bloqueadora.
Protocolos Escrita-Local
Um variante dos protocolos de primrio e
backup aquela em que a copia primaria
migra entre processos que desejam realizar
uma operao de escrita.
Sempre que um processo quer atualizar um

item de dados x, ele localiza a copia primaria
de x e, na sequencia, move essa copia para
sua prpria localizao, como mostra a Figura
ao lado.
A principal vantagem dessa abordagem que

mltiplas operaes sucessivas de escrita
podem ser executadas no local enquanto
processos leitores ainda podem acessar sua
copia local.
Contudo, so se pode conseguir tal melhoria se

for seguido um protocolo no bloqueador pelo
qual as atualizaes so propagadas para as
replicas aps o servidor primrio ter concludo
as atualizaes realizadas localmente.

PROTOCOLOS ESCRITA-REPLICADA
Em protocolos de escrita replicada, operaes de escrita podem ser executadas em varias replicas em vez de em s
uma, como no caso de replicas baseadas em primrios. Pode-se fazer uma distino entre replicao ativa, na qual uma
operao repassada para todas as replicas, e protocolos de consistncia baseados em voto majoritrio. Protocolos
deste tipo so:
Replicao Ativa onde uma operao repassada para todas as rplicas
Votao da maioria fazer com que os clientes requisitem e adquiram a permisso de mltiplos servidores
antes de ler ou escrever um item de dados replicado
REPLICAO ATIVA
Em replicao ativa, cada replica tem um processo associado que realiza as operaes de atualizao. Ao contrario de
outros protocolos, de modo geral, as atualizaes so propagadas por meio da operao de escrita que causa a
atualizao.
Um problema da replicao ativa que as operaes precisam ser executadas na mesma ordem em todos os lugares.
Por isso, preciso de um mecanismo de multicast totalmente ordenado. Tal multicast pode ser implementado com o
uso de relgios lgicos de Lamport.
Infelizmente essa implementao de multicast tona-se muito complexa em grandes sistemas distribudos. Como
alternativa, pode-se conseguir ordenao total usando um coordenador central, tambm denominado sequenciador.
Contuto, ele no resolve o problema de escalabilidade.
Protocolos de Votao
Uma abordagem diferente para suportar escritas replicadas usar votao. A ideia bsica exigir que clientes
requisitem e adquiram a permisso de vrios servidores antes de ler ou escrever um item de dados replicado.
O esquema do protocolo de votao diz que para ler um arquivo do qual existem N replicas, um cliente precisa
conseguir um qurum de leitura, um conjunto arbitario de quaisquer NR servidores, ou mais. De maneira semelhante,
para modificar um arquivo, exigido um qurum de escrita de, no mnimo, NW servidores. Os valores de NR e NW
esto sujeitos as duas restries seguintes:
1. NR + NW*N
Usada para evitar conflitos leitura-escrita.
2. NW*N/2
Usada para impedir conflitos escrita-escrita.
Para ver como esse algoritmo funciona, considere

Para ver como esse algoritmo funciona, considere a Figura acima, em (a) NR = 3 e NW = 10. Imagine que o qurum
de escrita mais recente consistiu em 10 servidores, C a L. Todos eles obtem a nova verso e o novo numero de verso.
Qualquer qurum de leitura subsequente de trs servidores ter de conter, no mnimo, um membro desse conjunto.
Quando o cliente vir os nmeros de verso, saber qual a mais recente e a adotar.
Em (b) pode ocorrer conflito escrita-escrita porque NW<=N/2. Em particular, se um dos clientes escolher {A,B,C,E,F,G}
como seu conjunto de escrita e um outro cliente escolher {D,H,I,J,K,L} como seu conjunto de escritas, ento estaremos
claramente em dificuldades porque ambas as atualizaes sero aceitas sem detectar que, na verdadem esto em
conflito.
Em (c) de especial interesse porque fixa NR em um, o que possibilita ler um arquivo replicado descobrindo e usando
qualquer copia.
Protocolos de Coerencia de cache
Caches so um caso especial de replicao, no sentido de que, em geral, so controladas por clientes, em vez que
servidores. Contudo protocolos de coerncia de cache que garantem que uma cache consistente com as replicas
iniciadas por servidor, em principio, no so muito diferentes dos protocolos de consistncia.
Em primeiro lugar, as solues de cache podem ser diferentes quanto a estratgia de deteco de coerncia, isto ,
quando as inconsistncias so realmente detectadas. Em solues estticas, a premissa adotada que um compilador
realize a analise necessria anterior a execuo e determine quais dados podem realmente levar a inconsistncias
porque podem ser colocados em cache. O compilador simplemente insere instrues que evitam inconsistncias.
Nos sistemas distribudos so aplicadas solues dinmicas. Nessa solues, as inconsistncias so detectadas em
tempo de execuo. Por exemplo, feita uma verificao no servidor para ver se os dados em cache foram modificados
desde que entraram na cache. No caso de banco de dados distribudos, os protocolos baseados em deteco dinmica
ainda podem ser classificados considerando exatamente em que ponto de uma transao a deteco feita.
Distinguem-se em trs casos seguintes.
No primeiro, quando um item de dados em cache acessado durante um transao, o cliente precisa verificar se esse
item de dados ainda consistente com a verso armazenada no servidor (possivelmente replicado). A transao no
pode prosseguir e usar a verso em cache at que sua consistncia tenha sido definitivamente validada.
Na segunda abordagem, a otimista, a transao pode prosseguir enquanto ocorre a verificao. Nesse caso, a premissa
adotada que os dados em cache estavam atualizados quando a transao comecaou. Se, mais tarde, essa premissa
mostrar ser faksam a transao ter de ser abortada.
A terceita abordagem verificar se os dados em cache esto atualizados somente quando a transao for
comprometida. Essa abordagem comparvel ao esquema otimista de controle de concorrncia. Na verdade, a
transao apenas inicia a operao nos dados em cache e espera que o melhor aconteca. Depois que todo o trabalho foi
realizado, verificada a consistncia dos dados acessados. Quando forem usados dados antigos, a transao
abortada.
Uma outra questo de projeto para protocolos de coerncia de cache a estratgia de imposio de coerncia, que
determina como as caches so mantidas consistentes com as copias armazenadas em servidores. A soluo mais
simples no permitir que dados compartilhados sejam colocados em cache. Em vez disso, dados compartilhados so
guardados somente nos servidores, que mantem consistncia usando um dos protocolos baseados em primrios ou de
replicao de escrita.
Quando dados compartilhados podem ser colocados em cache, h duas abordagens para impor coerncia de cache. A
primeira permitir que um servidor envie uma invalidao a todas as caches sempre que um item de dado for
modificado. A segunda simplesmente propagar a atualizao.

Resumo Da Materia - P2

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Resumo Da Materia - P2

Загружено:

Авторское право:

Доступные форматы

SISTEMAS DISTRIBUIDOS RESUMO P2

A temporizao exata importante em sistemas de Operaes bancrias, Agendamento de pagamento, transferncias,

ALGORITMOS DE SINCRONICAO DE RELOGIOS

Fast Clock = Relogio Adiantado e Slow Clock = Relogio

A diferena entre os vrios algoritmos de sincronizao de

O Algoritmo de leitura de relgio remoto executado da seguinte forma:

Elaborado por Luciana SA Amancio Pgina 1

Relgios no podem andar para trs. Se o cliente est

Mensagens no so instantneas existem um Tempo de

Esse mtodo adequado para um sistema no qual

Se a hora marcada pelo daemon nunca fosse

RELOGIOS LOGICOS DE LAMPORT

(1) Se a e b so eventos no mesmo processo e a

(2) Se a o envio de uma mensagem m de algum

(3) Se a b e b c ento a c. ( R transitiva)

Eventos Concorrentes: Dois eventos a e b so

Elaborado por Luciana SA Amancio Pgina 2

As seguintes regras de implementao fazem com que as condies C1 e C2 sejam satisfeitas:

ALGORITMO DE ELEIO ALGORITMO BULLY

Elaborado por Luciana SA Amancio Pgina 3

1. O Processo P envia uma mensagem election para

ALGORITMO DE ELEIO ALGORITMO RING

Os Processos so arranjados em um anel lgico. Todos

P envia mensagem de election com seu PID

Sucessor recebe mensagem, adiciona seu PID e passa

Quando voltar a P, a mensagem muda para coordinator

Cada um assume que o coordenador o maior PID da

2) EXCLUSO MUTUA DISTRIBUIDA

ALGORITMOS DE EXCLUSO MUTUA DISTRIBUIDA

Elaborado por Luciana SA Amancio Pgina 4

Os algoritmos utilizados na Excluso Mtua Distribuida so:

Elaborado por Luciana SA Amancio Pgina 5

Todos os processos so envolvidos em todas as

Problema: agora temos n pontos de falha.

ALGORITMO TOKEN RING

As posies no anel podem ser alocadas em ordem

Quando o anel inicializado, o processo 0 recebe uma

Vantagens: No ocorre inanio.

Elaborado por Luciana SA Amancio Pgina 6

A disponibilidade depender do nmero de rplicas e da probabilidade de

A replicao uma forma bsica de introduzir tolerncia a falhas num

RAZES PARA REPLICAO

PROBLEMA DA REPLICAO DE DADOS

Modelos de Consistencia Centrados em Dados

Modelos de Consistencia Centrados no Cliente

Elaborado por Luciana SA Amancio Pgina 7

MODELO DE CONSISTNCIA CENTRADO EM DADOS

Conforme mostra a Figura ao lado, operaes de escrita

Cada processo que pode acessar dados do depsito tem

CONIT (Consistency Unit)

Elaborado por Luciana SA Amancio Pgina 8

ORDENAO CONSISTENTE DE OPERAES

Elaborado por Luciana SA Amancio Pgina 9

Elaborado por Luciana SA Amancio Pgina 10

CONSISTNCIA versus COERNCIA

MODELO DE CONSISTNCIA CENTRADOS NO CLIENTE

Elaborado por Luciana SA Amancio Pgina 11

Suas atualizaes em A podem no terem sido propagadas ainda para B;

Voc pode estar lendo novas entradas daquelas disponveis em A

Suas modificaes em B podem eventualmente estar em conflito com aquelas em A.

Reads Monotnicos (Leituras Monotonicas)

Writes Monotnicos (Escritas Monotonicas)

Ler Escritas (Leia-suas-escritas)

Elaborado por Luciana SA Amancio Pgina 12