我正在开发一个具有Web作业和Azure功能的应用程序。 Web作业生成Redis缓存供功能应用程序使用。缓存大小约为10兆字节。我正在使用延迟加载，并且全部按照建议进行。我仍然发现总体缓存操作很慢。根据我正在处理的文件的大小，我可能最终调用Redis缓存多达100,000次。想知道是否需要将缓存数据保存在本地变量中，而不是每次都从redis读取数据。是否有人在访问Redis时遇到任何延迟？在c＃函数应用中创建单调对象并根据某些计时器或其他逻辑刷新它是否有意义？
答案 0 :(得分：2)
您能在使用中考虑这一点吗？这是天蓝色兑现的一些好习惯
Redis在较小的值上效果最好，因此请考虑将较大的数据分成多个键。在此Redis discussion中，100kb被视为“大”。阅读this article，了解可能由大值引起的示例问题。
对生产系统使用标准层或高级层。基本层是没有数据复制和SLA的单节点系统。另外，至少使用C1缓存。 C0缓存确实具有简单的开发/测试场景，因为它们具有共享的CPU核心，很少的内存，容易出现“嘈杂的邻居”等。
请记住，Redis是内存中的数据存储。以便您了解可能发生数据丢失的情况。
重用连接-创建新连接非常昂贵，并且增加了延迟，因此请尽可能重用连接。如果选择创建新连接，请确保在释放旧连接之前将其关闭（即使使用.NET或Java等托管内存语言也是如此）。
将缓存实例和应用程序定位在同一区域。连接到不同区域中的缓存可能会大大增加延迟并降低可靠性。支持从Azure外部进行连接，但不建议特别使用Redis作为缓存（与键/值存储相反，延迟可能不是主要问题）。
Redis在较小的值上效果最好，因此请考虑将较大的数据分成多个键。
配置您的maxmemory-reserved设置以提高系统响应速度（在内存压力大的情况下），尤其是对于写繁重的工作负载或在Redis中存储较大的值（100KB或更大）的情况。我建议您从缓存大小的10％开始，如果有大量写入负载，则建议增加缓存大小。选择值时，请参见some considerations。
避免使用昂贵的命令-一些redis操作（例如“ KEYS”命令）非常昂贵，应避免使用。
将您的客户端库配置为使用至少10到15秒的“连接超时” ，即使在更高的CPU条件下，系统也有时间进行连接。如果您的客户端或服务器负载较高，请使用更大的值。如果在单个应用程序中使用大量连接，请考虑添加某种交错的重新连接逻辑，以防止大量连接同时击中服务器。