缓存读取行为

shim 应仅缓存对 DynamoDB 进行的最终一致性读取调用。这包括 get_item、batch_get_item、query 和 scan。它不应缓存强一致性读取调用或事务性读取调用，因为这些调用本质上不希望看到数据的缓存版本。

缓存条目必须了解请求的签名，才能识别后续的等效请求。每个调用的签名由影响结果的请求的所有参数组成。对于get_item呼叫，签名包括TableName、KeyProjectionExpression、和ExpressionAttributeNames参数。对于查询调用，它包括TableName、IndexName、KeyConditionsFilterExpression、ScanIndexForward、和Limit参数。如果对同一函数的两个调用具有相同的签名，则可能是缓存命中。

以下是get_item呼叫的逻辑流程示例：

例如，假设你有这样的代码：

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

在内部cache_client，代码计算呼叫的哈希签名。签名源于对TableName、Key、和参数的串联进行哈希处理。ProjectionExpression ExpressionAttributeNames任何哈希系统都可以使用，只要它是确定性的，并且生成单个字符串值。在本例中，我们假设它哈希值为。0xad4c812a此哈希值标识了这组参数。

如果再打一个相同的电话怎么办，只是#attr1它被重命名了#attribute1？ 该通话是否应该被视为具有相同的签名？ 理想情况下，是的，因为它在语义上是相同的，但是弄清楚每个呼叫的语义等同性的开销是不切实际的。盲目地对参数值进行哈希处理并要求精确匹配要快得多。规则是：如果呼叫实际上是同一个呼叫，则有资格获得缓存命中，但如果它们基本上是相同的呼叫，则不符合缓存命中资格。

然后cache_client，代码在里面 ElastiCache 查找存储在下的项目缓存中的条目0xad4c812a。如果该条目存在，那就是缓存命中。如果不是，则从数据库中获取该值并存储在中 ElastiCache 供以后缓存中使用。

以下是具有三组不同表、键和投影参数的三个get_item调用的缓存样子。

其他调用（例如query和scan）的工作方式相同，但它们的签名由不同的参数组成。

这种设计可能会让你想起 HTTP 缓存代理的工作原理。如果它再次看到相同的请求，它可以返回先前请求的响应。HTTP 中相同请求的定义主要基于查询字符串。在 DynamoDB 中，传递给函数的调用类型和参数集会影响其结果。

还有一个步骤。对于项目缓存来说，重要的是要在每个项目的主键和主动用于缓存该项目的哈希列表之间保持映射。这将在写入操作期间发挥作用，如下一节所述。因此，除了之前的键和值之外，还会有额外的缓存条目，例如：