我在计时器上有一个Azure函数，该函数每分钟都会激活一次，该函数调用一个返回整数值的API。我将此值存储在SQL中。
然后我有另一个Azure函数，用户可以查询该函数以检索整数值。从理论上讲，该查询每秒可能高达数百或数千次。
我希望第二个Azure Function在每次收到请求时都没有查询SQL，而是希望将值缓存在内存中。如果缓存是完美的，那么根本就不需要SQL，但是由于Function可以扩展，而且似乎也会定期丢失其缓存，因此必须有一些持久性存储。
在函数中缓存值只是静态变量的一种情况，而在最近一次获取值的情况下又是一种情况？还是我可以在函数中使用另一种类型的缓存？
我了解有Redis之类的解决方案，但仅将其用于单个整数值似乎过于矫kill过正。我什至也不知道Azure SQL本身是否会在请求时缓存该值。
我的问题是，静态变量是否可以工作（如果它为null / reset，那么我们将执行一个快速SQL查询以获取该值）并实际上持久存在吗？还是存在像redis之类的替代方案，对于该应用程序来说不会过分杀伤力？最后，一遍又一遍地锤击SQL来检索单个值是否存在任何危害（性能问题）（即，是否足够聪明地进行缓存，因此与查询内存中的变量相比，性能不会受到重大影响）？
答案 0 :(得分：2)
真的取决于。如果您了解在azure函数中使用内存缓存的局限性，并且您的业务案例可以满足这些局限性，则应该使用它。
主要是您不能使缓存无效。 因此，例如，如果您的电话号码更改，则可能对您不可用。在某些情况下，您的天蓝色容器会旋转，并且具有旧的价值。同一用户在每个请求上可能会获得不同的值，因为谁知道他将命中哪个实例以及该实例正在缓存什么。 如果您的电话号码只能设置一次且不会更改，则不会出现此问题。
另一个重要的事情是，您仍然要进行很多缓存请求。每个新容器都必须为其自身进行缓存，而集中式缓存只能进行一次。对于较小的对象，这可能很好，但是如果您要缓存的东西确实要花费大量时间，或者服务的资源非常有限，那么使用集中式缓存会更加高效。
无论如何，Azure功能级别中的缓存仍会减少负载，并且没有必要在不需要时发出请求。
要回答您的sql问题，是的，很可能SQL Server也会对其进行缓存，但是您的azure函数仍然需要建立与sql server的连接，发出请求并终止该连接。
答案 1 :(得分：0)
Azure functions best practices指出函数应该是无状态的，并且您的状态信息应该与数据一起使用。我认为Redis仍然是比SQL更好的选择。