我在AWS Api Gateway中有一个GET方法 . 为阶段启用了缓存，适用于大多数请求 . 然而，无论我做什么，一些请求似乎都会传到后端 . 也就是说，一些通过API的请求不会被缓存 .
我已经定义了要缓存的参数 a ， b 和 c ;通过检查"request"设置下的各自"caching" -box . 还有其他未缓存的参数 .
请求可以包含所有三个参数，也可以只有一个：
example.com/?a=foo&b=bar&c=baz&d=qux
example.com/?a=foo&d=qux
a ， b ＆ c 可以采用3到25个不同的值 . 但如果存在 b 和 c ，则 a 只能有一个值 . 如果没有 c ， b 也不能出现，反之亦然 .
例如，缓存的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似乎不太可能无法处理类似的查询速率（在10 000个请求时启用了限制，在突发时启用了5000个），但似乎应用程序发送的前几个查询无法通过 . 这是API Gateway的预期吗？
我也在考虑可能存在缓存大小问题，但增加缓存似乎没有帮助 .
那么，什么原因可以让API Gateway让看似缓存的请求传递到后端呢？
更新：创建请求的应用程序的性质是它启动请求链 . 意思是，大约有500-600个应用程序都同时启动 . 当他们异步地制作一些，然后是大约300-500个请求的链（同步） .
考虑到这一点，0秒的突发速率可能要高得多 . 大约600个请求/ s超过60秒内平均约36,000个查询 . 大多数请求将在60年代初完成，但我没有确切的数字 . 对于第一秒，估计可能是大约1000-2000个请求/秒，并且对于第一秒可能甚至更多（比如说3000） .
1 回答
简而言之，我仍然不知道为什么会发生这种情况，但我确实设法尽量减少漏掉的请求数量 .
我通过让请求的应用程序延迟启动（我在一个随机时间内解释了对问题更新中的启动序列的性质）来做到这一点 . 我让应用程序选择0到3分钟之间的随机开始时间，以避免API网关出现峰值 .
这并没有消除请求滑过的现象，但它将数量从60秒左右的500-1500降低到3-10分钟的0-10 . 我的后端可以轻松处理的东西，与边缘上的60多个s相比 .
在我看来，当API网关在很短的时间内充斥着大量请求时，它只会通过这些请求 . 我很惊讶（并且有点怀疑）这些数字会大到导致AWS出现问题，但这就是我所看到的 .
也许这可以通过改变节流水平来解决，但我发现玩它时没有区别（请注意，我不是专家！） .