我可以在Azure函数中缓存单个值而不产生任何负面影响吗？

我在计时器上有一个Azure函数，它每分钟激活一次，调用一个返回整数值的API。我将该值存储在SQL中

然后，我有另一个Azure函数，用户可以查询该函数来检索整数值。理论上，这个查询可能高达每秒数百或数千次

与每次收到请求时都使用第二个Azure函数查询SQL不同，我希望它将值缓存在内存中。如果缓存是完美的，那么就根本不需要SQL，但是因为函数可以扩展，而且似乎会定期丢失缓存，所以必须有一些持久性存储

是否只是函数中的一个静态变量用于缓存值，而另一个变量具有检索到的最后日期？或者我可以在函数中使用另一种类型的缓存

我知道有像Redis这样的解决方案，但仅仅为了一个整数值，它们似乎有点过头了。我甚至不确定Azure SQL本身是否会在请求时缓存该值

---

我的问题是，静态变量会工作（如果它为null/reset，那么我们只需执行一个快速SQL查询来获取值）并实际保持吗？或者是否存在像redis或类似的替代方案，对于该应用程序来说不会太过苛刻？最后，反复使用SQL来检索单个值（即，缓存是否足够聪明，与查询内存中的变量相比，不会对性能造成重大影响）是否真的有任何危害（性能问题）？

指出函数应该是无状态的，您的状态信息应该包含数据。我认为Redis仍然是SQL真正依赖的更好的选择。如果您了解在azure函数中使用内存缓存的限制，并且您的商业案例对这些限制没有异议，那么您应该使用它

最重要的是你不能使缓存失效。 例如，如果您的号码发生变化，它可能对您不可用。在某些情况下，azure的容器正在旋转，并且它有一个旧值。同一个用户可以在每个请求上获得不同的值，因为谁知道他将命中哪个实例，以及该实例正在缓存什么。 如果您的数字只设置了一次，并且没有更改，则不会出现此问题

另一件重要的事情是，您仍然会发出相当多的请求来缓存它。每个新容器都必须自己缓存它，而集中式缓存只能缓存一次。这对于较小的东西来说是很好的，但是如果你正在缓存的东西真的需要大量的时间，或者如果服务的资源非常有限，那么使用集中式缓存会更有效率

不管怎样，Azure功能级别的缓存仍然会减少负载，而且在不需要的情况下也没有理由发出请求

---

要回答您的sql问题，是的，很可能sql server也会缓存它，但是您的azure函数仍然需要建立到sql server的连接，发出请求并终止连接。

Hmm，我认为缓存值不会与此相矛盾，前提是函数不依赖于缓存的值。