我正在开发一款移动应用，可以同时向成千上万的设备广播推送消息。当每个用户从推送消息打开他们的应用程序时，该应用程序将点击我们的API数据。对于此次推送的每个用户，API资源都是相同的。
现在让我们假设所有500,000名用户同时打开他们的应用程序。 API网关将获得500,000个相同的呼叫。
因为所有500,000个几乎并发的请求都要求相同的数据，所以我想缓存它。但请记住，计算所请求的值大约需要2秒钟。
我想要发生什么
我希望API网关看到数据不在缓存中，让第一个调用到我的后端服务，而其他请求保存在队列中，从第一个调用填充缓存，然后响应另一个使用缓存数据的499,999个请求。
（好像）正在发生什么
API网关，看到没有缓存值，将500,000个请求中的每一个发送到后端服务！因此，我将使用一些复杂的数据库查询方式重新计算该值，这比资源允许的次数多。发生这种情况是因为最后一次调用在第一次调用填充缓存之前进入API网关。
有什么方法可以解决这个问题吗？
我知道根据我的例子，也许我可以通过在广播批量推送作业之前调用API调用来填充缓存，但实际用例比我的稍微复杂一点简化的例子。但请放心，解决这个简化的用例将解决我想要做的事情。
答案 0 :(得分：0)
如果您预计会出现这种突发并发，那么自己启动缓存当然是最好的选择。您是否还考虑过在阶段/方法中添加限制以保护您的后端免受大量流量的影响？可以指示客户端重试节流阀，他们最终会得到响应。
我会将您的反馈和建议的解决方案提交给团队并将其放在我们的积压工作中。