O WebSphere eXtreme
Scale é mais frequentemente usado como um cache compartilhado, para fornecer acesso transacional a dados para múltiplos componentes onde, caso contrário, um banco de dados tradicional seria usado. O cache compartilhado elimina a necessidade de configurar um banco de
dados.
Coerência do Cache
O cache é coerente porque todos os clientes veem os mesmos dados no cache. Cada pedaço de dado é armazenado em exatamente um servidor no cache, evitando cópias de registros desperdiçadas que poderiam potencialmente conter diferentes versões dos dados. Um cache coerente também pode conter mais dados, à medida que mais servidores são incluídos na grade de dados, e escalado linearmente à medida que a grade cresce em tamanho. Como os clientes acessam dados a partir desta grade de dados com chamadas de processo remotas, ela também é conhecida como um cache remoto, ou cache distante.
Através do particionamento de dados, cada processo contém um subconjunto exclusivo do conjunto de dados total. As grades de dados maiores podem conter mais dados e atender mais solicitações para esses dados. A coerência também elimina a necessidade de enviar dados de invalidação ao redor da grade de dados porque não há dados antigos. O cache coerente retém somente a cópia mais recente de cada pedaço de dados.
Se você estiver executando um ambiente do
WebSphere Application Server, o plug-in TranPropListener também estará disponível. O plug-in TranPropListener usa o componente de alta disponibilidade (Gerenciador HA) do
WebSphere Application Server para propagar as alterações para cada instância de cache ObjectGrid de peer.
Figura 1. Cache Distribuído
Cache Local
Opcionalmente, os clientes têm um cache local, sequencial quando o
eXtreme Scale é usado em uma topologia distribuída. Este cache opcional é chamado de cache local, um ObjectGrid independente em cada cliente, servindo como um cache para o cache remoto, do lado do cliente. O cache local é ativado por padrão
quando o bloqueio é configurado como otimista ou nenhum e não pode ser utilizado quando
é configurado como pessimista.
Um cache local é muito rápido porque fornece acesso em memória a um subconjunto do conjunto inteiro de dados em cache que é armazenado remotamente nos servidores do
eXtreme Scale.
O cache local não é particionado e contém dados de qualquer uma das partições
eXtreme Scale remotas. O
WebSphere eXtreme
Scale pode ter até três camadas de cache, como a seguir.
- O cache da camada da transação contém todas as alterações para uma
única transação.
O cache da transação contém uma cópia de trabalho dos dados até que a
transação seja confirmada. Quando uma transação do cliente solicita
dados de um ObjectMap, a transação é verificada primeiro
- O cache local na camada do cliente contém um subconjunto de dados
da camada do servidor. Quando a camada da transação não possui os dados,
eles são buscados em uma camada do cliente, se disponíveis, e inseridos no cache da transação.
- A grade de dados na camada do servidor contém a maioria dos dados e é compartilhada entre todos os clientes. A camada do servidor pode
ser particionada, o que permite que uma grande quantidade de dados seja
armazenada em cache. Quando o cache local do cliente não possui os dados,
eles são buscados na camada do servidor e inseridos no cache cliente. A camada do servidor também pode ter um plug-in do Utilitário de Carga. Quando a grade não tem os dados necessários, o Utilitário de Carga é chamado e os dados resultantes são inseridos do armazém de dados de backend para a grade.
Para desativar
o cache local, configure o atributo numberOfBuckets como 0 no arquivo
descritor do ObjectGrid de substituição do cliente.
Consulte o tópico sobre bloqueio de entrada de mapa para obter
detalhes sobre estratégias de bloqueio do
eXtreme Scale.
O cache local também pode ser configurado para ter uma política de despejo configurada e diferentes plug-ins usando uma configuração do descritor do eXtreme Scale de substituição.
Vantagem
- Tempo de resposta rápido porque todos os acessos aos dados é local. Procurar pelos dados no cache próximo primeiro economiza acesso à grade de servidores, o que torna até mesmo os dados remotos acessíveis localmente.
Desvantagens
- Aumenta a duração dos dados antigos porque o cache próximo em cada camada pode estar fora de sincronização com os dados atuais na grade de dados.
- Depende de um evictor para invalidar dados a fim de evitar a falta de memória.
Quando Utilizar
Utilize quando o tempo de resposta for importante e
dados antigos puderem ser tolerados.