5 minutos de leitura, infinite knowledge by Invillia_ 

A evolução da informática nos últimos anos, trouxe conceitos cada vez mais complexos. A migração de sistemas, que antes eram focados em ambientes centralizados, se tornou redes complexas e sistemas distribuídos. 

</ conceitos > 

No conceito mais básico, um sistema distribuído é todo aquele que possui seus componentes (hardware ou software) localizados em computadores interligados por intermédio de uma rede, se comunicando e coordenando suas ações por mensagens. 

Em tese, aparenta ser simples, mas o compartilhamento de recursos trás consigo algumas características complexas. Construir um sistema distribuído é desafiador. Precisamos nos preocupar com a heterogeneidade, segurança, escalabilidade, tratamento de falhas, concorrência e transparência. Porém, nesse texto, vamos nos concentrar no tratamento de falhas. 

</ as falhas >  

Antes de tratar um erro, é necessário identificá-lo. Em algumas situações, eles podem ser extremamente difíceis de serem encontrados, ou até mesmo impossível de se detectar. Um servidor remoto na internet que se perdeu em algum ponto durante um request, por exemplo. 

Corriqueiramente, isso pode acontecer em diversos sistemas computacionais. Porém, quando falamos em sistemas distribuídos onde componentes se comunicam por meio de uma grande rede, as falhas podem ser parciais. Ou seja: mesmo que elas ocorram não impedem que os outros componentes ou recursos continuem funcionando, o que torna o tratamento particularmente difícil em alguns cenários. 

</ a falha bizantina > 

O problema da falha bizantina foi abordado pelo artigo The Byzantine Generals Problem de Leslie Lamport, Robert Shostak e Marshall Pease em 1981. Em eles trazem uma proposta de resolução de erros catastróficos em sistemas distribuídos. Tudo gira em torno de computadores (generais) que estão focados em diferentes propósitos e precisam, em pares, estabelecer uma comunicação e chegar a um consenso sobre algum ponto, mesmo que alguns dos participantes do processo estejam danificados. Para melhorar o entendimento do contexto, vamos entender a proposição do problema dos generais: 

• Vários generais (leais e não leais) bizantinos e seus exércitos estão localizados em diferentes posições de uma cidade com a intenção de criar um cerco; 
• Para que haja sucesso na tomada da cidade, os generais precisam atacar de maneira coordenada para derrotar as defesas ou recuar de forma coordenada para evitar a tomada de suas tropas; 
• Em caso de não sincronia, os inimigos irão vencer; 
• Para conseguir realizar os ataques ou recuos de forma coordenada em sua maioria, os generais utilizam-se de mensageiros, que passam pela cidade indo de local em local com as ordens a serem cumpridas; 
• A suposição indica que, por meio de um mensageiro, o exército informa ao outro a intenção de atacar ou não e quando irá ser realizada tal ação; 
• À medida que as propostas chegam, os generais confirmam se aceitam ou não, afim de estabelecer um consenso sobre qual passo dar; 
• Os generais leais devem ter um acordo comum sobre o plano de ataque (consenso); 
• Os generais não leais tentarão evitar um acordo (falha). 

Nesses passos, Lamport tenta abstrair um pouco da complexidade para resolver um problema dessa magnitude de forma coordenada e a rede distribuída chegue a um consenso (acordo sobre um valor único). Mesmo que isso signifique falhas de componentes ou informações incorretas (generais traidores), o importante é tornar o sistema protegido contra falhas sistêmicas. 

A tolerância à falhas bizantinas pode ser bem sucedida se os participantes do fluxo cheguem a um acordo sobre seus valores. Pode ser um voto padrão, limite de tempo etc. No artigo, Lamport ainda prova que se tivermos um valor 3m + 1 de processadores funcionando corretamente, há um consenso. Ou seja, dentro de um fluxo onde “m” sejam os componentes defeituosos, temos que possuir mais de 2/3 do total de componentes funcionando perfeitamente. 

Mas afinal, quais os efeitos de um sistema não tolerante à falhas bizantinas e como aplicar os conceitos falados até agora? 

</ na prática > 

Esses tipos de falhas são consideradas como as mais gerais e complexas a serem resolvidas, pois os participantes podem gerar dados que aparentam estarem corretos para o sistema em si, quando na verdade não estão. E é aí onde mora a complexidade, pois as falhas bizantinas conseguem confundir os sistemas de detecção de erros. Apesar desse ponto ser bem complexo, uma falha bizantina não chega a ser necessariamente um problema de segurança que envolve pessoas mal intencionadas ou softwares maliciosos. Podem ser ocasionadas inclusive devido ao acumulo de falhas elétricas. 

Esse tipo de resiliência de sistemas é muito forte em tecnologias blockchain, onde a existência de nós maliciosos ou não confiáveis podem inserir informações de transações inconsistentes, quebrando assim a confiabilidade da rede. Um bom exemplo dessa tolerância é o protocolo PoW (proof of work) que consiste em evitar certos comportamentos indesejados dentro de uma rede, permitindo obter consensos e permanecer resistente em fatos, como o de gastos duplos dentro de uma rede blockchain. 

Por fim, ainda tem muito para se aprofundar e se conhecer sobre sistemas distribuídos. Projetar e construir sistemas nesse molde é uma árdua tarefa e por muitas vezes complexas, então devemos pensar sempre em fazer algo resiliente e tolerante a falhas para evitarmos casos catastróficos. 

[ ϟ ] 

Esse conteúdo faz parte do programa Invillia Tech Creators, que incentiva mentes inovadoras e brilhantes a produzirem e compartilharem opiniões, visões sobre tecnologia, tendência, diversidade e carreira. Contribuindo para o crescimento de toda a comunidade.

 Se quiser descobrir mais como a Invillia pensa e acrescenta inteligência em todo o processo de desenvolvimento de produtos digitais para empresas que estão revolucionando seus segmentos, conheça nosso Global Growth Framework_  

Agora, se quiser juntar seu talento a esses game-changers e colaborar com a próxima grande inovação, conheça aqui nossas vagas. Nos vemos em breve_