我在AWS Api Gateway中有一个GET方法。缓存已为该阶段启用，并且适用于大多数请求。但是，无论我做什么，似乎都有一些请求会拖到后端。也就是说，某些通过API的请求不会被缓存。
我已经定义了要缓存的参数a，b和c；通过在“请求”设置下选中它们各自的“缓存”框。还有其他未缓存的参数。
请求可以具有所有三个参数，也可以只有一个：
example.com/?a=foo&b=bar&c=baz&d=qux
example.com/?a=foo&d=qux
a，b和c可以采用3到25个不同的值。但是，如果存在a和b，则c只能有一个值。同样，如果没有b，c就不会出现，反之亦然。
例如，假设缓存的TTL为60，我在时间0到10之间发送了此消息：
example.com/?a=foo&b=bar&c=baz&d=qux
example.com/?a=quux&d=qux
example.com/?a=foo&b=quux&c=baz&d=qux
example.com/?a=foo&b=corge&c=fred&d=qux
example.com/?a=baz&d=qux
然后在30到40之间，我发送了相同的请求，并且可能会看到以下日志：
example.com/?a=foo&b=bar&c=baz&d=qux
example.com/?a=quux&d=qux
example.com/?a=baz&d=qux
因此这些请求被缓存，而其他请求则没有：
example.com/?a=foo&b=quux&c=baz&d=qux
example.com/?a=foo&b=corge&c=fred&d=qux
在上面的示例中，大多数缓存没有被缓存，但实际情况并非如此；大多数查询都已缓存。在实际情况下，第二轮运行中有相当数量的请求，大约为600 / s。在第一次运行中，请求速率约为1 / s。我看到的查询是应用程序首先请求的查询。
AWS API Gateway似乎不太可能无法处理类似的查询速率（在1万个请求和5000个突发请求时启用了节流），但似乎应用程序发送的前几个查询会通过。这是API Gateway所期望的吗？
我还认为可能存在缓存大小问题，但是增加缓存似乎无济于事。
那么API网关有什么理由让看似已缓存的请求滑入后端？
更新：创建请求的应用程序的性质是启动请求链。这意味着大约有500-600个应用程序同时启动。当它们进行少量异步处理，然后大约300-500个请求链（同步）时。
考虑到这一点，0 s处的突发速率可能更高。约600个请求/秒高于60秒内平均约36 000个查询。大多数请求将在60年代初完成，但我没有确切的速率数字。在最初的几秒钟内，估计数量可能约为1000-2000个请求/秒，而在第一秒钟内可能甚至更高（例如3000 +）。
答案 0 :(得分：0)
简而言之，我仍然不知道为什么会发生这种情况，但是我设法将漏失的请求数量减到最少。
我这样做的原因是让请求的应用程序将启动延迟了一段时间（我在问题的更新中解释了启动序列的性质）一段时间。我让应用程序选择0到3分钟之间的随机开始时间，以避免API网关出现峰值。
这不能消除请求漏接的现象，但是将请求数从60秒内的500-1500降低到3分钟内的0-10。与60 s的边缘超过1000秒相比，我的后端可以轻松处理。
在我看来，当API网关在短时间内充满大量请求时，它只会将这些请求传递通过。我感到惊讶（有点怀疑），这些数字如此之大，以至于会给AWS造成问题，但这就是我所看到的。
也许这可以通过更改限制级别来解决，但是我发现在使用它时并没有什么区别（请注意，我不是专家！）。