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