Artigo Java Magazine 73 - Introdução ao Terracotta

Introdução ao Terracotta

Um poderoso middleware open source para clustering

Primeiros passos com o middleware capaz de armazenar seus objetos da rede de forma transparente, permitindo técnicas de alto desempenho e escalabilidade

Osvaldo Pinali Doederlein

De que trata o artigo:

Uma introdução ao Terracotta ES, um middleware open source para Java que sincroniza objetos de vários processos de forma eficiente e automática e sem exigir nenhuma alteração no seu código.

Para que serve:

Muitas aplicações de missão crítica precisam ser implantadas em cluster, fazer caching agressivo de dados persistentes, conteúdo gerado dinamicamente entre outras informações; ou simplesmente, sincronizar dados de forma imediata e eficiente com outros processos. A maneira mais fácil de satisfazer a estas necessidades é usando um middleware que coloca parte do heap da JVM “na rede”, permitindo que vários processos compartilhem os mesmos objetos. O Terracotta implementa esta idéia de forma transparente e com alto desempenho.

Em que situação o tema é útil:

Aplicações em cluster (Java EE ou não); aplicações que usam um SGBD e necessitam de um cache de segundo nível para melhorar o desempenho; aplicações web que geram muito conteúdo dinâmico, entre muitas outras.

Na Introdução de “Programando com Pools” (Edição 57), comecei dizendo: “A programação às vezes parece ser um campo tomado por uma enorme e confusa variedade de técnicas. (...) Fazendo um esforço de síntese, veremos que existe um número relativamente pequeno de fundamentos que embasam toda a programação.” Pooling é uma dessas técnicas fundamentais; podemos citar outra técnica igualmente fundamental e relacionada, o caching. São idéias parecidas, mas não iguais:

·      Um pool é uma coleção de objetos cuja criação é custosa, sendo mais eficiente um protocolo de aquisição / liberação permitindo reciclagem dos mesmos objetos em momentos distintos;

·      Um cache é uma coleção de objetos que replicam informações cuja consulta é custosa (como registros de um BD, objetos de outro processo, ou resultados de algum cálculo complexo).

É comum que o mesmo sistema implemente pools e caches: por exemplo, uma ferramenta de persistência OO como o Hibernate ou JPA pode conter pools de conexões com o SGBD, e um cache de entidades persistentes, entre outros.

A maior diferença entre um pool e um cache reside na maneira como os objetos são gerenciados. Num cache, os objetos são diferenciados, sendo identificados por IDs; já num pool, os objetos são “anônimos”, considerados iguais para os propósitos dos seus clientes, bastando pegar qualquer objeto que esteja disponível. Mas ambos são muito parecidos estruturalmente: são coleções que podem ser preenchidas e consultadas, suportando acesso concorrente, estratégias de gerenciamento de recursos (ex.: limitar o número de objetos contidos para evitar a exaustão de recursos externos ou da memória), e outras características comuns.

Uma terceira técnica igualmente fundamental é a distribuição: na minha definição particular, é a capacidade de tratar vários computadores como se fossem um só. Ou, alternativamente, fazer com que uma aplicação utilize ersos recursos – como CPUs, armazenamento, middlewares como SGBDs, e outras aplicações – de forma transparente em relação à sua disposição numa rede. A distribuição é um fator especialmente crítico em sistemas de grande porte (onde espalhamos a aplicação por várias máquinas que funcionam simultaneamente para idir a carga de trabalho), ou em sistemas de “missão crítica”, com baixa tolerância a falhas (onde replicamos a aplicação em máquinas que funcionam alternadamente, para que falhas isoladas não causem indisponibilidade).

Juntando tudo – como nós desenvolvedores não nascemos para ter uma vida fácil – é fatal que algum dia, tenhamos que juntar todas essas técnicas numa coisa só. Sim, um dia você terá que trabalhar com um pool distribuído, ou um cache distribuído. Quase todo desenvolvedor veterano já se deparou com sistemas que se beneficiariam de tais combinações (embora possa ter percebido o fato ou não). É possível criar soluções ad-hoc para estas necessidades; eu mesmo já fiz isso mais vezes do que gostaria de confessar. Mas é muito mais fácil adotar uma ferramenta que resolva o problema de forma simples e robusta. Neste artigo examinaremos esta ferramenta, o Terracotta.

Antes de seguir a leitura deste artigo, veja a apresentação elaborada por Osvaldo e entenda a importância do Terracotta; sem dúvida uma ferramenta importante e recomendada para todo desenvolvedor.

O problema

Vamos dar um exemplo simples, “mundo real”. Sua aplicação de vendas online tem uma tabela PRODUTO, que contém alguns milhares de registros, um para cada tipo de produto sendo vendido. Essa tabela é extremamente acessada, pois está envolvida no carrinho de compras, faturamento, controle de estoque, etc. – quase todas as entidades e operações importantes da aplicação. É óbvio que o acesso à tabela de produtos irá consumir uma quantidade significativa de recursos, com consultas envolvendo esta tabela várias vezes por segundo.

A solução

A resposta óbvia para este problema é: vamos fazer cache da tabela PRODUTOS. Ao inicializar a aplicação, carregamos esta tabela inteira para a memória, colocando-a em uma ou mais estruturas de dados que refletem as seleções mais comuns da tabela. Por exemplo, podemos ter um

ATENÇÃO! A exibição deste artigo foi interrompida.

  #Este é um post fechado

Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!