Conhecendo os componentes lógicos do "Velocity"

  • Article

Complementando o post anterior, vou falar sobre os componentes lógicos do "Velocity" CTP2.

Como vimos anteriormente, o Core do "Velocity" é um Windows Service instalado em uma ou mais máquinas. Esse Windows Service lê as informações do Cluster Configuration Storage Location e inicia a comunicação entre os nós do Cache Cluster. Antes de começarmos a codificar precisamos entender alguns conceitos sobre Caches distribuídos. Os componentes lógicos do "Velocity" serão listados a seguir.

Componentes Lógicos

Named Cache: É a unidade lógica que armazena os objetos na memória e que se espalha por todos os nós do cluster. Fazendo uma grosseira analogia com os bancos de dados relacionais, o Named Cache seria o Database em nossa estrutura física do SQL Server. Assim como no SQL Server, podemos ter vários Named Cache em um cache cluster. Cada Named Cache é independente, isto é, pode ser configurado separadamente.
Logo após a instalação do "Velocity" um Named Cache padrão chamado "Default" é criado. Para criar novos Named Cache pode-se utilizar o ambiente de administração do "Velocity" via Power Shell, ou, se um Named Cache além do "Default" for sempre utilizado, pode-se inserir esse parâmetro no arquivo de configuração do "Velocity", caso tenha sido escolhido o XML-based cluster configuration storage.

Criando um Named Cache via Power Shell:  

PS> New-Cache-CacheName <CacheName>

Configurando um Named Cache via XML-based cluster configuration storage:

Quando utiliza-se o XML-based cluster configuration storage são criados 2 arquivos na pasta compartilhada. São eles:

  • ClusterConfig.xml: Arquivo texto baseado em XML com as configurações do cache cluster que é lido durante a inicialização do serviço do "Velocity".

  • ConfigStore.sdf: Arquivo baseado em SQL Server Compact data file utilizado para armazenar informações de operação como a lista dos nós do cluster que estão no ar. Note que em nenhum momento os dados dos objetos colocados no cache do "Velocity" são persistidos em disco.

Essa sessão configura o nome do cache cluster:   

<dcache cluster="ClusterName1" size="Small">

Quando o cache cluster é criado, logo em seguida o "Velocity" lê a sessão <cache> e configura os Named Cache para aquele cluster. 

<caches>
<!-- Specifies the default cache -->
<!-- (High Availablity disabled)-->
<cache type="partitioned" consistency="strong" name="default" replicas="1"
minWriteQuorum="1">
<policy>
<eviction type="lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>

Acima é o Named Cache default, que vem pré-configurado com a instalação do "Velocity".

Para criar um novo Named Cache basta adicionar uma nova sub-sessão <cache> dentro da sessão <caches> conforme abaixo:

<!-- Specifies the new cache -->
<!-- (High Availablity enabled)-->
<cache type="partitioned" consistency="strong" name="MEU-NAMED-CACHE" replicas="2"
minWriteQuorum="2">
   <policy>
<eviction type="lru" />
<expiration defaultTTL="10" isExpirable="true" />
</policy>
</cache>

Pronto, dessa maneira toda vez que o "Velocity" iniciar o primeiro nó do cluster cache ele criara além do Named Cache default o Named Cache configurado. Em outro post falarei com mais detalhes do arquivo de configuração e suas sessões.

Regions: Voltando a fazer uma grosseira analogia com os banco de dados, assim como os Named Cache podem ser comparados com databases dentro do SQL Server, as Regions podem ser comparadas com as tabelas dentro dos databases do SQL Server. A diferença aqui é que a utilização de uma Region não é obrigatória. Podemos ter Cached Objects no nível dos Named Cache ou no nível das Regions como pode-se ver na figura acima. 
A escolha por utilizar ou não Regions afeta diretamente a performance e escalabilidade da solução. Quando utiliza-se Regions temos um resultado na busca dos Cached Objects muito mais rápido do que sem Regions, porém perdemos a alta disponibilidade, pois uma Region só fica hospedada em uma única máquina do cache cluster. Já quando não utilizamos Region, os Cached Objects são distribuídos por todos os hosts do cache cluster permitindo a alta disponibilidade porém com uma performance de busca um pouco pior.
O projeto de arquitetura deve levar em conta uma série de fatores para decidir o modelo de persistência em memória dos Cached Objects. Por esse motivo esse assunto será abordado em um post exclusivo.

Cached Objects: Na mesma linha das analogias grosseiras, os Cached Objects seriam as linhas das tabelas. O "Velocity" permite armazenar qualquer CLR Object. Todos os objetos quando são recuperados retornam como System.Object o que obriga o type cast para o tipo original como no exemplo abaixo:

//Create the cache object
Cache Cache1 = CacheFactory1.GetCache(strCacheName);

//Call the Get method
string strCacheItemValue = (string)Cache1.Get(strKey);

Bom, falarei mais sobre arquitetura do "Velocity" em outros posts. Especificamente o próximo post sobre arquitetura será sobre o modelo de comunicação interno do cache cluster.

Abraços a todos.

Daibert