Esta página se aplica à Apigee e à Apigee híbrida.
Confira a documentação da
Apigee Edge.
Ao usar políticas de cache, você garante a exclusividade das chaves de valor armazenadas em cache configurando as chaves de cache. Uma chave de cache, junto com outros valores que podem ser configurados, oferece a você uma maneira confiável de extrair os mesmos dados que foram armazenados. Você usa chaves de cache com as políticas PopulateCache, LookupCache, InvalidateCache e ResponseCache.
A Apigee usa os valores dos elementos de configuração
(<Scope>,
<CacheKey>/<Prefix> e
<CacheKey>/<KeyFragment>) para compor um
valor chave de cache, que é um identificador associado ao
valor no cache. A composição da chave de cache funciona da mesma forma com todas as
políticas de cache.
Com os seguintes elementos de configuração da política de cache, é possível criar uma chave de cache:
| Elemento de configuração de cache | Descrição |
|---|---|
<Scope> ou <CacheKey> /
<Prefix>
|
Use os elementos <Scope> ou
<CacheKey> <Prefix>
para configurar um prefixo a ser aplicado na chave de cache final.
<Scope> enumera uma lista de valores predefinidos. O
elemento <CacheKey> <Prefix>
modifica <Scope> para um valor que você
escolher.
|
<CacheKey> / <KeyFragment> |
Use um ou mais elementos <KeyFragment>
<CacheKey> combinados para especificar um identificador
exclusivo para entradas de cache. Os valores de KeyFragment podem ser literais estáticos
ou definidos com base em variáveis.
|
A Apigee compõe a chave de cache de duas partes, a parte de prefixo e a parte do fragmento composto, separadas por um sublinhado duplo.
PREFIX_PART__FRAGMENT_PART
A parte do prefixo é determinada pelo elemento <Scope> ou
pelo elemento <CacheKey> <Prefix>, se estiver
presente. A parte do fragmento é composta por cada um dos valores de cada
elemento <KeyFragment>, unidos por sublinhados duplos.
Com a política de cache de resposta, é possível anexar essa chave de cache com valores do cabeçalho de aceitação de resposta.
Como usar a {CacheKey}
O elemento <CacheKey> configura como a Apigee criará um
identificador exclusivo (uma chave) para cada entrada de cache criada. Quando a Apigee
recupera o valor armazenado em cache, ela usa a chave de cache para localizar o valor correto.
Na política ResponseCache, uma configuração define a chave para
o armazenamento em cache e a recuperação. Nas políticas PopulateCache e LookupCache, cada
política precisa ter elementos <CacheKey> idênticos para garantir
que um valor recuperado do cache corresponda a um valor inserido nele.
O elemento <CacheKey> pode incluir um único elemento
<Prefix>
opcional, bem como um ou mais
elementos <KeyFragment>. No ambiente de execução, a Apigee concatena os
valores determinados de cada parte dos dois sublinhados entre eles para compor a
chave de cache.
Por exemplo, a configuração a seguir cria um valor de
myprefix__hello__world para uso na chave de cache:
<CacheKey>
<Prefix>myprefix</Prefix>
<KeyFragment>hello</KeyFragment>
<KeyFragment>world</KeyFragment>
<CacheKey>
É possível configurar a Apigee para usar uma chave de cache composta dinamicamente
referenciando a variável em um elemento <KeyFragment>, como
mostrado aqui:
<KeyFragment ref="variable_name"/>
Por exemplo, para fazer com que o valor da chave de cache incorpore o Content-Type da mensagem de solicitação, faça o seguinte:
<KeyFragment ref="request.header.Content-Type"/>
Considere a seguinte configuração:
<CacheKey> <Prefix>system1</Prefix> <KeyFragment>apiAccessToken</KeyFragment> <KeyFragment ref="request.header.Content-Type" /> <KeyFragment>bar</KeyFragment> </CacheKey>
Se a variável request.header.Content-Type tiver o valor
application/json, isso resultará em uma chave de cache de
system1__apiAccessToken__application/json__bar.
É possível usar variáveis definidas pela plataforma ou personalizadas em um
atributo ref.
Chaves de cache derivadas dos parâmetros de consulta
Ao usar variáveis como request.queryparam.<queryparam_name> e request.querystring, é possível configurar uma chave de cache para que a chave inclua partes da string de consulta de uma solicitação. Por exemplo, o URL a seguir usa dois parâmetros de consulta (param1 e param2) que podem ser usados na chave de cache:
http://myaccount.apigee.net/mydata?param1=value1¶m2=value2
O elemento <CacheKey> pode incorporar esses valores com uma
configuração como a seguinte:
<CacheKey>
<KeyFragment ref="request.queryparam.param1" />
<KeyFragment ref="request.queryparam.param2" />
<CacheKey>No ambiente de execução, a chave de cache inclui os valores de parâmetro concatenados, como no exemplo a seguir:
prefix_part__value1__value2
Em vez de especificar vários parâmetros de consulta distintos, é possível
usar a variável request.querystring, que insere toda
a string de parâmetros literalmente como parte da chave de cache. Lembre-se de que
esse método considera todos os parâmetros, mas se a ordem dos
parâmetros variar de uma solicitação para a próxima, a chave será diferente.
Em outras palavras, param1=value1¶m2=value2 e
param2=value2¶m1=value1 não resultam no mesmo valor de chave
de cache.
Como usar <Scope> e <Prefix>
Os elementos <Scope> e <CacheKey> /
<Prefix> oferecem uma maneira de organizar valores em cache
em um namespace. A Apigee anexa um valor derivado deles à chave de cache.
A vantagem de usar um escopo ou prefixo na chave de cache é que é possível
invalidar todos os valores que compartilham um único prefixo, com uma chamada para a
política InvalidateCache.
O elemento <Scope> é usado por padrão. Trata-se de uma
enumeração com valores que variam de amplo a restrito, com o mais restrito como
padrão. Esse valor padrão será usado, a menos que você especifique outro valor ou
um valor de elemento <Prefix>. É possível modificar o
valor <Scope> usando um elemento <CacheKey> /
<Prefix>. Portanto, especifique um valor personalizado para
o namespace.
Por exemplo, o valor <Scope> "Global", o escopo
mais amplo, representa o nome da organização e do ambiente. Por isso, se o proxy for
implantado em uma organização chamada "mycompany" e um ambiente chamado
"prod", o valor resultante anexado como prefixo é o seguinte:
mycompany__prod__[FRAGMENT_PART]
Conforme descrito na política LookupCache, o escopo pode ser configurado para aumentar a especificidade de Global para Exclusivo. Um escopo Exclusivo é o mais específico e, portanto, representa um risco mínimo de colisões de namespaces em um determinado cache. Cada entrada de cache com um escopo Exclusivo é prefixada no seguinte formato:
orgName__envName__apiProxyName__deployedRevisionNumber__nameof(proxyEndpoint|targetEndpoint)__[serializedCacheKey]
Veja alguns exemplos. Eles presumem que a 16a revisão do proxy chamada "weatherapi" seja implantada em uma organização chamada "minhaempresa" e um ambiente chamado "prod", que o nome proxyEndpoint seja "padrão" e que a política de cache é anexada a um fluxo no proxyEndpoint.
| Configuração | Resultado |
|---|---|
<Scope>Global</Scope> <CacheKey> <KeyFragment>hello</KeyFragment> <KeyFragment>world</KeyFragment> <CacheKey> |
mycompany__prod__hello__world. |
<Scope>Exclusive</Scope>
<CacheKey>
<KeyFragment>hello</KeyFragment>
<KeyFragment>world</KeyFragment>
<CacheKey> |
mycompany__prod__weatherapi__16__default__hello__world |
<Scope>Exclusive</Scope>
<CacheKey>
<Prefix>system1</Prefix>
<KeyFragment>hello</KeyFragment>
<KeyFragment>world</KeyFragment>
<CacheKey> |
system1__hello__world
Nesse caso, o elemento |