caching - Azure Redis 缓存延迟

Question

我正在开发一个具有网络作业和天蓝色功能应用程序的应用程序。Web 作业生成 redis 缓存供函数应用使用。缓存大小约为 10 兆字节。我正在使用延迟加载，一切都按照建议。我仍然发现整体缓存操作很慢。根据我正在处理的文件的大小，我最终可能会调用 Redis 缓存多达 100,000 次。想知道我是否需要将缓存数据保存在本地变量中，而不是每次都从 redis 中读取。有没有人在访问 Redis 时遇到过任何延迟？在 c# 函数应用程序中创建一个单例对象并根据某些计时器或其他逻辑刷新它是否有意义？

标签： cachingredis

Answer 1

您能否在使用中考虑这一点？这是 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 条件下也可以为系统提供连接时间。如果您的客户端或服务器往往处于高负载状态，请使用更大的值。如果您在单个应用程序中使用大量连接，请考虑添加某种类型的交错重新连接逻辑，以防止大量连接同时冲击服务器。