Unidade 1

Prévia do material em texto

SISTEMAS DISTRIBUÍDOSSISTEMAS DISTRIBUÍDOS
CONCEITOS INICIAISCONCEITOS INICIAIS
Autor: Dr. Sidartha Azevedo Lobo de Carvalho
R e v i s o r : L i z a n d r o d e S o u z a
I N I C I A R
introdução
Introdução
Nesta unidade, você vai aprender sobre os principais conceitos que permeiam o 
mundo dos sistemas distribuídos, as principais características que são usadas para 
classificar esses sistemas e como ocorre a comunicação entre os processos que 
executam dentro dos programas do usuário e dos servidores.
Você vai entender como é feita a criação e identificação de processos e o 
escalonamento destes dentro do sistema operacional. Além disso, vai aprender 
sobre os principais modelos e padrões arquiteturais de comunicação para os 
sistemas distribuídos. Por fim, vai entender o que é e como funciona o modelo 
cliente-servidor, utilizado em todo o mundo.
Nesta seção, você vai aprender o que é um sistema distribuído e quais as principais 
características desse tipo de sistema. Primeiramente, você sabe onde pode usar um 
sistema distribuído? Os sistemas distribuídos compõem grandes redes de 
computadores, como a internet, redes de fábricas, redes de telefones móveis, 
dentre outras. 
Em outras palavras, um sistema distribuído pode ser definido como:
[...] aquele no qual os componentes de hardware ou software, localizados 
em computadores interligados em rede, comunicam-se e coordenam suas 
ações apenas enviando mensagens entre si. Essa definição simples 
abrange toda a gama de sistemas nos quais computadores interligados 
em rede podem ser distribuídos de maneira útil. (COULOURIS, 2013, p. 
2)
Uma das principais motivações para que os sistemas distribuídos existam é a 
necessidade do compartilhamento de recursos entre os elementos de uma rede de 
computadores. Você pode entender recursos como um termo abstrato que permite 
Características de um Características de um 
Sistema DistribuídoSistema Distribuído
caracterizar diversos itens, como arquivos de um computador, bancos de dados, 
serviços de software, impressoras, componentes de hardware, dentre outros.
Se você analisar os componentes de hardware, é possível compartilhar impressoras, 
discos e processadores para reduzir custos. Porém, se observar pela visão do 
usuário final do sistema, perceberá que este deseja compartilhar informações em 
mais alto nível, como aquelas necessárias para o seu trabalho e suas atividades 
sociais. Veja o exemplo a seguir: os usuários do sistema possuem a necessidade de 
compartilhar informações sobre suas viagens ou dados de uma tabela do banco de 
dados, não estando preocupados em compartilhar discos ou processadores. Ou 
seja, essa abstração mais baixo nível, como os processadores ou os servidores dos 
dados, não é importante ao usuário final. 
Os sistemas distribuídos estão presentes em diversos cenários. Então, imagine dois 
cenários extremos: o compartilhamento de dados na internet entre duas pessoas 
que não se conhecem, mas que compartilham do mesmo problema (e um deles sabe 
como resolver esse problema); e, no outro extremo, pessoas que trabalham lado a 
lado e utilizam os computadores para trocar informações que estão nas máquinas 
locais. Ambos os cenários descritos anteriormente utilizam sistemas distribuídos, 
mas com características distintas. 
Percebe a diferença geográfica que há entre os cenários anteriores? Os sistemas 
distribuídos devem oferecer mecanismos para tornar essa diferença geográfica 
transparente, de forma que os usuários não saibam o caminho que a requisição faz 
no navegador web até chegar à informação desejada, mesmo que seja do outro 
lado do mundo.
Já o termo “serviço”, segundo Coulouris (2013, p. 15), é definido como: 
[...] uma parte distinta de um sistema computacional que gerencia um 
conjunto de recursos relacionados e apresenta sua funcionalidade para 
usuários e aplicativos. Por exemplo, acessamos arquivos compartilhados 
por intermédio de um serviço de sistema de arquivos; enviamos 
documentos para impressoras por meio de um serviço de impressão; 
adquirimos bens por meio de um serviço de pagamento eletrônico. O 
único acesso que temos ao serviço é por intermédio do conjunto de 
operações que ele exporta. Por exemplo, um serviço de sistema de 
arquivos fornece operações de leitura, escrita e exclusão dos arquivos.
Perceba, na descrição de Coulouris (2013), que os serviços apresentam restrições 
no acesso aos recursos, especificando um conjunto finito de operações que podem 
ser realizadas por outro sistema ou usuário final. Essa restrição reflete a 
organização dos sistemas distribuídos, destacando a importância da comunicação 
entre os sistemas e permitindo que somente o que realmente deve estar exposto 
seja acessado. Esse conjunto bem-definido também auxilia na garantia da 
consistência e segurança dos dados dos servidores.
Em complemento, Tanenbaum (2007, p. 1) define um sistema distribuído como “um 
conjunto de computadores independente que se apresenta a seus usuários como 
um sistema único e coerente”. 
Atente-se para os termos destacados em negrito. O termo “único” reflete que o 
sistema distribuído deve ser transparente, ou seja, não deve ser visível ao usuário. 
Se você usa 1 ou 100 computadores interligados para prover o serviço ao usuário, 
ele somente deve ter acesso ao serviço, não como as coisas são feitas nos 
bastidores. 
O termo “coerente” se deve à necessidade de sincronização e consistência dos 
dados, pois não deve haver inconsistências (como informações desatualizadas) 
entre os elementos que compõem o sistema distribuído. Por exemplo, imagine um 
servidor de filmes que é composto por 2 computadores servidores, sendo que em 
um computador há 100 filmes e, no outro, há somente 80; quando o usuário tentar 
acessar um filme que não está presente no computador que tem somente os 80 
filmes, vai haver inconsistência de informações e o usuário não irá receber o 
serviço desejado.
Dado o exposto, os sistemas distribuídos geralmente são classificados de acordo 
com as seguintes características: 
• compartilhamento de recursos;
• abertura;
• concorrência;
• escalabilidade;
• tolerância a falhas;
• disponibilidade;
• transparência.
Cada uma dessas características será detalhada na seção a seguir.
Análise das Características
Dado o exposto, os sistemas distribuídos, geralmente, são classificados de acordo 
com as seguintes características: 
• Compartilhamento de recursos: deve especificar quais recursos estão 
disponíveis para serem acessados, como eles devem ser acessados e 
modificados, como o seu compartilhamento deve ser realizado dentro da 
rede e a implementação da interface de interação com o recurso e/ou 
servidor.
• Abertura: um sistema distribuído aberto oferece serviços com base em 
regras e padrões conhecidos pela comunidade, permitindo que outros 
sistemas que também conheçam esses padrões possam se comunicar com 
ele. Abertura é a capacidade de interagir com outros sistemas abertos 
(conhecem/implementam os mesmos protocolos). Um sistema aberto é 
independente de hardware, plataformas ou linguagens de programação; 
ele consegue abstrair esses conceitos para oferecer um serviço que pode 
ser acessado de forma facilitada por outro sistema na rede.
• Concorrência: o termo “concorrente” se dá como uma característica dos 
sistemas distribuídos que permitem que diversos usuários/computadores 
possam acessar os recursos que estão sendo compartilhados de forma 
simultânea, garantindo consistência na leitura e modificação dos dados. 
Imagine um sistema distribuído de um banco de dados que recebe 
pedidos de modificação dos dados de diversos usuários diferentes e, 
enquanto isso, há diversos outros fazendo a leitura desses mesmos dados. 
O sistema deve permitir que somente 1 usuário modifique os dados por 
vez, enquanto diversos outros podem ler (não haverá inconsistência). Ao 
ser feita uma modificação, essa alteração deve ser transmitida a todos os 
computadoresque armazenam esse banco de dados compartilhado, para 
que os usuários que estão acessando recebam os dados atualizados.
• Escalabilidade: a escalabilidade reflete o quão rápido um sistema 
distribuído pode ser expandido. A escalabilidade pode ter diversos 
aspectos, podendo ser: de distribuição, de replicação e de caching. A 
escalabilidade de distribuição é a habilidade do sistema distribuído em 
dividir dados/recursos entre as diversas máquinas que compõem o 
sistema distribuído; a escalabilidade de replicação é a habilidade do 
sistema distribuído em manter diversas cópias dos seus dados em 
diversas outras máquinas da rede, mantendo os dados consistentes e 
íntegros; por último, a escalabilidade de caching é a habilidade do sistema 
distribuído em gerenciar e permitir que os usuários acessem dados de 
forma local ou em servidores mais próximos ao usuário, reduzindo o 
tempo de acesso do usuário ao recursos e reduzindo o uso de rede de 
dados.
• Tolerância a falhas: o sistema distribuído deve apresentar a característica 
de ser tolerante a falhas, ou seja, ao entrar em estado de falha, deve se 
recuperar de forma transparente, não permitindo que o usuário saiba que 
ela aconteceu. Para possibilitar a transparência a falhas, o sistema deve 
implementar mecanismos de identificação e recuperação de falhas 
automatizados. Por exemplo, imagine que em um computador que faz 
parte de um sistema distribuído o disco rígido apresente problema e não 
consiga mais consultar os dados desejados pelo usuário, a partir disso, o 
mecanismo automático de gerência do sistema distribuído deve 
identificar essa falha e redirecionar as requisições desse servidor para um 
outro servidor que possua os mesmos dados. Tudo isso deve ser feito de 
forma transparente e automática, sem a ciência do usuário sobre o 
problema.
• Disponibilidade: a disponibilidade é outra importante característica dos 
sistemas distribuídos. A disponibilidade é o tempo em que o sistema está 
disponível, operando de forma correta. Um sistema tem alta 
disponibilidade se possui pouco tempo em estado de falha ou se está 
inoperante. Geralmente, os grandes sistemas, como Google e Amazon, 
possuem disponibilidade de 99,99% do tempo, ou seja, passam poucos 
segundos por ano inoperantes. Ter uma alta disponibilidade é custoso 
para a organização, pois ela tem que investir no gerenciamento e reparo 
automático de falhas, na replicação de máquinas de forma distribuída 
geograficamente, hardware de alto desempenho etc.
• Transparência: a transparência é uma meta importante dos sistemas 
distribuídos, visto que é a habilidade de esconder o fato de que os 
processos e recursos do sistema distribuído estão fisicamente separados 
em vários computadores que integram o sistema distribuído.
Veja, a seguir, os principais tipos de transparências:
• Acesso: o sistema distribuído não permite que o usuário saiba como os 
dados são representados dentro do sistema distribuído, por exemplo, se é 
usado um banco de dados relacional ou orientado a objetos, se é usado 
tecnologia X ou Y, dentre outras informações.
• Localização: o sistema distribuído não permite que o usuário do sistema 
tenha conhecimento sobre a localização dos recursos, se ele é fornecido 
por máquina X com IP 10.0.0.1, ou por máquina Y com IP 10.0.0.5, por 
exemplo. Como exemplo, lembre-se do sistema distribuído para streaming
de vídeos: quando o usuário acessa o sistema para assistir a um filme, ele 
não tem conhecimento de qual servidor vai fornecer o vídeo a ele, 
podendo ser até mais de um servidor (cada servidor pode fornecer 
metade do filme).
• Migração: a transparência de migração esconde do usuário final do 
sistema que um recurso é movido de um servidor para outro; isso pode 
acontecer em tempo de execução (nesse caso, se chama relocação). O 
usuário não tem conhecimento da mudança de um recurso; por exemplo, 
ao acessar um site a partir de um endereço URL, o usuário não sabe a 
localização do servidor que armazena o site. Nesse cenário, os 
administradores podem alterar o site de servidor e o usuário continuará 
sendo redirecionado ao site (recurso), mesmo que fornecido por outro 
servidor. 
• Relocação: a transparência de relocação é bem parecida com a de 
migração, porém, diferencia-se pelo fato de o recurso usado ser movido 
para outro local durante o uso pelo usuário final. Por exemplo, o usuário 
está assistindo a um filme que é fornecido em um servidor X e, por 
motivos de força maior, o funcionamento desse servidor precisa ser 
interrompido. O vídeo (recurso do servidor), juntamente com a conexão 
do usuário, é movido para um novo servidor, de forma transparente, sem a 
ciência do usuário. Assim, o usuário não consegue perceber que foi 
redirecionado para outro servidor.
• Replicação: a transparência de replicação esconde do usuário quais e 
quantas vezes determinado recurso está copiado/replicado pela rede, em 
diversos computadores.
• Concorrência: a transparência de concorrência de dados em sistemas 
distribuídos é a habilidade do sistema em esconder do usuário que 
diversos outros usuários estão usando o mesmo recurso de forma 
simultânea. O sistema garante consistência no dado que está sendo 
acessado e, com isso, provê a transparência.
• Falha: a transparência de falha esconde do usuário final se o sistema 
provedor do recurso está em estado de falha, permitindo a recuperação 
da falha e manutenção do provimento do recurso para o usuário.
• Persistência: a transparência de persistência esconde do usuário a 
informação do armazenamento e, assim, o usuário não sabe se o recurso 
que ele está acessando está armazenado em memória volátil ou em um 
armazenamento não volátil. Por exemplo, ao acessar o streaming de vídeo, 
os bytes são transmitidos pela rede para o usuário que o requisitou; nesse 
cenário, o usuário não sabe se os bytes que ele está recebendo estavam 
armazenados em um HD ou se estavam na memória RAM do servidor de 
dados.
Dito isso, você conseguiu identificar diversas características que podem estar 
presentes nos sistemas distribuídos? Percebeu como elas estão relacionadas? A 
seguir, você vai aprender um pouco mais sobre a taxonomia de Flynn.
Taxonomia de Flynn
A taxonomia proposta por Flynn (1972), chamada de taxonomia de Flynn, é uma 
classificação de arquiteturas para computadores. A taxonomia de Flynn é usada na 
arquitetura e definição de funcionalidades de processadores modernos. 
As quatro classificações propostas por Flynn são baseadas no número de 
instruções concorrentes, diferenciando um fluxo de dados para instruções e outro 
fluxo para dados. Veja as classificações a seguir:
1. Single Instruction Single Data(SISD): quando o sistema utiliza somente um 
fluxo de instruções e um fluxo único para os dados. Exemplos dessa 
categoria é o computador de Von Neumann e os computadores 
sequências de forma geral.
Acesso
O não permite que o usuário saiba como os 
dados são representados dentro do sistema. 
Por exemplo, se é usado um banco de dados 
relacional ou orientado a objetos, se é usada 
tecnologia X ou Y, dentre outras informações.
2. Single Instruction Multiple Data (SIMD): quando o sistema possui um fluxo 
único de instruções e diversos fluxos para transferência de dados. Nessa 
categoria, temos os computadores vetoriais.
3. Multiple Instruction Single Data (MISD): nessa categoria, o sistema possui 
diversos fluxos de instruções, mas somente um fluxo para transferência 
de dados. Essa categoria é bastante abstrata e não se conhecem exemplos 
práticos de aplicação.
4. Multiple Instruction Multiple Data (MIMD): nessa abordagem, o sistema 
possui diversos fluxos para a transferência de instruções e diversos canais 
para a transferência de dados. Como exemplo dessa categoria temos 
praticamente todos os computadores que possuem mais de um 
processador, ou seja, os computadores multiprocessados.
Quadro 1.1 - Resumo da taxonomia de Flynn
Fonte: Elaborado pelo autor.
A taxonomia de Flynn pode ser usada no projeto de sistemasdistribuídos, 
definindo os canais de comunicação e de instrução. Isso auxilia no gerenciamento 
da complexidade dos elementos que compõem o sistema distribuído.
Fluxo de 
instruções/Fluxo de 
dados 
Canal único Múltiplos canais 
Canal único SISD SIMD 
Múltiplos canais MISD MIMD 
praticarVamos Praticar
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor 
incididunt ut labore et dolore magna aliqua, assinale a alternativa correta:
a) Compartilhamento de recursos.
b) Abertura.
c) Concorrência.
d) Escalabilidade.
e) Disponibilidade.
Um processo é uma abstração de um programa em execução, englobando todos os 
recursos necessários para que ele possa ser executado. As threads são fluxos de 
execução dentro de um processo que utilizam o mesmo espaço de memória do 
processo compartilhando variáveis e recursos do processo. As threads permitem 
paralelismo (embora somente uma thread por vez seja executada na CPU) dentro 
do processo com um pequeno overhead na troca de contexto da CPU comparado à 
troca de contexto de um processo.
As threads podem existir tanto no lado do servidor como no lado do cliente. As 
threads no lado do cliente auxiliam nas chamadas bloqueantes, evitando que o 
fluxo de execução seja congelado enquanto aguarda pela resposta da requisição. 
Veja o exemplo em um programa de edição de texto: 1 thread para correção 
ortográfica (t1) e uma outra para salvar automaticamente (t2), ambas dentro do 
processo Pi.
Já as threads no lado do servidor servem para auxiliar no paralelismo, permitindo 
que mais requisições de clientes sejam respondidas com um atraso mínimo de 
resposta. Uma thread é responsável por receber as requisições e criar uma nova 
Comunicação entre Comunicação entre 
ProcessosProcessos
thread para tratar dessa nova requisição, voltando ao seu dever: receber e 
encaminhar as requisições.
A seguir, vamos entender como acontece a criação e a identificação de processos.
Criação e Identificação de Processos
O gerenciamento dos processos é realizado pelo sistema operacional. Assim, para 
ser possível organizar esses processos, o SO atribui a cada processo três conjuntos 
de informações:
• identificação do processo;
• quotas de recursos;
• privilégios.
Vamos analisar cada uma das informações a seguir:
Figura 1.1 - Exemplificação de threads
Fonte: Elaborada pelo autor.
• Identificação do processo: os processos podem ser identificados por dois 
campos específicos: o identificador único do processo (Process 
Identification - PID) e o criador do processo (Owner). 
• Quotas de recursos: esse campo de informações reúne os dados sobre a 
quantidade de recursos que o processo poderá utilizar. Podem ser 
informações sobre o tamanho máximo de memória, tamanho máximo de 
arquivos abertos simultaneamente, ou outras informações que possam 
limitar a execução do processo.
• Privilégios: cada processo pode conter informações diferentes de 
privilégios, que definem as permissões de acesso ao sistema. Esse campo 
reúne as informações definidas pelo aplicativo. Por exemplo, um processo 
pode ter permissão de acesso a arquivos de outros usuários, enquanto 
outro processo pode estar restrito a um usuário apenas.
Sistemas operacionais baseados no Unix são os mais usados no mundo para 
servidores de aplicações e dados. O sistema operacional Linux é um exemplo de 
sistema Unix. No Linux, os processos são criados com o comando fork,  enquanto as 
threads são criadas com o comando clone. 
reflita
Reflita
Você consegue identificar sobre outras formas de identificar 
processos de forma única? Como identificá-los de forma correta 
quando há milhares executando? Com o que devemos nos 
preocupar? E se houver identificadores duplicados? Como 
podemos evitar que isso aconteça? Pense sobre isso!
Fonte: Elaborado pelo autor.
Porém, a nível de kernel, ambos utilizam a mesma função: o do_fork. A função 
do_fork é capaz de criar um processo que compartilha os endereços com o 
processo pai, ou novos endereços podem ser alocados exclusivamente para o novo 
processo criado. Quando se usa o fork, garante-se que uma cópia totalmente nova e 
desacoplada dos endereços de memória do processo pai será criada.
Assim, a transição dos processos é organizada por meio de três estados principais: 
Pronto, Execução ou Bloqueado. Quando um processo está no estado Bloqueado, 
deve passar pelo estado de Pronto antes de retornar ao processador; quando um 
processo deixa o processador por ter terminado o tempo alocado (time slice), ele 
retorna ao estado de Pronto, aguardando na fila para entrar novamente em 
Execução.
Vale ressaltar que a escolha dos processos concorrentes que irão ser executados é 
realizada pelo escalonador. Esse é um componente integrante do sistema 
operacional, que reúne uma série de critérios para o escalonamento e seleção dos 
processos.
Quando um processo adquire o estado de Pronto, ele é alocado em uma fila de 
processos que aguardam liberação do processador para iniciar sua execução. Para 
realizar a escolha dos processos concorrentes, o sistema operacional conta com 
um componente de seleção, denominado escalonador. 
O escalonamento dos processos em estado Pronto é realizado com o auxílio de um 
algoritmo que define os critérios de escolha do processo a ser executado. Nessa 
tarefa de escolha, podemos nos deparar com dois tipos de escalonamento: 
preemptivo ou não preemptivo. 
Quando um sistema operacional utiliza o escalonamento preemptivo, é realizada a 
interrupção de um processo em Execução para que outro seja alocado no mesmo 
local. Essa interrupção para troca de processos é utilizada em sistemas que 
trabalham com processos de alta prioridade e exigem respostas rápidas.
Já no caso do escalonamento não preemptivo, quando um processo é alocado para 
execução, não há interrupção; assim, cada processo irá permanecer em execução 
durante o período que for necessário para sua finalização. É um tipo de 
escalonamento que não utiliza prioridades entre os processos e pode ocasionar 
dois problemas: monopolização do processador por um grande período de tempo e 
a espera de processos importantes que aguardam outros menos importantes.
A escolha do tipo de escalonamento deverá ser realizada conforme as 
necessidades do sistema operacional, devendo considerar os tipos de prioridade: 
estática ou dinâmica.
A prioridade do tipo estática é aquela associada ao processo, sendo permanente e 
definida pelo usuário de acordo com suas necessidades. Já a prioridade do tipo 
dinâmica varia de acordo com a necessidade e desempenho do sistema.
Modelos e Arquitetura de Comunicação
Para entender melhor os modelos e arquiteturas de comunicação usadas nos 
sistemas distribuídos, vamos estudar alguns exemplos a seguir. 
Dando continuidade, alguns exemplos de arquiteturas de comunicação são: 
comunicação por troca de mensagens, peer-to-peer, cliente-servidor, orientada a 
serviços e orientada a dados (repositório e quadro negro). Veja as descrições a 
seguir:
• Arquitetura orientada por troca de mensagens: nesse tipo de 
arquitetura, a comunicação é feita pelo envio e recebimento de 
mensagens, geralmente usando as primitivas send() e receive(). Veja um 
exemplo: há um processo A e um processo B; o processo A quer acessar 
um dado que está disponível pelo processo B. Para conseguir se 
comunicar, o processo A envia uma mensagem send(“Desejo acessar o 
método X”), e o processo B está executando a primitiva receive(), 
esperando uma nova requisição de chegada de mensagem. Ao receber a 
mensagem, o processo B realiza o processamento devido (executa o 
método desejado pelo processo A) e, então, retorna a mensagem para o 
processo B. Após isso, o processo B volta a executar a primitiva receive(), 
até receber uma nova mensagem.
• Arquitetura peer-to-peer: também chamada de arquitetura ponto a ponto, 
é um modelo de comunicação que não distingue os nós que compõem a 
rede, ou seja, qualquer elemento darede pode ser um cliente ou um 
servidor de dados. Cada nó nesse tipo de rede mantém seus próprios 
dados e endereços de outros nós da rede (endereços IP, por exemplo). 
Nesse estilo de arquitetura, não há um ponto único de falha, ou seja, se 
um nó apresentar problema, ele poderá ser excluído da rede e, mesmo 
assim, a rede continuará a se comunicar com os nós que estão 
funcionando corretamente. Porém, uma desvantagem desse tipo de 
organização é o tempo de consulta por um dado; a mensagem tem que ser 
transmitida em broadcast para os nós vizinhos e, então, para os vizinhos 
dos vizinhos, até que se chegue ao nó desejado. Esse procedimento de
broadcast é muito custoso para a rede e consome muitos recursos, 
podendo até inviabilizar o uso por consumir toda a largura de 
comunicação da rede.
• Arquitetura cliente-servidor: nessa arquitetura, há dois elementos 
comunicantes principais: o cliente e o servidor. O cliente é a entidade que 
requisita serviços ao servidor, e este último responde aos pedidos de 
diversos clientes. Essa arquitetura apresenta um problema: possui um 
ponto único de falha, ou seja, se o servidor não estiver disponível, a rede 
para de funcionar. Os clientes não conseguem se comunicar entre eles 
para trocar informações, como acontece no modelo peer-to-peer. Por 
outro lado, a arquitetura cliente-servidor é mais simples de ser 
implementada e é a mais utilizada em todo o mundo, para os mais 
diversos serviços.
• Arquitetura orientada a serviços: nessa arquitetura, há um baixo 
acoplamento entre as entidades que fornecem os serviços, permitindo 
maior distribuição da carga de processamento em uma infraestrutura de 
computadores. Por conta disso, a complexidade de implementação é 
aumentada, principalmente o desenho arquitetural do sistema.
• Arquitetura orientada a dados: o foco não é nos elementos que 
compõem a rede nem nos serviços oferecidos, mas nos dados em si. Veja, 
a seguir, dois exemplos deste tipo de arquitetura:
• Repositório: na arquitetura repositório, temos um banco de dados 
compartilhado, ou seja, que é acessado por diversos clientes. Esse banco 
de dados pode estar distribuído em diversos computadores (sistema 
distribuído). Esse modelo permite integridade nos dados, pois tem uma 
base de dados única e também fornece maior escalabilidade tanto do 
banco de dados como da quantidade de clientes.
• Quadro negro: nessa arquitetura, temos um nó gerenciador e diversos 
nós operários. O nó controlador é responsável por mapear todos os 
demais nós da rede que fornecem serviços/funcionalidades e quebrar o 
problema a ser resolvido em diversos problemas menores e que podem 
ser realocados para os nós específicos. Ao final, o nó controlador é 
responsável por integrar todos os microrresultados dos nós específicos e 
retornar a resposta final ao usuário que requisitou. Veja a ilustração a 
seguir:
Troca de Mensagens
Na comunicação entre os elementos dos sistemas distribuídos, podemos ter 
chamadas síncronas ou assíncronas. Nas chamadas síncronas, o usuário faz uma 
requisição a um servidor e fica aguardando a resposta e, enquanto isso, não pode 
fazer outro processamento, devendo ficar em modo de espera até receber a 
mensagem de retorno. Em outras palavras, há dependência de resposta do 
recebedor da mensagem, o que pode implicar perda de desempenho por 
ociosidade de processamento útil.
Figura 1.2 - Arquitetura quadro negro
Fonte: Elaborada pelo autor.
A comunicação assíncrona traz a ideia daquilo que não ocorre simultaneamente, ou 
seja, algo que não é sincronizado. Mas como isso se relaciona com aplicações ricas? 
As chamadas assíncronas correspondem a um comando que não precisa ser 
processado pelo servidor para que o usuário possa continuar a navegação. Isso 
ocorre por ser possível enviar uma solicitação ao servidor e fazer outras atividades 
enquanto a requisição é executada.
Para exemplificar esse assincronismo, imagine o uso de um armazenamento nas 
nuvens (como Google Drive, OneDrive ou DropBox) em um navegador. Nesse 
contexto, você deseja fazer o upload (carregamento) de um conjunto de novos 
arquivos. Ao selecioná-los e solicitar o envio, a aplicação não exige que você pare o 
que está fazendo enquanto os arquivos estão sendo carregados; desse modo, você 
pode realizar outras atividades sem que essa solicitação interfira na transferência 
de dados, uma vez que ela está sendo feita em segundo plano. Essa capacidade 
enriquece a experiência do usuário e permite que os sistemas distribuídos operem 
de forma otimizada, uma vez que permite a realização de diferentes atividades.
Na comunicação por troca de mensagens, temos dois comandos que geralmente 
são utilizados: o send() e o receive(). Na comunicação síncrona, a primitiva send() é 
bloqueante, ou seja, o processo cliente aguarda, enquanto o núcleo envia a 
mensagem para o processo servidor. Da mesma forma, a primitiva receive() 
também é bloqueante para a comunicação síncrona, ou seja, o processo servidor 
aguarda até que o destinatário receba uma mensagem endereçada para aquele 
processo.
Já na comunicação assíncrona, a primitiva send() não é bloqueante, ou seja, o 
processo cliente aguarda somente enquanto a mensagem é copiada para o buffer 
de saída. A primitiva receive() pode ser: bloqueante ou não bloqueante. Na 
bloqueante, o processo servidor aguarda por uma mensagem, enquanto na não 
bloqueante o processo servidor simplesmente comunica o destinatário que espera 
receber uma mensagem.
praticarVamos Praticar
A escolha da arquitetura que será utilizada para projetar um sistema distribuído é 
essencial para o seu funcionamento e, dentre tantas opções, deve-se escolher a mais 
adequada para cada tipo de problema a ser resolvido. Dito isso, assinale a alternativa que 
apresenta qual estilo arquitetural possui uma arquitetura distribuída e não apresenta 
ponto único de falha, além disso, permite que os nós da rede se comportem como emissor 
e receptor de dados.
a) Peer-to-peer.
b) Cliente-servidor.
c) Quadro negro.
d) Repositório.
e) Orientada a serviços.
O modelo cliente-servidor é um dos modelos mais utilizados pelos sistemas 
baseados em rede do mundo. A seguir, você vai compreender alguns exemplos que 
destacam a importância e utilidade do modelo cliente-servidor, bem como os 
principais protocolos utilizados para manter a comunicação entre o cliente e o 
servidor.
Definição e Exemplos
A arquitetura cliente-servidor é, historicamente, a mais utilizada, e continua sendo 
até os dias de hoje. 
A Figura 1.3 ilustra uma estrutura simples de uso da arquitetura cliente-servidor. 
Perceba que os clientes interagem (enviam e recebem mensagens) com o servidor 
localizado em outro computador. Também é possível haver comunicação de 
servidor para servidor. 
Modelo Cliente/ServidorModelo Cliente/Servidor
Ademais, é possível perceber que o cliente requisita o servidor para acessar algum 
recurso que deseja. Nessa comunicação, podem ser usados os protocolos: TCP/IP 
para a camada de transporte; o Hypertext Transfer Protocol (HTTP) para acessar 
páginas web, se esse servidor for um servidor web; o DNS para resgatar o 
endereço IP de algum site a partir de sua Uniform Resource Locator (URL) (caso este 
seja um servidor Domain Name System (DNS)); dentre outros.
Ainda de acordo com a ilustração, os servidores podem ser servidores ou clientes 
(pois um servidor pode requisitar um recurso de outro servidor). Veja o exemplo a 
seguir: um servidor web, geralmente, é um cliente de um outro servidor que 
armazena os arquivos dos sites.
saiba mais
Saiba mais
Para saber mais sobre os protocolos TCP, IP, 
HTTP e DNS, consulte o livro de Coulouris 
(2013), capítulo 3, Redes de computadores e 
interligação de rede, a partir da página 81. Bons 
estudos!
ACESSAR
Em complemento, a maioria dos servidores web também são clientes dos 
servidores de DNS, estabelecendo novamente a relação Servidor(Cliente)-
Servidor. Veja mais um exemplo:
Outroexemplo relacionado à Web diz respeito aos mecanismos de busca, 
os quais permitem aos usuários pesquisar resumos de informações 
disponíveis em páginas Web em sites de toda a internet. Esses resumos 
são feitos por programas chamados Web crawlers*, que são executados 
em segundo plano (background) em um site de mecanismo de busca, 
usando pedidos HTTP para acessar servidores Web em toda a internet. 
Assim, um mecanismo de busca é tanto um servidor como um cliente: ele 
responde às consultas de clientes navegadores e executa Web crawlers 
Figura 1.3 - Exemplo de uso da arquitetura cliente-servidor
Fonte: Adaptada de Coulouris (2013, p. 47).
que atuam como clientes de outros servidores Web. Nesse exemplo, as 
tarefas do servidor (responder às consultas dos usuários) e as tarefas do 
Web crawler (fazer pedidos para outros servidores Web) são totalmente 
independentes; há pouca necessidade de sincronizá-las e elas podem ser 
executadas concomitantemente. Na verdade, um mecanismo de busca 
típico, normalmente, é feito por muitas threads concorrentes, algumas 
servindo seus clientes e outras executando Web crawlers. (COULOURIS, 
2013, p. 46)
Dito isso, a seguir você vai aprender um pouco mais sobre os protocolos que 
podem ser utilizados na comunicação entre os clientes e servidores.
Protocolos
Um dos principais protocolos usados no modelo cliente-servidor é o protocolo de 
requisição-resposta, que auxilia na definição de como as mensagens devem ser 
trocadas entre as entidades comunicantes, ou seja, o cliente e o servidor. Esse 
protocolo suporta a troca de mensagens e via dupla, permitindo ao cliente tanto 
enviar como receber mensagens, e o mesmo se aplica ao servidor.
É possível definir três estilos para o protocolo de troca de mensagens requisição-
resposta (COULOURIS, 2013):
• protocolo request (requisição) (R);
• protocolo request-reply (requisição-resposta) (RR);
• protocolo request-reply-acknowledge reply (requisição-resposta-
reconhecimento da resposta) (RRA).
No protocolo request, uma única mensagem de requisição é enviada do cliente para 
o servidor. O protocolo request, geralmente, é utilizado quando não há necessidade 
de o servidor retornar nenhum valor/dado/recurso para o cliente, ou seja, pode ser 
usado para ativar algum mecanismo no servidor, como efetuar o logout de uma 
conta em um site. Não há necessidade de confirmar ao cliente que a operação foi 
realmente realizada e, por isso, não precisa de uma resposta do servidor.
É importante destacar que esse estilo do protocolo não é bloqueante, ou seja, o 
cliente pode realizar outros processamentos e não necessita ficar esperando por 
um retorno do servidor. Geralmente, esse protocolo pode ser implementado 
usando outros protocolos já conhecidos das redes de computadores, como o UDP. 
Lembre-se de que o UDP não guarda estados como o TCP; é possível enviar uma 
mensagem e não aguardar resposta, o que permite o envio de mais mensagens por 
uma quantidade de tempo, mas pode sofrer por perdas de mensagens durante a 
comunicação. Além disso, essas perdas não serão detectadas, pois não há regras 
para garantia do recebimento.
O protocolo request-reply (requisição-resposta) é utilizado pela maioria dos 
sistemas que são baseados no estilo arquitetural cliente-servidor. Geralmente, a 
maioria das mensagens trafegadas no cliente-servidor é de requisição e resposta, 
ou seja, o cliente envia uma requisição ao servidor e espera uma resposta para 
completar o processamento. Além disso, embora se espere uma resposta, não é 
necessária a confirmação do recebimento por parte do cliente. Pode haver 
inconsistência na comunicação se a mensagem de resposta do servidor por perdida 
na rede durante o transporte, e isso pode levar o cliente a esperar sem receber a 
resposta. Há regras de segurança que previnem que o cliente espere por tempo 
indeterminado, ou seja, após algum tempo, o cliente pode assumir que a mensagem 
foi perdida e enviar uma nova requisição ao servidor. As falhas de comunicação 
ocasionadas pela perda de datagramas UDP podem ser mascaradas pela 
retransmissão das requisições pelo cliente e de acordo com o registro das 
respostas recebidas.
O protocolo request-reply-acknowledge reply (requisição-resposta-reconhecimento 
da resposta) é estruturado na troca de três mensagens: uma mensagem de 
requisição, uma de resposta e, a última, de confirmação da resposta. A última 
mensagem, a de reconhecimento da resposta, possui um campo que identifica 
unicamente a mensagem que ela deseja confirmar, geralmente um IdResposta. 
Para otimizar esse protocolo, assume-se que a chegada de uma IdResposta 
representa a confirmação do recebimento de todas as mensagens passadas a esse 
IdResposta, logo, a perda de uma mensagem de confirmação não é tão prejudicial 
ao protocolo. Além disso, embora o protocolo requisição-resposta-
reconhecimento utilize uma mensagem a mais, o cliente não precisa ficar 
bloqueado; ele primeiro recebe a mensagem e, só então, envia a mensagem de 
confirmação.
A figura a seguir resume os conceitos apresentados sobre o protocolo de 
requisição-resposta.
Para finalizar, lembre-se de que os sistemas distribuídos podem usar a arquitetura 
cliente-servidor, peer-to-peer, ambas, ou outros estilos arquiteturais.
praticarVamos Praticar
Figura 1.4 - Protocolos de requisição-resposta
Fonte: Adaptada de Coulouris (2013, p. 191).
Os protocolos de comunicação guiam como deve acontecer a comunicação entre as 
entidades comunicantes. Além disso, os protocolos são essenciais para permitir que 
entidades que não se conhecem possam se comunicar, dado que usam o mesmo 
protocolo. Dito isso, o que caracteriza o protocolo requisição-resposta-reconhecimento 
(request-reply-acknowledge)?
a) É enviada somente uma mensagem de requisição, geralmente para ativar algum 
método no servidor, e se usa o UDP.
b) Há somente duas mensagens: uma que é requisição do cliente e outra que é a 
resposta do servidor.
c) Há uma mensagem que é enviada pelo cliente para afirmar que recebeu a 
resposta do servidor.
d) Há uma única mensagem que é enviada pelo cliente usando o protocolo TCP/IP.
e) Falta de mensagem de reconhecimento da resposta do servidor.
indicações
Material 
Complementar
L I V R O
Sistemas operacionais modernos
Andrew S. Tanenbaum
Editora: Pearson Universidades
ISBN: 8543005671
Comentário: Este livro vai lhe ajudar a entender melhor os 
conceitos básicos dos sistemas operacionais. Esses 
conceitos servirão para auxiliar seu entendimento sobre os 
sistemas distribuídos, principalmente os sistemas 
operacionais distribuídos.
F I L M E
Star Trek Discovery
Ano: 2017-2019
Comentário: Este filme vai lhe ajudar a entender a 
complexidade que existe em manter a comunicação entre 
diversos sistemas em tempo real, uma dificuldade comum 
aos sistemas distribuídos.
Para conhecer mais sobre o filme, acesse o trailer 
disponível em:
T R A I L E R
conclusão
Conclusão
Nesta unidade, você aprendeu um pouco mais sobre os sistemas distribuídos. Você 
conheceu as características que definem um sistema distribuído e como analisá-las, 
bem como as características de escalabilidade, abertura, tolerância a falhas, 
concorrência, transparência, dentre outras. Além disso, você entendeu como se 
estrutura um sistema distribuído a partir de protocolos de comunicação, o que são 
e como funcionam os processos dentro do sistema operacional que gerencia os 
recursos da máquina (hardware) de um servidor ou cliente e como identificar os 
processos. Por fim, você conheceu o modelo cliente-servidor e suas principais 
características, como os elementos que o compõem e os protocolos que são 
utilizados para comunicação.
referências
Referências 
Bibliográficas
COULOURIS, G. Sistemas distribuídos: conceitos e projeto. São Paulo: Bookman, 
2013.
FLYNN, M. J. Some Computer Organizations and Their Effectiveness. IEEE 
Transactions on Computers. C-21 (9). Sept/1972, p. 948-960.Disponível em: 
https://pdfs.semanticscholar.org/4ed0/5370f6d622ee57bc79037e8fe940b73bec33.pdf
Acesso em: 14 jan. 2020.
TANENBAUM, A. S. Sistemas distribuídos princípios e práticas. São Paulo: 
Pearson Prentice Hall, 2007.