As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Comportamento de leitura do cache
<a name="cache-read"></a>

O shim deve armazenar em cache somente as chamadas de leitura eventualmente consistentes feitas para o DynamoDB. Isso inclui `get_item`, `batch_get_item`, `query` e `scan`. Ele não deve armazenar em cache chamadas de leitura fortemente consistentes ou chamadas de leitura transacionais, porque essas chamadas inerentemente não querem ver uma versão em cache dos dados.

As entradas do cache devem compreender a assinatura da solicitação para identificar solicitações subsequentes equivalentes. A assinatura de cada chamada consiste em todos os parâmetros da solicitação que afetam o resultado. Para uma `get_item` chamada, a assinatura inclui os `ExpressionAttributeNames` parâmetros `TableName` `Key``ProjectionExpression`,, e. Para uma chamada de consulta, ela inclui os `TableName` `Limit` parâmetros `IndexName` `KeyConditions``FilterExpression`,`ScanIndexForward`,,, e. Se duas chamadas para a mesma função tiverem a mesma assinatura, isso é uma possível ocorrência de cache.

Aqui está um exemplo de fluxo lógico para uma `get_item` chamada:
+ Verifique se`ConsistentRead=true`. Nesse caso, chame diretamente o banco de dados e retorne o resultado. Chamadas fortemente consistentes não devem usar um cache.
+ Calcule a assinatura da chamada. Faça o hash dos `ExpressionAttributeNames` parâmetros `TableName``Key`,`ProjectionExpression`, e para obter um único valor de assinatura de string.
+ Veja se existe uma entrada de cache com essa chave de assinatura. Em caso afirmativo, é um problema de cache, então devolva-o.
+ Caso contrário, passe a chamada para o banco de dados, recupere o resultado, preencha a entrada de cache dessa assinatura e retorne o resultado. Ao armazenar o item, especifique um prazo de validade (TTL).

Por exemplo, suponha que você tenha esse código:

```
cache_client.get_item(
  TableName='test',
  Key={ 'PK': { 'S': '123' } },
  ProjectionExpression='#attr1, #attr2',
  ExpressionAttributeNames={
    '#attr1': 'agent',
    '#attr2': 'count'
  },
  ConsistentRead=False
)
```

No interior`cache_client`, o código calcula a assinatura hash da chamada. A assinatura é derivada do hashing da concatenação dos parâmetros`TableName`,`Key`, e. `ProjectionExpression` `ExpressionAttributeNames` Qualquer sistema de hash pode ser usado, desde que seja determinístico e produza um único valor de string. Nesse caso, vamos supor que se reduza a`0xad4c812a`. Esse hash identifica esse conjunto de parâmetros.

E se outra chamada for feita da mesma forma, exceto que ela `#attr1` seja renomeada`#attribute1`? Essa chamada deve ser considerada como tendo a mesma assinatura? Idealmente, sim, porque é semanticamente idêntico, mas a sobrecarga de descobrir a equivalência semântica em cada chamada simplesmente não é prática. É muito mais rápido fazer o hash dos valores dos parâmetros às cegas e exigir correspondências exatas. A regra é: as chamadas são elegíveis para um cache hit se forem *realmente* a mesma chamada, mas não se forem *basicamente* a mesma chamada.

No interior`cache_client`, o código então ElastiCache procura uma entrada no cache de itens que está armazenada em`0xad4c812a`. Se a entrada existir, isso é um hit no cache. Caso contrário, o valor é obtido do banco de dados e armazenado ElastiCache para uma visita posterior ao cache.

Veja a aparência do cache para três `get_item` chamadas que têm três conjuntos diferentes de parâmetros de tabela, chave e projeção.


| Pseudocódigo | ElastiCache cálculo chave | ElastiCache valor | 
| --- | --- | --- | 
| `get_item(t1, k1, p1)` | `hash('get', t1, k1, p1) = 0xad4c812a` | `{ 'Item': … }` | 
| `get_item(t1, k1, p2)` | `hash('get', t1, k2, p2) = 0x045deaab` | `{ 'Item': … }` | 
| `get_item(t1, k2, p1)` | `hash('get', t1, k2, p1) = 0x9cda78af` | `{ 'Item': … }` | 

Outras chamadas, como `query` e`scan`, funcionam da mesma forma, mas parâmetros diferentes compõem suas assinaturas.

Esse design pode lembrá-lo de como funciona um proxy de cache HTTP. Se ele ver a mesma solicitação novamente, ele poderá retornar a resposta da solicitação anterior. A definição da *mesma solicitação* em HTTP é baseada principalmente na string de consulta. Com o DynamoDB, o tipo de chamada e o conjunto de parâmetros que são passados para a função influenciam seus resultados.

Há mais uma etapa. É importante que o armazenamento em cache de itens mantenha um mapeamento entre a chave primária de cada item e a lista de hashes usados ativamente para armazenar esse item em cache. Isso entrará em ação durante as operações de gravação, conforme descrito na próxima seção. Portanto, além das chaves e valores anteriores, haverá entradas extras de cache, como estas:


| Operação | ElastiCache cálculo chave  | ElastiCache valor | 
| --- | --- | --- | 
| Rastreie a lista de entradas para tabela`t1`, chave `k1` | `hash('list', t1, k1)` | ( `0xad4c812a, 0x045deaab` ) | 
| Rastreie a lista de entradas para tabela`t1`, chave `k2` | `hash('list', t1, k2) ` | ( `0x9cda78af` ) |