您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

开发

连接复原能力和服务器负载

开发客户端应用程序时,请务必考虑与连接复原能力管理服务器负载相关的最佳做法。

考虑更多键和较小的值

Azure Cache for Redis 的值越小,效果最佳。 请考虑将较大的数据块划分为较小的区块,以将数据分布到多个键。 有关理想值大小的详细信息,请参阅这篇文章

请求或响应大小过大

请求/响应过大可能导致超时。 例如,假设你在客户端上配置的超时值为 1 秒。 你的应用程序(使用相同的物理网络连接)的同时请求两个键 (例如,A 和 B)。 大多数客户端支持对请求进行“管道操作”,使得请求“A”和“B”可以逐个发送,而无需等待响应。 服务器会按相同顺序将响应发送回来。 如果响应“A”较大,可能会消耗掉后续请求的大部分超时时间。

在以下示例中,请求“A”和“B”快速发送到服务器。 服务器开始快速发送响应“A”和“B”。 由于数据传输需要时间,即使服务器的响应速度很快,响应“B”也必须等到响应“A”超时。

|-------- 1 Second Timeout (A)----------|
|-Request A-|
     |-------- 1 Second Timeout (B) ----------|
     |-Request B-|
            |- Read Response A --------|
                                       |- Read Response B-| (**TIMEOUT**)

此请求/响应很难度量值。 可对客户端代码进行检测,以跟踪大型请求和响应。

针对大型响应的解决方法各不相同,但是包括:

  • 优化应用程序以处理大量的小值,而不是处理少量的大值。
  • 增大 VM 的大小以获得更高的带宽能力
    • 提高客户端或服务器 VM 上的带宽可以缩短较大响应的数据传输时间。
    • 将两台计算机上的网络用量与当前 VM 大小的限制进行比较。 只提高服务器上的带宽,或者只提高客户端上的带宽,都不足以解决问题。
  • 增加应用程序使用的连接对象数。
    • 使用轮询方法通过不同的连接对象发出请求。

键分布

如果计划使用 Redis 聚类分析,请先阅读针对键的 Redis 聚类分析最佳做法

使用管道

尝试选择支持 Redis 管道的 Redis 客户端。 管道有助于高效利用网络并尽可能获取最佳吞吐量。

避免高开销的操作

某些 Redis 操作(如 KEYS 命令)开销很高,应避免使用。 有关长时间运行命令的一些注意事项,请参阅长时间运行的命令

选择适当的层级

对生产系统使用标准层或高级层。 请勿在生产环境中使用基本层。 基本层是没有数据复制和 SLA 的单节点系统。 此外,使用至少一个 C1 缓存。 C0 缓存仅适用于简单的开发/测试方案,原因如下:

  • 它们共享一个 CPU 核心
  • 使用少量内存
  • 容易出现“近邻干扰”问题

建议进行性能测试以选择适当的层级,并验证连接设置。 有关更多信息,请参阅性能测试

客户端与缓存位于同一区域

将缓存实例和应用程序定位在同一区域中。 连接到不同区域中的缓存可能会明显提高延迟并降低可靠性。

虽然可以从 Azure 外部进行连接,但不建议这样做,尤其是使用 Redis 作为缓存时。 如果仅将 Redis 服务器用作键/值存储,那么延迟可能不是主要问题。

使用 TLS 加密

默认情况下,Azure Cache for Redis 要求使用 TLS 加密通信。 目前支持 TLS 版本 1.0、1.1 和 1.2。 但是,TLS 1.0 和 TLS 1.1 即将在全行业范围内弃用,因此,请尽可能使用 TLS 1.2。

如果客户端库或工具不支持 TLS,则可通过 Azure 门户管理 API 来启用未加密的连接。 在无法加密连接的情况下,建议将缓存和客户端应用程序放入虚拟网络中。 有关虚拟网络缓存方案中使用的端口的详细信息,请参阅此

特定于客户端库的指南

后续步骤