reactor pattern e evented programming

No último encontro do guru-sp eu tive a oportunidade de apresentar uma lightning-talk sobre Reactor Pattern, Evented programming e IO não blocante

Como não dá pra enxergar praticamente nada da lousa na gravação, fica aqui um breve resumão da palestra:

A maioria das aplicações que construímos não começam já com expectativas de grandes volumes de acessos; normalmente vamos enfrentar no máximo 100-1000 usuários. A primeira abordagem seria quase que ter um servidor pra cada usuário (CGI), o que obviamente tem os seus problemas, se o volume de usuários crescer da noite para o dia.

Uma segunda abordagem seria usar os servidores baseados em threads, onde cada cliente recebia uma thread e o processamento era distribuído entre todos os clientes. Apesar de serem mais rápidos do que o modelo do CGI, ainda gastavam muito tempo com a constante troca de contextos, e com um volume muito grande de threads, o sistema passa a degradar rapidamente.

A outra abordagem seria colocar uma thread de servidor para atender várias conexões. Para que isso seja possível, devemos fazer uso de IO não blocante, de maneira que possamos processar várias conexões usando uma thread só; todas as chamadas de read() devolvem apenas os dados que estiverem disponíveis no momento da invocação, ao invés de ficarem travadas esperando que os dados cheguem.

Nesse caso, conseguimos atender mais de uma conexão por thread, com ressalvas. O cenário ideal é se aproveitar do bom e velho princípio de Inversão de Controle (IoC), e pedir que alguém nos avise quando mais dados estiverem disponíveis, ao invés de ficar perguntando o tempo todo se existem mais dados a serem processados. Registramos Callbacks, que são invocados dentro de um loop de eventos, que reage à chegada de dados (um evento), e invoca os nossos callbacks.

Servidores http famosos que se utilizam disso são o NGINX e o thin, entre outros.

O thin faz uso de uma gem chamada Event Machine, que auxilia muito a escrever aplicações usando o Reactor Pattern

Em diversas conversas sobre escalabilidade, Dan Kegel escreveu um artigo gigantesco mostrando novas alternativas para se obter 10.000 conexões, mais conhecido como c10k. Leitura obrigatória!

Acho que o maior desafio foi falar de um assunto tão complicado em tão pouco tempo, espero que tenha conseguido dar uma visão geral à respeito.

O que você achou da palestra?