我正在开发一个具有网络作业和天蓝色功能应用程序的应用程序。 Web 作业生成 redis 缓存供函数应用使用。缓存大小约为 10 兆字节。我正在使用延迟加载，一切都按照建议。我仍然发现整体缓存操作很慢。根据我正在处理的文件的大小，我最终可能会调用 Redis 缓存多达 100,000 次。想知道我是否需要将缓存数据保存在本地变量中，而不是每次都从 redis 中读取。有没有人在访问 Redis 时遇到过任何延迟？在 c# 函数应用程序中创建一个单例对象并根据某些计时器或其他逻辑刷新它是否有意义？
【问题讨论】：
您能否在使用中考虑这一点？这是 azure redis cashe 的一些良好实践
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 较高的条件下，系统也有时间进行连接。如果您的客户端或服务器往往处于高负载状态，请使用更大的值。如果您在单个应用程序中使用大量连接，请考虑添加某种类型的交错重新连接逻辑，以防止大量连接同时访问服务器。
【讨论】：