更新:我想出来了,请看下面的答案帖子 .
我有一个AWS API Gateway api,它定义了各种资源和各种GET和POST方法 .
一切都很好 . POST正在进行中 . GET返回响应(JSON有效负载),但返回的值似乎是 cached 值 .
我的GET api调用Lambda函数调用RDS查询 . 我可以确认我的回复是陈旧的,因为:
-
当我手动查询RDS时,我得到更新的值
-
我启用了Cloud Watch日志,并且没有调用lambda函数(我相信我已正确设置它,因为当我测试调用lambda时,我可以获得Cloud Watch日志)
它刷新了一次,但我认为这是因为我越过了一些(如1小时)缓存阈值或其他东西 .
我了解API Gateway在幕后生成CloudFront . 我觉得这就是缓存的作用 . 但这只是猜测,我没有证据 . 也许某种默认缓存TTL?
我显然在API Gateway阶段关闭了缓存 . 我甚至尝试启用它,将TTL设置为1,刷新缓存,并再次禁用缓存 . 该测试的每个阶段仍然返回过时的值 .
我不知道它是否相关,但更多细节:
-
我启用了CORS("*")
-
我启用了Cognito授权程序
-
我通过Authorization标头传入JWT令牌(这一切都正常)
是否有一些 Headers 我应该传递给请求未缓存的值?我去了CloudFront,但这里没有配置 .
API网关缓存上的所有其他帖子似乎都是关于缓存不起作用或人们询问缓存密钥特异性 . 我还没有看到任何关于 Value 总是被缓存的东西,无论如何 . 所以我觉得我错过了一些明显的东西......
任何帮助或调试技巧将不胜感激!
1 回答
好吧,所以我觉得自己是回答自己问题的白痴,但希望有一天能帮助别人 .
这不是API网关缓存问题 . 问题是pymysql连接和lambda会话缓存问题 .
我的Lambda使用pymysql来查询MySQL RDS . 根据推荐的性能原因,我重用了lambdas之间的连接(意味着我每次都没有关闭连接) .
解决方案是致电
conn.commit()
在我做了我的fetchall()之后
发生的事情是我后来的调用返回了一个缓存的查询结果(称为 consistent read . 谢谢!@Michael - sqlbot)我相信我可能有一个以上的lambda容器或其他东西,所以当我不活动一段时间(即繁忙阅读) stackoverflow posts),lambda将卸载 . 然后我的下一个API网关尝试将重新初始化一个新的lambda处理程序,并创建一个分支新连接(没有缓存) . 所以这就是为什么它似乎"sometimes work, then stop" .
如果我浪费了任何人的时间,我会道歉 .