Chronicle Queue – A microsecond messaging framework

É chover no molhado citar que o mundo da computação se reinventa, avança e expande para novos modelos e tecnologias a cada ano, entretanto, para aqueles um pouco mais “experientes” na área de TI, é perceptível que nos últimos 10 anos um mercado, antes adormecido, tem ressurgido de uma forma que talvez se assemelhe ao boom causado com o surgimento da microinformática em meados dos anos 70.

Estou me referindo a computação de alta performance, onde tudo era desenvolvido de tal forma a se extrair a capacidade máxima das tecnologias existentes da época, uma vez que a própria tecnologia avançava de maneira mais lenta devido às limitações da própria época, obrigando os programadores a pensar em como economizar ciclos e estados de máquina.

A grande limitação, naqueles dias, estava relacionada à memórias de maneira geral, sejam voláteis (RAM) ou não voláteis (ROM, hard disks, Flash memories), sendo esses dispositivos caríssimos, até pouco tempo. Só para se ter uma ideia, em 1980 nos EUA, um hard disk de 26MB custava em média U$5.000 e 64KB de memória RAM custava em média U$405,00.

Memória RAM versus Hard disks

Historicamente as memórias RAM sempre estiveram muito a frente dos hard disks na questão de velocidade de E/S, mas por outro lado o custo por megabyte dos hard disks e a grande capacidade desses dispositivos sempre o colocaram à frente das memórias RAM no quesito capacidade de armazenamento.

Com o avanço e barateamento das tecnologias de armazenamento voláteis e não voláteis, aliado ao aumento gradativo do poder dos processadores, esse cenário mudou fazendo com que novas indústrias de tecnologia surgissem e despontassem para o mundo em pouquíssimo tempo.

Algumas delas tem seu “negócio” fortemente embasado no processamento em memória RAM, como é o caso de empresas desenvolvedoras de engines para jogos, já outras nem precisam de performance extrema sendo seu foco mesmo a venda de sua capacidade de armazenamento não volátil, como o DropBox por exemplo.

Entretanto existem aquelas empresas que necessitam de capacidade e performance extremas nos dispositivos voláteis (RAM) e nos não voláteis (hard disks), como por exemplo redes sociais, sites de busca, sites de comparação de preços, dentre outras que trabalham com informações dinâmicas e em grande quantidade.

Nesse cenário de alta capacidade de armazenamento e performance, aliado ao uso de tecnologias disponíveis nos diversos sistemas operacionais modernos, surgem tecnologias que utilizam as mais variadas técnicas computacionais já conhecidas dos pioneiros da alta performance de décadas passadas.

Chronicle Queue

Chronicle Queue é um componente de IPC (inter-process communication), open source, escrito em Java, que possibilita a transferência de grandes quantidades de dados em alta performance, entre threads, processos e máquinas, com persistência de dados em disco. Segundo a página do projeto no GitHub o Chronicle Queue é definido como “Micro second messaging that stores everything to disk“.

O grande segredo da performance do Chronicle Queue é que ele trabalha justamente utilizando estruturas simples porém rápidas tal qual as utilizadas por diversas aplicações nos primórdios da computação, que necessitavam armazenar e recuperar dados com uma performance aceitável e o faziam utilizando índices otimizados que apontam direto para o dado real no arquivo de dados em disco, entretanto ao contrário das antigas tecnologias, agora os arquivos de dados podem ser manipulados utilizando mecanismos de memory-mapping existente nos sistemas operacionais modernos, otimizando assim a performance das operações de E/S em disco.

Arquitetura e modos de operação

A interface básica de funcionamento da arquitetura do Chronicle Queue é bem simplista, com algumas poucas variações do modo de funcionamento, sendo restrito a um componente de escrita na fila, denominado Appender (producer) e um outro de leitura, denominado Tailer (consumer).

Dentro desse modelo, que é basicamente o tradicional pattern producer-consumer, o Chronicle Queue pode operar em modo sequencial (FIFO) ou aleatório, quando operando como Tailer e apenas em modo sequencial quando em modo Appender.

Modelo tradicional do Chronicle Queue (producer-consumer)

O Chronicle Queue, além do suporte à filas diretamente acessadas via os arquivos físicos da mesma, também possui outros modos de operação interessantes, dentre eles um modo de fila acessado via TCP/IP, ou seja, diversos Tailers conectados a uma fila via um Appender TCP, o que de fato diminui a performance de processamento das filas mas que por outro lado permite toda a facilidade de inter-process communication do Chronicle Queue, expandindo-a, uma vez que abre possibilidade de comunicação entre máquinas diferentes.

Outra característica do Chronicle Queue é que, diferente das estruturas IPC presentes nos sistemas operacionais modernos, todos os dados trafegados pela fila são persistidos em disco e com isso é possível utilizar a própria fila Chronicle como um sistema de journaling, podendo ser usado para recuperação do sistema em caso de uma eventual queda (crash).

Source Code

A simplicidade de uso e operação do Chronicle, por parte do programador é uma de suas principais características, conforme verificado no exemplo abaixo:

try (ChronicleQueue queue = ChronicleQueueBuilder.single("queue-dir").build()) {
    // Obtain an ExcerptAppender
    ExcerptAppender appender = queue.acquireAppender();

    // write - {msg: TestMessage}
    appender.writeDocument(w -> w.write(() -> "msg").text("TestMessage"));

    // write - TestMessage
    appender.writeText("TestMessage");

    ExcerptTailer tailer = queue.createTailer();

    tailer.readDocument(w -> System.out.println("msg: " + w.read(()->"msg").text()));

    assertEquals("TestMessage", tailer.readText());
}

O código acima demonstra 1 Appender escrevendo e 1 Tailer consumindo na mesma Thread, para fins de demonstração, entretanto a disposição desses producers-consumers pode estar da forma como melhor se adequar ao modelo da aplicação que está sendo desenvolvida, podendo o producer estar em um processo e o consumer em outro, em Threads separadas ou até em máquinas separadas.

Por ser um projeto enxuto, bem estruturado e que utiliza muito bem os recursos computacionais sejam do sistema operacional ou de estruturas de dados internas do projeto, o Chronicle Queue garante uma boa performance e confiabilidade, além de uma vasta comunidade trabalhando em atualizações e melhorias do projeto.

Ainda assim, é possível ter um suporte “enterprise” por parte do grupo que o desenvolve, o que o torna um projeto de vida longa no mercado e comunidade, além da segurança de continuidade e suporte necessário ao ambiente corporativo.

Conclusão

Apesar de bastante resumido, esse artigo visa demonstrar a importância desse retorno às origens da computação, principalmente considerando o atual momento onde vivemos a febre de computação distribuída, vide BlockChain e da necessidade de processamento de dados em grande escala, vide BigData.

Entretanto, para que esses conceitos se tornem realidade, muitas tecnologias de base e que muitas vezes sequer aparecem no desenvolvimento desses conceitos, precisam ser muito bem desenvolvidas, otimizadas e principalmente que sejam confiáveis, portanto vale a pena investir um tempo utilizando tecnologias abertas como o Chronicle Queue.

[]’s
PopolonY2k

Print Friendly, PDF & Email

Leave a Reply