A API de Cache Dinâmico está disponível para os aplicativos Java EE que são implementados no WebSphere Application Server. É possível usar o provedor de cache dinâmico para armazenar dados de negócios em cache, HTML gerado ou sincronizar dados em cache na célula usando o Data Replication Service (DRS).
Previamente, o único provedor de serviços para a API de Cache Dinâmico era o mecanismo de cache dinâmico padrão construído dentro doWebSphere Application Server. Os clientes podem usar a interface do provedor de serviço de cache dinâmico no WebSphere Application Server para plugar o eXtreme Scale no cache dinâmico. Ao configurar esse recurso, é possível ativar aplicativos gravados com a API de Cache Dinâmico ou os aplicativos usando o armazenamento em cache no nível do contêiner (como servlets) para usar os recursos e as capacidades de desempenho do WebSphere eXtreme Scale.
É possível instalar e configurar o provedor de cache dinâmico conforme descrito em Configurando o Provedor de Cache Dinâmico para o WebSphere eXtreme Scale.
Os recursos disponíveis noWebSphere eXtreme Scale aumentam significantemente os recursos distribuídos da API do cache dinâmico além do que é oferecido pelo mecanismo de cache dinâmico e serviço de replicação de dados. Com o eXtreme Scale, é possível criar caches que são verdadeiramente distribuídos entre múltiplos servidores, em em de simplesmente replicados e sincronizados entre os servidores. Também, os caches do eXtreme Scale são transacionais e altamente disponíveis, garantindo que cada servidor veja o mesmo conteúdo para o serviço de cache dinâmico. O WebSphere eXtreme Scale oferece um qualidade de serviço mais alta para replicação de cache do que o DRS.
Porém, essas vantagens não significam que o provedor de cache dinâmico doeXtreme Scale seja a escolha certa para cada aplicativo. Use as árvores de decisão e matriz e comparação de recursos abaixo para determinar qual tecnologia se encaixa melhor no seu aplicativo.
Recursos do cache | Provedor padrão | Provedor do eXtreme Scale | eXtreme Scale API |
---|---|---|---|
Cache na memória, local |
x |
x |
x |
Armazenamento em cache distribuído |
Integrado |
Integrado, particionado integrado e particionado remoto |
Múltiplo |
Linearmente escalável |
x |
x |
|
Replicação confiável (síncrona) |
ORB |
ORB |
|
Estouro de disco |
x |
||
Despejo |
LRU/TTL/baseado em heap |
LRU/TTL (por partição) |
Múltiplo |
Invalidação |
x |
x |
x |
Relacionamentos |
IDs de dependência, modelos |
IDs de dependência, modelos |
x |
Consultas sem chave |
Consulta e índice |
||
Integração de backend |
Utilitários de Carga |
||
Transacional |
Implícito |
x |
|
Armazenamento baseado em chave |
x |
x |
x |
Eventos e listeners |
x |
x |
x |
Integração do WebSphere Application Server |
Somente célula única |
Célula múltipla |
Célula independente |
Suporte à Java Standard Edition |
x |
x |
|
Monitoramento e estatística |
x |
x |
x |
Segurança |
x |
x |
x |
Recursos do cache | Provedor padrão | Provedor do eXtreme Scale | eXtreme Scale API |
Armazenamento em cache dos resultados do servlet/JSP do WebSphere Application Server |
V5.1+ |
V6.1.0.25+ |
|
Armazenamento em cache do resultado do WebSphere Application Server Web Services (JAX-RPC) |
V5.1+ |
V6.1.0.25+ |
|
Armazenamento em cache de sessão HTTP |
x |
||
Provedor de cache para OpenJPA e Hibernate |
x |
||
Sincronização de banco de dados usando OpenJPA e Hibernate |
x |
Recursos do cache | Provedor padrão | Provedor do eXtreme Scale | eXtreme Scale API |
---|---|---|---|
API baseada em comandos |
API da estrutura de comandos |
API da estrutura de comandos |
API de DataGrid |
API baseada em mapa |
API de DistributedMap |
API de DistributedMap |
API do ObjectMap |
API do EntityManager |
x |
Para obter uma descrição mais detalhada sobre como os caches distribuídos do eXtreme Scale funcionam, consulte o Planejando a Topologia .
Um serviço de cache dinâmico criado com o provedor doeXtreme Scale pode ser implementado em qualquer uma de três topologias disponíveis, permitindo que você padronize o cache especificamente para desempenho, recurso e necessidades administrativas. Essas topologias são integradas, particionadas integradas e remotas.
Topologia Integrada
A topologia integrada é similar ao cache dinâmico padrão e ao provedor DRS. Instâncias de cache distribuído criados com a topologia integrada mantêm uma cópia integral do cache dentro de cada processo doeXtreme Scale que acessa o serviço de cache dinâmico, permitindo que todas as operações de leitura ocorram localmente. Todas as operações de gravação passam por um processo de servidor único, no qual os bloqueios transacionais são gerenciados, antes de serem replicados para o restante dos servidores. Consequentemente, esta topologia é melhor para cargas de trabalho nas quais as operações de leitura de cache excedem grandemente as operações de gravação em cache.
Com a topologia integrada, entradas de cache novas e atualizadas não são imediatamente visíveis em cada processo de servidor único. Uma entrada de cache não estará visível, mesmo para o servidor que a gerou, até ser propagada por meio dos serviços de replicação assíncrona do WebSphere eXtreme Scale. Esses serviços operam tão rapidamente quanto o hardware permitir, mas ainda há um pequeno atraso. A topologia integrada é mostrada na seguinte imagem:
Topologia particionada integrada
Para cargas de trabalho nas quais as gravações em cache ocorrem tão frequentemente quanto ou mais frequentemente que as leituras, as topologias remotas ou particionadas integradas são recomendadas. A topologia particionada integrada mantém todos os dados do cache dentro dos processos do WebSphere Application Server que acessam o cache. Porém, cada processo somente armazena uma parte dos dados do cache. Todas as leituras e gravações para os dados localizados nesta “partição” passam pelo processo, o que significa que a maioria dos pedidos para o cache será preenchido com uma chamada de procedimento remoto. Isto resulta em uma latência mais alta para operações de leitura do que a topologia integrada, mas a capacidade do cache distribuído de manipular operações de leitura e gravação escalarão linearmente com o número de processos doWebSphere Application Server que acessa o cache. Também, com esta topologia, o tamanho máximo do cache não é limitado pelo tamanho de um único processo doWebSphere. Porque cada processo somente retém uma parte do cache, o tamanho de cache máximo se torna o tamanho agregado de todos os processos, menos o gasto adicional do processo. A topologia particionada integrada é mostrada na seguinte imagem:
Por exemplo, suponha que você tem uma grade de processos do servidor com 256 megabytes de heap livre em cada um deles para hospedar um serviço de cache dinâmico. O provedor de cache dinâmico padrão e o provedor do eXtreme Scale que usa a topologia integrada seriam, ambos, limitados a um tamanho de cache de memória de 256 megabytes menos o gasto adicional. Consulte a seção Planejamento de Capacidade e Alta Disponibilidade, posteriormente neste documento. O provedor doeXtreme Scale que usa a topologia particionada integrada seria limitado a um tamanho de cache de um gigabyte menos o gasto adicional. Desta maneira, o provedor do WebSphere eXtreme Scale possibilita ter serviços de cache dinâmico na memória maiores que o tamanho de um único processo do servidor. O provedor de cache dinâmico padrão conta com o uso de um cache de disco para permitir que instâcias de cache cresçam além do tamanho de um processo único. Em muitas situações, o provedor doWebSphere eXtreme Scale pode eliminar a necessidade de um cache de disco e os dispendiosos sistemas de armazenamento em disco necessários para fazê-los executar.
Topologia Remota
A topologia remota também pode ser usada para eliminar a necessidade de um cache de disco. A única diferença entre as topologias remotas e particionadas integradas é que todas os dados em cache são armazenados fora dos processos do WebSphere Application Server quando você está usando a topologia remota. O WebSphere eXtreme Scale suporta processos de contêiner independentes para dados do cache. Esses processos de contêiner têm um gasto adicional mais baixo do que um processo do WebSphere Application Server e também não são limitados ao uso de uma Java Virtual Machine (JVM) particular. Por exemplo, os dados para um serviço de cache dinâmico que está sendo acessado por um processo do WebSphere Application Server de 32 bits poderiam ser alocados em um processo de contêiner do eXtreme Scale que estivesse executando em uma JVM de 64 bits. Isso permite aos usuários usar a capacidade de memória aumentada dos processos de 64 bits para armazenamento em cache, sem incorrer um gasto adicional de 64 bits para os processos do servidor de aplicativos. A topologia remota é mostrada na seguinte imagem:
Compactação de dados
Outro recurso de desempenho oferecido pelo provedor de cache dinâmico do WebSphere eXtreme Scale que pode ajudar os usuários a gerenciar o gasto adicional de cache é a compactação. O provedor de cache dinâmico padrão não permite compactação de dados em cache na memória. Com o provedor doeXtreme Scale, isso se torna possível. A compactação de cache que usa o algoritmo de deflação pode ser ativada em qualquer uma das três topologias distribuídas. Ativar a compactação aumentará o gasto adicional para operações de leitura e gravação, mas aumentará drasticamente a densidade do cache para aplicações como armazenamento em cache de servlet e JSP.
Cache de Memória Local
O provedor de cache dinâmico do WebSphere eXtreme Scale também pode ser usado para retornar as instâncias do cache dinâmico que têm a replicação desativada. Como o provedor de cache dinâmico padrão, esses caches podem armazenar dados não serializáveis. Eles também podem oferecer melhor desempenho que o provedor de cache dinâmico padrão em servidores corporativos de multiprocessador grande porque o caminho do código do eXtreme Scale é projetado para maximizar a simultaneidade do cache em memória.
No caso de caches em memória locais nos quais a replicação está desativada, não deve haver nenhuma diferença funcional apreciável entre os caches retornados pelo provedor de cache dinâmico padrão e o WebSphere eXtreme Scale. Os usuários não devem observar uma diferença funcional entre os dois caches, exceto que os caches retornados pelo WebSphere eXtreme Scale não suportam a transferência de disco ou estatísticas e operações relacionadas ao tamanho do cache em memória.
No caso de caches nos quais a replicação está ativada, não deve haver nenhuma diferença funcional apreciável nos resultados retornados pela maioria das chamadas de API de Cache Dinâmico, independentemente de o cliente estar usando o provedor de cache dinâmico padrão ou o provedor de cache dinâmico do eXtreme Scale. Para algumas operações não é possível emular o comportamento do mecanismo de cache dinâmico usando o eXtreme Scale.
As estatísticas de cache dinâmico são relatadas por meio do aplicativo CacheMonitor ou do MBean de cache dinâmico. Quando o provedor de cache dinâmico do eXtreme Scale for usado, as estatísticas ainda serão reportadas através dessas interfaces, mas o contexto dos valores estatísticos serão diferente.
Se uma instância do cache dinâmico é compartilhada entre três servidores nomeados A, B e C, então o objeto das estatísticas do cache dinâmico somente retorna estatísticas para a cópia do cache no servidor no qual a chamada é feita. Se as estatísticas são recuperadas no servidor A, elas refletem somente a atividade no servidor A.
Com o eXtreme Scale, existe somente um único cache distribuído compartilhado entre todos os servidores, assim, é impossível controlar a maioria das estatísticas em uma base servidor-a-servidor como o provedor de cache dinâmico padrão faz. Uma lista das estatísticas reportadas pela API de Estatísticas de Cache e o que elas representam quando você está usando o provedor de cache dinâmico do WebSphere eXtreme Scale estão a seguir. Como o provedor padrão, essas estatísticas não são sincronizadas e, portanto, podem variar até 10% para cargas de trabalho simultâneas.
O provedor de cache dinâmico permite reconfigurar as estatísticas de cache. Com o provedor padrão a operação de reconfiguração somente limpa as estatísticas no servidor afetado. O provedor de cache dinâmico do eXtreme Scale controla a maioria de seus dados estatísticos nos contêineres de cache remoto. Estes dados não são limpos ou alterados quando as estatísticas são reconfiguradas. Em vez disso, o comportamento do cache dinâmico padrão é simulado no cliente por meio do relato da diferença entre o valor atual de uma determinada estatística e o valor dessa estatística na última vez que a reconfiguração foi chamada nesse servidor.
Por exemplo, se o tráfego no Servidor A gerar 10 remoções de cache, as estatísticas no Servidor A e no Servidor B relatarão 10 remoções. Agora, se as estatísticas no Servidor B são reconfiguradas e o tráfego no Servidor A gerar 10 remoções adicionais, as estatísticas no Servidor A relatarão 20 remoções e as estatísticas no Servidor B relatarão 10 remoções.
A API do Cache Dinâmico permite aos usuários registrar listeners de evento. Quando estiver usando o eXtreme Scale como o provedor de cache dinâmico, os listeners de evento funcionarão como esperado para caches na memória local.
Para caches distribuídos, o comportamento de evento dependerá da topologia que estiver sendo usada. Para caches que usam a topologia integrada, os eventos serão gerados no servidor que manipula as operações de gravação, também conhecidos como o shard primário. Isso significa que somente um servidor receberá notificações de evento, mas ele terá todas as notificações de evento normalmente esperadas do provedor de cache dinâmico. Porque o WebSphere eXtreme Scale escolhe o shard primário no tempo de execução, é impossível garantir que um processo de servidor particular sempre receba esses eventos.
Caches particionados integrados gerarão eventos em qualquer servidor que hospede uma partição do cache. Portanto, se um cache tiver 11 partições e cada servidor em uma grade do WebSphere Application Server Network Deployment de 11 servidores hospedar uma das partições, cada servidor receberá os eventos do cache dinâmico para as entradas de cache que hospedar. Nenhum processo de servidor único veria todos os eventos a menos que todas as 11 partições estivessem hospedadas nesse processo de servidor. Assim como ocorre com a topologia integrada, é impossível garantir que um processo de servidor particular receberá um conjunto particular de eventos ou quaisquer eventos.
Os caches que usam a topologia remota não suportam eventos de cache dinâmico.
O provedor de cache dinâmico do WebSphere eXtreme Scale não suporta o armazenamento em disco. Quaisquer chamadas de MBean relacionadas ao armazenamento em disco não funcionarão.
O provedor de cache dinâmico integrado do WebSphere Application Server suporta múltiplas políticas de replicação de cache. Essas políticas podem ser configuradas globalmente ou em cada entrada de cache. Consulte a documentação de cache dinâmico para obter umadescrição dessas políticas de replicação.
O provedor de cache dinâmico do eXtreme Scale não segue essas políticas diretamente. As características de replicação de um cache são determinadas pelo tipo de topologia distribuídas do eXtreme Scale configurado e se aplicam a todos os valores colocados neste cache, independentemente do conjunto de políticas de replicação na entrada pelo serviço de cache dinâmico. A seguir há uma lista de todas as políticas de replicação suportadas pelo serviço de cache dinâmico e a ilustração de qual topologia do eXtreme Scale fornece características de replicação similares.
Note que o provedor de cache dinâmico do eXtreme Scale ignora as configurações da política de replicação DRS em um cache ou entrada de cache. Os usuários devem escolher a topologia que se adéqua às suas necessidades de replicação.
Estas informações são fornecidas principalmente para que você possa se certificar de que a topologia satisfaz suas necessidades de consistência distribuída. Por exemplo, se a topologia integrada é uma melhor escolha para as suas necessidades de desempenho e implementação, mas você precisa do nível da consistência de cache fornecido por SHARED_PUSH_PULL, então considere usar a particionada integrada, ainda que o desempenho possa ser ligeiramente mais lento.
Você pode proteger as instâncias de cache dinâmico que estão executando em topologias particionadas integradas ou topologias integradas com a funcionalidade de segurança compilada no WebSphere Application Server. Consulte a documentação em Protegendo servidores de aplicativos no WebSphere Application Server Centro de Informações.
Quando um cache está executando em topologia remota, é possível para um cliente eXtreme Scale independente se conectar ao cache e afetar o conteúdo da instância do cache dinâmico. O provedor de cache dinâmico do eXtreme Scale tem um recurso de criptografia de gasto adicional baixo que pode evitar que os dados do cache sejam lidos ou alterados por clientes não-WebSphere Application Server. Para ativar esse recurso, configure o parâmetro opcional com.ibm.websphere.xs.dynacache.encryption_password para o mesmo valor em cada instância do WebSphere Application Server que acesse o provedor de cache dinâmico. Isso irá criptografar o valor e os metadados do usuário para o CacheEntry usando criptografia AES de 128 bits. É muito importante que o mesmo valor seja configurado em todos os servidores. Os servidores não poderão ler dados colocados em cache por servidores com um valor diferentes para este parâmetro.
Se o provedor do eXtreme Scale detectar que diferentes valores estão configurados para esta variável no mesmo cache, ele gera um aviso no log do processo do contêiner do eXtreme Scale.
Consulte a documentação do eXtreme Scale no Visão Geral de Segurança se autenticação SSL ou do cliente for necessária.