[Prévia] [Próxima] [Prévia por assunto] [Próxima por assunto]
[Índice cronológico] [Índice de assunto]

Questao 1 da prova



Olas,

Como nao fui tao bem quanto gostaria na questao 1 da prova, resolvi trazer
o assunto para a lista (que, por sinal, anda meio parada).

A questao 1 era sobre o sistema para a venda de ingressos para jogos de
futebol. O meu problema foi nao ter resolvido:

- tolerancia a falhas
- adaptacao dinamica em funcao da carga

O meu sistema tinha um servidor central CORBA e pontos-de-venda baseados
em clientes CORBA. Eu pude garantir que um ingresso nao e' vendido duas
vezes (e' so' fazer a verificacao da disponibilidade e a "reserva" de um
ingresso uma operacao atomica) e que uma operacao de venda nao seja
concluida sem que o ingresso seja pago (ou seja, depois que o ingresso e'
"reservado" com sucesso, uma nova mensagem informa o servidor sobre o
sucesso da cobranca).

O problema e' que ainda sobra uma situacao problematica: o ingresso e'
reservado com sucesso, a cobranca e' realizada com sucesso mas a mensagem
informando ao servidor sobre o sucesso da cobranca e' perdida, por
exemplo, por uma falha na rede ou no servidor. Nesse caso, como efetivar a
venda posteriormente?

Uma solucao simples e bastante razoavel e' simplesmente imprimir um "log"
dessa falha no PDV; depois alguem pode finalizar a operacao manualmente
com base no registro de problemas em papel. Basicamente, isso significa
dizer que o PDV precisa ser capaz de guardar estado. Sera' que existe uma
solucao melhor?

O outro problema e' que o uso de um servidor centralizado tambem nao e'
muito seguro com relacao a falhas (p. ex., um incendio) e nao e' muito
escalavel (basicamente, o servidor tem que ter capacidade disponivel para
atender o pico de uso, sempre).

Com dois servidores em lugares diferentes, a coisa fica melhor em termos
de seguranca, mas ai' precisamos manter a consistencia dos dados nos dois
servidores. Nao basta usarmos transacoes que garantam a atualizacao
simultanea dos dados nos dois servidores, pois com isso a falha de apenas
um servidor paralisaria o sistema.

E finalmente sobra o problema da adaptacao dinamica em funcao da carga. No
caso do jogo de futebol, acaba de me ocorrer uma ideia divertida: quando o
volume de transacoes simultaneas e' grande, o servidor "delega" para cada
PDV um numero de lugares (p.ex., 30) na "geral" (onde nao ha' numeracao, e
portanto todos os ingressos sao iguais). O PDV apenas precisa contactar o
servidor ou quando trata-se de uma venda numerada (o que ocorre mais
raramente) ou cada vez que todos os lugares da "geral" que lhe foram
assinalados sao vendidos, para armazenar essa informacao no servidor e
para pegar mais lugares se ainda houver lugares disponiveis. O numero de
lugares assinalado para cada PDV pode, inclusive, ser definido em funcao
do volume de vendas de cada PDV (os que vendem mais recebem mais lugares a
cada vez).

Mas se todos os lugares fossem numerados, essa solucao nao seria possivel;
a unica outra solucao razoavel que vejo para o problema e': o servidor
central, alem de atuar como servidor para essas operacoes, tambem e' usado
para outras finalidades; quando o trafego por causa das vendas cresce, o
servidor paralisa essas outras atividades para liberar mais processamento
para o sistema, e retoma as outras atividades depois do expediente. Na
verdade, se o sistema for usado tanto para a venda de ingressos para jogos
de futebol quanto para a venda de ingressos para "shows" de rock, a coisa
provavelmente funcionaria bem, pois os momentos de "pico" da venda de um
dos tipos de ingresso nao devem coincidir com os momentos de pico da venda
do outro tipo. Mas acho que deve haver solucoes mais interessantes para
esse problema...

E' isso ai', quem tiver ideias escreva!

Ate' +
Nelson

--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth