我有一个计时器上的 Azure 函数，每分钟激活一次，它调用一个返回整数值的 API。我将此值存储在 SQL 中。
然后，我有另一个 Azure 函数，用户可以查询该函数以检索整数值。理论上，该查询每秒可能高达数百或数千次。
我希望它能够将值缓存在内存中，而不是每次收到请求时都让第二个 Azure Function 查询 SQL。如果缓存是完美的，则根本不需要 SQL，但由于函数可以扩展并且似乎也会定期丢失其缓存，因此必须有一些持久存储。
这是否只是函数内的静态变量缓存值的情况，以及另一个具有检索到的最后日期的情况？或者我可以在函数中使用另一种类型的缓存吗？
我知道有一些解决方案，例如 Redis，但它们似乎只是为了单个整数值而旋转，有点过分了。我什至不确定 Azure SQL 本身是否会在请求时缓存该值。
我的问题是，静态变量是否有效(如果它为 null/重置，那么我们只需执行快速 SQL 查询即可获取该值)并且实际上会持续存在？或者是否存在像 redis 或类似的替代方案，对于这个应用程序来说不会太过分？最后，一遍又一遍地敲击 SQL 来检索单个值实际上是否有任何危害(性能问题)(即，它是否足够聪明，可以缓存，因此与查询内存中的变量相比，不会对性能造成重大影响)？ p>
最佳答案
确实取决于。如果您了解在 Azure 函数中使用内存缓存的限制，并且您的业务案例可以满足这些限制，那么您应该使用它。
最主要的是你不能使缓存失效。 例如，如果您的号码发生变化，您可能无法使用该号码。您可能会遇到这样的情况:您的 azure 容器正在旋转，并且它具有旧值。同一用户可能会在每个请求上获得不同的值，因为谁知道他将命中哪个实例，以及该实例正在缓存什么。 如果您的编号仅设置一次并且不会更改，则不会遇到此问题。
另一件重要的事情是，您仍然会发出相当多的请求只是为了缓存它。每个新容器都必须为自己缓存它，而集中式缓存只会执行一次。这对于较小的东西来说可能没问题，但如果您要缓存的东西确实需要大量时间，或者服务的资源非常有限，那么使用集中式缓存会更加高效。
无论如何，Azure Function 级别的缓存仍然可以减少负载，并且没有理由在不必要时发出请求。
要回答你的sql问题，是的，很可能SQL服务器也会缓存它，但是你的azure函数仍然需要建立到sql服务器的连接，发出请求并终止连接。
关于azure - 我可以在 Azure Functions 中缓存单个值而不产生任何负面影响吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54824132/